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
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（ユーザ・データグラム・プロトコルライト）、UDP / IPを圧縮ROHC（ロバストヘッダ圧縮）プロファイルを指定します、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の（ユーザ・データグラム・プロトコルライト）ヘッダ[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 RTP / UDP / IP：UDP / IP Oプロファイル0x0101：ESP / IP Oプロファイル0x0102：IP Oプロファイル0x0103：RTP / UDP-Liteの/ IP Oプロファイル0x0104：0x0107 O UDP-Liteの/ IPをプロファイル：プロファイル0x0108
Each of the profiles above can compress the following type of extension headers:
プロファイルのそれぞれは、上記拡張ヘッダの次のタイプを圧縮することができます。
o AH [RFC4302]
AH [RFC4302]
o GRE [RFC2784][RFC2890]
GRE [RFC2784] [RFC2890]
o MINE [RFC2004]
O MINE [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.
初期化および更新（IR）ヘッダタイプ、および圧縮（CO）ヘッダタイプ：ROHCv2プロファイルは、二つの異なるヘッダタイプを使用します。
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つのまたはいくつかのパケットの前にデコンプレッサに到達するパケット。順次早期パケットの到着時には、リンクに遅れたパケット（複数可）失われたパケット（複数可）と区別することはできません。
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パケット間のタイムスタンプ値の予想増加です。例えば、一つのフレーム20ms毎の製造は8kHzのサンプルレートを有するメディア符号化のために、RTPタイムスタンプは、典型的には、ある整数nについて、n個の* 160（= * 0.02 8000）によって増加します。
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）は、一つ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認証ヘッダー。 ESPカプセル化セキュリティペイロード。 GRE総称ルーティングカプセル化。 FC完全なコンテキスト状態（減圧装置）。 IPインターネットプロトコル。 LSB最下位ビット。 IPでのMINE最小カプセル化。 MSB最上位ビットが。 MSNマスターシーケンス番号。 NCいいえ文脈状態（デコンプレッサ）。 OA楽観的アプローチ。 RC修理Context状態（デコンプレッサ）。 ROHCヘッダ圧縮フレームワーク（RFC 4995）。この文書で定義されたヘッダ圧縮プロファイルのROHCv2セット。 RTPリアルタイムトランスポートプロトコル。 SSRC同期ソース。 RTPヘッダ内のフィールド。 CSRCは、ソースを貢献します。 RTPヘッダは、寄与ソースのオプションのリストを含みます。 TCトラフィッククラス。 IPv6ヘッダーのフィールド。また、TOSを参照してください。サービスのTOSタイプ。 IPv4ヘッダ内のフィールド。また、TCを参照してください。 TS RTPタイムスタンプ。生きるためのTTL時間。 IPv4ヘッダ内のフィールド。 UDPユーザーデータグラムプロトコル。 UDP-Liteのユーザーデータグラムプロトコル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フレームワークの基本は、それぞれ、セクション3と[RFC4995]の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.
リストを付録し、詳細にこのドキュメントに関連するすべてのヘッダフィールドを分類します。付録では、様々なフィールドは、ヘッダ圧縮アルゴリズムによって処理されるべき方法に関する推奨事項と結論します。
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のチェックサム（16ビット） - チェックサム - UDP-Liteのチェックサム・カバレッジ（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光源によって放出された各パケットについて1ずつインクリメントRTPシーケンス番号（SN）と強い相関を持っていることがわかります。 RTP Mビットは、ほとんどの時間を同じ値を持つことが期待されるが、それは機会に明示的に通信する必要があります。
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.
（IPv6で必須）有効な場合であるとして、UDPのチェックサムフィールドは推測できない、または受信端に再計算され、そのエンド・ツー・エンドの特性に違反することなく、従って、送信されます。 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の場合と同様の相関は、しばしば（例えば、RTP SNはRTPヘッダーを圧縮するとき）は、圧縮のために使用される識別子フィールド（IP-ID）、マスタシーケンス番号（MSN）との間に観察され。
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]と少なくとも同等である圧縮効率およびロバスト性を達成することができます。具体的には、最小の圧縮ヘッダのサイズとビットレイアウト（即ち、ROHCv2でRFC 3095、及びpt_0_crc3におけるPT-0フォーマットU / O-0）が同一です。
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:
RFCこのセクションでは、最も重要な改善点のいくつかの概要を説明します3095.で定義されたこの文書で定義されたプロファイルとその以前のバージョンとの違いや改善点がいくつかあります：
Tolerance to reordering
並べ替えに対する耐性
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.
RFC 3095で定義されたプロファイルは、コンプレッサとデコンプレッサとの間のチャネルは、圧縮エンドポイント間での順序配信を提供することを必要とします。 ROHCv2プロファイルは、しかしながら、圧縮アルゴリズム自体の一部として圧縮点後堅牢かつ効率的に並べ替えの限られた量を扱うことができます。また、並べ替えのために、このサポートが改善され、それが可能ROHCv2プロファイルがより効率的にprelinkの並べ替えを処理できるようになります。
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でプロファイルは、異なる更新ロジックおよび圧縮ヘッダフォーマットの各々を複数の動作モードを定義します。フィードバックは、第1の双方向動作が使用される時点でコンテキスト（CID）のために受信されるまでROHCv2プロファイルは、一方向の操作で動作します。フォーマットは、動作ロジックが使用されているものとは無関係です。
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でのプロファイルは、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.
これはRFC 3095に比べRFC 3095.またROHCv2に使用されるフィードバック・オプションの異なるセットにおいて任意であるがROHCv2は、FEEDBACK-2のフォーマットでCRCを強制プロファイル。
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.
ヘッダ圧縮は、解凍器状態機械、コンテキストごとに有する圧縮機との相互作用として概念的に特徴づけることができます。コンプレッサーの責任が正常にデコンプレッサのコンテキストの状態に関する一定の信頼に基づいてパケットを、解凍するために必要な情報を伝えることです。
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を参照）から、解凍器から受信されます。
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.
ほとんど変化しないため、LSB符号化されたフィールド[RFC4997]、および楽観アプローチのために使用されるスライディング・ウィンドウのオフセット解釈インターバル（セクション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符号化のみ、そのフィールドに由来する他の順次変更フィールドの（暗黙的に）それが圧縮そのフィールドの堅牢性を提供し、。
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の情報のみが解凍器に搬送する必要がある場合、トレードオフは、圧縮の数に関する
MSN bits in the compressed header format. Otherwise, the tradeoff relates to the implementation of the optimistic approach.
圧縮されたヘッダフォーマットで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.
圧縮された流れのための第1の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を、STATIC-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）又は完全なコンテキスト更新（STATIC-NACK）のための明示的な要求を送るかもしれません。しかし、デコンプレッサは、失敗の原因を特定するための手段を持っていない、特にどのようなフィールド（複数可）の解凍には、失敗の責任があります。コンプレッサはヘッダを圧縮するときに使用する圧縮ヘッダの種類を選択するとき、それは解凍器コンテクストの状態で持っている信頼を使用して、常にこのように否定応答に最も適切な応答を決定する責任があります。
The decompressor normally uses the last received and successfully validated (IR packets) or verified (CO packets) header as the reference for future decompression.
減圧装置は、通常、将来の復元のための基準として最後に受信に成功（COパケット）（IRパケット）検証又は検証ヘッダを使用します。
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の存在を使用して検証されます。デコンプレッサは、この結果が正常に検証されたコンテキスト情報を更新します。デコンプレッサは、圧縮されたフローのために一度のフィードバックを使用している場合、最終的に、それは限り、対応するコンテキストが同じプロファイルに関連付けられているようのためにそうしていきます。
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ヘッダが正常に検証されている場合、デコンプレッサは、コンテキストを更新し、基準ヘッダとしてヘッダを使用し、FC状態に移行します。デコンプレッサ・ステート・マシンは、FC状態に入ると、それが正常に残していません。だけ繰り返し減圧障害が低い状態に遷移下方にデコンプレッサを強制します。コンテキストの損傷が検出された場合、デコンプレッサは、それが正常に7ビットのCRCを有するか、正常IRヘッダを検証するまで圧縮されたヘッダの復元の試みを確認するまで、それがまま修理コンテキスト（RC）状態に移動します。静的コンテクスト損傷が検出されると、減圧装置は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許可されていません：デコンプレッサは、デコンプレッサの現在のコンテキストがパケットを解凍するのに十分な有効な状態情報を提供しないためにパケットタイプ（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.
いいえコンテキスト（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.
IR以外のタイプのパケットを受信した場合NC状態において、圧縮解除装置はSTATIC-NACKを送信しなければならない、またはIRヘッダは、フィードバックレートの制限を受けるCRC-8検証に失敗した場合は、セクション5.2に記載されているように。 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.
RC状態では、唯一のヘッダは、8ビットのCRC（即ち、IR）によって覆われ又は7ビットのCRCを運ぶCOヘッダを解凍することができます。
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.
CRC検証が7ビットのCRC場合やIRヘッダ内の8ビットCRCの検証が成功を運ぶCOヘッダの成功したときにデコンプレッサがフルコンテキスト（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.
IRヘッダのCRC-8検証が失敗した、または7ビットのCRCを運ぶCOヘッダが失敗したときに静的コンテクスト損傷がフィードバックレート制限などを受け、想定される場合にRC状態において、圧縮解除装置はSTATIC-NACKを送信しなければなりません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検証が失敗したときにデコンプレッサは、NACKを送信しなければならない、または静的コンテクスト損傷が想定される場合にはSTATIC-NACKを送信しなければなりません。これは、セクション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障害または何のフィールドの正確な理由（s）は、それを引き起こし知ることができないので、コンテキストの有効性は、それゆえ有効とするかしない文脈の特定のどの部分（複数可）を指すものではありません。
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を運ぶ、そしてのみCRC-7によって保護IRヘッダまたはCOヘッダの解凍を試みる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フィードバックチャネルが利用可能であり、このチャネルは、特定のコンテキストのための減圧装置によって少なくとも一度使用された場合、このチャネルは、その文脈（すなわち、双方向動作）のための全体の圧縮動作中に使用される場合と仮定しています。
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.
ACK、NACKの、及びSTATIC-NACKを：ROHCフレームワークは、フィードバック・メッセージの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を送信する必要があり、それが静的コンテクストダメージを前提としていたときには、STATIC-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チャネルの構成は、内の少なくとも1つのROHCv2プロファイルが含まれている場合、ROHCセグメンテーション（[RFC4995]のセクション5.2.5を参照）、すなわち、最大再構築受信部（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.
コンプレッサーは、常にそれが新しいコンテキスト（セクション5.1.1における新しいコンテキストの定義を参照の初期化を行う際にデコンプレッサは、フィードバックを送信しないという前提で始まる。の[RFC4995]は、つまりは、ための確立フィードバックチャネルが存在しません。減圧装置がパケットを正しく解凍するのに十分な情報を受信していないかもしれないので、新しいコンテキストは、この時点で、楽観的アプローチの使用にもかかわらず、減圧障害が依然として可能であり、減圧装置がフィードバックチャネルを確立するまで、したがって、圧縮機は、定期的にSHOULD 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）または負のフィードバック（のNACK又はSTATIC-NACK信号）のいずれかの受信フィードバックを受信したのコンテキスト（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）または負のフィードバック（のNACK又はSTATIC-NACK信号）のいずれかがこのチャネルを確立します。それは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）フィールドがいずれかの既にプロファイル圧縮（例えば、RTP SN）、あるいはそれは圧縮機で作成されているプロトコルのヘッダーの1つに存在するフィールドから取られます。コンテキストごとに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).
（例えば、IPv4の識別子）インクリメントフィールドの値を推測O。
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は常に圧縮機によって送信される各ヘッダ・タイプに存在します。それはLSB COヘッダフォーマット内で符号化することができるがMSNは、IRヘッダに完全に送信されます。減圧装置が常にフィードバックに確認応答番号フィールドに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;
そのコンテキストが最初に作成されたとき、またはプロファイルがコンテキストの変更に関連付けられている場合、圧縮機のみコンテキストのMSNを初期化し、O。
o When the MSN is initialized, it is initialized to a random value;
MSNが初期化されると、O、それがランダムな値に初期化されます。
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.
IPヘッダーの複数のレベルを圧縮するときROHCv2プロファイルは、最も内側のIPヘッダ内の任意のIP-IDにシーケンシャル動作（ネットワークバイト順またはバイトスワップ）が、1つを割り当ててはいけません。最も内側の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.
制御フィールドcoverage_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ヘッダの完全性を検証する必要があります。ヘッダが検証された場合、デコンプレッサは、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ヘッダから開始し、圧縮されたプロトコルヘッダの鎖の各ヘッダのための一つの項目から成ります。ヘッダフォーマットの形式的記述では、各ヘッダタイプについて、この静的チェーン項目は<です。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ヘッダから開始し、圧縮されたプロトコルヘッダの鎖の各ヘッダのための一つの項目から成ります。ヘッダフォーマットの形式的記述では、各ヘッダタイプのダイナミックチェーン項目は<です。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節の一般的なフォーマットを使用する各圧縮ヘッダのために、不規則な鎖は、圧縮ヘッダの一般的な形式の特定の位置に付加されます。ヘッダフォーマットの形式的記述では、各ヘッダタイプの不規則なチェーン項目は、名前が「_irregular」サフィックスされるフォーマットです。不規則な鎖は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ヘッダに使用される形式とは異なります。正式な表記法を使用して、ヘッダ・フォーマットの定義において、対応する符号化方式（IPv4またはIPv6）に渡される引数「is_innermost」は、不規則なチェーンアイテムを使用するかを決定します。外側IPヘッダの不規則なチェーン・アイテムのフォーマットは、TTL /ホップリミット及び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]、AH [RFC4302]に圧縮することができ、すべてのヘッダーのチェーンを定義します、GRE [RFC2784]、[RFC2890]、MINE [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符号化方法に、構文的に正しいヘッダ・フォーマットの定義を維持することが必要です。これは、トンネルIPヘッダおよびCOヘッダのそれぞれの拡張ヘッダ（すなわち、すべてのヘッダは、最も内側の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長フィールドはサブヘッダの前の長さフィールド（複数可）と一致していることを確認する必要があり、すなわち、IP長によって覆われているUDPペイロードの後に、任意のパディングがあってはなりません。
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ビットワードの1の補数和の16ビットの1の補数です。チェックサムを計算する目的のために、チェックサムフィールドの値はゼロです。
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.
inferred_ip_v4_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ビットワードの1の補数和の16ビットの1の補数。チェックサムを計算する目的のために、チェックサムフィールドの値は0（最小の転送ヘッダの後）IPヘッダとIPペイロードこのチェックサムの計算に含まれないのです。
The inferred_mine_header_checksum encoding method compresses the minimal encapsulation header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation.
inferred_mine_header_checksum符号化方法は、ダウンゼロビットのサイズに最小限のカプセル化ヘッダチェックサムを圧縮する、すなわち、何ビットがこのフィールドの圧縮ヘッダで送信されません。この符号化方法を使用して、解凍装置は、上記の計算を使用して、このフィールドの値を推定します。
The motivations for inferring this checksum are similar to the ones explained above in Section 6.6.4.
このチェックサムを推測するための動機は、セクション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.
inferred_ip_v4_length符号化方法は、ダウンゼロビットのサイズに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ヘッダ内のペイロード長フィールドを圧縮します。次のように、このlengthフィールドは、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.
「inferred_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の値を更新します。
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のinferred_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と共に基準値として使用されます。
ts_scaled =:= timer_based_lsb(<time_stride_param>, <num_lsbs_param>, <offset_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ビットを使用して適用された圧縮ヘッダで受信し、（[RFC4997]のセクション4.11.5による）「ref_value」としてtsc_ref_advanced。
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はtimer_based_lsb方法がCOヘッダに使用されているか否かを制御します。デコンプレッサは、次の場合、ゼロ値で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:
inferred_scaled_field符号化方法は、MSNに関連して変化として定義されているフィールドを符号化し、そのためMSNに対して増加は、いくつかのスケーリングファクタによってスケーリングすることができます。この符号化方法は、スケーリングされたフィールドのいずれかのビットが含まれていない圧縮ヘッダフォーマットで使用されています。この場合、デコンプレッサは、MSNのフィールドからのスケーリングされたフィールドのスケールなしの値を推定します。スケーリングされていない値は、以下の式に従って計算されます。
unscaled_value = delta_msn * stride + reference_unscaled_value
unscaled_value = delta_msn *ストライド+ 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の値は、このパケットの解凍、「reference_unscaled_value」は文脈でスケーリングされたフィールドの値であり、「ストライド」である場合このフィールドのスケーリング値。
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
タイムスタンプ= 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を提供します。この符号化方式の定義は、「CRC」の差がCRCによって覆われたデータは、制御フィールドの連結リストによって与えられることがあると、[RFC4997]のセクション4.11.6に指定された符号化方式の場合と同じです。
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 { }
control_crc_encoding（ctrl_data_value、ctrl_data_length）{UNCOMPRESSED {}
COMPRESSED { control_crc3 =:= crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ]; } }
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
reorder_ratio O、2ビットがゼロの6 MSBで埋め
o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)
（のみプロファイル0x0101と0x0107のための）TS_STRIDE O、32ビット
o time_stride, 32 bits (only for profiles 0x0101 and 0x0107)
（のみプロファイル0x0101と0x0107のための）time_stride O、32ビット
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)
coverage_behavior O、2ビット（のみプロファイル0x0107と0x0108のための）ゼロの6 MSBで埋め
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.
減圧装置はco_commonとco_repairヘッダフォーマットによって更新された制御フィールドを検証するために、得られた3ビットのCRCを使用します。この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-7検証によって保護されていないので、このCRCは、制御フィールドの更新を保護します。これはco_repair co_commonのかの解凍が成功し、何らかの理由で制御フィールドが正しく更新されている間、デコンプレッサは、正のフィードバックを送信する場合に発生可能性障害を防ぐことができます。
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ビットが存在しない場合。この場合、IP-IDは一定であり、かつ（inferred_scaled_field符号化方法に類似）MSNと同じ量だけIP-IDが増加MSNからのオフセット。
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の非圧縮値との差であり、ここで「reference_IP_ID_value」は文脈におけるIP-IDの値である。ここでスワップIP-IDの動作のために（すなわち、ip_id_behavior_innermostがIP_ID_BEHAVIOR_SEQUENTIAL_SWAPPEDに設定されている場合）、「reference_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フィールドの値です。デコンプレッサは、デコンプレッサが正しく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リストにリスト圧縮を行う場合、各項目は、一つ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.
減圧装置は概念的に受信されたすべての（インデックス、項目）対を含む項目テーブルを維持します。 （インデックス、項目）対を受信し、解凍が成功しているときはいつでもアイテムテーブルは、（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：メートルの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リストに送信されることを示します。
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においてX = 1とXIに対応...、XI mを。アイテムのリストの各エントリは、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個の異なるアイテムに制限されます。項目がIN /項目テーブルのスワップアウトされたときにアイテムテーブルに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)
udp_lite O（profile_value、reorder_ratio_value、coverage_behavior_value）
o esp(profile_value, reorder_ratio_value)
ESP O（profile_value、reorder_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、reorder_ratio_value））
o ipv6(profile_value, is_innermost, outer_ip_flag, reorder_ratio_value))
入出力のIPv6（profile_value、is_innermost、outer_ip_flag、reorder_ratio_value））
o iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
O iponly_baseheader（profile_value、outer_ip_flag、ip_id_behavior_value、reorder_ratio_value）
o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
udp_baseheader O（profile_value、outer_ip_flag、ip_id_behavior_value、reorder_ratio_value）
o udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
udplite_baseheader O（profile_value、outer_ip_flag、ip_id_behavior_value、reorder_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、reorder_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、reorder_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)
udplite_rtp_baseheader O（profile_value、ts_stride_value、time_stride_value、outer_ip_flag、ip_id_behavior_value、reorder_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.
以下、下記のすべてのパラメータに適用される圧縮機では、パラメータの値は、各パラメータの推奨に従って設定されています。デコンプレッサでは、パラメータの値はundefinedに設定されており、特に断りのある場合を除き、符号化方式に拘束されます。
The following is a list of external arguments with their respective definition:
以下は、それぞれの定義と外部の引数のリストです：
o profile_value:
profile_value O：
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).
o reorder_ratio_value:
reorder_ratio_value O：
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.
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.
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.
o outer_ip_flag:
outer_ip_flag O：
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.
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.
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.
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.
ROHCv2 profiles use two different header types: the Initialization and Refresh (IR) header type, and the Compressed header type (CO).
初期化および更新（IR）ヘッダタイプ、および圧縮ヘッダタイプ（CO）：ROHCv2プロファイルは、二つの異なるヘッダタイプを使用します。
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ヘッダタイプは、ヘッダフォーマットの数を定義する：両方のセットに共通するいくつかの追加のフォーマットを有するベースヘッダーフォーマットの二組が存在します。
The IR header format uses the structure of the ROHC IR header as defined in Section 5.2.2.1 of [RFC4995].
[RFC4995]のセクション5.2.2.1で定義されるようにIRヘッダフォーマットは、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ヘッダオーバー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.
最も内側のIPヘッダは順次IP-ID（ネットワークバイト順のいずれかまたはバイトスワップ）を含有ヘッダーの一組、およびシーケンシャルIPせずにヘッダーの一組：圧縮ヘッダフォーマットは、各プロファイルのための2つの別個のセットとして定義され-ID（ランダムゼロ、または全くIP-IDのいずれか）。両方のセットの間で共有される共通ヘッダフォーマットの数もあります。以下の説明では、シーケンシャルセットに属するヘッダ・フォーマットのために使用される命名規則は、同様に「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延長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.
co_repair O：このフォーマットは、その圧縮されていない値を搬送することにより、すべての動的フィールドの内容を更新するために使用することができます。コンテキストの損傷が想定される（例えば、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].
pt_0_crc3 O：このフォーマットはMSNを伝えます。従ってのみ（該当するプロファイルの場合）、このようなIP-IDとしてMSN、およびRTPタイムスタンプから導出され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].
pt_1_rnd O：このフォーマットは、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].
pt_1_seq_ts O：このフォーマットは、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].
pt_2_rnd O：このフォーマットは、RTPマーカビットへ、及びRTPタイムスタンプに、MSNへの変更を伝えることができます。これは、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].
pt_2_seq_ts O：このフォーマットは、RTPマーカビットに、MSNへの変更を伝えることができ、それは、スケーリングされたタイムスタンプ符号化を使用して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].
pt_2_seq_both O：このフォーマットは、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は、DATA_VALUE全体非圧縮ヘッダ鎖に対応し、ここでは、DATA_LENGTHの長さに対応するセクション6.8.2.4で定義されこのヘッダーチェーン。
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>以下の表に定義されている<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.
//注：不規則な静的および動的鎖（セクション6.5を参照）//複数の符号化方法を横切って定義され、それらの符号化//方法以内対応命名形式で//具現化されます。具体的には、静的および動的//鎖は通常、一緒に行くことに注意してください。圧縮されていないフィールドは、//むしろ1 //またはそれらの他に比べて、組み合わせこれら二つのフォーマット間で定義されています。不規則なチェーン項目は、同様に// baseheader形式と組み合わされます。
//////////////////////////////////////////// // 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;
//////////////////////////////////////////// // 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: ///////////////////////////////////////////////
/////////////////////////////////////////////// //エンコーディングFNの構文で指定されていない方法：/////////////////////////////////////////// ////
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 ]; }
static_or_irreg（フラグ、幅）{UNCOMPRESSED {フィールド[幅]。 }
COMPRESSED irreg_enc {
ENFORCE(flag == 1);
field =:= irregular(width) [ width ];
}
COMPRESSED static_enc {
COMPRESSED static_enc {
ENFORCE(flag == 0);
field =:= static [ 0 ];
}
}
optional_32(flag) { UNCOMPRESSED { item [ 0, 32 ]; }
optional_32（フラグ）{UNCOMPRESSED {アイテム[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 ]; }
//値全体を送ったり、前回値sdvl_or_static（フラグ）{UNCOMPRESSED {フィールド[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 ]; }
//値全体を送信するか、またはデフォルト値sdvl_or_default（フラグ、DEFAULT_VALUE）{UNCOMPRESSED {フィールド[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 ]; }
lsb_7_or_31 {UNCOMPRESSED {項目[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 ]; } }
UNCOMPRESSED {} COMPRESSED {crc_value =：= CRC（3、0x06で、0x07の、DATA_VALUE、DATA_LENGTH）[3]。 }}
crc7(data_value, data_length) { UNCOMPRESSED { }
CRC7（DATA_VALUE、DATA_LENGTH）{UNCOMPRESSED {}
COMPRESSED { crc_value =:= crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; } }
COMPRESSED {crc_value =：= CRC（7、0x79、0x7Fの、DATA_VALUE、DATA_LENGTH）[7]。 }}
// 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 }
スケールフィールドとそれに関連する//制御フィールドを更新するための//エンコーディング方法。値が圧縮形式で//スケーリングまたはスケーリングされていないれたときの両方に使用されるべきです。 //は圧縮されていない側面を持っていません。 field_scaling（stride_value、scaled_value、unscaled_value、residue_value）{UNCOMPRESSED {//なし}
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 ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6の宛先オプションヘッダー////////////////////////////////////////////
ip_dest_opt { UNCOMPRESSED {
ip_dest_opt {UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED dest_opt_dynamic { value =:= irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED dest_opt_dynamic {値=：=不規則（length.UVALUE * 64 + 48）[length.UVALUE * 64 + 48]。 }
COMPRESSED dest_opt_irregular { }
COMPRESSED dest_opt_irregular {}
}
｝
//////////////////////////////////////////// // IPv6 Hop-by-Hop options header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6のホップバイ-Hopオプションヘッダ////////////////////////////////////////////
ip_hop_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_dynamic { value =:= irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED hop_opt_dynamic {値=：=不規則（length.UVALUE * 64 + 48）[length.UVALUE * 64 + 48]。 }
COMPRESSED hop_opt_irregular { }
COMPRESSED hop_opt_irregular {}
}
｝
//////////////////////////////////////////// // IPv6 Routing header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6ルーティングヘッダ/ ///////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED rout_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED rout_opt_dynamic { }
COMPRESSED rout_opt_dynamic {}
COMPRESSED rout_opt_irregular { } }
COMPRESSED rout_opt_irregular {}}
//////////////////////////////////////////// // GRE Header ////////////////////////////////////////////
//////////////////////////////////////////// // GO //ヘッダー//////////////////////////////////////////
optional_lsb_7_or_31(flag) {
optional_lsb_7_or_31（フラグ）{
UNCOMPRESSED { item [ 0, 32 ]; }
UNCOMPRESSED {アイテム[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 ]; }
gre_proto {UNCOMPRESSED {プロトコル[16]。 }
COMPRESSED ether_v4 {
discriminator =:= '0' [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
}
COMPRESSED ether_v6 { discriminator =:= '1' [ 1 ];
COMPRESSED ether_v6 {弁別=：= '1' [1]。
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; } }
プロトコル=（0x86DD、16）= uncompressed_value [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 {
COMPRESSED gre_irregular {
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ヘッダ/ ////////////////////////////////////////////
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_dynamic {}
COMPRESSED mine_irregular { } }
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 /////////////////////////////////////////////
///////////////////////////////////////////// // IPv6のヘッダ/ ////////////////////////////////////////////
fl_enc { UNCOMPRESSED {
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); }
COMPRESSED ipv6_innermost_irregular {（== 1 is_innermost）ENFORCE。 }
}
｝
///////////////////////////////////////////// // IPv4 Header /////////////////////////////////////////////
///////////////////////////////////////////// // IPv4のヘッダ/ ////////////////////////////////////////////
ip_id_enc_dyn(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
ip_id_enc_dyn（挙動）{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 ]; }
ip_id_enc_irreg（挙動）{UNCOMPRESSED {ip_id [16]。 }
COMPRESSED ip_id_seq { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); }
COMPRESSED ip_id_seq {（動作== IP_ID_BEHAVIOR_SEQUENTIAL）をENFORCE。 }
COMPRESSED ip_id_seq_swapped { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); }
COMPRESSED ip_id_seq_swapped {（動作== IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED）ENFORCE。 }
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 ];
IPv4の（profile_value、is_innermost、outer_ip_flag、ip_id_behavior_value、reorder_ratio_value）{UNCOMPRESSED {バージョン= = 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 /////////////////////////////////////////////
///////////////////////////////////////////// // RTPヘッダー/ ////////////////////////////////////////////
csrc_list_dynchain(presence, cc_value) { UNCOMPRESSED { csrc_list; }
csrc_list_dynchain（プレゼンス、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_static {SSRC =：=不規則（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 { } }
COMPRESSED RTP不規則{}}
///////////////////////////////////////////// // UDP-Lite Header /////////////////////////////////////////////
///////////////////////////////////////////// // UDP-Liteのヘッダー/////////////////////////////////////////////
checksum_coverage_dynchain(behavior) { UNCOMPRESSED { checksum_coverage [ 16 ]; }
checksum_coverage_dynchain（挙動）{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 ]; }
checksum_coverage_irregular（挙動）{UNCOMPRESSED {checksum_coverage [16]。 }
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED static_coverage {
COMPRESSED 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ヘッダ/ ////////////////////////////////////////////
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_static {SPI =：=不規則（32）[32]。 }
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= irregular(2) [ 2 ];
}
COMPRESSED esp_irregular { } }
COMPRESSED esp_irregular {}}
/////////////////////////////////////////////////// // Encoding methods used in the profiles' CO headers ///////////////////////////////////////////////////
//////////////////////////////////////////////////プロファイルCOヘッダーで使用/ //エンコード方法////////////////////////////////////// /////////////
// Variable reordering offset used for MSN msn_lsb(k) { UNCOMPRESSED { master [ VARIABLE ]; }
MSNのmsn_lsb（K）{UNCOMPRESSED {マスタ[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 ]; }
ip_id_lsb（挙動、K）{UNCOMPRESSED {ip_id [16]。 }
CONTROL { ip_id_nbo [ 16 ]; }
CONTROL {ip_id_nbo [16]。 }
COMPRESSED nbo { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
COMPRESSED NBO {（動作== IP_ID_BEHAVIOR_SEQUENTIAL）ENFORCE。
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 ]; }
ip_id_sequential_variable（挙動、インジケータ）{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)); } }
COMPRESSED NOT_PRESENT {ENFORCE（（挙動== IP_ID_BEHAVIOR_RANDOM）||（動作== IP_ID_BEHAVIOR_ZERO））。 }}
dont_fragment(version) { UNCOMPRESSED { df [ 0, 1 ]; }
dont_fragment（バージョン）{UNCOMPRESSED {[1,0] DF。 }
COMPRESSED v4 {
TSOMPRESSED RF {
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 ]; }
pt_irr_or_static（フラグ）{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; }
csrc_list_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 {
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 ]; }
//自己記述並べ替えオフセットsdvl_sn_lsb（field_width）と可変長符号化を{UNCOMPRESSED {フィールド[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 ]; }
//自己記述可変長符号化sdvl_lsb（field_width）{UNCOMPRESSED {フィールド[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 ]; }
sdvl_scaled_ts_lsb（time_stride）{UNCOMPRESSED {フィールド[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 ]; }
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))); } }
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 ]; }
variable_unscaled_timestamp（tss_flag、tsc_flag）{UNCOMPRESSED {タイムスタンプ[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));
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プロファイル// //////////////////////////////////////////
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 {
UNCOMPRESSED 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);
DEFAULT {（== 0 outer_ip_flag）ENFORCE。
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交換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 profile ////////////////////////////////////////////
//////////////////////////////////////////// // UDPプロファイル// //////////////////////////////////////////
udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value) { UNCOMPRESSED v4 { outer_headers =:= baseheader_outer_headers [ VARIABLE ];
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ビットCOMPRESSED pt_0_crc7とタイプ0 {
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プロファイル// //////////////////////////////////////////
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 ////////////////////////////////////////////
//////////////////////////////////////////// // IP-のみのプロフィール////////////////////////////////////////////
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 ////////////////////////////////////////////
//////////////////////////////////////////// // UDP-LITE / RTPプロファイル////////////////////////////////////////////
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);
UNCOMPRESSED V6 {ENFORCE（ip_id_behavior innermost.UのVALUE == 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 ////////////////////////////////////////////
//////////////////////////////////////////// // UDP-liteのプロフィール////////////////////////////////////////////
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 ];
//新しいフォーマット、強いCRCよりSNビットCOMPRESSED pt_0_crc7 {識別器とタイプ0 =：= '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-有効でないオプションを運ばなければなりません。 FEEDBACK-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.
FEEDBACK-1がACKです。 NACK又はSTATIC-NACKを送信するために、FEEDBACK-2を使用しなければなりません。
FEEDBACK-2
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
Acktype：
0 = ACK
ACK = 0
1 = NACK
1 =鼻
2 = STATIC-NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
3は予約されている（parsabilityために使用してはいけません）
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：[RFC4995]のセクション5.3.1.1で定義された多項式を用いて、帰還型、「サイズ」フィールド、および「コード」オクテットの任意のCIDフィールドを含むが、除く全体フィードバックペイロードにわたって計算さ8ビットのCRC。 CIDは、アドインCIDのオクテットで指定された場合、アドインCIDオクテットは直ちにFEEDBACK-1またはFEEDBACK-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.
ACKNUMBER-VALID NOTオプション（セクション6.9を参照しない限り、FEEDBACK-2タイプのNACK又はSTATIC-NACKのは、常に、そのLSBをフィードバック素子の確認応答番号と一致するパケットに対応する正常解凍パケットのための暗黙の確認応答であります.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.
FEEDBACK-2フォーマットは、常にCRCを運び、したがって、より堅牢FEEDBACK-1フォーマットよりも長いです。 FEEDBACK-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.4通じ節6.9.2.1はROHCv2フィードバックオプションについて説明します。
Opt Len: Unsigned integer that represents the length of the Option Data field, in octets.
オクテット単位で、オプションデータフィールドの長さを表す符号なし整数。レンを選びます。
Option Data: Feedback type specific data. Present if the value of the Opt Len field is set to a non-zero value.
オプションデータ：フィードバックタイプ固有のデータ。本オプトLENフィールドの値がゼロ以外の値に設定されている場合。
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
REJECTオプションは、デコンプレッサは、フローを処理するのに十分なリソースを持っていないコンプレッサーを通知します。
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
REJECTオプションを受信すると、コンプレッサーは、パケットの流れを圧縮するのを止めなければなりませんし、圧縮されたパケットの数はいくつかの時間のためのフローを増加しようとするお控えください。 REJECTオプション
MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
一度FEEDBACK-2形式でより多く見えてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment Number field of the feedback is not valid.
ACKNUMBER-有効でないオプションは、フィードバックの確認応答番号フィールドが有効でないことを示しています。
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.
圧縮機は、このオプションが存在する場合、対応する送信されたヘッダを見つけるために、フィードバックの確認応答番号を使用してはいけません。このオプションを使用すると、FEEDBACK-2形式の確認応答番号フィールドはゼロに設定されます。したがって、NACKまたはACKNUMBER-VALID NOTオプションと共に送信STATIC-NACKフィードバックタイプは減圧装置によって要求されたコンテキストの修復のタイプに対してSTATIC-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-有効でないオプションは、一度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オプションは一度FEEDBACK-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オプション、すなわち、それはオプションは、圧縮装置と解凍ペア間の関連されたプロファイルに関連付けられた任意のコンテキストに適用され、チャネルごとに適用可能です。
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オプションは、一度FEEDBACK-2形式でより多く見えてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
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.
作者はこのドキュメントの開発中に犯した文書の校閲としてのために、また、建設的な議論のためにマーク・西、ロバートFinking、Haipengジン、とのRohitカプールに感謝したいと思います。有益なコメントやフィードバックのためにこの仕様に、だけでなく、ヤニJuvanとアンダースEdqvistに彼の豊富な貢献のためのカールKnutssonに感謝します。 IETF最後に通話中のIETFセキュリティ理事に代わって彼のレビューのための一般的なエリアレビューチーム（ジェン・ART）のレビューとして、そしてスティーブン・ケントへの彼のレビューのためにも、エルウィン・デイヴィスのおかげで、。最後に、前のROHC仕様に貢献し、この努力を支えてきた多くの人々に感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年9月。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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.、ピンク、S.、ヨンソン、L-E。、およびG. Fairhurst、 "軽量ユーザーデータグラムプロトコル（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]ペルティエ、G.、 "ロバストヘッダ圧縮（ROHC）：ユーザーデータグラムプロトコル（UDP）Liteのプロファイル"、RFC 4019、2005年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995]ジョンソン、L-E。、ペルティエ、G.、及びK. Sandlund、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、RFC 4995、2007年7月。
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC4997] Finking、R.とG.ペルティエ、 "ロバストヘッダ圧縮（ROHC-FN）のための正式な表記法"、RFC 4997、2007年7月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]ボーマン、D.、デアリング、S.、およびR. Hindenと "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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[RFC3843]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮（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]ペルティエ、G.、ヨンソン、L-E、およびK. Sandlund、 "ロバストヘッダ圧縮（ROHC）：パケットの順序を変更できますチャンネル以上のROHC"。、RFC 4224、2006年1月。
Appendix A. Detailed Classification of Header Fields
ヘッダフィールドの付録A.詳細な分類
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:
フィールドは、以下のクラスの1つに属するものとして分類されています。
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.
STATICは - これらのフィールドは、流れの生涯を通じて一定であることが予想されます。一般的には、これらのフィールドのみ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.
STATIC知られている - これらのフィールドは、よく知られた値を持っているので、全く通信する必要はありません期待されています。
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.
IRREGULAR - これらは有用な変化パターンを識別することはできないし、すべての圧縮パケットに圧縮されていない送信する必要のあるフィールドです。
PATTERN - These are fields that change between each packet, but change in a predictable pattern.
PATTERN - これらは、各パケットの間で変化するフィールドですが、予測可能なパターンに変更します。
A.1. IPv4 Header Fields
A.1。 IPv4のヘッダフィールド
+------------------------+----------------+
| 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プロファイルによって圧縮されます。フィールドは、したがって、STATIC-知られているように分類されています。
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（DiffServコードポイント）およびECN（明示的輻輳通知）フィールドは、相対的にほとんど変わらないことが予想されます。
Packet Length
パケット長
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケット長に関する情報は、リンク層により提供されることが期待されます。フィールドには、そのため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.
予約フラグがゼロに設定する必要があり、従って、STATIC-公知のように分類されます。めったに（DF）フラグ変化を断片化しませんので、RACHとして分類されています。最後に、以上のフラグメント（MF）フラグは、IPフラグメントがROHCによって圧縮されず、従ってSTATIC-公知のように分類されているので、ゼロであると予想されます。
Fragment Offset
フラグメントオフセット
Under the assumption that no fragmentation occurs, the fragment offset is always zero and is therefore classified as STATIC-KNOWN.
フラグメンテーションが発生しないという仮定の下で、フラグメントオフセットは常にゼロであり、したがって、STATIC-公知のように分類されます。
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.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-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ヘッダ情報を離れる圧縮されたときに、この追加のチェックサムを有するにも意味がありません。その代わり、それは、デコンプレッサ側で再生することができます。フィールドには、そのためINFERREDとして分類されています。
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.
これらのフィールドは、フローの定義の一部であり、したがって、フロー内のすべてのパケットに対して一定でなければなりません。
A.2. IPv6 Header Fields
A.2。 IPv6のヘッダフィールド
+----------------------+----------------+
| 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.
パケット長（及び、従って、ペイロード長）に関する情報は、リンク層により提供されることが期待されます。フィールドには、そのためINFERREDとして分類されています。
Next Header
次のヘッダー
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-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として分類されています。
A.3. UDP Header Fields
A.3。 UDPヘッダフィールド
+------------------+-------------+
| 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.
パケット長に関する情報は、リンク層により提供されることが期待されます。フィールドには、そのため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.
チェックサムはオプションとすることができます。無効にした場合、その値は常にゼロであると離れて圧縮することができます。有効にした場合、その値は、圧縮の目的のために、それはすべてのパケットをランダムに変更することに相当し、ペイロードに依存します。
A.4. UDP-Lite Header Fields
A.4。 UDP-Liteのヘッダフィールド
+--------------------+-------------+
| 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 Lengthフィールドと同じ動作を以下か、一定の値をとる場合のケースのために）、完全に予測可能であることのいずれか又はパケット毎にランダムに変化することが期待されますヘッダ圧縮の観点から）。すべてのケースでは、動作自体は、パケットフローの存続期間中にこのフィールドに変更したり、比較的ほとんど変わらないことが予想されていません。
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のヘッダを含みます。チェックサムは、あるとして常に送信されなければならない変更フィールドです。
A.5. RTP Header Fields
A.5。 RTPヘッダフィールド
+----------------+----------------+
| 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を持つことが予想され、フィールドは、したがって、STATIC-知られているように分類されています。
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.
ビデオのために、それはすべての映像の最後のパケットに設定されるべきである一方で、オーディオの場合は、マーカービットは、有音部の最初のパケットにのみ設定する必要があります。これは、両方のケースで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シーケンス番号に従います。そこに沈黙期間となって、新たな有音が開始された場合、タイムスタンプは、サイレント期間の長さに比例してジャンプします。しかし、増分はおそらく、比較的限られた範囲内であろう。
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.
二つの連続するパケット間の、タイムスタンプが変更されませんいずれか又は画像クロック周波数に対応する固定値の倍数で増加します。タイムスタンプは、特定の符号化方式のための固定値の倍数だけ減少させることができます。画像クロック周波数の倍数として表現タイムスタンプ値の変化は、限られた範囲内のほとんどの場合です。
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フィールドで識別されるセッションの参加者は、通常、パケット間ベースで変わらないことが予想されますが、まれにしかいくつかの追加および/または削除によって変化します。
A.6. ESP Header Fields
A.6。 ESPヘッダフィールド
+------------------+-------------+
| 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ずつインクリメントされます。
A.7. IPv6 Extension Header Fields
A.7。 IPv6拡張ヘッダフィールド
+-----------------------+---------------+
| 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.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-DEFとして分類されます。
Ext Hdr Len
内線HDRレン
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パケットによって更新することができます。
A.8. GRE Header Fields
A.8。 GREヘッダフィールド
+--------------------+---------------+
| 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
Reserved0、バージョン
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.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-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.
存在する場合、キーフィールドは、フローを定義するために使用され、変更されません。
A.9. MINE Header Fields
A.9。 MINEヘッダフィールド
+---------------------+----------------+
| 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.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-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.
これらのフィールドは、フローを定義するために使用することができ、変化することが予想されていません。
A.10. AH Header Fields
A.10。 AHヘッダフィールド
+---------------------+----------------+
| 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.
このフィールドは、フローのすべてのパケットで同じ値を持つことになり、したがって、STATIC-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.
このフィールドの値は0に設定されます。
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.
このフィールドは、特定のフローを識別するために使用され、シーケンス番号がラップアラウンドするときのみが変化し、従ってSTATIC-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は、予期しない動作をすることが予想されるためIRREGULARとして分類されています。
Appendix B. Compressor Implementation Guidelines
付録B.コンプレッサー実装のガイドライン
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プロファイルが実装されている方法についての規範的要件を定義していません。
B.1. Reference Management
B.1。リファレンスの管理
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つの連続するヘッダ間の流れの中で発生したの説明が含まれており、新たな基準は、ウィンドウ内のパケットは、この文脈で圧縮されるたびに挿入されています。非圧縮ヘッダの格納されたコピーが表されているように、基準は、例えば、実装されてもよいです。圧縮機が特定基準（受信楽観的アプローチまたはフィードバックを使用して、例えば）解凍装置によってもはや使用されていることを確信していない場合、参照は、スライディングウィンドウから除去されます。
B.2. Window-based LSB Encoding (W-LSB)
B.2。ウィンドウベースの最下位ビット符号化（W-LSB）
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の数を選択することができます。
B.3. W-LSB Encoding and Timer-based Compression
B.3。 W-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.
ここで、 - （ - a_j A_N）これらの同じ2つのヘッダ間の到着時間の差である（T_N T_J）は、現在圧縮されたヘッダと基準ヘッダとの間のタイムスタンプの差があります。
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))
天井（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ペルティエエリクソンボックス920 SE-971 28ルレオスウェーデン
Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
電話：+46（0）8 404 29 43 Eメール：ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
クリストファーSandlundエリクソンボックス920ルーレオSE-971 28スウェーデン
Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
電話：+46（0）8 404 41 58 Eメール：kristofer.sandlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。