RFC5225 日本語訳
5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP,UDP, IP, ESP and UDP-Lite. G. Pelletier, K. Sandlund. April 2008. (Format: TXT=246120 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Pelletier
Request for Comments: 5225 K. Sandlund
Category: Standards Track Ericsson
April 2008
コメントを求めるワーキンググループG.ペレティア要求をネットワークでつないでください: 5225年のK.Sandlundカテゴリ: 標準化過程エリクソン2008年4月
RObust Header Compression Version 2 (ROHCv2):
Profiles for RTP, UDP, IP, ESP and UDP-Lite
強健なヘッダー圧縮バージョン2(ROHCv2): RTP、UDP、IP、超能力、および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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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(リアルタイムのTransportプロトコル、ユーザー・データグラム・プロトコル、インターネットプロトコル)を圧縮するROHC(強健なHeader Compression)プロフィールを指定します、RTP/UDP-Lite/IP(ユーザー・データグラム・プロトコルLite)、UDP/IP、UDP-Lite/IP、IPと超能力/IP(Security有効搭載量を要約する)ヘッダー。
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.
この仕様はRFC3095、RFC3843、およびRFC4019で見つけられたプロフィールの第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チャンネルの上にパケットを失われている、そして/または、再命令できるとき減圧成功の確率を増加させるのにコンプレッサー実現で使用されるかもしれない丈夫さメカニズムを定義します。 最終的に、ROHCの正式な記法を使用して、ROHCv2プロフィールはそれら自身の特定のヘッダー形式を定義します。
Pelletier & Sandlund Standards Track [Page 1] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[1ページ]
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 4 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 頭文字語. . . . . . . . . . . . . . . . . . . . . . . . . . 7 4。 バックグラウンド(有益な).74.1。 ヘッダーフィールド. . . . . . . . . . . . . 7 4.2の分類。 RFC3095の上のROHCv2の改良は.84.3の輪郭を描きます。 ROHCv2の操作上の特性は.105の輪郭を描きます。 ROHCv2の概観は(有益)の.105.1の輪郭を描きます。 コンプレッサー概念. . . . . . . . . . . . . . . . . . . 11 5.1.1。 楽観的なアプローチ. . . . . . . . . . . . . . . . . 11 5.1.2。 損失と、そして、Reordering. . . . . . . . . . . . . . . . . . . . . 11 5.1.3への丈夫さの間の見返り。 減圧装置文脈. . . . . 13 5.2との相互作用。 減圧装置概念. . . . . . . . . . . . . . . . . . 14 5.2.1。 減圧装置州のマシン. . . . . . . . . . . . . 14 5.2.2。 減圧装置文脈管理. . . . . . . . . . . 17 5.2.3。 フィードバック論理. . . . . . . . . . . . . . . . . . . 19 6。 ROHCv2は(標準)の.196.1の輪郭を描きます。 チャンネルパラメタ、分割、およびReordering. . . . 19 6.2。 操作、1文脈あたり.206.3の輪郭を描いてください。 分野. . . . . . . . . . . . . . . . . . . . . 21 6.3.1を制御してください。 一連番号(MSN). . . . . . . . . . . . 21 6.3.2を習得してください。 比率. . . . . . . . . . . . . . . . . . 21 6.3.3をReorderingします。 IP-IDの振舞い. . . . . . . . . . . . . . . . . . . 22 6.3.4。 UDP-Lite適用範囲の振舞い. . . . . . . . . . . . . 22 6.3.5。 タイムスタンプストライド. . . . . . . . . . . . . . . . . . 22 6.3.6。 時間ストライド. . . . . . . . . . . . . . . . . . . . . 22 6.3.7。 制御フィールド. . . . . . . . . . . . . . 23 6.4へのCRC-3。 再建と検証. . . . . . . . . . . . . 23 6.5。 圧縮されたヘッダーチェインズ. . . . . . . . . . . . . . . . 24 6.6。 ヘッダーFormatsとEncoding Methods、.256.6、.1. baseheader_拡大_ヘッダー、.266.6、.2. baseheaderの_の外側の_ヘッダー、.266.6、.3. 推論された_のudp_長さ、.266.6、.4. 推論された_ip_v4_ヘッダー_チェックサム、.266.6、.5. 推論された_私のもの_ヘッダー_チェックサム、.276.6、.6. 推論された_ip_v4_の長さ、.286.6、.7. 推論された_ip_v6_の長さ、.286.6、.8 スケーリングされたRTP Timestamp Compression、.296.6、.9. タイマ_が_lsbを基礎づけた、.306.6、.10. 推論された_が_分野をスケーリングした、.316.6、.11. コントロール_crc3_コード化、.326.6、.12. 推論された_連続した_ip_イド、.336.6、.13. リスト_csrc(cc_値).346.7 議論. 38 6.8として外部のパラメタで方法をコード化します。 ヘッダー形式. . . . . . . . . . . . . . . . . . . . . 40
Pelletier & Sandlund Standards Track [Page 2] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[2ページ]
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
6.8.1. 初期設定、.2にヘッダー形式(IR). . . . 40 6.8をリフレッシュしてください。 圧縮されたヘッダーは(CO). . . . . . . . . . . 41 6.9をフォーマットします。 フィードバック形式とオプション. . . . . . . . . . . . . . 100 6.9.1。 フィードバックは.2に.100 6.9をフォーマットします。 フィードバックオプション. . . . . . . . . . . . . . . . . . 102 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 104 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 105 9。 承認. . . . . . . . . . . . . . . . . . . . . . 105 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 106 10.1。 引用規格. . . . . . . . . . . . . . . . . . 106 10.2。 有益な参照. . . . . . . . . . . . . . . . . 107付録A.はヘッダーフィールド. . . . . 108A.1の分類を詳しく述べました。 IPv4ヘッダーフィールド. . . . . . . . . . . . . . . . . . . 109A.2。 IPv6ヘッダーフィールド. . . . . . . . . . . . . . . . . . . 112A.3。 UDPヘッダーフィールド. . . . . . . . . . . . . . . . . . . 113A.4。 UDP-Liteヘッダーフィールド. . . . . . . . . . . . . . . . . 114A.5。 RTPヘッダーフィールド. . . . . . . . . . . . . . . . . . . . 115A.6。 超能力ヘッダーフィールド. . . . . . . . . . . . . . . . . . . . 117A.7。 IPv6拡大ヘッダーフィールド. . . . . . . . . . . . . . 117A.8。 GREヘッダーフィールド. . . . . . . . . . . . . . . . . . . . 118A.9。 ヘッダーフィールド. . . . . . . . . . . . . . . . . . . 119A.10を採掘してください。 ああ、ヘッダーフィールド. . . . . . . . . . . . . . . . . . . . 120付録B.コンプレッサー実施要綱. . . . . . . 121B.1。 参照管理. . . . . . . . . . . . . . . . . . 121B.2。 (W-LSB). . . . . . . . . . . 121B.3をコード化する窓のベースのLSB。 W-LSBのコード化していてタイマベースの圧縮. . . . . . . 122
Pelletier & Sandlund Standards Track [Page 3] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[3ページ]
1. Introduction
1. 序論
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枠組みは最初に[RFC3095]に記録されました、RTP/UDP/IP(リアルタイムのTransportプロトコル、ユーザー・データグラム・プロトコル、インターネットプロトコル)の圧縮のためのプロフィールと共に、UDP/IP、IPと超能力/IP(Security有効搭載量を要約する)ヘッダー。 IPヘッダー[RFC3843]とUDP-Lite(ユーザー・データグラム・プロトコルLite)ヘッダー[RFC4019]の圧縮のための追加プロフィールは、後でROHCプロフィールの始発を完成するために指定されました。
This document defines an updated version for each of the above mentioned profiles, and the definitions depend on the ROHC framework as found in [RFC4995]. The framework is required reading to understand the profile definitions, rules, and their role.
このドキュメントはそれぞれの上記のプロフィールのためのアップデートされたバージョンを定義します、そして、定義は[RFC4995]で見つけられるようにROHC枠組みによります。 枠組みはプロフィール定義、規則、およびそれらの役割を理解する必読書です。
Specifically, this document defines header compression schemes for:
明確に、このドキュメントは以下のためにヘッダー圧縮技術を定義します。
o RTP/UDP/IP : profile 0x0101 o UDP/IP : profile 0x0102 o ESP/IP : profile 0x0103 o IP : profile 0x0104 o RTP/UDP-Lite/IP : profile 0x0107 o UDP-Lite/IP : profile 0x0108
o RTP/UDP/IP: プロフィール0x0101o UDP/IP: プロフィール0x0102o超能力/IP: プロフィール0x0103o IP: プロフィール0x0104o RTP/UDP-Lite/IP: プロフィール0x0107o UDP-Lite/IP: プロフィール0x0108
Each of the profiles above can compress the following type of extension headers:
それぞれの上記のプロフィールは以下のタイプの拡張ヘッダーを圧縮できます:
o AH [RFC4302]
o ああ[RFC4302]
o GRE [RFC2784][RFC2890]
o GRE[RFC2784][RFC2890]
o MINE [RFC2004]
o 私のもの[RFC2004]
o IPv6 Destination Options header[RFC2460]
o IPv6 Destination Optionsヘッダー[RFC2460]
o IPv6 Hop-by-hop Options header[RFC2460]
o ホップによるIPv6 Hop Optionsヘッダー[RFC2460]
o IPv6 Routing header [RFC2460]
o IPv6ルート設定ヘッダー[RFC2460]
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Pelletier & Sandlund Standards Track [Page 4] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[4ページ]
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[RFC4997]において、このドキュメントはROHC枠組み[RFC4995]と正式な記法で見つけられる用語と一致しています。 さらに、このドキュメントは、次の用語を使用するか、または定義します:
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.
Acknowledgment Numberは、どんなパケットがRoHCv2フィードバック要素で承認されているかを特定します(セクション6.9を見てください)。 通常、この分野の値は最後に首尾よく減圧されたヘッダーのMaster Sequence Number(MSN)に対応しています、フィードバック情報が適用される圧縮文脈(CID)のために。
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ビットのCyclic Redundancy Check(CRC)を含むCompressed(CO)ヘッダーを受けるとき、この合法化は減圧装置によって実行されます。 この3ビットのCRCは文脈の特定の制御フィールドと同様にCOヘッダーで運ばれたコントロール野原を覆っています。 ヘッダー形式の公式の定義では、この3ビットのCRCは「_crc3"を制御してください。そうすれば、用途はコントロール_crc3_コード化を制御(また、セクション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
深さをReorderingします。
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)と交際しました。 以下の連続して遅いパケットの定義を見てください。
Pelletier & Sandlund Standards Track [Page 5] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[5ページ]
ROHCv2 Header Types
ROHCv2ヘッダータイプ
ROHCv2 profiles use two different header types: the Initialization
and Refresh (IR) header type, and the Compressed (CO) header type.
ROHCv2プロフィールは2つの異なったヘッダータイプを使用します: 初期設定、Refresh(IR)ヘッダータイプ、およびCompressed(CO)ヘッダータイプ。
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).
1時以前減圧装置に達するパケットか前述のパケットのすべてが同じヘッダーによって圧縮された流れに属すチャンネルの上に遅れて、同じ圧縮文脈(CID)に関連づけられるいくつかのパケット。 連続して早いパケットの到着時点で、無くなっているパケットとリンクに遅れるパケットは区別できません。
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.
1か同じCIDに属す他のいくつかのパケットを受け取った後に減圧装置に達するなら、パケットは系列の中で遅れています、他のパケットの前のコンプレッサーから連続して遅いパケットを送りましたが。 この仕様の範囲の外に減圧装置がどう連続して遅いパケットを検出するかがありますが、例えば、それはこのためにMSNを使用できます。
Timestamp Stride (ts_stride)
タイムスタンプストライド(t_ストライド)
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.
タイムスタンプストライド(t_ストライド)は連続した一連番号がある2つのRTPパケットの間のタイムスタンプ値の予想された増加です。 通常、8kHzの見本郵送料率が1つを生産しているメディアコード化が20ms毎を縁どっているので例えばRTPタイムスタンプはn*160(8000*0.02と等しい)増加するでしょう、何らかの整数nのために。
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.
時間ストライド(時間_ストライド)は1つのt_ストライドに同等な時間間隔です、例えば、RTPタイムスタンプ増分のための上記の例の20ms。
Pelletier & Sandlund Standards Track [Page 6] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[6ページ]
3. Acronyms
3. 頭文字語
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.
ああ、認証ヘッダー。 セキュリティ有効搭載量を要約する超能力。 GRE一般ルーティングのカプセル化。 FC Full Contextは(減圧装置)を述べます。 IPインターネットプロトコル。 LSB最下位ビット。 IPで最小量のカプセル化を採掘してください。 MSB最上位ビット。 MSNは系列番号を習得します。 NCノーContextは(減圧装置)を述べます。 OAの楽観的なアプローチ。 RC Repair Contextは(減圧装置)を述べます。 ROHC Header圧縮枠組み(RFC4995)。 本書では定義されたヘッダー圧縮プロフィールのROHCv2 Set。 RTPのリアルタイムのトランスポート・プロトコル。 SSRC Synchronizationソース。 RTPヘッダーでは、さばきます。 CSRC Contributingソース。 RTPヘッダーは貢献しているソースの任意のリストを含んでいます。 Tc交通のクラス。 IPv6ヘッダーでは、さばきます。 また、TOSを見てください。 サービスのTOSタイプ。 IPv4ヘッダーでは、さばきます。 また、TCを見てください。 t、RTPタイムスタンプ。 生きるTTL時間。 IPv4ヘッダーでは、さばきます。 UDPユーザー・データグラム・プロトコル。 UDP-Liteユーザー・データグラム・プロトコルLite。
4. Background (Informative)
4. バックグラウンド(有益)です。
This section provides background information on the compression profiles defined in this document. The fundamentals of general header compression and of the ROHC framework may be found in sections 3 and 4 of [RFC4995], respectively. The fundamentals of the formal notation for ROHC are defined in [RFC4997]. [RFC4224] describes the impacts of out-of-order delivery on profiles based on [RFC3095].
このセクションは本書では定義された圧縮プロフィールに関する基礎的な情報を提供します。 一般的なヘッダー圧縮とROHC枠組みの原理は[RFC4995]のセクション3と4でそれぞれ見つけられるかもしれません。 ROHCに、正式な記法の原理は[RFC4997]で定義されます。 [RFC4224]は[RFC3095]に基づくプロフィールの上に不適切な配送の影響について説明します。
4.1. Classification of Header Fields
4.1. ヘッダーフィールドの分類
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
付録Aは、詳細にこのドキュメントに関連しているすべてのヘッダーフィールドを記載して、分類します。 付録は締めくくります。
Pelletier & Sandlund Standards Track [Page 7] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[7ページ]
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 Identification(16ビット)--IP-ID--超能力Sequence Number(32ビット)--ESP SN--UDP Checksum(16ビット)--チェックサム--UDP-Lite Checksum(16ビット)--チェックサム--UDP-Lite Checksum Coverage(16ビット)--CCov--RTP Marker(1ビット)--M-ビット--RTP Sequence Number(16ビット)--RTP SN--RTP Timestamp(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に関して、特に、Appendix Aでの分析は、通常、RTP Timestamp(TS)分野の値がRTP Sequence Number(SN)に強い相関関係を持っているのを明らかにします。(各パケットあたり1つによる増分はRTPソースでRTP Sequence Numberを放ちました)。 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.
UDPに関しては、Checksum野原を犠牲者に終わりから終わりへの特性に違反しないで推論できないか、再計算できないで、可能にすると(IPv6によって義務的な)、このようにしてそのままで送ります。 同じくらいはUDP-Lite Checksum(IPv4とIPv6の両方によって義務的な)に適用されます、UDP-Lite Checksum Coverageがいくつかの場合圧縮性であるかもしれませんが。
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のものとしての同様の相関関係がIdentifier分野(IP-ID)と圧縮に使用されるマスター一連番号(MSN)の間でしばしば観測される、(例えば、RTP SN、いつ、RTPヘッダーを圧縮します)
4.2. Improvements of ROHCv2 over RFC 3095 Profiles
4.2. RFC3095プロフィールの上のROHCv2の改良
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プロフィールはともにRFC3095プロフィール[RFC3095]に少なくとも同等な圧縮効率と丈夫さを達成できます、同じ運転条件の下で使用されると。 最も小さい圧縮されたヘッダー(すなわち、PT-0はRFC3095でU/O-0をフォーマットして、ROHCv2で_Pt0_crc3をフォーマットする)のサイズと噛み付いているレイアウトは特に、同じです。
There are a number of differences and improvements between profiles defined in this document and their earlier version defined in RFC 3095. This section provides an overview of some of the most significant improvements:
本書では定義されたプロフィールとRFC3095で定義されたそれらの以前のバージョンの間には、多くの違いと改良があります。 このセクションは最も顕著な改良のいくつかの概観を提供します:
Pelletier & Sandlund Standards Track [Page 8] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[8ページ]
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.
RFC3095で定義されたプロフィールは、コンプレッサーと減圧装置の間のチャンネルが圧縮終点の間にオーダーにおける配送を提供するのを必要とします。 しかしながら、ROHCv2プロフィールは強壮に効率的に圧密点の後に圧縮アルゴリズム自体の一部として再命令する数量限定を扱うことができます。 さらに、再命令するこの改良されたサポートで、ROHCv2プロフィールが、より効率的にprelink reorderingを扱うのが可能になります。
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.
RFC3095のプロフィールはそれぞれ異なったアップデート論理と圧縮されたヘッダー形式で複数の操作上のモードを定義します。 ROHCv2プロフィールは単方向の操作で最初に文脈(CID)のためにフィードバックを受け取るまで運転して、双方向の操作はそのポイントで使用されています。 どんな操作上の論理が使用されるかから形式は独立しています。
IP extension header
IP拡張ヘッダー
Profiles in RFC 3095 compress IP Extension headers using list
compression. ROHCv2 profiles instead treat extension headers in
the same manner as other protocol headers, i.e., using the
chaining mechanism; it thus assumes that extension headers are not
added or removed during the lifetime of a context (CID), otherwise
compression has to be restarted for this flow.
RFC3095のプロフィールは、リスト圧縮を使用することでIP Extensionヘッダーを圧縮します。 すなわち、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.
RFC3095のプロフィールは2つのレベルのIPヘッダーを高々圧縮できます。 ROHCv2プロフィールはIPヘッダーの特殊活字の数字を圧縮できます。
List compression
リスト圧縮
ROHCv2 profiles do not support reference-based list compression.
ROHCv2プロフィールは参照ベースのリスト圧縮を支持しません。
Robustness and repairs
丈夫さと修理
ROHCv2 profiles do not define a format for the IR-DYN packet;
instead, each profile defines a compressed header that can be used
to perform a more robust context repair using a 7-bit CRC
verification. This also implies that only the IR header can
change the association between a CID and the profile it uses.
ROHCv2プロフィールはIR-DYNパケットのために書式を定義しません。 代わりに、各プロフィールは7ビットのCRC検証を使用することで、より体力を要している文脈修理を実行するのに使用できる圧縮されたヘッダーを定義します。 また、これは、IRヘッダーだけがCIDとそれが使用するプロフィールとの協会を変えることができるのを含意します。
Pelletier & Sandlund Standards Track [Page 9] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[9ページ]
Feedback
フィードバック
ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2,
while this is optional in RFC 3095. A different set of feedback
options is also used in ROHCv2 compared to RFC 3095.
ROHCv2プロフィールはFEEDBACK-2の形式でCRCを強制しますが、これはRFC3095で任意です。 また、RFC3095と比べて、異なったセットのフィードバックオプションはROHCv2で使用されます。
4.3. Operational Characteristics of ROHCv2 Profiles
4.3. ROHCv2プロフィールの操作上の特性
Robust header compression can be used over different link technologies. Section 4.4 of [RFC4995] lists the operational characteristics of the ROHC channel. The ROHCv2 profiles address a wide range of applications, and this section summarizes some of the operational characteristics that are specific to these profiles.
異なったリンク技術の上で体力を要しているヘッダー圧縮を使用できます。 [RFC4995]のセクション4.4はROHCチャンネルの操作上の特性を記載します。 ROHCv2プロフィールはさまざまなアプリケーションを記述します、そして、このセクションはこれらのプロフィールに特定の操作上の特性のいくつかをまとめます。
Packet length
パケット長
ROHCv2 profiles assume that the lower layer indicates the length
of a compressed packet. ROHCv2 compressed headers do not contain
length information for the payload.
ROHCv2プロフィールは、下層が圧縮されたパケットの長さを示すと仮定します。 圧縮されたヘッダーがするROHCv2はペイロードのための長さの情報を含んでいません。
Out-of-order delivery between compression endpoints
圧縮終点の間の不適切な配送
The definition of the ROHCv2 profiles places no strict requirement
on the delivery sequence between the compression endpoints, i.e.,
packets may be received in a different order than the compressor
has sent them and still have a fair probability of being
successfully decompressed.
ROHCv2プロフィールの定義は圧縮終点の間にどんな厳しい要件も配送系列に置きません、すなわち、コンプレッサーがそれらを送って、まだ首尾よく減圧されるという公正な確率に送るのと異なったオーダーにパケットを受け取るかもしれません。
However, frequent out-of-order delivery and/or significant
reordering depth will negatively impact the compression
efficiency. More specifically, if the compressor can operate
using a proper estimate of the reordering characteristics of the
path between the compression endpoints, larger headers can be sent
more often to increase the robustness against decompression
failures due to out-of-order delivery. Otherwise, the compression
efficiency will be impaired from an increase in the frequency of
decompression failures and recovery attempts.
しかしながら、頻繁な不適切な配送、そして/または、重要な再命令の深さは否定的に圧縮効率に影響を与えるでしょう。 より明確に、コンプレッサーが圧縮終点の間の経路の再命令の特性の適切な見積りを使用することで作動できるなら、よりしばしば不適切な配送のため減圧失敗に対して丈夫さを増加させるように、より大きいヘッダーを送ることができます。 さもなければ、圧縮効率は減圧失敗と回復試みの頻度の増加から損なわれるでしょう。
5. Overview of the ROHCv2 Profiles (Informative)
5. ROHCv2プロフィールの概観(有益)です。
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プロフィールに重要で役に立つ概念の概観を提供します。 これらの概念は実現にガイドラインとして使用されるかもしれませんが、それらはプロフィールの標準の定義の一部ではありません、これらの概念が実現の相互運用性の特性に影響を与えないでプロトコルの圧縮効率に関連するとき。
Pelletier & Sandlund Standards Track [Page 10] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[10ページ]
5.1. Compressor Concepts
5.1. コンプレッサー概念
Header compression can be conceptually characterized as the interaction of a compressor with a decompressor state machine, one per context. The responsibility of the compressor is to convey the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context.
減圧装置州のマシン、1文脈あたり1つとのコンプレッサーの相互作用として概念的にヘッダー圧縮を特徴付けることができます。 コンプレッサーの責任は首尾よくパケットを減圧するのに必要である情報を伝えることです、減圧装置文脈の状態に関する、ある信用に基づいて。
This confidence is obtained from the frequency and the type of information the compressor sends when updating the decompressor context from the optimistic approach (Section 5.1.1), and optionally from feedback messages (See Section 6.9), received from the decompressor.
楽観的なアプローチ(セクション5.1.1)から減圧装置文脈を任意にアップデートするときコンプレッサーがフィードバックメッセージから送る頻度と情報の種類からこの信用を得ます(セクション6.9を見てください)、減圧装置から、受け取られています。
5.1.1. Optimistic Approach
5.1.1. 楽観的なアプローチ
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.
通常、この信用を得るのに必要である繰返し数はヘッダー圧縮が使用されているリンクのパケット損失と不適切な配送の特性に関連します。 それはこのようにして本書では定義されません。 それは、この仕様の範囲の外にあって、決めるのが作成者に残されます。
5.1.2. Tradeoff between Robustness to Losses and to Reordering
5.1.2. 損失と、そして、Reorderingへの丈夫さの間の見返り
The ability of a header compression algorithm to handle sequentially late packets is mainly limited by two factors: the interpretation interval offset of the sliding window used for lsb encoded fields [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom changing fields.
ヘッダー圧縮アルゴリズムが連続して遅いパケットを扱う能力は2つの要素によって主に制限されます: lsbに使用される引窓の解釈間隔オフセットは、めったに職業を替えないように分野[RFC4997]、および楽観的なアプローチをコード化しました(セクション5.1.1を見ます)。
Pelletier & Sandlund Standards Track [Page 11] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[11ページ]
lsb encoded fields:
lsbは分野をコード化しました:
The interpretation interval offset specifies an upper limit for
the maximum reordering depth, by which is it possible for the
decompressor to recover the original value of a dynamically
changing (i.e., sequentially incrementing) field that is encoded
using a window-based lsb encoding. Its value is typically bound
to the number of lsb compressed bits in the compressed header
format, and thus grows with the number of bits transmitted.
However, the offset and the lsb encoding only provide robustness
for the field that it compresses, and (implicitly) for other
sequentially changing fields that are derived from that field.
解釈間隔オフセットは深さを再命令する最大に上限を指定します、どれがそれであるかで、窓のベースのlsbコード化を使用することでコード化されるダイナミックに変化している(すなわち、連続して増加します)分野の元の値を回復する減圧装置において、可能です。 値はlsbの数へのバウンドが通常、圧縮されたヘッダー形式でビットを圧縮して、その結果、ビットの数に応じて伝えられるのに成長するということです。 しかしながら、オフセットとlsbコード化はそれが圧縮する分野に丈夫さを提供するだけです、そして、(それとなく、)他の連続して変化している分野において、その分野からそれを得ます。
This is shown in the figure below:
これは以下の図に示されます:
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
v_ref-p v_ref v_ref + (2^k-1) - p
Lower Upper
Bound Bound
<--- reordering --> <--------- losses --------->
<。--- 解釈間隔(サイズは2^kです)---->|------------------+---------------------------| _+ _審判v_審判(2^k-1)に対する審判p--p Lower Upper Bound Bound<に対して--- 再命令--><。--------- 損失--------->。
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].
どこに、基準値は方法をコード化するlsbで定義されるように[RFC4997]に_審判に反対していますか?
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の唯一の情報が、減圧装置まで運ばれる必要があるとき、見返りは圧縮されることの数に関連します。
Pelletier & Sandlund Standards Track [Page 12] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[12ページ]
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つのパケットが減圧装置に達したのに、合理的に自信があるまで各アップデートが繰り返されるのを確実にすることができます。
5.1.3. Interactions with the Decompressor Context
5.1.3. 減圧装置文脈との相互作用
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)パケットを初期設定とRefreshに送ります。
Initially, when sending the first IR packet for a compressed flow, the compressor does not expect to receive feedback for that flow, until such feedback is first received. At this point, the compressor may then assume that the decompressor will continue to send feedback in order to repair its context when necessary. The former is referred to as unidirectional operation, while the latter is called bidirectional operation.
初めは圧縮された流れのために最初のIRパケットを送るとき、コンプレッサーは、その流れのために反響を調べると予想しません、最初にそのようなフィードバックを受け取るまで。 そして、ここに、コンプレッサーは、減圧装置が、必要であるときに、文脈を修理するためにフィードバックを送り続けると仮定するかもしれません。 前者は単方向の操作と呼ばれますが、後者は双方向の操作と呼ばれます。
The compressor can then adjust the compression level (i.e., what header format it selects) based on its confidence that the decompressor has the necessary information to successfully process the compressed headers that it selects.
そして、コンプレッサーは首尾よく、それが選ぶ圧縮されたヘッダーを処理するために減圧装置には必要事項があるという信用に基づく圧縮レベル(すなわち、それが選択するすべてのヘッダー形式)を調整できます。
In other words, the responsibilities of the compressor are to ensure that the decompressor operates with state information that is sufficient to successfully decompress the type of compressed header(s) it receives, and to allow the decompressor to successfully recover that state information as soon as possible otherwise. The compressor therefore selects the type of compressed header based on the following factors:
言い換えれば、コンプレッサーの責任は減圧装置が首尾よくそれが受ける圧縮されたヘッダーのタイプを減圧して、そうでなければ、減圧装置ができるだけ早く首尾よくその州の情報を回復するのを許容するために十分な州の情報で作動するのを保証することです。 したがって、コンプレッサーは以下の要素に基づく圧縮されたヘッダーのタイプを選びます:
o the outcome of the encoding method applied to each field;
o 各分野に適用されたコード化方法の結果。
o the optimistic approach, with respect to the characteristics of
the channel;
o チャンネルの特性に関する楽観的なアプローチ。
o the type of operation (unidirectional or bidirectional), and if in
bidirectional operation, feedback received from the decompressor
(ACKs, NACKs, STATIC-NACK, and options).
o 双方向の操作で操作(単方向の、または、双方向の)のタイプであり、フィードバックは減圧装置(ACKs、NACKs、STATIC-ナック、およびオプション)から受信されました。
Pelletier & Sandlund Standards Track [Page 13] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[13ページ]
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)ヘッダー形式のためにも減圧失敗を検出する手段があります。 頻度失敗のタイプに頼っていて、それは完全な文脈最新版(STATIC-ナック)を求める否定的承認(ナック)か明白な要求を送るかもしれません。 しかしながら、減圧装置には、失敗の原因、および特にどんな分野が失敗に原因となるかに関する減圧を特定する手段がありません。 その結果、コンプレッサーはいつも否定的承認への最も適当な応答を決定するのに原因となります、それが減圧装置文脈の状態に持っている信用を使用してヘッダーを圧縮するときそれが使用する圧縮されたヘッダーのタイプを選んで。
5.2. Decompressor Concepts
5.2. 減圧装置概念
The decompressor normally uses the last received and successfully validated (IR packets) or verified (CO packets) header as the reference for future decompression.
通常、減圧装置は今後の減圧の参照として首尾よく最後に受け取られた、有効にされたか(IRパケット)、または確かめられた(COパケット)ヘッダーを使用します。
The decompressor is responsible for verifying the outcome of every decompression attempt, to update its context when successful, and finally to request context repairs by making coherent usage of feedback once it has started using feedback.
減圧装置はいったんフィードバックを使用し始めたとフィードバックの論理的な用法を作ることによって、うまくいくとき文脈をアップデートするあらゆる減圧試みの結果について確かめて、最終的な要求文脈修理に原因となります。
Specifically, the outcome of every decompression attempt is verified using the CRC present in the compressed header; the decompressor updates the context information when this outcome is successfully verified; finally, if the decompressor uses feedback once for a compressed flow, then it will continue to do so for as long as the corresponding context is associated with the same profile.
明確に、あらゆる減圧試みの結果は圧縮されたヘッダーの現在のCRCを使用することで確かめられます。 減圧装置はこの結果がいつ首尾よく確かめられるかという文脈情報をアップデートします。 減圧装置が圧縮された流れに一度フィードバックを使用すると、それは、対応する文脈が同じプロフィールに関連している限り、最終的に、そうし続けるでしょう。
5.2.1. Decompressor State Machine
5.2.1. 減圧装置州のマシン
The decompressor operation may be represented as a state machine defining three states: No Context (NC), Repair Context (RC), and Full Context (FC).
減圧装置操作は3つの州を定義する州のマシンとして表されるかもしれません: 関係(NC)、修理関係(RC)、および完全な関係がありません(FC)。
The decompressor starts without a valid context, the NC state. Upon receiving an IR packet, the decompressor validates the integrity of
減圧装置は有効な文脈、NC州なしで始まります。 IRパケットを受けると、減圧装置は保全を有効にします。
Pelletier & Sandlund Standards Track [Page 14] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[14ページ]
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.
CRC-8合法化を使用しているヘッダー。 IRヘッダーが首尾よく有効にされるなら、減圧装置は、参照ヘッダーとして文脈をアップデートして、このヘッダーを使用して、FC状態に動きます。 減圧装置州のマシンがいったんFC状態に入ると、通常、いなくなりません。 繰り返された減圧失敗だけが下向きに下側の状態にトランジットへの減圧装置を強制するでしょう。 文脈損害が検出されるとき、減圧装置は修理文脈(RC)州に動きます。そこでは、圧縮されたヘッダーのために7ビットのCRCと共に減圧試みについて首尾よく確かめるか、または首尾よくIRヘッダーを有効にするまで、それはいます。 静的な文脈損害が検出されるとき、減圧装置はNC州に戻ります。
Below is the state machine for the decompressor. Details of the transitions between states and decompression logic are given in the sub-sections following the figure.
以下に、減圧装置のための州のマシンがあります。 図に従って、州と減圧論理の間の変遷の詳細は小区分で明らかにされます。
CRC-8(IR) Validation
+----->----->----->----->----->----->----->----->----->----->----+
| CRC-8(IR) |
| !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) |
| PT not allowed CRC-8(IR) or CRC-3(CO) |
| +--->---+ +--->----->----->----->---+ +--->---->---+ |
| | | | | | | |
| | v | v | v v
+-----------------+ +----------------------+ +--------------------+
| No Context (NC) | | Repair Context (RC) | | Full Context (FC) |
+-----------------+ +----------------------+ +--------------------+
^ ^ Static Context | ^ !CRC-7(CO) or | ^ Context Damage | |
| | Damage Detected | | PT not allowed | | Detected | |
| +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ |
| |
| Static Context Damage Detected |
+--<-----<-----<-----<-----<-----<-----<-----<-----<---------+
CRC-8(IR)合法化+----->----->----->----->----->----->----->----->----->----->----+ | CRC-8(IR)| | または、CRC-8(IR)かCRC-7(CO)、CRC-7(CO)| | CRC-8(IR)かCRC-3(CO)が許容されなかったPT| | +--->--+ +--->、-、-、-、--、>、-、-、-、--、>、-、-、-、-->--+ +--->、-、-、-->--+ | | | | | | | | | | | v| v| v対+-----------------+ +----------------------+ +--------------------+ | 文脈がありません(NC)。| | 修理文脈(RC)| | 完全な関係(FC)| +-----------------+ +----------------------+ +--------------------+ ^ ^ Static Context | または^!CRC-7(CO)。| ^文脈損害| | | | 検出された損害| | 許容されなかったPT| | 検出されます。| | | +--<。-----<、-、-、-、--<--+ +----<、-、-、-、-、--、<、-、-、--+ +--<。-----<、-、-、-、--<--+ | | | | 検出された静的な文脈損害| +--<。-----<-----<-----<-----<-----<-----<-----<-----<---------+
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は許容しませんでした: 減圧装置は減圧装置の現在の背景がパケットを減圧できるくらいの有効な州の情報を提供しないパケットタイプ(太平洋標準時の)を受けました。
Pelletier & Sandlund Standards Track [Page 15] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[15ページ]
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との定義を見てください。
5.2.1.1. No Context (NC) State
5.2.1.1. 文脈(NC)状態がありません。
Initially, while working in the No Context (NC) state, the decompressor has not yet successfully validated an IR header.
初めは、減圧装置はいいえContext(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合法化がうまくいっているとき、減圧装置はFull Context(FC)状態に動くことができます。
Feedback logic:
フィードバック論理:
In the NC state, the decompressor should send a STATIC-NACK if a
packet of a type other than IR is received, or if an IR header has
failed the CRC-8 validation, subject to the feedback rate
limitation as described in Section 5.2.3.
NC州では、IR以外のタイプのパケットが受け取られているか、またはIRヘッダーがフィードバックレート制限を条件としたCRC-8合法化に失敗したなら、減圧装置がセクション5.2.3で説明されるようにSTATIC-ナックを送るべきです。
5.2.1.2. Repair Context (RC) State
5.2.1.2. 修理文脈(RC)状態
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.
Repair Context(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を運ぶCOヘッダーのために成功するか、またはIRヘッダーでの8ビットのCRCの合法化が成功すると、減圧装置はFull Context(FC)状態に動くことができます。
Downward transition:
下向きの変遷:
The decompressor moves back to the NC state if it assumes static
context damage.
静的な文脈損害を仮定するなら、減圧装置はNC州に戻ります。
Pelletier & Sandlund Standards Track [Page 16] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[16ページ]
Feedback logic:
フィードバック論理:
In the RC state, the decompressor should send a STATIC-NACK when
CRC-8 validation of an IR header fails, or when a CO header
carrying a 7-bit CRC fails and static context damage is assumed,
subject to the feedback rate limitation as described in
Section 5.2.3. If any other packet type is received, the
decompressor should treat it as a CRC verification failure to
determine if NACK is to be sent.
RC状態では、IRヘッダーのCRC-8合法化が失敗するか、または7ビットのCRCを運ぶCOヘッダーが失敗すると、減圧装置はSTATIC-ナックを送るべきです、そして、静的な文脈損害はセクション5.2.3で説明されるフィードバックレート制限を条件として想定されます。 いかなる他のパケットタイプも受け取られているなら、減圧装置はナックが送られるつもりであるかどうか決定しないCRC検証のこととしてそれを扱うべきです。
5.2.1.3. Full Context (FC) State
5.2.1.3. 完全な関係(FC)状態
In the Full Context (FC) state, the decompressor assumes that its entire context is valid.
Full Context(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検証も失敗して、文脈損害が想定されるなら、減圧装置がナックを送るべきですか、または静的な文脈損害が想定されるなら、STATIC-ナックを送るべきです。 これはセクション5.2.3で説明されたフィードバックレート制限を受けることがあります。
5.2.2. Decompressor Context Management
5.2.2. 減圧装置文脈管理
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
または、減圧装置は、いくつかか全体の文脈が無効であると仮定するかもしれません、そうしないと有効にする、CRCを使用することで1個以上のヘッダーについて確かめるために。 減圧装置が正確を知ることができないので
Pelletier & Sandlund Standards Track [Page 17] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[17ページ]
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の故障か分野がそれを引き起こしたことの理由、したがって、文脈のどんな特定の部分が有効であると考えられるか文脈の正当性は示しません。
Validity of the context rather relates to the detection of a problem with the context. The decompressor first assumes that the type of information that most likely caused the failure(s) is the state that normally changes for each packet, i.e., context damage of the dynamic part of the context. Upon repeated decompression failures and unsuccessful repairs, the decompressor then assumes that the entire context, including the static part, needs to be repaired, i.e., static context damage. Failure to validate the 3-bit CRC that protects control fields should be treated as a decompression failure when the decompressor asserts the validity of its context.
文脈の正当性はむしろ文脈に関する問題の検出に関連します。 減圧装置は、最初に、たぶん失敗を引き起こした情報の種類が通常、各パケット(すなわち、文脈のダイナミックな部分の文脈損害)のために変化する状態であると仮定します。 次に、繰り返された減圧失敗と失敗の修理のときに減圧装置は、静的な部分を含む全体の文脈が、修理される必要であると仮定します、すなわち、静的な文脈損害。 減圧装置が文脈の正当性について断言して、制御フィールドを保護する3ビットのCRCを有効にしない場合、減圧失敗として扱われるべきです。
Context Damage Detection
文脈損害検出
The assumption of context damage means that the decompressor will
not attempt decompression of a CO header that carries only a 3-bit
CRC, and will only attempt decompression of IR headers or CO
headers protected by a CRC-7.
文脈損害の仮定は、減圧装置が3ビットのCRCだけを運ぶCOヘッダーの減圧を試みないで、CRC-7によって保護されたIRヘッダーかCOヘッダーの減圧を試みるだけであることを意味します。
Static Context Damage Detection
静的な文脈損害検出
The assumption of static context damage means that the
decompressor refrains from attempting decompression of any type of
header other than the IR header.
静的な文脈損害の仮定は、減圧装置が、IRヘッダー以外のどんなタイプのヘッダーの減圧も試みるのを控えることを意味します。
How these assumptions are made, i.e., how context damage is detected, is open to implementations. It can be based on the residual error rate, where a low error rate makes the decompressor assume damage more often than on a high rate link.
これらの仮定がどうされるか文脈損害がすなわち、どう検出されるかは、実現に開かれています。 それは見逃し誤りレートに基づくことができます、減圧装置が高い率リンクよりしばしば低誤り率で損害を仮定するところで。
The decompressor implements these assumptions by selecting the type of compressed header for which it will attempt decompression. In other words, validity of the context refers to the ability of a decompressor to attempt (or not) decompression of specific packet types.
減圧装置は、それが減圧を試みる圧縮されたヘッダーのタイプを選ぶことによって、これらの仮定を実行します。 言い換えれば、文脈の正当性は減圧装置が特定のパケットタイプの(or not)減圧を試みる能力について言及します。
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プロフィールがオーダーにおける配送を保証できないチャンネルの上に使用されるとき、減圧装置は、首尾よく減圧される連続して遅いパケットの内容で文脈をアップデートするのを控えるかもしれません。 これは、減圧装置が文脈に既に持っているものより古い情報で文脈をアップデートするのを避けるためのものです。
Pelletier & Sandlund Standards Track [Page 18] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[18ページ]
5.2.3. Feedback Logic
5.2.3. フィードバック論理
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.
ROHC枠組みは3つのタイプに関するフィードバックメッセージを定義します: ACKs、NACKs、および静的なNACKs。 それぞれのメッセージの意味論は[RFC4995]についてセクション5.2.4で.1に定義されます。 どんなフィードバックを送ったらよいかはすなわち、減圧装置、セクション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.
それが文脈損害を仮定すると、減圧装置はナックを送るべきです、そして、静的な文脈損害を仮定すると、それはSTATIC-ナックを送るべきです。 減圧装置がうまくいっている減圧のフィードバックを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.
減圧装置は、それがACKsとSTATIC-ナック/NACKsの両方のためにフィードバックを送るレートを制限するべきであり、同じタイプの同じ出来事に関連するかもしれないフィードバックメッセージの不要な写しを送るのを避けるべきです。
6. ROHCv2 Profiles (Normative)
6. ROHCv2プロフィール(標準)です。
6.1. Channel Parameters, Segmentation, and Reordering
6.1. チャンネルパラメタ、分割、およびReordering
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分割を使用してはいけません(.5セクション5.2[RFC4995]を見てください)、すなわち、Maximum Reconstructed Reception Unit(MRRU)は0に用意ができなければなりません、ROHCチャンネルの構成が支持されたプロフィール(すなわち、PROFILESパラメタ)のリストに少なくとも1個のROHCv2プロフィールを含んでいて、チャンネルが圧縮終点の間でオーダーにおけるパケットの配信を保証できないなら。
Pelletier & Sandlund Standards Track [Page 19] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[19ページ]
6.2. Profile Operation, Per-context
6.2. 1文脈あたりのプロフィール操作
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パケットを定期的に送ります。周期性はタイムアウトに基づくことができます、流れのために送られた圧縮されたパケットの数、またはimplementerが選ぶいかなる他の戦略でも。
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.
減圧装置からの積極的なフィードバック(ACKs)か負のフィードバック(NACKsかSTATIC-NACKs)のどちらかのレセプションはフィードバックが受け取られた文脈(CID)のためにフィードバックチャンネルを確立します。 特定の文脈のための確立したフィードバックチャンネルがいったんあると、コンプレッサーは、減圧装置の現状を見積もるのにこのフィードバックを利用できます。 これは、コンプレッサーが必要な信頼水準を達成するのに必要である情報を提供することによって圧縮効率を増加させるのを助けます。 フィードバックチャンネルが確立されるとき、周期的に発信するコンプレッサーがリフレッシュするので、余計になります、そして、代わりに、減圧装置から楽観的なアプローチとフィードバックに完全に依存できます。
The decompressor MAY send positive feedback (ACKs) to initially establish the feedback channel for a particular flow. Either positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs) establishes this channel. Once it has established a feedback channel for a CID, the decompressor is REQUIRED to continue sending feedback for the lifetime of the context (i.e., until it receives an IR packet that associates the CID to a different profile), to send error recovery requests and (optionally) acknowledgments of significant context updates.
減圧装置は、初めは特定の流れのためにフィードバックチャンネルを証明するために、積極的なフィードバック(ACKs)を送るかもしれません。 積極的なフィードバック(ACKs)か負のフィードバック(NACKsかSTATIC-NACKs)のどちらかがこのチャンネルを確立します。 CIDのためにいったんフィードバックチャンネルを確立すると、減圧装置は意味のある文脈最新版のエラー回復要求と(任意に)承認を送るために文脈(すなわち、異なったプロフィールにCIDを関連づけるIRパケットを受けるまで)の生涯のためのフィードバックを送り続けるREQUIREDです。
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.
そして、確立したフィードバックチャンネルのない圧縮がそれほど効率的でなく、周期的のためにリフレッシュする、エラー回復の引き金となるフィードバックの不足。 また、ケースと比べて、損失伝播のわずかに高い確率が減圧装置がフィードバックを使用するところにあるでしょう。
Pelletier & Sandlund Standards Track [Page 20] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[20ページ]
6.3. Control Fields
6.3. 制御フィールド
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は減圧装置によってコンプレッサーから受け取られたヘッダー形式の解釈に使用される多くの制御フィールドを定義します。 以下の小区分で記載された制御フィールドは、この.4通の正式な記法[RFC4997]コネセクション6.8.2ドキュメントを使用することで定義されます。
6.3.1. Master Sequence Number (MSN)
6.3.1. マスター配列番号(MSN)
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.
プロフィールが圧縮するプロトコル(例えば、RTP SN)のヘッダーのひとりに既に存在する分野からMaster Sequence Number(MSN)グラウンドに出るか、またはあるいはまたそれをコンプレッサーに作成します。 1文脈あたりの1MSNのスペースがあります。
The MSN field has the following two functions:
MSN分野には、以下の2つの機能があります:
o Differentiating between reference headers when receiving feedback
data;
o フィードバックデータを受け取るとき、参照ヘッダーを区別します。
o Inferring the value of incrementing fields (e.g., IPv4
Identifier).
o 増加している分野(例えば、IPv4 Identifier)の値を推論します。
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.
1つのMSN分野がすべてのROHCv2ヘッダーにあります、すなわち、MSNはコンプレッサーによって送られたそれぞれのヘッダータイプでいつも存在しています。 IRヘッダーでMSNをすべて送りますが、それはCOヘッダー形式の中でコード化されたlsbであるかもしれません。 減圧装置はAcknowledgment Number分野にフィードバックでMSNのLSBsをいつも含んでいます(セクション6.9を見てください)。 コンプレッサーは、後で減圧装置が承認しているすべてのパケットを推論するのにこの分野を使用できます。
For profiles for which the MSN is created by the compressor (i.e., 0x0102, 0x0104, and 0x0108), the following applies:
コンプレッサー(すなわち、0×0102、0×0104、および0×0108)によってMSNが作成されるプロフィールに関しては、以下は適用されます:
o The compressor only initializes the MSN for a context when that
context is first created or when the profile associated with a
context changes;
o その文脈が最初に、作成されるか、または文脈に関連しているプロフィールが変化するときだけ、コンプレッサーは文脈のためにMSNを初期化します。
o When the MSN is initialized, it is initialized to a random value;
o MSNが初期化されるとき、それは無作為の値に初期化されます。
o The value of the MSN SHOULD be incremented by one for each packet
that the compressor sends for a specific CID.
o 値、MSN SHOULDでは、コンプレッサーが特定のCIDのために送る各パケットあたり1つ増加されてください。
6.3.2. Reordering Ratio
6.3.2. 比率をReorderingします。
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
制御フィールド追加注文_比は、どのくらいの再命令がMSNのlsbコード化で扱われるかを指定します。 ヘッダー圧縮が再命令される異なるとのリンクの上に実行されるとき、これは役に立ちます。
Pelletier & Sandlund Standards Track [Page 21] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[21ページ]
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.
特性。 追加注文_比率制御フィールドはコンプレッサーが再命令と連敗に関して方法をコード化するlsbの丈夫さの特性を調整する手段を提供します、セクション5.1.2で説明されるように。
6.3.3. IP-ID Behavior
6.3.3. IP-IDの振舞い
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]があるconformantではありませんが、ゼロの恒常価値は実際には観測されました)。 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.
1つ以上のレベルのIPヘッダーを圧縮するとき、ROHCv2プロフィールはどんなIP-IDにもかかわらず、最も奥深いIPヘッダーのものにも連続した振舞いを割り当ててはいけません(ネットワークバイトオーダーの、または、バイトと交換された)。 これは最も奥深いIPヘッダーのIP-IDだけが連続して変化している分野としてそれを圧縮するためにMSNと共に十分近い相関関係を持っていそうであるからです。 したがって、コンプレッサーはいずれのIP-IDもトンネリングヘッダーへの無作為のIP-IDの振舞いも定数に割り当ててはいけません。
6.3.4. UDP-Lite Coverage Behavior
6.3.4. UDP-Lite適用範囲の振舞い
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.
制御フィールドの適用範囲_振舞いはUDP-Liteヘッダーのチェックサム適用範囲分野がRoHCv2と共にどう圧縮されるかを指定します。 それは方法をコード化しながら、以下の1つを示すことができます: 不規則であるか、静的であるか、推論されたコード化。
6.3.5. Timestamp Stride
6.3.5. タイムスタンプストライド
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.
t_ストライド制御フィールドはスケーリングされたRTPタイムスタンプコード化に使用されます(セクション6.6.8を見てください)。 それは連続したRTP一連番号の間のRTPタイムスタンプの予想された増加を定義します。
6.3.6. Time Stride
6.3.6. 時間ストライド
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.
時間_ストライド制御フィールドはタイマベースの圧縮コード化に使用されます(セクション6.6.9を見てください)。 タイマベースの圧縮が連続したRTPパケットの間の到着時間に使用されているとき、時間_ストライドは予想された違いに設定されるべきです。
Pelletier & Sandlund Standards Track [Page 22] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[22ページ]
6.3.7. CRC-3 for Control Fields
6.3.7. 制御フィールドへのCRC-3
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は共同_に、一般的なヘッダー形式と修理ヘッダーがタイプする共同_に存在しています。
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.
減圧装置がいつも一般的に共同_を処理するときこの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のどちらかを使用することで減圧試みについて確かめることができるなら、減圧装置はまだ減圧されたヘッダーを上側の層に送っているかもしれません。 これは保護された制御フィールドがそれらのそれぞれの値をアップデートするヘッダー(すなわち、_の共同コモンか_の共同修理)を減圧するのにいつも使用されるというわけではないからです。
The CRC polynomial and coverage of this CRC-3 is defined in Section 6.6.11.
このCRC-3のCRC多項式と適用範囲はセクション6.6.11で定義されます。
6.4. Reconstruction and Verification
6.4. 再建と検証
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.
CRCがIRヘッダーの中に運んだ8ビットを使用して、減圧装置はいつも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 MUST NOTを使用することで減圧が試みるものについて確かめることができません。パケット、上側の層に渡します。
Pelletier & Sandlund Standards Track [Page 23] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[23ページ]
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を使用して、どんな減圧試みの結果についても確かめなければなりません。
6.5. Compressed Header Chains
6.5. 圧縮されたヘッダーチェインズ
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 | 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 |
+----------------------------------+---------------+
+----------------------------------+---------------+ | プロトコル| プロトコル_名| +----------------------------------+---------------+ | IPv4 RFC0791| ipv4| | IPv6 RFC2460| ipv6| | UDP RFC0768| udp| | RTP RFC3550| rtp| | 超能力RFC4303| esp| | UDP-Lite RFC3828| udp_lite| | ああ、RFC4302| ああ| | GRE RFC2784、RFC2890| gre| | RFC2004を採掘してください。| 私のもの| | IPv6目的地オプションRFC2460| dest_は選ばれます。| | IPv6はホップでオプションRFC2460を飛び越します。| ホップ_は選ばれます。| | IPv6ルート設定ヘッダーRFC2460| 総崩れする_は選ばれます。| +----------------------------------+---------------+
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.
静的なチェーンは圧縮されるプロトコルヘッダーのチェーンの各ヘッダーあたり1つの項目から成ります、一番はずれのIPヘッダーから始めて。 ヘッダー形式の形式的記述では、それぞれのヘッダータイプのためのこの静的なチェーンの品目は<プロトコル_名前>_静電気とラベルされます。 静的なチェーンはIRヘッダー形式に使用されるだけです。
Pelletier & Sandlund Standards Track [Page 24] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[24ページ]
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.
ダイナミックなチェーンは圧縮されるプロトコルヘッダーのチェーンの各ヘッダーあたり1つの項目から成ります、一番はずれのIPヘッダーから始めて。 ヘッダー形式の形式的記述では、それぞれのヘッダータイプのためのダイナミックなチェーンの品目は<プロトコル_名前>_動力とラベルされます。 ダイナミックなチェーンはIRと修理ヘッダーがフォーマットする共同_で使用されるだけです。
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の一般形式を使用するそれぞれの圧縮されたヘッダーに関しては、圧縮されたヘッダーの一般形式の特定の位置で不規則なチェーンを追加します。 「ヘッダー形式の形式的記述では、それぞれのヘッダータイプのための不規則なチェーンの品目は名前が」 _不規則によってsuffixedされる形式です。」 不規則なチェーンは_の修理の共同形式以外のすべての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)をコード化しながら、相当に通過されます)、どんな不規則なチェーンの品目を使用したらよいかを決定します。 また、外側のIPヘッダーのための不規則なチェーンの品目の形式も、TTL/ホップLimitと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]、超能力[RFC4303]、UDP-Lite[RFC3828]、IPv4[RFC0791]、IPv6[RFC2460]、AH[RFC4302]、GRE[RFC2784][RFC2890]、MINE[RFC2004]、IPv6 Destination Optionsヘッダー[RFC2460]、ホップによるIPv6 Hop Optionsヘッダー[RFC2460]、およびIPv6ルート設定ヘッダー[RFC2460]のためにチェーンを定義します。
6.6. Header Formats and Encoding Methods
6.6. ヘッダー形式と方法をコード化すること。
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]で定義されます、他の方法はこのセクションで定義されますが。
Pelletier & Sandlund Standards Track [Page 25] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[25ページ]
6.6.1. baseheader_extension_headers
6.6.1. baseheader_拡大_ヘッダー
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.
彼らのいずれもコード化しないで最も奥深いIPヘッダーの拡張ヘッダーのすべての分野にわたる方法スキップをコード化するbaseheader_拡大_ヘッダー。 これらの拡張ヘッダーの分野は代わりに不規則なチェーンでコード化されます。
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.
ベースヘッダーは正式な記法の構文に従うために拡張ヘッダーの表現を定義します。 このコード化方法はこの表現を提供します。
6.6.2. baseheader_outer_headers
6.6.2. baseheaderの_の外側の_ヘッダー
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の_の外側の_ヘッダーは最も奥深い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_拡大_ヘッダーには、同様に、上の方法をコード化するのが、ヘッダー形式の定義をシンタクス上正しく保つのに必要です。 それは、COヘッダーのために、IPヘッダーと彼らのそれぞれの拡張ヘッダー(最も奥深いIPヘッダーの前に位置するすなわちすべてのヘッダー)にトンネルを堀ると説明します(セクション6.8.2を見てください)。
6.6.3. inferred_udp_length
6.6.3. 推論された_のudp_長さ
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 Lengthでカバーされている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 Checksum Coverage分野に使用されます。
6.6.4. inferred_ip_v4_header_checksum
6.6.4. 推論された_ip_v4_ヘッダー_チェックサム
This encoding method compresses the header checksum field of the IPv4 header. This checksum is defined in RFC 791 [RFC0791] as follows:
このコード化方法はIPv4ヘッダーのヘッダーチェックサム分野を圧縮します。 このチェックサムは以下のRFC791[RFC0791]で定義されます:
Pelletier & Sandlund Standards Track [Page 26] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[26ページ]
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.
その結果方法をコード化する推論された_ip_v4_ヘッダー_チェックサムはIPv4ヘッダーのヘッダーチェックサム分野をゼロ・ビットのサイズまで圧縮します、すなわち、ビットが全く圧縮されたヘッダーでこの分野に伝えられません。 方法をコード化しながらこれを使用して、減圧装置は、上の計算を使用することでこの分野の値を推論します。
The compressor MAY use the header checksum to validate the correctness of the header before compressing it, to avoid processing a corrupted header.
コンプレッサーは、崩壊したヘッダーを処理するのを避けるためにそれを圧縮する前にヘッダーの正当性を有効にするのにヘッダーチェックサムを使用するかもしれません。
6.6.5. inferred_mine_header_checksum
6.6.5. 推論された_私のもの_ヘッダー_チェックサム
This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in RFC 2004 [RFC2004] as follows:
このコード化方法は最小量のカプセル化ヘッダーチェックサムを圧縮します。 このチェックサムは以下のRFC2004[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.
方法をコード化する推論された_私のもの_ヘッダー_チェックサムは最小量のカプセル化ヘッダーチェックサムをゼロ・ビットのサイズまで圧縮します、すなわち、ビットが全く圧縮されたヘッダーでこの分野に伝えられません。 方法をコード化しながらこれを使用して、減圧装置は、上の計算を使用することでこの分野の値を推論します。
Pelletier & Sandlund Standards Track [Page 27] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[27ページ]
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.
コンプレッサーは、崩壊したヘッダーを処理するのを避けるためにそれを圧縮する前にヘッダーの正当性を有効にするのに最小量のカプセル化ヘッダーチェックサムを使用するかもしれません。
6.6.6. inferred_ip_v4_length
6.6.6. 推論された_ip_v4_の長さ
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ヘッダーの全長分野は以下のRFC791[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.
総Lengthはインターネットヘッダーとデータを含む八重奏で測定されたデータグラムの長さです。 この分野は、データグラムの長さが最大6万5535の八重奏であることを許容します。
The inferred_ip_v4_length encoding method compresses the IPv4 header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
方法をコード化する推論された_ip_v4_の長さはIPv4ヘッダーチェックサムをゼロ・ビットのサイズまで圧縮します、すなわち、ビットが全く圧縮されたヘッダーでこの分野に伝えられません。 方法をコード化しながらこれを使用して、減圧装置は、減圧の後に八重奏で全体のパケットの長さを数えることによって、この分野の値を推論します。
6.6.7. inferred_ip_v6_length
6.6.7. 推論された_ip_v6_の長さ
This encoding method compresses the payload length field in the IPv6 header. This length field is defined in RFC 2460 [RFC2460] as follows:
このコード化方法はIPv6ヘッダーのペイロード長分野を圧縮します。 この長さの分野は以下のRFC2460[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.
方法をコード化する「推論された_ip_v6_の長さ」は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.
ペイロード長分野の値がパケットの長さに合っていないのでこれが方法をコード化している状態で、RFC2675[RFC2675]のジャンボなペイロードオプションを使用しているIPv6ヘッダーが圧縮性にならないでしょう。
Pelletier & Sandlund Standards Track [Page 28] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[28ページ]
6.6.8. Scaled RTP Timestamp Compression
6.6.8. スケーリングされたRTPタイムスタンプ圧縮
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.
このセクションはRTPタイムスタンプをスケーリングするのに使用されるencodingsに関する追加詳細を明らかにします、セクション6.8.2で.4に正式な記法で定義されるように
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 Sequence Numberの(SN)の増加の倍数増加して、したがって、スケーリングされたコード化の適当な候補です。 このけた移動子は正式な記法とのプロフィールの定義におけるt_ストライドとラベルされます。 コンプレッサーは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.
けた移動子t_ストライドのデフォルト値はセクション6.8.2で.4に定義されるように160です。 t_ストライドに異価を使用するために、コンプレッサーはこの情報を運ぶことができるヘッダー形式の1つを使用することでt_ストライドの値を明らかに減圧装置にアップデートします。
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.
コンプレッサーがt_ストライドのデフォルト値と異なったけた移動子を使用すると、減圧装置がタイムスタンプのために首尾よくスケーリング機能の残り(t_オフセット)について計算したという十分な信用がいったんあると、それは新しいけた移動子を使用できるだけです。 コンプレッサーは、減圧装置が現在のt_ストライドに基づく残りを確立するのを許容するために送付の非スケーリングされたタイムスタンプ値でこれを達成します。 コンプレッサーはt_ストライドの値を証明するのに使用される同じ圧縮されたヘッダーで非スケーリングされたタイムスタンプを送るかもしれません。
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.
コンプレッサーがそれを検出するとき、残り(t_オフセット)価値は変化して、それは上で説明されるように残りを復職させる前にスケーリングされたタイムスタンプコード化を使用する圧縮されたヘッダー形式を選択してはいけません。
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.
t_ストライドがゼロと等しい間、スケーリングされたタイムスタンプビットを含んでいて、減圧装置が圧縮されたヘッダーを受けるなら、それは上側の層とそれにパケットを渡してはいけません。SHOULDはCRC検証の故障としてこれを扱います。
Pelletier & Sandlund Standards Track [Page 29] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[29ページ]
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分野に適用されるかどうかが、コンプレッサー実現(すなわち、スケーリングの使用はOPTIONALである)まであって、tsc_インディケータ制御フィールドによって示されます。 スケーリングがRTP TS分野に適用されるといけないので、コンプレッサーによって使用されるt_ストライドの値は実現まで達しています。 RTP SNの連続したユニット増加の間のRTPタイムスタンプの予想された増加に設定されるt_ストライドの値は最も多くの利得をスケーリングされたコード化に提供するでしょう。 他の値は、同じ利得をいくつかの状況に提供しますが、他のもので利得を下げるかもしれません。
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の推論された_スケーリングされた_分野コード化は、タイムスタンプをコード化するのに使用されます。
6.6.9. timer_based_lsb
6.6.9. タイマ_は_lsbを基礎づけました。
The timer-based compression encoding method, timer_based_lsb, compresses a field whose change pattern approximates a linear function of the time of day.
タイマベース、方法をコード化する圧縮(_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>)
t_は=をスケーリングしました: = タイマ_は_lsbを基礎づけました。(_<時間ストライド_param>、<num_lsbs_param>、<のオフセット_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」というパラメタと「オフセット_param」は、lsbコード化に使用するパラメタとすなわち、最下位ビットの数とそれぞれ相殺された解釈間隔です。 「_時間ストライド_param」というパラメタは制御フィールド時間_ストライドの文脈値を表します。
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_審判_は=tsc_審判のために+ (a--_審判)/時間_ストライドを進めました。
Pelletier & Sandlund Standards Track [Page 30] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[30ページ]
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_審判は分野のスケーリングされた表現の基準値です。 - aは解読する値に関連している到着時間です。 - _審判は参照ヘッダーに関連している到着時間です。 - _審判_が進めたtscは分野のスケーリングされた価値の近似です。
The lsb encoding is then applied using the num_lsbs_param bits received in the compressed header and the tsc_ref_advanced as "ref_value" (as per Section 4.11.5 of [RFC4997]).
そして、lsbコード化は、圧縮されたヘッダーに受け取られたnum_lsbs_paramビットと「審判_値」として高度なtsc_審判_(.5セクション4.11[RFC4997]に従って)を使用することで適用されます。
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:
制御フィールド時間_ストライドは、_のベースの_lsbタイマ方法がCOヘッダーで使用されるかどうかを制御します。 減圧装置SHOULDがaとのCLOCK_RESOLUTIONオプションに値を全く送らない、:
o it receives a non-zero time_stride value, and
o そしてそれが非ゼロ時間_ストライド価値を受ける。
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.
タイマベースの圧縮のサポートと用法はコンプレッサーと減圧装置の両方のためのOPTIONALです。 コンプレッサーは、それがCLOCK_RESOLUTIONオプションのために非ゼロ値を受けたとき、時間_ストライド制御フィールドを非ゼロ値に設定するのに必要ではありません。
6.6.10. inferred_scaled_field
6.6.10. 推論された_は_分野をスケーリングしました。
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:
方法をコード化する推論された_スケーリングされた_分野はMSNと関連して変化すると定義して、何らかのけた移動子でMSNに関する増加をスケーリングできる分野をコード化します。 このコード化方法はスケーリングされた分野へのどんなビットも含まない圧縮されたヘッダー形式に使用されます。 この場合、減圧装置はMSN分野からスケーリングされた分野の非スケーリングされた値を推論します。 以下の公式によると、非スケーリングされた値は計算されます:
unscaled_value = delta_msn * stride + reference_unscaled_value
デルタ_msn*ストライド+参照の_の非スケーリングされた__値=価値を非スケーリングしました。
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
「デルタ_msn」が文脈のMSNの基準値とMSNの値の間で減圧されたMSNの違いであるところ
Pelletier & Sandlund Standards Track [Page 31] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[31ページ]
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.
このパケットから、「参照_は_値を非スケーリングしました」は文脈でスケーリングされる分野の値です、そして、「ストライド」はこの分野へのスケーリング値です。
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
タイムスタンプ=デルタ_msn*t_ストライド+参照_タイムスタンプ
6.6.11. control_crc3_encoding
6.6.11. コントロール_crc3_コード化
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.
方法をコード化するコントロール_crc3_は多くの制御フィールドにわたって計算されたCRCを提供します。 方法をコード化するこの定義は"crc"のように.6セクション4.11[RFC4997]で指定された方法をコード化するのにおいて同じです、制御フィールドの連結されたリストでCRCでカバーされたデータを与えるということである違いで。
In other words, the definition of the control_crc3_encoding method is equivalent to the following definition:
言い換えれば、方法をコード化するコントロール_crc3_の定義は以下の定義に同等です:
control_crc_encoding(ctrl_data_value, ctrl_data_length)
{
UNCOMPRESSED {
}
_(ctrl_データ_価値、ctrl_データ_の長さ)をコード化するcrc_を制御してください、UNCOMPRESSED{ }
COMPRESSED {
control_crc3 =:=
crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
}
}
COMPRESSED、_crc3=を制御してください: =crc(3、0×06、0×07、ctrl_データ_価値、ctrl_データ_の長さ)[ 3 ]
where the parameter "ctrl_data_value" binds to the concatenated values of the following control fields, in the order listed below:
「ctrl_データ_価値」というパラメタが以下にリストアップされたオーダーにおける、以下の制御フィールドの連結された値に付くところ:
o reorder_ratio, 2 bits padded with 6 MSB of zeroes
o 追加注文_比、ゼロの6MSBと共に水増しされた2ビット
o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o t_ストライド、32ビット(プロフィール0×0101と0x0107のためだけの)
o time_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o 時間_ストライド、32ビット(プロフィール0×0101と0x0107のためだけの)
o msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and
0x0107)
o msn、16ビット(プロフィール0×0101、0×0103、および0x0107には適切でない)です。
o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only for
profiles 0x0107 and 0x0108)
o 適用範囲_の振舞い、ゼロの6MSBと共に水増しされた2ビット(プロフィール0×0107と0x0108のためだけの)
Pelletier & Sandlund Standards Track [Page 32] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[32ページ]
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_イド_の振舞い、一番はずれのヘッダーから始める圧縮性のヘッダーチェーンにおけるそれぞれのIPヘッダーあたり1つの八重奏。 各八重奏はゼロの6MSBsと共に水増しされた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_データ_の長さ」は特定のプロフィールに適切な制御フィールドの長さに付きます。
The decompressor uses the resulting 3-bit CRC to validate the control fields that are updated by the co_common and co_repair header formats; this CRC cannot be used to verify the outcome of a decompression attempt.
減圧装置は一般的に共同_によってアップデートされる制御フィールドと修理ヘッダーがフォーマットする共同_を有効にするのに結果として起こる3ビットのCRCを使用します。 減圧試みの結果について確かめるのにこのCRCを使用できません。
This CRC protects the update of control fields, as the updated values are not always used to decompress the header that carries them and thus are not protected by the CRC-7 verification. This prevents impairments that could occur if the decompression of a co_common or of a co_repair succeeds and the decompressor sends positive feedback, while for some reason the control fields are incorrectly updated.
このCRCは制御フィールドのアップデートを保護します、アップデートされた値が、それらを運ぶヘッダーを減圧するのにいつも使用されるというわけではなくて、その結果、CRC-7検証で保護されません。 共同_に、修理は成功します、そして、これが一般的に共同_の減圧であるなら起こるかもしれない損傷を防ぐか、または減圧装置は積極的なフィードバックを送ります、不当にある理由で制御フィールドをアップデートしますが。
6.6.12. inferred_sequential_ip_id
6.6.12. 推論された_連続した_ip_イド
This encoding method is used with a sequential IP-ID behavior (sequential or sequential byte-swapped) and when there are no coded IP-ID bits in the compressed header. In this case, the IP-ID offset from the MSN is constant, and the IP-ID increases by the same amount as the MSN (similar to the inferred_scaled_field encoding method).
このコード化方法が連続したIP-IDの振舞いと共に使用される、(連続するか連続する、バイトと交換される、)、そして、コード化されなかったIP-IDビットがいつ圧縮されたヘッダーにあるか。 この場合、MSNから相殺されたIP-IDは一定です、そして、MSN(方法をコード化する推論された_スケーリングされた_分野と同様の)と同じ量に従って、IP-IDは増加します。
The decompressor calculates the value for the IP-ID according to the following formula:
以下の公式によると、減圧装置はIP-IDに値について計算します:
IP-ID = delta_msn + reference_IP_ID_value
デルタ_msn+参照_IP_ID_IP-ID=価値
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.
「デルタ_msn」が文脈のMSNの基準値と圧縮されたヘッダーに関連づけられたMSNの解凍された値の違いであり、「参照_IP_ID_価値」が文脈のIP-IDの値であるところで。 交換されたIP-IDの振舞い(_ip_イド_振舞い_最も奥深いときに、すなわち、_IP_ID BEHAVIORへのセットはSEQUENTIAL_SWAPPEDです、)のために、「参照_IP_ID_価値」と「IP-ID」は文脈のバイトと対応に関して交換された分野です。
If the IP-ID behavior is random or zero, this encoding method does not update any fields.
IP-IDの振舞いが無作為であるか、またはゼロ、このコード化方法が無作為でないなら、あらゆる分野をアップデートしてください。
Pelletier & Sandlund Standards Track [Page 33] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[33ページ]
6.6.13. list_csrc(cc_value)
6.6.13. リスト_csrc(cc_値)
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_値)をこれに通過します: これはRTPヘッダーから出られるCCグラウンドの値です。 減圧装置が、減圧装置が正しくCC分野を再建できるリストの件数にこの引数の値を縛るのに必要です。
6.6.13.1. List Compression
6.6.13.1. リスト圧縮
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 |
+--------+--------+--...--+--------+
+--------+--------+--...--+--------+ リスト: | 項目1| 項目2| | 項目n| +--------+--------+--...--+--------+
When performing list compression on a CSRC list, each item is the uncompressed value of one CSRC identifier.
CSRCリストにリスト圧縮を実行するとき、各個条は1つのCSRC識別子の解凍された値です。
The basic principles of list-based compression are the following:
リストベースの圧縮の基本原理は以下です:
When initializing the context:
文脈を初期化するとき:
1) The complete representation of the list of CSRC identifiers is
transmitted.
1) CSRC識別子のリストの完全表記は伝えられます。
Then, once the context has been initialized:
次に、一度、文脈は初期化されたことがあります:
2) When the list is unchanged, a compressed header that does not
contain information about the list can be used.
2) リストが変わりがないときに、リストの情報を含まない圧縮されたヘッダーは使用できます。
3) When the list changes, a compressed list is sent in the compressed
header, including a representation of its structure and order.
Previously unknown items are sent uncompressed in the list, while
previously known items are only represented by an index pointing
to the item stored in the context.
3) リストが変化するとき、圧縮されたヘッダーで圧縮されたリストを送ります、その構造と注文の表現を含んでいて。 以前、リストで解凍されていた状態で未知の商品を送ります、以前に知られている項目は文脈に格納された項目を示すインデックスによって表されるだけですが。
Pelletier & Sandlund Standards Track [Page 34] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[34ページ]
6.6.13.2. Table-based Item Compression
6.6.13.2. テーブルベースの項目圧縮
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.
コンプレッサーは概念的に「インデックス」を使用することで索引をつけられたすべての項目を含む項目テーブルを維持します。 コンプレッサーが減圧装置が項目の間のマッピングを観測したという信用とそれらのそれぞれのインデックスを十分に獲得するまで、圧縮されたリストで(Item、索引をつけてください)組を一緒に送ります。 減圧装置、または楽観的なアプローチを使用することで組を送ることによって(Item、索引をつけてください)、承認のレセプションから信用を得ます。 いったん信用を得ると、項目の存在を示すためにこのインデックスに対応しながら、圧縮されたリストでインデックスだけを送ります。
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.
減圧装置は概念的に組が受けたすべて(Item、索引をつける)を含む項目テーブルを維持します。 (Item、索引をつけてください)組が受け取られていて、減圧がうまくいっている(CRC検証、またはCRC-8合法化)ときはいつも、項目テーブルをアップデートします。 付随のItemなしでIndexを受け取るときはいつも、減圧装置はテーブルから項目を検索します。
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.
付随のItemなしでインデックスを受け取って、減圧装置にこのインデックスのための何か文脈がないなら、減圧装置は上側の層にパケットを渡してはいけません。
6.6.13.3. Encoding of Compressed Lists
6.6.13.3. 圧縮されたリストのコード化
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 項目のテーブル、および項目の圧縮された表現がリストに存在しているかどうかを示す存在ビットへのIndex。
o an item (if the presence bit is set).
o 項目(存在ビットが設定されるなら)。
Pelletier & Sandlund Standards Track [Page 35] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[35ページ]
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
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 予約されます。|PS| m| +---+---+---+---+---+---+---+---+ | ξ_1…, ξ_m| m八重奏、またはm*4ビット/--- --- --- ---/ | : 詰め物: 0とPS=mが変な+であるなら---+---+---+---+---+---+---+---+ | | /項目_1…, 項目/可変です。| | +---+---+---+---+---+---+---+---+
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の品目の数。 リスト_csrcコード化(セクション6.6.13を見る)に関するcc_値の引数の値も。
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.
ξ_1…, ξ_m: m XIの品目 各XIは解凍されたヘッダーに現れるように解凍されたヘッダーの項目のリスト、同次における1つの項目を表します。
The format of an XI item is as follows:
XIの品目の形式は以下の通りです:
0 1 2 3
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 +---+---+---+---+ PS=0: | X| インデックス| +---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ PS=1: | X| 予約されます。| インデックス| +---+---+---+---+---+---+---+---+
X: Indicates whether the item is present in the list:
X: 項目がリストに存在しているかどうかを示します:
Pelletier & Sandlund Standards Track [Page 36] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[36ページ]
X = 1 indicates that the item corresponding to the Index is
sent in the Item_1, ..., Item_n list;
X=1は、Indexに対応する商品がItem_1で送られるのを示します…, 項目リスト。
X = 0 indicates that the item corresponding to the Index is
not sent.
X=0は、Indexに対応する商品が送られないのを示します。
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
以下に索引をつけてください。 項目テーブルへのインデックス。 .4は、6.6に.13を区分するのを見ます。
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 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | ξ_k| ξ_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ビットのPadding分野は存在しています。 Padding分野をゼロに設定しなければなりません。 さもなければ、減圧装置はパケットを捨てなければなりません。
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: 各個条はXI1でX=1でXIに対応しています…, XI m。 Itemリストにおける各エントリーは1つのCSRC識別子の解凍された表現です。
6.6.13.4. Item Table Mappings
6.6.13.4. 項目テーブルマッピング
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.
項目テーブル繰返し要素の並び圧縮は16の異なった項目に制限されます、RTPヘッダーが15の同時のCSRC識別子しか高々運ぶことができないので。 項目が/で項目テーブルから交換されるときだけ、項目テーブルに16以上の項目を持っているという効果はわずかなオーバーヘッドをコンプレッサーに引き起こすでしょう。
6.6.13.5. Compressed Lists in Dynamic Chain
6.6.13.5. ダイナミックなチェーンにおける圧縮されたリスト
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-ビットを設定しなければなりません。 また、減圧装置文脈で以前に項目テーブルで確立した項目がこのパケットから減圧されたリストに示さないすべてを保有しなければなりません。
Pelletier & Sandlund Standards Track [Page 37] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[37ページ]
6.7. Encoding Methods with External Parameters as Arguments
6.7. 議論として外部のパラメタで方法をコード化します。
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.
ヘッダー形式のROHC-FN[RFC4997]仕様の範囲の外の.4には1つ以上の議論があるセクション6.8.2におけるパラメタの価値の派生がそうである方法をコード化する数。
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(プロフィール_価値、追加注文_比率_価値)
o udp_lite(profile_value, reorder_ratio_value,
coverage_behavior_value)
o udp_lite(プロフィール_価値、追加注文_比率_価値、適用範囲_振舞い_価値)
o esp(profile_value, reorder_ratio_value)
o esp(プロフィール_価値、追加注文_比率_価値)
o rtp(profile_value, ts_stride_value, time_stride_value,
reorder_ratio_value)
o rtp(プロフィール_価値、t_ストライド_価値、時間_ストライド_価値、追加注文_比率_価値)
o ipv4(profile_value, is_innermost, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value))
o ipv4(_値の輪郭を描いて、_の最も奥深くて、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値です)
o ipv6(profile_value, is_innermost, outer_ip_flag,
reorder_ratio_value))
o ipv6(_プロフィール_値は_の最も奥深くて、外側の_ip_旗であり、追加注文_比率は値です)
o iponly_baseheader(profile_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value)
o iponly_baseheader(プロフィール_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値)
o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
o udp_baseheader(プロフィール_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値)
o udplite_baseheader(profile_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value)
o udplite_baseheader(プロフィール_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値)
o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
o esp_baseheader(プロフィール_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値)
o rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o rtp_baseheader(プロフィール_価値、t_ストライド_価値、時間_ストライド_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値)
o udplite_rtp_baseheader(profile_value, ts_stride_value,
time_stride_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value, coverage_behavior_value)
o udplite_rtp_baseheader(プロフィール_価値、t_ストライド_価値、時間_ストライド_価値、外側の_ip_旗、ip_イド_振舞い_価値、追加注文_比率_価値、適用範囲_振舞い_価値)
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
以下は以下にリストアップされたすべてのパラメタに申し込みます: コンプレッサーでは、各パラメタのための推薦に従って、パラメタの値は設定されます。 減圧装置、値で
Pelletier & Sandlund Standards Track [Page 38] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[38ページ]
of the parameter is set to undefined and will get bound by encoding methods, except where otherwise noted.
パラメタは、未定義の状態で設定されて、別の方法で述べられるところを除いて、方法をコード化することによって、縛られるでしょう。
The following is a list of external arguments with their respective definition:
↓これは彼らのそれぞれの定義との外部の議論のリストです:
o profile_value:
o _値の輪郭を描いてください:
Set to the 16-bit number that identifies the profile used to
compress this packet. When processing the static chain at the
decompressor, this parameter is set to the value of the profile
field in the IR header (see Section 6.8.1).
このパケットを圧縮するのに使用されるプロフィールを特定する16ビットの数にセットしてください。 減圧装置で静的なチェーンを処理するとき、このパラメタはIRヘッダーのプロフィール分野の値に設定されます(セクション6.8.1を見てください)。
o 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.
2ビットの整数値にセットしてください、名前が接頭語REORDERING_、セクション6.8.2で.4に定義されるように始まる定数の1つを使用して
o ip_id_behavior_value:
o ip_イド_振舞い_価値:
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.
2ビットの整数値にセットしてください、名前が_接頭語IP_ID BEHAVIOR_、セクション6.8.2で.4に定義されるように始まる定数の1つを使用して
o coverage_behavior_value:
o 適用範囲_振舞い_価値:
Set to a 2-bit integer value, using one of the constants whose
name begins with the prefix UDP_LITE_COVERAGE_ and as defined
in Section 6.8.2.4.
2ビットの整数値にセットしてください、名前が接頭語UDP_LITE_COVERAGE_、セクション6.8.2で.4に定義されるように始まる定数の1つを使用して
o outer_ip_flag:
o 外側の_ip_旗:
This parameter is set to 1 if at least one of the TOS/TC or
TTL/Hop Limit fields in outer IP headers has changed compared
to their reference values in the context; otherwise, it is set
to 0. This flag may only be set to 1 for the "co_common"
header format in the different profiles.
文脈の彼らの基準値と比べて、少なくとも外側のIPヘッダーのTOS/TCかTTL/ホップLimit分野の1つが変化したなら、このパラメタは1に設定されます。 さもなければ、それは0に設定されます。 この旗は異なったプロフィールの「共同_一般的な」ヘッダー形式のために1にしか設定されないかもしれません。
o is_innermost:
o _最も奥深いです:
This boolean flag is set to 1 when processing the innermost of
the compressible IP headers; otherwise, it is set to 0.
圧縮性のIPヘッダーの最も奥深さを処理するとき、この論理演算子旗は1に設定されます。 さもなければ、それは0に設定されます。
Pelletier & Sandlund Standards Track [Page 39] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[39ページ]
o ts_stride_value
o t_ストライド_価値
The value of this parameter should be set to the expected
increase in the RTP Timestamp between consecutive RTP sequence
numbers. The value selected is implementation-specific. See
also Section 6.6.8.
このパラメタの値は連続したRTP一連番号の間のRTP Timestampの予想された増加に設定されるべきです。 選択された値は実現特有です。 また、セクション6.6.8を見てください。
o time_stride_value
o 時間_ストライド_価値
The value of this parameter should be set to the expected
inter-arrival time between consecutive packets for the flow.
The value selected is implementation-specific. This parameter
MUST be set to zero, unless the compressor has received a
feedback message with the CLOCK_RESOLUTION option set to a non-
zero value. See also Section 6.6.9.
このパラメタの値は流れのための連続したパケットの間の予想された相互到着時間までセットであるべきです。 選択された値は実現特有です。 このパラメタをゼロに設定しなければならなくて、コンプレッサーがフィードバックメッセージを受け取っていない場合、CLOCK_RESOLUTIONオプションで、値は非ゼロにセットしていました。 また、セクション6.6.9を見てください。
6.8. Header Formats
6.8. ヘッダー形式
ROHCv2 profiles use two different header types: the Initialization and Refresh (IR) header type, and the Compressed header type (CO).
ROHCv2プロフィールは2つの異なったヘッダータイプを使用します: 初期設定、Refresh(IR)ヘッダータイプ、およびCompressedヘッダータイプ(CO)。
The CO header type defines a number of header formats: there are two sets of base header formats, with a few additional formats that are common to both sets.
COヘッダータイプは多くのヘッダー形式を定義します: いくつかの両方のセットに共通の追加形式がある2セットのベースヘッダー形式があります。
6.8.1. Initialization and Refresh Header Format (IR)
6.8.1. 初期設定、ヘッダー形式をリフレッシュしてください。(IR)
The IR header format uses the structure of the ROHC IR header as defined in Section 5.2.2.1 of [RFC4995].
IRヘッダー形式は、セクション5.2.2で.1[RFC4995]を定義するので、ROHC IRヘッダーの構造を使用します。
Header type: IR
ヘッダータイプ: IR
This header format communicates the static part and the dynamic
part of the context.
このヘッダー形式は静的な部分と文脈のダイナミックな部分を伝えます。
Pelletier & Sandlund Standards Track [Page 40] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[40ページ]
The ROHCv2 IR header has the following format:
ROHCv2IRヘッダーには、以下の形式があります:
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
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : CIDを加えている八重奏: 小さいCIDsと(CID!=0)+のために---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | IRタイプ八重奏+---+---+---+---+---+---+---+---+ : : CID / 1-2八重奏の/0-2八重奏、大きいCIDsのために: : +---+---+---+---+---+---+---+---+ | プロフィール| 1 八重奏+---+---+---+---+---+---+---+---+ | CRC| 1 八重奏+---+---+---+---+---+---+---+---+ | | /静的なチェーン/可変長| | - - - - - - - - - - - - - - - - | | /ダイナミックなチェーン/可変長| | - - - - - - - - - - - - - - - -
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: どんなCID分野も含んで、[RFC4995]で多項式を使用するダイナミックなチェーンの端まで定義された全体のIRヘッダーの上の8ビットのCRC。 CRCを計算する目的のために、CRC分野はゼロです。
Static chain: See Section 6.5.
静的なチェーン: セクション6.5を見てください。
Dynamic chain: See Section 6.5.
ダイナミックなチェーン: セクション6.5を見てください。
6.8.2. Compressed Header Formats (CO)
6.8.2. 圧縮されたヘッダー形式(CO)
6.8.2.1. Design Rationale for Compressed Base Headers
6.8.2.1. 圧縮された基地のヘッダーのためのデザイン原理
The compressed header formats are defined as two separate sets for each profile: one set for the headers where the innermost IP header contains a sequential IP-ID (either network byte order or byte- swapped), and one set for the headers without sequential IP-ID (either random, zero, or no IP-ID). There are also a number of common header formats shared between both sets. In the description below, the naming convention used for header formats that belong to the sequential set is to include "seq" in the name of the format, while similarly "rnd" is used for those that belong to the non- sequential set.
圧縮されたヘッダー形式は各プロフィールあたり別々の2セットと定義されます: 1つが最も奥深いIPヘッダーがヘッダーのために連続したIP-IDなしで連続したIP-ID(ネットワークバイトオーダーかバイトはスワップされた)、および1セットを含むヘッダーのためにセットした、(無作為である、ゼロにもかかわらず、IP-IDがありません) また、両方のセットの間で共有された多くの一般的なヘッダー形式があります。 以下での記述では、連続したセットに属すヘッダー形式に使用される命名規則は形式の名にかけて"seq"を含めることになっています、同様に"rnd"は非連続したセットに属すものに使用されますが。
Pelletier & Sandlund Standards Track [Page 41] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[41ページ]
The design of the header formats is derived from the field behavior analysis found in Appendix A.
Appendix 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 共同_一般的: ダイナミックな分野の確立した変化パターンが変化するとき、文脈をアップデートするのにこの形式を使用できます、ダイナミックな分野のいずれにも。 しかしながら、それらの解凍された値を伝えることによって、すべてのダイナミックな分野をアップデートするというわけではありません。 圧縮された表現を使用することでいくつかの野原を伝えることができるだけです。 めったに変化していない分野が、アップデートする必要があるとき、この形式は特に役に立ちます。 この形式はヘッダーでどんな分野が存在しているかを示す旗のセットを含んでいます、そして、サイズはそれに従って、異なることができます。 この形式は7ビットのCRCによって保護されます。 それは制御フィールドをアップデートできます、そして、その結果、また、それらの分野を保護するために3ビットのCRCを運びます。 この形式は目的において3がフォーマットする[RFC3095]のUOR2拡張子と同様です。
o co_repair: This format can be used to update the context of all
the dynamic fields by conveying their uncompressed value. This is
especially useful when context damage is assumed (e.g., from the
reception of a NACK) and a context repair is performed. This
format is protected by a 7-bit CRC. It also carries a 3-bit CRC
over the control fields that it can update. This format is
similar in purpose to the IR-DYN format of [RFC3095] when
performing context repairs.
o _の共同修理: それらの解凍された値を伝えることによってすべてのダイナミックな分野の文脈をアップデートするのにこの形式を使用できます。 文脈損害が想定されて(例えば、ナックのレセプションから)、文脈修理が実行されるとき、これは特に役に立ちます。 この形式は7ビットのCRCによって保護されます。 また、それはそれがアップデートできる制御フィールドの上まで3ビットのCRCを運びます。 文脈修理を実行するとき、この形式は目的において[RFC3095]のIR-DYN形式と同様です。
o pt_0_crc3: This format conveys only the MSN; it can therefore only
update the MSN and fields that are derived from the MSN, such as
IP-ID and the RTP Timestamp (for applicable profiles). It is
protected by a 3-bit CRC. This format is equivalent to the UO-0
header format in [RFC3095].
o _Pt0_crc3: この形式はMSNだけを運びます。 したがって、それはMSNから得られるMSNと野原をアップデートできるだけです、IP-IDやRTP Timestamp(適切なプロフィールのための)のように。 それは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 _Pt0_crc7: この形式は、_Pt0_crc3と同じ特性を持っていますが、代わりに7ビットのCRCによって保護されて、多く以上の量のlsbによってコード化されたMSNビットを含んでいます。 この形式は再命令の多量か高見逃し誤りレートが起こることができるところで環境で役に立ちます。
Pelletier & Sandlund Standards Track [Page 42] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[42ページ]
The following header format descriptions apply to profiles 0x0101 and 0x0107.
以下のヘッダー書式の記述はプロフィール0×0101と0x0107に適用されます。
o pt_1_rnd: This format can convey changes to the MSN and to the RTP
Marker bit, and it can update the RTP timestamp using scaled
timestamp encoding. It is protected by a 3-bit CRC. It is
similar in purpose to the UO-1 format in [RFC3095].
o _Pt1_rnd: この形式はMSNと、そして、RTP Markerビットへの変化を運ぶことができます、そして、それはスケーリングされたタイムスタンプコード化を使用することで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_イド: この形式はMSNと、そして、IP-IDへの変化を運ぶことができます。 それは3ビットのCRCによって保護されます。 それはUO1IDへの目的が[RFC3095]でフォーマットする同様のコネです。
o pt_1_seq_ts: This format can convey changes to the MSN and to the
RTP Marker bit, and it can update the RTP Timestamp using scaled
timestamp encoding. It is protected by a 3-bit CRC. It is
similar in purpose to the UO-1-TS format in [RFC3095].
o Pt_1_seq_t: この形式はMSNと、そして、RTP Markerビットへの変化を運ぶことができます、そして、それはスケーリングされたタイムスタンプコード化を使用することでRTP Timestampをアップデートできます。 それは3ビットのCRCによって保護されます。 それは目的において[RFC3095]のUO-1-TS形式と同様です。
o pt_2_rnd: This format can convey changes to the MSN, to the RTP
Marker bit, and to the RTP Timestamp. It is protected by a 7-bit
CRC. It is similar in purpose to the UOR-2 format in [RFC3095].
o _Pt2_rnd: この形式はMSNと、そして、RTP Markerビットと、そして、RTP Timestampへの変化を運ぶことができます。 それは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_イド: この形式はMSNと、そして、IP-IDへの変化を運ぶことができます。 それは7ビットのCRCによって保護されます。 それは目的において[RFC3095]のUO2ID形式と同様です。
o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP
Marker bit and it can update the RTP Timestamp using scaled
timestamp encoding. It is protected by a 7-bit CRC. It is
similar in purpose to the UO-2-TS format in [RFC3095].
o Pt_2_seq_t: この形式はMSN、RTP Markerビットへの変化を運ぶことができます、そして、それはスケーリングされたタイムスタンプコード化を使用することでRTP Timestampをアップデートできます。 それは7ビットのCRCによって保護されます。 それは目的において[RFC3095]のUO-2-TS形式と同様です。
o pt_2_seq_both: This format can convey changes to both the RTP
Timestamp and the IP-ID, in addition to the MSN and to the Marker
bit. It is protected by a 7-bit CRC. It is similar in purpose to
the UOR-2-ID extension 1 format in [RFC3095].
o __seqについてPt2_ともに: この形式はRTP TimestampとIP-IDの両方と、そして、MSNに加えたMarkerビットへの変化を運ぶことができます。 それは7ビットのCRCによって保護されます。 それは目的において拡大1が[RFC3095]でフォーマットするUOR2IDと同様です。
The following header format descriptions apply to profiles 0x0102, 0x0103, 0x0104, and 0x0108.
以下のヘッダー書式の記述はプロフィール0×0102、0×0103、0×0104、および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_イド: この形式はMSNと、そして、IP-IDへの変化を運ぶことができます。 それは7ビットのCRCによって保護されます。 それはUO1IDへの目的が[RFC3095]でフォーマットする同様のコネです。
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_イド: この形式はMSNと、そして、IP-IDへの変化を運ぶことができます。 それは7ビットのCRCによって保護されます。 それは目的において[RFC3095]のUO2ID形式と同様です。
Pelletier & Sandlund Standards Track [Page 43] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[43ページ]
6.8.2.2. co_repair Header Format
6.8.2.2. _の共同修理Header Format
The ROHCv2 co_repair header has the following format:
ROHCv2_の修理の共同ヘッダーには、以下の形式があります:
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
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : CIDを加えている八重奏: 小さいCIDsとCID1-15+のために---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 1 | 弁別器+---+---+---+---+---+---+---+---+ : : CID / 1-2八重奏の/0、1、または2八重奏、大きいCIDsであるなら: : +---+---+---+---+---+---+---+---+ |r1| CRC-7| +---+---+---+---+---+---+---+---+ | r2| CRC-3| +---+---+---+---+---+---+---+---+ | | /ダイナミックなチェーン/可変長| | - - - - - - - - - - - - - - - -
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: セクション6.8.2で定義された.4、どこデータ_が全体の解凍されたヘッダーチェーニングとデータ_長さがどこでこのヘッダーチェーンの長さに相当しているかと対応するのを評価する方法をコード化しながらcrc7(データ_価値、データ_の長さ)を使用することで計算された全体の解凍されたヘッダーの上の7ビットのCRC。
r2: MUST be set to zero; otherwise, the decompressor MUST discard
the packet.
r2: ゼロに設定しなければなりません。 さもなければ、減圧装置はパケットを捨てなければなりません。
CRC-3: Encoded using the control_crc3_encoding method defined in
Section 6.6.11.
CRC-3: セクション6.6.11で定義された方法をコード化するコントロール_crc3_を使用することで、コード化されます。
Dynamic chain: See Section 6.5.
ダイナミックなチェーン: セクション6.5を見てください。
6.8.2.3. General CO Header Format
6.8.2.3. 一般COヘッダー形式
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に定義されます)。
Pelletier & Sandlund Standards Track [Page 44] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 44] RFC 5225 ROHCv2 Profiles April 2008
The general format for a compressed header is as follows:
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
: :
--- --- --- --- --- --- --- ---
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:
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:
+------------------+----------------+
| Profile number | profile_name |
+------------------+----------------+
| 0x0101 | rtp |
| 0x0102 | udp |
| 0x0103 | esp |
| 0x0104 | ip |
| 0x0107 | udplite_rtp |
| 0x0108 | udplite |
+------------------+----------------+
+------------------+----------------+ | Profile number | profile_name | +------------------+----------------+ | 0x0101 | rtp | | 0x0102 | udp | | 0x0103 | esp | | 0x0104 | ip | | 0x0107 | udplite_rtp | | 0x0108 | udplite | +------------------+----------------+
6.8.2.4. Header Formats in ROHC-FN
6.8.2.4. Header Formats in ROHC-FN
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].
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].
Pelletier & Sandlund Standards Track [Page 45] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 45] RFC 5225 ROHCv2 Profiles April 2008
// 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.
// NOTE: The irregular, static, and dynamic chains (see Section 6.5) // are defined across multiple encoding methods and are embodied // in the correspondingly named formats within those encoding // methods. In particular, note that the static and dynamic // chains ordinarily go together. The uncompressed fields are // defined across these two formats combined, rather than in one // or the other of them. The irregular chain items are likewise // combined with a baseheader format.
//////////////////////////////////////////// // Constants ////////////////////////////////////////////
//////////////////////////////////////////// // 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;
// 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
// 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;
// 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
// 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;
// Default values for RTP timestamp encoding TS_STRIDE_DEFAULT = 160; TIME_STRIDE_DEFAULT = 0;
//////////////////////////////////////////// // Global control fields ////////////////////////////////////////////
//////////////////////////////////////////// // Global control fields ////////////////////////////////////////////
CONTROL {
CONTROL {
Pelletier & Sandlund Standards Track [Page 46] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 46] RFC 5225 ROHCv2 Profiles April 2008
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 ]; }
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: ///////////////////////////////////////////////
/////////////////////////////////////////////// // Encoding methods not specified in FN syntax: ///////////////////////////////////////////////
baseheader_extension_headers "defined in Section 6.6.1"; baseheader_outer_headers "defined in Section 6.6.2"; control_crc3_encoding "defined in Section 6.6.11"; inferred_ip_v4_header_checksum "defined in Section 6.6.4"; inferred_ip_v4_length "defined in Section 6.6.6"; inferred_ip_v6_length "defined in Section 6.6.7"; inferred_mine_header_checksum "defined in Section 6.6.5"; inferred_scaled_field "defined in Section 6.6.10"; inferred_sequential_ip_id "defined in Section 6.6.12"; inferred_udp_length "defined in Section 6.6.3"; list_csrc(cc_value) "defined in Section 6.6.13"; timer_based_lsb(time_stride, k, p) "defined in Section 6.6.9";
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 ////////////////////////////////////////////
//////////////////////////////////////////// // General encoding methods ////////////////////////////////////////////
static_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
static_or_irreg(flag, width) { UNCOMPRESSED { field [ width ]; }
COMPRESSED irreg_enc {
ENFORCE(flag == 1);
field =:= irregular(width) [ width ];
}
COMPRESSED irreg_enc { ENFORCE(flag == 1); field =:= irregular(width) [ width ]; }
COMPRESSED static_enc {
COMPRESSED static_enc {
Pelletier & Sandlund Standards Track [Page 47] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 47] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(flag == 0);
field =:= static [ 0 ];
}
}
ENFORCE(flag == 0); field =:= static [ 0 ]; } }
optional_32(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
optional_32(flag) { UNCOMPRESSED { item [ 0, 32 ]; }
COMPRESSED present {
ENFORCE(flag == 1);
item =:= irregular(32) [ 32 ];
}
COMPRESSED present { ENFORCE(flag == 1); item =:= irregular(32) [ 32 ]; }
COMPRESSED not_present {
ENFORCE(flag == 0);
item =:= compressed_value(0, 0) [ 0 ];
}
}
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 ];
}
// Send the entire value, or keep previous value sdvl_or_static(flag) { UNCOMPRESSED { field [ 32 ]; }
COMPRESSED present_7bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^7);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '0' [ 1 ];
field [ 7 ];
}
COMPRESSED present_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_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);
COMPRESSED present_21bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^21);
Pelletier & Sandlund Standards Track [Page 48] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 48] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '110' [ 3 ];
field [ 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_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 present_32bit { ENFORCE(flag == 1); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '11111111' [ 8 ]; field [ 32 ]; }
COMPRESSED not_present {
ENFORCE(flag == 0);
field =:= static;
}
}
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 ];
}
// Send the entire value, or revert to default value sdvl_or_default(flag, default_value) { UNCOMPRESSED { field [ 32 ]; }
COMPRESSED present_7bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^7);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '0' [ 1 ];
field [ 7 ];
}
COMPRESSED present_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_14bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^14); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '10' [ 2 ]; field [ 14 ]; }
Pelletier & Sandlund Standards Track [Page 49] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 49] RFC 5225 ROHCv2 Profiles April 2008
COMPRESSED present_21bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^21);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '110' [ 3 ];
field [ 21 ];
}
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_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 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);
}
}
COMPRESSED not_present { ENFORCE(flag == 0); field =:= uncompressed_value(32, default_value); } }
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
lsb_7_or_31 { UNCOMPRESSED { item [ 32 ]; }
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
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 ];
}
}
COMPRESSED lsb_31 { discriminator =:= '1' [ 1 ]; item =:= lsb(31, ((2^31) / 4) - 1) [ 31 ]; } }
crc3(data_value, data_length)
{
crc3(data_value, data_length) {
Pelletier & Sandlund Standards Track [Page 50] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 50] RFC 5225 ROHCv2 Profiles April 2008
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
}
// Encoding method for updating a scaled field and its associated // control fields. Should be used both when the value is scaled // or unscaled in a compressed format. // Does not have an uncompressed side. field_scaling(stride_value, scaled_value, unscaled_value, residue_value) { UNCOMPRESSED { // Nothing }
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_value == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED 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);
}
}
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 Destination options header ////////////////////////////////////////////
ip_dest_opt
{
UNCOMPRESSED {
ip_dest_opt { UNCOMPRESSED {
Pelletier & Sandlund Standards Track [Page 51] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 51] RFC 5225 ROHCv2 Profiles April 2008
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; }
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
DEFAULT { length =:= static; next_header =:= static; value =:= static; }
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
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 { value =:= irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED dest_opt_irregular {
}
COMPRESSED dest_opt_irregular { }
}
}
//////////////////////////////////////////// // IPv6 Hop-by-Hop options header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6 Hop-by-Hop options header ////////////////////////////////////////////
ip_hop_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
ip_hop_opt { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; }
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
DEFAULT { length =:= static; next_header =:= static; value =:= static; }
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_static { next_header =:= irregular(8) [ 8 ]; length =:= irregular(8) [ 8 ]; }
Pelletier & Sandlund Standards Track [Page 52] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 52] RFC 5225 ROHCv2 Profiles April 2008
COMPRESSED hop_opt_dynamic {
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED hop_opt_dynamic { value =:= irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED hop_opt_irregular {
}
COMPRESSED hop_opt_irregular { }
}
}
//////////////////////////////////////////// // IPv6 Routing header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6 Routing header ////////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
ip_rout_opt { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; }
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
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_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 ////////////////////////////////////////////
//////////////////////////////////////////// // GRE Header ////////////////////////////////////////////
optional_lsb_7_or_31(flag)
{
optional_lsb_7_or_31(flag) {
Pelletier & Sandlund Standards Track [Page 53] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 53] RFC 5225 ROHCv2 Profiles April 2008
UNCOMPRESSED {
item [ 0, 32 ];
}
UNCOMPRESSED { item [ 0, 32 ]; }
COMPRESSED present {
ENFORCE(flag == 1);
item =:= lsb_7_or_31 [ 8, 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 ];
}
}
COMPRESSED not_present { ENFORCE(flag == 0); item =:= compressed_value(0, 0) [ 0 ]; } }
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
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 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 ];
}
}
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 { protocol [ 16 ]; }
COMPRESSED ether_v4 {
discriminator =:= '0' [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
}
COMPRESSED ether_v4 { discriminator =:= '0' [ 1 ]; protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; }
COMPRESSED ether_v6 {
discriminator =:= '1' [ 1 ];
COMPRESSED ether_v6 { discriminator =:= '1' [ 1 ];
Pelletier & Sandlund Standards Track [Page 54] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 54] RFC 5225 ROHCv2 Profiles April 2008
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ];
}
}
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; } }
gre
{
UNCOMPRESSED {
c_flag [ 1 ];
r_flag =:= uncompressed_value(1, 0) [ 1 ];
k_flag [ 1 ];
s_flag [ 1 ];
reserved0 =:= uncompressed_value(9, 0) [ 9 ];
version =:= uncompressed_value(3, 0) [ 3 ];
protocol [ 16 ];
checksum_and_res [ 0, 32 ];
key [ 0, 32 ];
sequence_number [ 0, 32 ];
}
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;
}
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_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_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 {
Pelletier & Sandlund Standards Track [Page 55] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 55] RFC 5225 ROHCv2 Profiles April 2008
checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ];
}
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 header /////////////////////////////////////////////
mine
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
}
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;
}
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_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 { } }
/////////////////////////////////////////////
/////////////////////////////////////////////
Pelletier & Sandlund Standards Track [Page 56] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 56] RFC 5225 ROHCv2 Profiles April 2008
// Authentication Header (AH) /////////////////////////////////////////////
// Authentication Header (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 ];
}
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;
}
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_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_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 ];
}
COMPRESSED ah_irregular { sequence_number =:= lsb_7_or_31 [ 8, 32 ]; icv =:= irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; }
}
}
///////////////////////////////////////////// // IPv6 Header /////////////////////////////////////////////
///////////////////////////////////////////// // IPv6 Header /////////////////////////////////////////////
fl_enc
{
UNCOMPRESSED {
fl_enc { UNCOMPRESSED {
Pelletier & Sandlund Standards Track [Page 57] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 57] RFC 5225 ROHCv2 Profiles April 2008
flow_label [ 20 ];
}
flow_label [ 20 ]; }
COMPRESSED fl_zero {
discriminator =:= '0' [ 1 ];
flow_label =:= uncompressed_value(20, 0) [ 0 ];
reserved =:= '0000' [ 4 ];
}
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 ];
}
}
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 ];
}
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 ];
}
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;
}
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 ];
COMPRESSED ipv6_static { version_flag =:= '1' [ 1 ]; innermost_ip =:= irregular(1) [ 1 ];
Pelletier & Sandlund Standards Track [Page 58] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 58] RFC 5225 ROHCv2 Profiles April 2008
reserved =:= '0' [ 1 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
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_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_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_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 { ENFORCE(is_innermost == 1); }
}
}
///////////////////////////////////////////// // IPv4 Header /////////////////////////////////////////////
///////////////////////////////////////////// // IPv4 Header /////////////////////////////////////////////
ip_id_enc_dyn(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
ip_id_enc_dyn(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
Pelletier & Sandlund Standards Track [Page 59] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 59] RFC 5225 ROHCv2 Profiles April 2008
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_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_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 ];
}
}
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(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
COMPRESSED ip_id_seq {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
}
COMPRESSED ip_id_seq { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); }
COMPRESSED ip_id_seq_swapped {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED ip_id_seq_swapped { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); }
COMPRESSED ip_id_rand {
ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED ip_id_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 ];
}
}
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 { version =:= uncompressed_value(4, 4) [ 4 ];
Pelletier & Sandlund Standards Track [Page 60] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 60] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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;
}
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_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 ];
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 ];
Pelletier & Sandlund Standards Track [Page 61] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 61] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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_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_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_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 ];
}
COMPRESSED ipv4_innermost_irregular { ENFORCE(is_innermost == 1); ip_id =:= ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; }
}
}
///////////////////////////////////////////// // UDP Header /////////////////////////////////////////////
///////////////////////////////////////////// // UDP Header /////////////////////////////////////////////
Pelletier & Sandlund Standards Track [Page 62] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 62] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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;
}
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_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_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_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_zero_checksum_irregular { ENFORCE(checksum_used.UVALUE == 0); checksum =:= uncompressed_value(16, 0) [ 0 ]; }
Pelletier & Sandlund Standards Track [Page 63] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 63] RFC 5225 ROHCv2 Profiles April 2008
COMPRESSED udp_with_checksum_irregular {
ENFORCE(checksum_used.UVALUE == 1);
checksum =:= irregular(16) [ 16 ];
}
COMPRESSED udp_with_checksum_irregular { ENFORCE(checksum_used.UVALUE == 1); checksum =:= irregular(16) [ 16 ]; }
}
}
///////////////////////////////////////////// // RTP Header /////////////////////////////////////////////
///////////////////////////////////////////// // RTP Header /////////////////////////////////////////////
csrc_list_dynchain(presence, cc_value)
{
UNCOMPRESSED {
csrc_list;
}
csrc_list_dynchain(presence, cc_value) { UNCOMPRESSED { csrc_list; }
COMPRESSED no_list {
ENFORCE(cc_value == 0);
ENFORCE(presence == 0);
csrc_list =:= uncompressed_value(0, 0) [ 0 ];
}
COMPRESSED 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 ];
}
}
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 ];
}
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 {
CONTROL {
Pelletier & Sandlund Standards Track [Page 64] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 64] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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);
}
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;
}
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 =:= irregular(32) [ 32 ]; }
COMPRESSED rtp_dynamic {
reserved =:= compressed_value(1, 0) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
list_present =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
tis_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
marker =:= irregular(1) [ 1 ];
payload_type =:= irregular(7) [ 7 ];
sequence_number =:= irregular(16) [ 16 ];
timestamp =:= irregular(32) [ 32 ];
ts_stride =:= sdvl_or_default(tss_indicator.CVALUE,
TS_STRIDE_DEFAULT) [ VARIABLE ];
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 ];
Pelletier & Sandlund Standards Track [Page 65] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 65] RFC 5225 ROHCv2 Profiles April 2008
time_stride =:= sdvl_or_default(tis_indicator.CVALUE,
TIME_STRIDE_DEFAULT) [ VARIABLE ];
csrc_list =:= csrc_list_dynchain(list_present.CVALUE,
cc.UVALUE) [ 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_irregular { } }
///////////////////////////////////////////// // UDP-Lite Header /////////////////////////////////////////////
///////////////////////////////////////////// // UDP-Lite Header /////////////////////////////////////////////
checksum_coverage_dynchain(behavior)
{
UNCOMPRESSED {
checksum_coverage [ 16 ];
}
checksum_coverage_dynchain(behavior) { UNCOMPRESSED { checksum_coverage [ 16 ]; }
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
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 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 ];
}
}
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(behavior) { UNCOMPRESSED { checksum_coverage [ 16 ]; }
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED inferred_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED); checksum_coverage =:= inferred_udp_length [ 0 ]; }
COMPRESSED static_coverage {
COMPRESSED static_coverage {
Pelletier & Sandlund Standards Track [Page 66] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 66] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
checksum_coverage =:= static [ 0 ];
}
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC); checksum_coverage =:= static [ 0 ]; }
COMPRESSED irregular_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
checksum_coverage =:= irregular(16) [ 16 ];
}
}
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 ];
}
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);
}
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;
}
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_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_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 ]; }
Pelletier & Sandlund Standards Track [Page 67] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 67] RFC 5225 ROHCv2 Profiles April 2008
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_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 ];
}
}
COMPRESSED udp_lite_irregular { checksum_coverage =:= checksum_coverage_irregular(coverage_behavior.UVALUE) [ 0, 16 ]; checksum =:= irregular(16) [ 16 ]; } }
///////////////////////////////////////////// // ESP Header /////////////////////////////////////////////
///////////////////////////////////////////// // ESP Header /////////////////////////////////////////////
esp(profile_value, reorder_ratio_value)
{
UNCOMPRESSED {
ENFORCE(profile_value == PROFILE_ESP_0103);
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
spi [ 32 ];
sequence_number [ 32 ];
}
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);
}
CONTROL { ENFORCE(profile == profile_value); ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); }
DEFAULT {
spi =:= static;
sequence_number =:= static;
}
DEFAULT { spi =:= static; sequence_number =:= static; }
COMPRESSED esp_static {
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_static { spi =:= irregular(32) [ 32 ]; }
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= irregular(2) [ 2 ];
}
COMPRESSED esp_dynamic { sequence_number =:= irregular(32) [ 32 ]; reserved =:= compressed_value(6, 0) [ 6 ]; reorder_ratio =:= irregular(2) [ 2 ]; }
Pelletier & Sandlund Standards Track [Page 68] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 68] RFC 5225 ROHCv2 Profiles April 2008
COMPRESSED esp_irregular {
}
}
COMPRESSED esp_irregular { } }
/////////////////////////////////////////////////// // Encoding methods used in the profiles' CO headers ///////////////////////////////////////////////////
/////////////////////////////////////////////////// // Encoding methods used in the profiles' CO headers ///////////////////////////////////////////////////
// Variable reordering offset used for MSN
msn_lsb(k)
{
UNCOMPRESSED {
master [ VARIABLE ];
}
// Variable reordering offset used for MSN msn_lsb(k) { UNCOMPRESSED { master [ VARIABLE ]; }
COMPRESSED none {
ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
master =:= lsb(k, 1);
}
COMPRESSED 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 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 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);
}
}
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(behavior, 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 { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
Pelletier & Sandlund Standards Track [Page 69] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 69] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ];
}
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 ];
}
}
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(behavior, indicator) { UNCOMPRESSED { ip_id [ 16 ]; }
COMPRESSED short {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
ip_id =:= ip_id_lsb(behavior, 8) [ 8 ];
}
COMPRESSED 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 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((behavior == IP_ID_BEHAVIOR_RANDOM) || (behavior == IP_ID_BEHAVIOR_ZERO)); } }
dont_fragment(version)
{
UNCOMPRESSED {
df [ 0, 1 ];
}
dont_fragment(version) { UNCOMPRESSED { df [ 0, 1 ]; }
COMPRESSED v4 {
COMPRESSED v4 {
Pelletier & Sandlund Standards Track [Page 70] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 70] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(version == 4);
df =:= irregular(1) [ 1 ];
}
ENFORCE(version == 4); df =:= irregular(1) [ 1 ]; }
COMPRESSED v6 {
ENFORCE(version == 6);
unused =:= compressed_value(1, 0) [ 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(flag) { UNCOMPRESSED { payload_type [ 7 ]; }
COMPRESSED not_present {
ENFORCE(flag == 0);
payload_type =:= static [ 0 ];
}
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 ];
}
}
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(presence, cc_value) { UNCOMPRESSED { csrc_list; }
COMPRESSED no_list {
ENFORCE(presence == 0);
csrc_list =:= static [ 0 ];
}
COMPRESSED no_list { ENFORCE(presence == 0); csrc_list =:= static [ 0 ]; }
COMPRESSED list_present {
ENFORCE(presence == 1);
csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
}
}
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 {
Pelletier & Sandlund Standards Track [Page 71] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 71] RFC 5225 ROHCv2 Profiles April 2008
timestamp [ 32 ];
}
timestamp [ 32 ]; }
COMPRESSED timerbased {
ENFORCE(time_stride_value != 0);
timestamp =:= timer_based_lsb(time_stride_value, k,
((2^k) / 2) - 1);
}
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);
}
}
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 ];
}
// Self-describing variable length encoding with reordering offset sdvl_sn_lsb(field_width) { UNCOMPRESSED { field [ field_width ]; }
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= msn_lsb(7) [ 7 ];
}
COMPRESSED lsb7 { discriminator =:= '0' [ 1 ]; field =:= msn_lsb(7) [ 7 ]; }
COMPRESSED lsb14 {
discriminator =:= '10' [ 2 ];
field =:= msn_lsb(14) [ 14 ];
}
COMPRESSED lsb14 { discriminator =:= '10' [ 2 ]; field =:= msn_lsb(14) [ 14 ]; }
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= msn_lsb(21) [ 21 ];
}
COMPRESSED lsb21 { discriminator =:= '110' [ 3 ]; field =:= msn_lsb(21) [ 21 ]; }
COMPRESSED lsb28 {
discriminator =:= '1110' [ 4 ];
field =:= msn_lsb(28) [ 28 ];
}
COMPRESSED lsb28 { discriminator =:= '1110' [ 4 ]; field =:= msn_lsb(28) [ 28 ]; }
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(field_width) [ field_width ];
}
}
COMPRESSED lsb32 { discriminator =:= '11111111' [ 8 ]; field =:= irregular(field_width) [ field_width ]; } }
Pelletier & Sandlund Standards Track [Page 72] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 72] RFC 5225 ROHCv2 Profiles April 2008
// Self-describing variable length encoding
sdvl_lsb(field_width)
{
UNCOMPRESSED {
field [ field_width ];
}
// Self-describing variable length encoding sdvl_lsb(field_width) { UNCOMPRESSED { field [ field_width ]; }
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
COMPRESSED 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 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 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 lsb28 { discriminator =:= '1110' [ 4 ]; field =:= lsb(28, ((2^28) / 4) - 1) [ 28 ]; }
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(field_width) [ field_width ];
}
}
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 { field [ 32 ]; }
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= scaled_ts_lsb(time_stride, 7) [ 7 ];
}
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 lsb14 { discriminator =:= '10' [ 2 ]; field =:= scaled_ts_lsb(time_stride, 14) [ 14 ]; }
Pelletier & Sandlund Standards Track [Page 73] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 73] RFC 5225 ROHCv2 Profiles April 2008
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= scaled_ts_lsb(time_stride, 21) [ 21 ];
}
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 lsb28 { discriminator =:= '1110' [ 4 ]; field =:= scaled_ts_lsb(time_stride, 28) [ 28 ]; }
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(32) [ 32 ];
}
}
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 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 { timestamp [ 32 ]; }
COMPRESSED present {
ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
((tss_flag == 0) && (tsc_flag == 0)));
timestamp =:= sdvl_lsb(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));
Pelletier & Sandlund Standards Track [Page 74] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 74] RFC 5225 ROHCv2 Profiles April 2008
} }
} }
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 ];
}
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 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 ];
}
}
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 ];
}
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);
COMPRESSED not_present{ ENFORCE(flag == 0); ENFORCE(list_indicator.UVALUE == 0);
Pelletier & Sandlund Standards Track [Page 75] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 75] RFC 5225 ROHCv2 Profiles April 2008
ENFORCE(pt_indicator.UVALUE == 0);
ENFORCE(time_stride_indicator.UVALUE == 0);
pad_bit =:= static;
extension =:= static;
}
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 ];
}
}
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 ];
}
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 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 ];
}
}
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 ];
profile_8_flags_enc(flag, ip_version) { UNCOMPRESSED { ip_outer_indicator [ 1 ]; df [ 0, 1 ]; ip_id_behavior [ 2 ]; coverage_behavior [ 2 ];
Pelletier & Sandlund Standards Track [Page 76] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 76] RFC 5225 ROHCv2 Profiles April 2008
}
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
coverage_behavior =:= static;
}
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 ];
}
}
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 ];
}
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 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 ];
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 ];
Pelletier & Sandlund Standards Track [Page 77] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 77] RFC 5225 ROHCv2 Profiles April 2008
extension =:= irregular(1) [ 1 ];
coverage_behavior =:= irregular(2) [ 2 ];
}
}
extension =:= irregular(1) [ 1 ]; coverage_behavior =:= irregular(2) [ 2 ]; } }
//////////////////////////////////////////// // RTP profile ////////////////////////////////////////////
//////////////////////////////////////////// // RTP profile ////////////////////////////////////////////
rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
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 {
Pelletier & Sandlund Standards Track [Page 78] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 78] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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);
}
INITIAL { ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); }
DEFAULT {
ENFORCE(outer_ip_flag == 0);
DEFAULT { ENFORCE(outer_ip_flag == 0);
Pelletier & Sandlund Standards Track [Page 79] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 79] RFC 5225 ROHCv2 Profiles April 2008
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;
}
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 ];
// 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 ];
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 ];
Pelletier & Sandlund Standards Track [Page 80] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 80] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
// 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 ];
}
// 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 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 ];
Pelletier & Sandlund Standards Track [Page 81] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 81] RFC 5225 ROHCv2 Profiles April 2008
}
}
// 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-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 ];
}
// 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 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 replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior_innermost.UVALUE ==
Pelletier & Sandlund Standards Track [Page 82] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 82] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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-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 ];
}
}
// 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 profile ////////////////////////////////////////////
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 ];
Pelletier & Sandlund Standards Track [Page 83] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 83] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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);
}
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); }
Pelletier & Sandlund Standards Track [Page 84] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 84] RFC 5225 ROHCv2 Profiles April 2008
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;
}
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 ];
}
// 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 ];
}
// 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 {
// New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 {
Pelletier & Sandlund Standards Track [Page 85] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 85] RFC 5225 ROHCv2 Profiles April 2008
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 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 ];
}
// 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 ];
}
}
// 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 profile ////////////////////////////////////////////
esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
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 ];
Pelletier & Sandlund Standards Track [Page 86] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 86] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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);
}
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;
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;
Pelletier & Sandlund Standards Track [Page 87] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 87] RFC 5225 ROHCv2 Profiles April 2008
sequence_number =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= 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 ];
// 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 ];
}
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 ];
}
// 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 ];
}
// 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 replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id {
Pelletier & Sandlund Standards Track [Page 88] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 88] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
}
// 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-only profile ////////////////////////////////////////////
iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
}
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 ]; }
Pelletier & Sandlund Standards Track [Page 89] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 89] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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);
}
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;
}
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 =:=
// 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 =:=
Pelletier & Sandlund Standards Track [Page 90] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 90] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
// 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 ];
}
// 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 ];
}
// 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 ];
// 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 ];
Pelletier & Sandlund Standards Track [Page 91] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 91] RFC 5225 ROHCv2 Profiles April 2008
} }
} }
//////////////////////////////////////////// // UDP-lite/RTP profile ////////////////////////////////////////////
//////////////////////////////////////////// // UDP-lite/RTP profile ////////////////////////////////////////////
udplite_rtp_baseheader(profile_value, ts_stride_value,
time_stride_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value,
coverage_behavior_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
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.UVALUE == IP_ID_BEHAVIOR_RANDOM);
Pelletier & Sandlund Standards Track [Page 92] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 92] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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);
}
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;
DEFAULT { ENFORCE(outer_ip_flag == 0); tos_tc =:= static;
Pelletier & Sandlund Standards Track [Page 93] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 93] RFC 5225 ROHCv2 Profiles April 2008
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;
}
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 ];
// 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 =:=
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 =:=
Pelletier & Sandlund Standards Track [Page 94] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 94] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
// 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 ];
}
// 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 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 ]; }
Pelletier & Sandlund Standards Track [Page 95] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 95] RFC 5225 ROHCv2 Profiles April 2008
// 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-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 ];
}
// 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 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 ];
// 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 ];
Pelletier & Sandlund Standards Track [Page 96] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 96] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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-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 ];
}
}
// 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 profile ////////////////////////////////////////////
udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value, coverage_behavior_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
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 ];
Pelletier & Sandlund Standards Track [Page 97] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 97] RFC 5225 ROHCv2 Profiles April 2008
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 ];
}
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 ];
}
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);
}
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 {
DEFAULT {
Pelletier & Sandlund Standards Track [Page 98] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 98] RFC 5225 ROHCv2 Profiles April 2008
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;
}
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 ];
}
// 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 ];
}
// 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 ];
// New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '100' [ 3 ];
Pelletier & Sandlund Standards Track [Page 99] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 99] RFC 5225 ROHCv2 Profiles April 2008
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
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 ];
}
// 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 ];
}
}
// 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 ]; } }
6.9. Feedback Formats and Options
6.9. Feedback Formats and Options
6.9.1. Feedback Formats
6.9.1. Feedback Formats
This section describes the feedback format for ROHCv2 profiles, using the formats described in Section 5.2.3 of [RFC4995].
This section describes the feedback format for ROHCv2 profiles, using the formats described in Section 5.2.3 of [RFC4995].
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
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
Pelletier & Sandlund Standards Track [Page 100] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 100] RFC 5225 ROHCv2 Profiles April 2008
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Acknowledgment Number | +---+---+---+---+---+---+---+---+
Acknowledgment Number: The eight least significant bits of the
MSN.
Acknowledgment Number: The eight least significant bits of the MSN.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used.
FEEDBACK-2
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |Acktype| Acknowledgment Number | +---+---+---+---+---+---+---+---+ | Acknowledgment Number | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ / Feedback options / +---+---+---+---+---+---+---+---+
Acktype:
Acktype:
0 = ACK
0 = ACK
1 = NACK
1 = NACK
2 = STATIC-NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
3 is reserved (MUST NOT be used for parsability)
Acknowledgment Number: The least significant bits of the MSN.
Acknowledgment Number: The least significant bits of the MSN.
CRC: 8-bit CRC computed over the entire feedback payload including
any CID fields but excluding the feedback type, the 'Size' field,
and the 'Code' octet, using the polynomial defined in Section
5.3.1.1 of [RFC4995]. If the CID is given with an Add-CID octet,
the Add-CID octet immediately precedes the FEEDBACK-1 or
FEEDBACK-2 format. For purposes of computing the CRC, the CRC
field is zero.
CRC: 8-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.
Feedback options: A variable number of feedback options, see
Section 6.9.2. Options may appear in any order.
Feedback options: A variable number of feedback options, see Section 6.9.2. Options may appear in any order.
Pelletier & Sandlund Standards Track [Page 101] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 101] RFC 5225 ROHCv2 Profiles April 2008
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.
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.
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.
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.
6.9.2. Feedback Options
6.9.2. Feedback Options
A feedback option has variable length and the following general format:
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)
+---+---+---+---+---+---+---+---+
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 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 Len: Unsigned integer that represents the length of the Option
Data field, in octets.
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.
Option Data: Feedback type specific data. Present if the value of the Opt Len field is set to a non-zero value.
6.9.2.1. The REJECT Option
6.9.2.1. The REJECT Option
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
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
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
Pelletier & Sandlund Standards Track [Page 102] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 102] RFC 5225 ROHCv2 Profiles April 2008
MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
6.9.2.2. The ACKNUMBER-NOT-VALID Option
6.9.2.2. The ACKNUMBER-NOT-VALID Option
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment Number field of the feedback is not valid.
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment Number field of the feedback is not valid.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
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.
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.
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.
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.
6.9.2.3. The CONTEXT_MEMORY Option
6.9.2.3. The CONTEXT_MEMORY Option
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.
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.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
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.
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.
6.9.2.4. The CLOCK_RESOLUTION Option
6.9.2.4. The CLOCK_RESOLUTION Option
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
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
Pelletier & Sandlund Standards Track [Page 103] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 103] RFC 5225 ROHCv2 Profiles April 2008
(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.
(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.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 10 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| Clock resolution (ms) |
+---+---+---+---+---+---+---+---+
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.
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.
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.
6.9.2.5. Unknown Option Types
6.9.2.5. Unknown Option Types
If an option type other than those defined in this document is encountered, the compressor MUST discard the entire feedback element.
If an option type other than those defined in this document is encountered, the compressor MUST discard the entire feedback element.
7. Security Considerations
7. Security Considerations
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.
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.
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.
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.
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.
Pelletier & Sandlund Standards Track [Page 104] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 104] RFC 5225 ROHCv2 Profiles April 2008
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.
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.
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.
8. IANA Considerations
8. IANA Considerations
The following ROHC profile identifiers have been assigned by the IANA for the profiles defined in this document:
The following ROHC profile identifiers have been assigned by the IANA for the profiles defined in this document:
Identifier Profile
---------- -------
0x0101 ROHCv2 RTP
0x0102 ROHCv2 UDP
0x0103 ROHCv2 ESP
0x0104 ROHCv2 IP
0x0107 ROHCv2 RTP/UDP-Lite
0x0108 ROHCv2 UDP-Lite
Identifier Profile ---------- ------- 0x0101 ROHCv2 RTP 0x0102 ROHCv2 UDP 0x0103 ROHCv2 ESP 0x0104 ROHCv2 IP 0x0107 ROHCv2 RTP/UDP-Lite 0x0108 ROHCv2 UDP-Lite
9. Acknowledgements
9. Acknowledgements
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.
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.
Pelletier & Sandlund Standards Track [Page 105] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 105] RFC 5225 ROHCv2 Profiles April 2008
10. References
10. References
10.1. Normative References
10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles
for User Datagram Protocol (UDP) Lite", RFC 4019,
April 2005.
[RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
Pelletier & Sandlund Standards Track [Page 106] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 106] RFC 5225 ROHCv2 Profiles April 2008
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust
Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.
10.2. Informative References
10.2. Informative References
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843,
June 2004.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
Pelletier & Sandlund Standards Track [Page 107] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 107] RFC 5225 ROHCv2 Profiles April 2008
Appendix A. Detailed Classification of Header Fields
Appendix A. Detailed Classification of Header Fields
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.
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).
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).
Fields are classified as belonging to one of the following classes:
Fields are classified as belonging to one of the following classes:
INFERRED - These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be included in compressed packets.
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 - 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-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 - 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-KNOWN - These fields are expected to have well-known values and therefore do not need to be communicated at all.
STATIC-KNOWN - These fields are expected to have well-known values and therefore do not need to be communicated at all.
SEMISTATIC - These fields are unchanged most of the time. However, occasionally the value changes but will revert to its original value. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets.
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.
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.
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.
IRREGULAR - These are the fields for which no useful change pattern can be identified and should be transmitted uncompressed in all compressed packets.
IRREGULAR - These are the fields for which no useful change pattern can be identified and should be transmitted uncompressed in all compressed packets.
Pelletier & Sandlund Standards Track [Page 108] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 108] RFC 5225 ROHCv2 Profiles April 2008
PATTERN - These are fields that change between each packet, but change in a predictable pattern.
PATTERN - These are fields that change between each packet, but change in a predictable pattern.
A.1. IPv4 Header Fields
A.1. IPv4 Header Fields
+------------------------+----------------+ | 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 | +------------------------+----------------+
+------------------------+----------------+ | 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
Version
The version field states which IP version is used and is set to
the value four.
The version field states which IP version is used and is set to the value four.
Header Length
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.
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.
Type Of Service
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.
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.
Pelletier & Sandlund Standards Track [Page 109] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 109] RFC 5225 ROHCv2 Profiles April 2008
Packet Length
Packet Length
Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED.
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
IPv4 Identification
IPv4 Identification
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.
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.
Sequential
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.
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.
Sequential Swapped
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.
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.
Random
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.
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.
Zero
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.
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.
Pelletier & Sandlund Standards Track [Page 110] RFC 5225 ROHCv2 Profiles April 2008
Pelletier & Sandlund Standards Track [Page 110] RFC 5225 ROHCv2 Profiles April 2008
Flags
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.
Reserved旗は、ゼロに設定しなければならなくて、したがって、STATIC-KNOWNとして分類されます。 Fragment(DF)旗ではなく、ドンが、めったに変化しないで、したがって、RACHとして分類されます。 最終的に、More Fragments(MF)旗は、IP断片がROHCによって圧縮されないのでゼロであると予想されて、したがって、STATIC-KNOWNとして分類されます。
Fragment Offset
断片オフセット
Under the assumption that no fragmentation occurs, the fragment
offset is always zero and is therefore classified as STATIC-KNOWN.
断片化が全く起こらないという仮定で、断片オフセットは、いつもゼロであり、したがって、STATIC-KNOWNとして分類されます。
Time To Live
生きる時間
The Time To Live field is expected to be constant during the
lifetime of a flow or to alternate between a limited number of
values due to route changes.
Time To Live分野は、流れの生涯一定であるか、またはルート変化のため限られた数の値の間を行き来すると予想されます。
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
ソースとDestinationアドレス
These fields are part of the definition of a flow and must thus be
constant for all packets in the flow.
これらの分野は、流れの定義の一部であり、流れにおけるすべてのパケットに、その結果、一定であるに違いありません。
Pelletier & Sandlund Standards Track [Page 111] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[111ページ]
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 | +----------------------+----------------+
+----------------------+----------------+ | 分野| クラス| +----------------------+----------------+ | バージョン| 静電気は知られています。| | 交通のクラス| RACH| | 流れラベル| 静的にクールです。| | ペイロード長| 推論されます。| | 次のヘッダー| 静的にクールです。| | ホップ限界| RACH| | ソースアドレス| 静的にクールです。| | 送付先アドレス| 静的にクールです。| +----------------------+----------------+
Version
バージョン
The version field states which IP version is used and is set to
the value six.
バージョン分野は、どのIPバージョンが使用されているかを述べて、値sixに設定されます。
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と電子証券取引ネットワーク分野が比較的めったに変化しないと予想されます。
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として分類されます。
Pelletier & Sandlund Standards Track [Page 112] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[112ページ]
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.
Hop Limit分野は、流れの生涯一定であるか、またはルート変化のため限られた数の値の間を行き来すると予想されます。
Source and Destination addresses
ソースとDestinationアドレス
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
ソースとDestinationポート
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.
チェックサムは任意である場合があります。 無能にされるなら、値が無能にされる、絶えずゼロに合わせて、遠くに圧縮されていて、そうすることができます。 可能にされるなら、値はペイロードに依存します。(圧縮目的のために、それは、手当たりしだいにあらゆるパケットを交換しながら、それに同等です)。
Pelletier & Sandlund Standards Track [Page 113] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[113ページ]
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.
Checksum Coverage分野は異なった方法で振る舞うかもしれません: それには、ゼロの値があるかもしれませんか、それがデータグラムの長さと等しいかもしれませんか、またはそれはデータグラムの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ヘッダーを最少量で含んでいます。 チェックサムはいつもそのままで送らなければならない変化野原です。
Pelletier & Sandlund Standards Track [Page 114] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[114ページ]
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 | +----------------+----------------+
+----------------+----------------+ | 分野| クラス| +----------------+----------------+ | バージョン| 静電気は知られています。| | 詰め物| RACH| | 拡大| RACH| | CSRCカウンタ| RACH| | マーカー| SEMISTATIC| | 有効搭載量タイプ| RACH| | 一連番号| パターン| | タイムスタンプ| パターン| | SSRC| 静的にクールです。| | CSRC| RACH| +----------------+----------------+
Version
バージョン
This field is expected to have the value two and the field is
therefore classified as STATIC-KNOWN.
この分野には値twoがあると予想されて、したがって、分野はSTATIC-KNOWNとして分類されます。
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ミキサーも使用されていない限り、この分野の値はゼロになるでしょう。
Pelletier & Sandlund Standards Track [Page 115] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[115ページ]
Marker
マーカー
For audio, the marker bit should be set only in the first packet
of a talkspurt, while for video, it should be set in the last
packet of every picture. This means that in both cases the RTP
marker is classified as SEMISTATIC.
オーディオにおいて、マーカービットはtalkspurtの最初のパケットだけに設定されるべきです、それがあらゆる絵の最後のパケットにビデオにおいて設定されるべきですが。 これは、どちらの場合も、RTPマーカーがSEMISTATICとして分類されることを意味します。
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 Sequence Numberは送られた各パケットあたり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 Timestampは恒常価値によって増加されるでしょう。(それは、スピーチフレームのサンプルの数に対応します)。 その結果、それはRTP Sequence Numberにほとんど続くでしょう。 沈黙期があって、新しいtalkspurtが始まると、タイムスタンプは沈黙期の長さに比例してジャンプするでしょう。 しかしながら、比較的限られた範囲の中に増分がたぶんあるでしょう。
In the video case:
ビデオでは、以下をケースに入れてください。
Between two consecutive packets, the timestamp will either be
unchanged or increase by a multiple of a fixed value
corresponding to the picture clock frequency. The timestamp
can also decrease by a multiple of the fixed value for certain
coding schemes. The change in timestamp value, expressed as a
multiple of the picture clock frequency, is in most cases
within a limited range.
2つの連続したパケットの間では、タイムスタンプは、変わりがないか、または絵のクロック周波数に対応する一定の価値の倍数増加するでしょう。 また、タイムスタンプはコード構成を確かな一定の価値の倍数減少させることができます。 多くの場合限られた範囲の中に絵のクロック周波数の倍数として言い表されたタイムスタンプ値における変化があります。
SSRC
SSRC
This field is part of the definition of a flow and must thus be
constant for all packets in the flow. The field is therefore
classified as STATIC-DEF.
この分野は、流れの定義の一部であり、流れにおけるすべてのパケットに、その結果、一定であるに違いありません。 したがって、分野はSTATIC-DEFとして分類されます。
Pelletier & Sandlund Standards Track [Page 116] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[116ページ]
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。 超能力ヘッダーフィールド
+------------------+-------------+ | Field | Class | +------------------+-------------+ | SPI | STATIC-DEF | | Sequence Number | PATTERN | +------------------+-------------+
+------------------+-------------+ | 分野| クラス| +------------------+-------------+ | SPI| 静的にクールです。| | 一連番号| パターン| +------------------+-------------+
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
超能力一連番号
The ESP Sequence Number will be incremented by one for each packet
sent.
超能力Sequence Numberは送られた各パケットあたり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 | +-----------------------+---------------+
+-----------------------+---------------+ | 分野| クラス| +-----------------------+---------------+ | 次のヘッダー| 静的にクールです。| | Ext Hdrレン| | | ルート設定| 静的にクールです。| | ホップで、跳んでください。| 静電気| | 目的地| 静電気| | オプション| | | ルート設定| 静的にクールです。| | ホップで、跳んでください。| RACH| | 目的地| 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として分類されます。
Pelletier & Sandlund Standards Track [Page 117] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[117ページ]
Ext Hdr Len
Ext 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コンプレッサーによって分類されるはずであると予想されます。 ホップによるHopとDestinationオプションヘッダーに関しては、長さを静的に残っていると予想しますが、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コンプレッサーによって分類されるはずであると予想されます。 ホップによるHopとDestinationオプションヘッダーに関しては、オプションを静的に残っていると予想しますが、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 | +--------------------+---------------+
+--------------------+---------------+ | 分野| クラス| +--------------------+---------------+ | C旗| 静電気| | K旗| 静電気| | S旗| 静電気| | R旗| 静電気は知られています。| | Reserved0、バージョン| 静電気は知られています。| | プロトコル| 静的にクールです。| | チェックサム| 不規則| | 予約されます。| 静電気は知られています。| | 一連番号| パターン| | キー| 静的にクールです。| +--------------------+---------------+
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として分類されます。
Pelletier & Sandlund Standards Track [Page 118] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[118ページ]
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.
存在しているとき、Sequence Numberは各パケットあたり1つ増加します。
Key
キー
When present, the Key field is used to define the flow and does
not change.
存在しているとき、Key分野は、流れを定義するのに使用されて、変化しません。
A.9. MINE Header Fields
A.9。 鉱山ヘッダーフィールド
+---------------------+----------------+ | Field | Class | +---------------------+----------------+ | Protocol | STATIC-DEF | | S bit | STATIC-DEF | | Reserved | STATIC-KNOWN | | Checksum | INFERRED | | Source Address | STATIC-DEF | | Destination Address | STATIC-DEF | +---------------------+----------------+
+---------------------+----------------+ | 分野| クラス| +---------------------+----------------+ | プロトコル| 静的にクールです。| | Sビット| 静的にクールです。| | 予約されます。| 静電気は知られています。| | チェックサム| 推論されます。| | ソースアドレス| 静的にクールです。| | 送付先アドレス| 静的にクールです。| +---------------------+----------------+
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.
予約された分野によってゼロに設定されると予想されます。
Pelletier & Sandlund Standards Track [Page 119] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[119ページ]
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。 ああ、ヘッダーフィールズ
+---------------------+----------------+ | Field | Class | +---------------------+----------------+ | Next Header | STATIC-DEF | | Payload Length | STATIC | | Reserved | STATIC-KNOWN | | SPI | STATIC-DEF | | Sequence Number | PATTERN | | ICV | IRREGULAR | +---------------------+----------------+
+---------------------+----------------+ | 分野| クラス| +---------------------+----------------+ | 次のヘッダー| 静的にクールです。| | ペイロード長| 静電気| | 予約されます。| 静電気は知られています。| | SPI| 静的にクールです。| | 一連番号| パターン| | ICV| 不規則| +---------------------+----------------+
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.
この分野の値はゼロに設定されるでしょう。
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として分類されます。
Pelletier & Sandlund Standards Track [Page 120] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[120ページ]
Sequence Number
一連番号
The Sequence Number will be incremented by one for each packet
sent.
Sequence Numberは送られた各パケットあたり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。 窓のベースのLSBコード化(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 楽観的なアプローチがどうコンプレッサーのためのパケット・フォーマット選択に影響を与えるかを説明します。 コンプレッサーがちょうどどうパケット・フォーマットを選択するかが決める実現まで達していますが、↓これは(W-LSB)をコード化するWindowベースの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
W-LSBコード化と共に、コンプレッサーは文脈からの多くの参照(窓)を使用します。 どんな参照を使用したらよいかは楽観的なアプローチで決定します。 コンプレッサーは、窓での各参照からコード化されたW-LSBになるように分野の値を抽出して、最大の、そして、最小の値に当たります。 いったんこれらの値を決定すると、コンプレッサーはこれらの境界のそばで減圧装置で範囲の中のこの分野への値を与えるという仮定を使用します。
Pelletier & Sandlund Standards Track [Page 121] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[121ページ]
(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.
(包括的に) 参照として。 次に、コンプレッサーは、値からの多くのLSBsが圧縮されるのを選択できます、減圧装置が可能な参照の範囲で最小値、最大値またはいかなる他の値も使用するかどうかにかかわらずLSBsを減圧できるように。
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}
マックス_Jitter_紀元前=最大| (T--t_j)--(a--_j)/時間_ストライド)|、引窓のすべてのヘッダーj
where (T_n - T_j) is the difference in the timestamp between the currently compressed header and a reference header and (a_n - a_j) is the difference in arrival time between those same two headers.
(T--T_j)が現在圧縮されたヘッダーと参照ヘッダーの間のタイムスタンプの違いであり、(a--_j)がそれらの同じ2個のヘッダーの間の到着時間の違いであるところ。
In addition to this, the compressor needs to estimate an upper bound for the jitter between the compressor and decompressor (Max_Jitter_CD). This information may for example come from lower layers.
これに加えて、コンプレッサーは、コンプレッサーと減圧装置(マックス_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*(マックス_ジター_紀元前+最大_ジター_CD+2)+1))
This number is then used to select a packet format that contains at least this many scaled timestamp bits.
この数はそうであり、少なくともこれを含むパケット・フォーマットを選択するのに使用されて、次に、多くがタイムスタンプビットをスケーリングしました。
Pelletier & Sandlund Standards Track [Page 122] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[122ページ]
Authors' Addresses
作者のアドレス
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
GhyslainペレティアエリクソンBox920ルーレオSE-971 28スウェーデン
Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
以下に電話をしてください。 +46(0) 8 404 29 43はメールされます: ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
クリストファSandlundエリクソンBox920ルーレオSE-971 28スウェーデン
Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
以下に電話をしてください。 +46(0) 8 404 41 58はメールされます: kristofer.sandlund@ericsson.com
Pelletier & Sandlund Standards Track [Page 123] RFC 5225 ROHCv2 Profiles April 2008
ペレティアとRFC5225ROHCv2が2008年4月に輪郭を描くSandlund標準化過程[123ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Pelletier & Sandlund Standards Track [Page 124]
ペレティアとSandlund標準化過程[124ページ]
一覧
スポンサーリンク
