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