RFC4413 日本語訳
4413 TCP/IP Field Behavior. M. West, S. McCann. March 2006. (Format: TXT=28435 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. West
Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
コメントを求めるワーキンググループのM.の西要求をネットワークでつないでください: 4413秒間マッキャンCategory: 2006年の情報のシーメンス/Roke荘園研究行進
TCP/IP Field Behavior
TCP/IP分野の振舞い
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers.
このメモはヘッダー圧縮の文脈におけるTCP/IP分野の振舞いについて説明します。 パケットによってほとんどのヘッダーフィールドが手当たりしだいに異ならないので、ヘッダー圧縮は可能です。 分野の多くが、静的な振舞いを示すか、または多少予測できる方法で変化します。 ヘッダー圧縮技術が設計されているとき、それは、詳細に分野の振舞いを理解するために基本的に重要です。 RFC3095のこの分析に関する例を見られることができます。 このメモはTCP/IPヘッダーの圧縮のために同様の役割を実行します。
West & McCann Informational [Page 1] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[1ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
Table of Contents
目次
1. Introduction ....................................................3
2. General classification ..........................................4
2.1. IP Header Fields ...........................................5
2.1.1. IPv6 Header Fields ....................................5
2.1.2. IPv4 Header Fields ....................................7
2.2. TCP Header Fields .........................................10
2.3. Summary for IP/TCP ........................................11
3. Classification of Replicable Header Fields .....................11
3.1. IPv4 Header (Inner and/or Outer) ..........................12
3.2. IPv6 Header (inner and/or outer) ..........................14
3.3. TCP Header ................................................14
3.4. TCP Options ...............................................15
3.5. Summary of Replication ....................................16
4. Analysis of Change Patterns of Header Fields ...................16
4.1. IP Header .................................................19
4.1.1. IP Traffic-Class / Type-Of-Service (TOS) .............19
4.1.2. ECN Flags ............................................19
4.1.3. IP Identification ....................................20
4.1.4. Don't Fragment (DF) flag .............................22
4.1.5. IP Hop-Limit / Time-To-Live (TTL) ....................22
4.2. TCP Header ................................................23
4.2.1. Sequence Number ......................................23
4.2.2. Acknowledgement Number ...............................24
4.2.3. Reserved .............................................25
4.2.4. Flags ................................................25
4.2.5. Checksum .............................................26
4.2.6. Window ...............................................26
4.2.7. Urgent Pointer .......................................27
4.3. Options ...................................................27
4.3.1. Options Overview .....................................28
4.3.2. Option Field Behavior ................................29
5. Other Observations .............................................36
5.1. Implicit Acknowledgements .................................36
5.2. Shared Data ...............................................36
5.3. TCP Header Overhead .......................................37
5.4. Field Independence and Packet Behavior ....................37
5.5. Short-Lived Flows .........................................37
5.6. Master Sequence Number ....................................38
5.7. Size Constraint for TCP Options ...........................38
6. Security Considerations ........................................39
7. Acknowledgements ...............................................39
8. References .....................................................40
8.1. Normative References ......................................40
8.2. Informative References ....................................41
1. 序論…3 2. 一般分類…4 2.1. IPヘッダーフィールド…5 2.1.1. IPv6ヘッダーフィールド…5 2.1.2. IPv4ヘッダーフィールド…7 2.2. TCPヘッダーフィールド…10 2.3. IP/TCPのための概要…11 3. Replicableヘッダーフィールドの分類…11 3.1. IPv4ヘッダー(内側の、そして/または、外側の)…12 3.2. IPv6 Header(内側の、そして/または、外側の)…14 3.3. TCPヘッダー…14 3.4. TCPオプション…15 3.5. 模写の概要…16 4. ヘッダーフィールドの変化パターンの分析…16 4.1. IPヘッダー…19 4.1.1. サービスのIP交通クラス/タイプ(TOS)…19 4.1.2. 電子証券取引ネットワークは弛みます…19 4.1.3. IP識別…20 4.1.4. Fragment(DF)は弛みませんか?… ……… ……… ……22 4.1.5. 生きるIPホップ限界/時間(TTL)…22 4.2. TCPヘッダー…23 4.2.1. 一連番号…23 4.2.2. 承認番号…24 4.2.3. 予約されます…25 4.2.4. 旗…25 4.2.5. チェックサム…26 4.2.6. 窓…26 4.2.7. 緊急のポインタ…27 4.3. オプション…27 4.3.1. オプション概観…28 4.3.2. オプション・フィールドの振舞い…29 5. 他の観測…36 5.1. 暗黙の承認…36 5.2. データを共有します…36 5.3. TCPヘッダーオーバーヘッド…37 5.4. 独立とパケットの振舞いをさばいてください…37 5.5. 短命な流れ…37 5.6. 系列番号を習得してください…38 5.7. TCPオプションのサイズ規制…38 6. セキュリティ問題…39 7. 承認…39 8. 参照…40 8.1. 標準の参照…40 8.2. 有益な参照…41
West & McCann Informational [Page 2] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[2ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
1. Introduction
1. 序論
This document describes the format of the TCP/IP header and the header field behavior, i.e., how fields vary within a TCP flow. The description is presented in the context of header compression.
このドキュメントはすなわち、分野がTCP流動の中でどう異なるかというTCP/IPヘッダーとヘッダーフィールドの振舞いの形式について説明します。 記述はヘッダー圧縮の文脈に示されます。
Since the IP header does exhibit slightly different behavior from that previously presented in RFC 3095 [31] for UDP and RTP, it is also included in this document.
IPヘッダーがわずかに以前にUDPとRTPのためのRFC3095[31]に提示されたそれと異なった振舞いを示すので、また、それは本書では含まれています。
This document borrows much of the classification text from RFC 3095 [31], rather than inserting many references to that document.
このドキュメントはそのドキュメントの多くの参照を挿入するよりRFC3095[31]から分類テキストの多くをむしろ借ります。
According to the format presented in RFC 3095 [31], TCP/IP header fields are classified and analyzed in two steps. First, we have a general classification in Section 2, where the fields are classified on the basis of stable knowledge and assumptions. This general classification does not take into account the change characteristics of changing fields, as those will vary more or less depending on the implementation and on the application used. Section 3 considers how field values can be used to optimize short-lived flows. A more detailed analysis of the change characteristics is then done in Section 4. Finally, Section 5 summarizes with conclusions about how the various header fields should be handled by the header compression scheme to optimize compression.
RFC3095[31]に提示された形式によると、TCP/IPヘッダーフィールドは、2ステップで分類されて、分析されます。 まず最初に、私たちはセクション2に大別を持っています。そこでは、分野が安定した知識と仮定に基づいて分類されます。 この大別は職業を替える変化の特性を考慮に入れません、多少実現と、そして、使用されるアプリケーションによって、それらが異なるとき。 セクション3は、短命な流れを最適化するのにどのように分野値を使用できるかを考えます。 そして、セクション4で変化の特性の、より詳細な分析をします。 最終的に、セクション5は、様々なヘッダーフィールドがヘッダー圧縮技術によってどう扱われるべきであるかに関する結論で圧縮を最適化するのをまとめます。
A general question raised by this analysis is: what 'baseline' definition of all possible TCP/IP implementations is to be considered? This review is based on an analysis of currently deployed TCP implementations supporting mechanisms standardised by the IETF.
この分析で提起された一般疑問は以下の通りです。 すべての可能なTCP/IPインプリメンテーションのどんな'基線'定義が考えられることになっていますか? このレビューはIETFによって標準化されたメカニズムをサポートする現在配備されたTCP実現の分析に基づいています。
The general requirement for transparency is also interesting. A number of recent proposals for extensions to TCP use some of the previously 'reserved' bits in the TCP packet header. Therefore, a 'reserved' bit cannot be taken to have a guaranteed zero value; it may change. Ideally, this should be accommodated by the compression profile.
また、透明のための一般的な要件もおもしろいです。 TCPへの拡大のための多くの最近の提案がTCPパケットのヘッダーで以前に'予約された'数ビットを使用します。 したがって、値を全くaに保証させないように'予約された'ビットを取ることができません。 それは変化するかもしれません。 理想的に、これは圧縮プロフィールによって設備されるべきです。
A number of reserved bits are available for future expansion. A treatment of field behavior cannot predict the future use of such bits, but we expect that they will be used at some point. Given this, a compression scheme can optimise for the current situation but should be capable of supporting any arbitrary usage of the reserved bits. However, it is impossible to optimise for usage patterns that have yet to be defined.
多くの予約されたビットが今後の拡大に有効です。 分野の振舞いの処理はそのようなビットの今後の使用を予測できませんが、私たちは、それらが何らかのポイントで使用されると予想します。 これを考えて、圧縮技術は、現在の状況のために最適化できますが、予約されたビットのどんな任意の使用法も支持できるべきです。 しかしながら、用法のためにまだ定義されていないパターンを最適化するのは不可能です。
West & McCann Informational [Page 3] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[3ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
2. General classification
2. 大別
The following definitions (and some text) are copied from RFC 3095 [31], Appendix A. Differences of IP field behavior between RFC 3095 [31] (i.e., IP/UDP/RTP behavior for audio and video applications) and this document have been identified.
以下の定義(そして、何らかのテキスト)はRFC3095[31]からコピーされて、RFC3095[31](すなわち、オーディオとビデオ・アプリケーションのためのIP/UDP/RTPの振舞い)とこのドキュメントの間のIP分野の振舞いのAppendix A.Differencesは特定されました。
For the following, we define "session" as a TCP packet stream, being a series of packets with the same IP addresses and port numbers. A packet flow is defined by certain fields (see STATIC-DEF, below) and may be considered a subset of a session. See [31] for a fuller discussion of separation of sessions into streams of packets for header compression.
以下に関しては、私たちは「セッション」をTCPパケットの流れと定義します、同じIPアドレスとポートナンバーがある一連のパケットであり。 パケット流動は、ある一定の分野(以下のSTATIC-DEFを見る)によって定義されて、セッションの部分集合であると考えられるかもしれません。 ヘッダー圧縮に関してセッションの分離の、よりふくよかな議論のための[31]をパケットの流れの中に見てください。
At a general level, the header fields are separated into 5 classes:
一般的なレベルでは、ヘッダーフィールドは5つのクラスに切り離されます:
o INFERRED
o 推論されます。
These fields contain values that can be inferred from other
values (for example, the size of the frame carrying the packet)
and thus do not have to be handled at all by the compression
scheme.
これらの分野は他の値(例えば、パケットを運ぶフレームのサイズ)から推論できて、その結果圧縮技術によって全く扱われる必要はない値を含んでいます。
o STATIC
o 静電気
These fields are expected to be constant throughout the
lifetime of the packet stream. Static information must in some
way be communicated once.
これらの分野がパケットの流れの生涯の間中一定であると予想されます。 一度何らかの方法で静的な情報を伝えなければなりません。
o STATIC-DEF
o 静的にクールです。
STATIC fields whose values define a packet stream. They are in
general handled as STATIC.
値がパケットの流れを定義するSTATIC分野。 一般に、それらはSTATICとして扱われます。
o STATIC-KNOWN
o 静電気は知られています。
These STATIC fields are expected to have well-known values and
therefore do not need to be communicated at all.
これらのSTATIC分野は周知の値を持っていると予想されて、したがって、全くコミュニケートする必要はありません。
o CHANGING
o 変化します。
These fields are expected to vary randomly within a limited
value set or range or in some other manner.
これらの分野が限られた選択値群か範囲以内かある他の方法で手当たりしだいに異なると予想されます。
West & McCann Informational [Page 4] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[4ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
In this section, each of the IP and TCP header fields is assigned to one of these classes. For all fields except those classified as CHANGING, the motives for the classification are also stated. In section 4, CHANGING fields are further examined and classified on the basis of their expected change behavior.
このセクションでは、それぞれのIPとTCPヘッダーフィールドはこれらのクラスの1つに割り当てられます。 また、CHANGINGとして分類されたもの以外のすべての分野において、分類のための動機は述べられています。 セクション4では、CHANGING分野は、彼らの予想された変化の振舞いに基づいてさらに調べられて、分類されます。
2.1. IP Header Fields
2.1. IPヘッダーフィールド
2.1.1. IPv6 Header Fields
2.1.1. IPv6ヘッダーフィールド
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT,
and CE flags were amalgamated into the Traffic
Class octet in RFC 3095).
+---------------------+-------------+----------------+ | 分野| サイズ(ビット)| クラス| +---------------------+-------------+----------------+ | バージョン| 4 | 静電気| | DSCP*| 6 | 交替します。| | ECT旗*| 1 | 変化します。| | CE旗*| 1 | 変化します。| | 流れラベル| 20 | 静的にクールです。| | ペイロード長| 16 | 推論されます。| | 次のヘッダー| 8 | 静電気| | ホップ限界| 8 | 変化します。| | ソースアドレス| 128 | 静的にクールです。| | 送付先アドレス| 128 | 静的にクールです。| +---------------------+-------------+----------------+ *はRFC3095[31]と異なっています。 (DSCP、ECT、およびCE旗はRFC3095のTraffic Class八重奏と合併しました。)
Figure 1. IPv6 Header Fields
図1。 IPv6ヘッダーフィールド
o Version
o バージョン
The version field states which IP version is used. Packets
with different values in this field must be handled by
different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is
classified as STATIC.
バージョン分野は、どのIPバージョンが使用されているかを述べます。 異なったIPスタックで異価がこの分野にあるパケットを扱わなければなりません。 したがって、パケットの流れのすべてのパケットが同じIPバージョンのものであるに違いありません。 それに従って、分野はSTATICとして分類されます。
o Flow Label
o 流れラベル
This field may be used to identify packets belonging to a
specific packet stream. If the field is not used, its value
should be zero. Otherwise, all packets belonging to the same
stream must have the same value in this field, it being one of
the fields that define the stream. The field is therefore
classified as STATIC-DEF.
この分野は、特定のパケットの流れに属すパケットを特定するのに使用されるかもしれません。 分野が使用されていないなら、値はゼロであるべきです。 さもなければ、同じ流れに属すすべてのパケットがこの分野に同じ値を持たなければなりません、それが流れを定義する分野の1つであり。 したがって、分野はSTATIC-DEFとして分類されます。
West & McCann Informational [Page 5] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[5ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
o Payload Length
o ペイロード長
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The
field is therefore classified as INFERRED.
リンクレイヤのそばでパケット長(その結果ペイロード長)に関する情報が提供されると予想されます。 したがって、分野はINFERREDとして分類されます。
o Next Header
o 次のヘッダー
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes absent will the field
change its value during the lifetime of the stream. The field
is therefore classified as STATIC. The classification of
STATIC is inherited from RFC 3095 [31]. However, note that the
next header field is actually determined by the type of the
following header. Thus, it might be more appropriate to view
this as an inference, although this depends upon the specific
implementation of the compression scheme.
通常、この分野はパケットの流れのすべてのパケットに同じ値を持つでしょう。 それはその後のヘッダーのタイプをコード化します。 拡張ヘッダーが時々欠けているときだけ、分野は流れの生涯値を変えるでしょう。 したがって、分野はSTATICとして分類されます。 STATICの分類はRFC3095[31]から引き継がれます。 しかしながら、次のヘッダーフィールドが実際に以下のヘッダーのタイプによって決定されることに注意してください。 したがって、これを推論であるとみなすのは、より適切であるかもしれません、これが圧縮技術の特定の実現によりますが。
o Source and Destination Addresses
o ソースと送付先アドレス
These fields are part of the definition of a stream and
therefore must be constant for all packets in the stream. The
fields are therefore classified as STATIC-DEF.
これらの分野は、流れの定義の一部であり、すべてのパケットに、したがって、流れで一定であるに違いありません。 したがって、分野はSTATIC-DEFとして分類されます。
This might be considered as a slightly simplistic view. In
this document, the IP addresses are associated with the
transport layer connection and assumed to be part of the
definition of a flow. More complex flow-separation could, of
course, be considered (see also RFC 3095 [31] for more
discussion of this issue). Where tunneling is being performed,
the use of the IP addresses in outer tunnel headers is also
assumed to be STATIC-DEF.
これはわずかに安易な視点であるとみなされるかもしれません。 本書では、IPアドレスは、トランスポート層接続に関連づけられて、流れの定義の一部であると思われます。 もちろんより複雑な流れ分離を考えることができました(また、この問題の、より多くの議論のためのRFC3095[31]を見てください)。 また、トンネリングが実行されているところでは、外トンネルヘッダーにおけるIPアドレスの使用はSTATIC-DEFであると思われます。
The total size of the fields in each class is as follows:
各クラスにおける、分野の総サイズは以下の通りです:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| STATIC-KNOWN | 0 |
| CHANGING | 2 |
+--------------+--------------+
+--------------+--------------+ | クラス| サイズ(八重奏)| +--------------+--------------+ | 推論されます。| 2 | | 静電気| 1.5 | | 静的にクールです。| 34.5 | | 静電気は知られています。| 0 | | 変化します。| 2 | +--------------+--------------+
Figure 2: Field sizes
図2: 分野サイズ
West & McCann Informational [Page 6] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[6ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
2.1.2. IPv4 Header Fields
2.1.2. IPv4ヘッダーフィールド
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING |
| Don't Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT
and CE flags were amalgamated into the TOS
octet in RFC 3095; the DF flag behavior is
considered later; the reserved field is
discussed below).
+---------------------+-------------+----------------+ | 分野| サイズ(ビット)| クラス| +---------------------+-------------+----------------+ | バージョン| 4 | 静電気| | ヘッダ長| 4 | 静電気は知られています。| | DSCP*| 6 | 交替します。| | ECT旗*| 1 | 変化します。| | CE旗*| 1 | 変化します。| | パケット長| 16 | 推論されます。| | 識別| 16 | 変化します。| | 予約された旗*| 1 | 変化します。| | Fragmentは*に旗を揚げさせません。| 1 | 変化します。| | より多くのFragments旗| 1 | 静電気は知られています。| | 断片オフセット| 13 | 静電気は知られています。| | 生きる時間| 8 | 変化します。| | プロトコル| 8 | 静電気| | ヘッダーチェックサム| 16 | 推論されます。| | ソースアドレス| 32 | 静的にクールです。| | 送付先アドレス| 32 | 静的にクールです。| +---------------------+-------------+----------------+ *はRFC3095[31]と異なっています。 (DSCP、ECT、およびCE旗はRFC3095のTOS八重奏と合併しました; DF旗の振舞いは後で考えられます; 以下で予約された分野について議論します。)
Figure 3. IPv4 Header Fields
図3。 IPv4ヘッダーフィールド
o Version
o バージョン
The version field states which IP version is used. Packets
with different values in this field must be handled by
different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is
classified as STATIC.
バージョン分野は、どのIPバージョンが使用されているかを述べます。 異なったIPスタックで異価がこの分野にあるパケットを扱わなければなりません。 したがって、パケットの流れのすべてのパケットが同じIPバージョンのものであるに違いありません。 それに従って、分野はSTATICとして分類されます。
o Header Length
o ヘッダ長
As long as no options are present in the IP header, the header
length is constant and well known. If there are options, the
fields would be STATIC, but it is assumed here that there are
no options. The field is therefore classified as STATIC-KNOWN.
どんなオプションもIPヘッダーに存在していない限り、ヘッダ長は、一定であって、よく知られています。 オプションがあれば、分野はSTATICでしょうが、ここで、オプションが全くないと思われます。 したがって、分野はSTATIC-KNOWNとして分類されます。
West & McCann Informational [Page 7] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[7ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
o Packet Length
o パケット長
Information about packet length is expected to be provided by
the link layer. The field is therefore classified as INFERRED.
リンクレイヤのそばでパケット長に関する情報が提供されると予想されます。 したがって、分野はINFERREDとして分類されます。
o Flags
o 旗
The Reserved flag must be set to zero, as defined in RFC 791
[1]. In RFC 3095 [31] the field is therefore classified as
STATIC-KNOWN. However, it is expected that reserved fields may
be used at some future point. It is undesirable to select an
encoding that would preclude the use of a compression profile
for a future change in the use of reserved fields. For this
reason, the alternative encoding of CHANGING is used. (A
compression profile can, of course, still optimise for the
current situation, where the field value is known to be 0).
RFC791[1]で定義されるようにReserved旗をゼロに設定しなければなりません。 したがって、RFC3095[31]では、分野はSTATIC-KNOWNとして分類されます。 しかしながら、予約された分野が何らかの将来のポイントで使用されるかもしれないと予想されます。 圧縮プロフィールの予約された分野の使用における将来の変化の使用を排除するコード化を選択するのは望ましくありません。 この理由で、CHANGINGの代替のコード化は使用されています。 (圧縮プロフィールは、現在の状況のためにもちろん0であることをまだ最適化できます。)(そこでは、分野値が知られています)。
The More Fragments (MF) flag is expected to be zero because
fragmentation is, ideally, not expected. However, it is also
understood that some scenarios (for example, some tunnelling
architectures) do cause fragmentation. In general, though,
fragmentation is not expected to be common in the Internet due
to a combination of initial MSS negotiation and subsequent use
of path-MTU discovery. RFC 3095 [31] points out that, for RTP,
only the first fragment will contain the transport layer
protocol header; subsequent fragments would have to be
compressed with a different profile. This is also obviously
the case for TCP. If fragmentation were to occur, the first
fragment, by definition, would be relatively large, minimizing
the header overhead. Subsequent fragments would be compressed
with another profile. It is therefore considered undesirable
to optimise for fragmentation in performing header compression.
The More Fragments flag is therefore classified as STATIC-
KNOWN.
More Fragments(MF)旗は断片化が理想的に予想されないのでゼロであると予想されます。 しかしながら、また、いくつかのシナリオ(例えば、いくつかのトンネル構造)が原因断片化をするのが理解されています。 一般に、もっとも、断片化が経路MTU探索の初期のMSSの組み合わせによるインターネット交渉とその後の使用で一般的でないと予想されます。 RFC3095[31]は、最初の断片だけがRTPに関してトランスポート層プロトコルヘッダーを含むと指摘します。 その後の断片は異なったプロフィールで圧縮されなければならないでしょう。 これは明らかにもTCPのためのそうです。 断片化が起こるなら、ヘッダーオーバーヘッドを最小にして、最初の断片は定義上比較的大きいでしょうに。 その後の断片は別のプロフィールで圧縮されるでしょう。 したがって、それは断片化のためにヘッダー圧縮を実行する際に最適化するのにおいて望ましくないと考えられます。 したがって、More Fragments旗はSTATIC- KNOWNとして分類されます。
o Fragment Offset
o 断片オフセット
Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as
STATIC-KNOWN. Even if fragmentation were to be further
considered, only the first fragment would contain the TCP
header, and the fragment offset of this packet would still be
zero.
断片化が全く起こらないという仮定で、いつも断片オフセットはゼロです。 したがって、分野はSTATIC-KNOWNとして分類されます。 最初の断片だけが断片化がさらに考えられることであるなら、TCPヘッダーを含んでいます、そして、このパケットの断片オフセットはまだゼロでしょう。
o Protocol
o プロトコル
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
通常、この分野はパケットの流れのすべてのパケットに同じ値を持つでしょう。 それはその後のヘッダーのタイプをコード化します。
West & McCann Informational [Page 8] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[8ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
Only where the sequence of headers changes (e.g., an extension
header is inserted or deleted or a tunnel header is added or
removed) will the field change its value. The field is
therefore classified as STATIC. Whether such a change would
cause the sequence of packets to be treated as a new flow (for
header compression) is an issue for profile design. ROHC
profiles must be able to cope with extension headers and
tunnelling, but the choice of strategy is outside the scope of
this document.
分野はヘッダーの系列が変化する(例えば拡張ヘッダーが挿入されるか、削除される、またはトンネルヘッダーを加えるか、取り除きます)ところで値を変えるだけでしょう。 したがって、分野はSTATICとして分類されます。 そのような変化で新しい流れ(ヘッダー圧縮のための)としてパケットの系列を扱うかどうかが、プロフィールデザインのための問題です。 ROHCプロフィールは拡張ヘッダーとトンネルに対処できなければなりませんが、このドキュメントの範囲の外に戦略の選択があります。
o Header Checksum
o ヘッダーチェックサム
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum. Instead, it can be regenerated at the decompressor
side. The field is therefore classified as INFERRED.
ヘッダーチェックサムは崩壊したヘッダーを処理するのから個々のホップを保護します。 ほとんどすべてのIPヘッダー情報が遠くに圧縮されるとき、この追加チェックサムを持つ意味が全くありません。 代わりに、減圧装置側でそれを作り直すことができます。 したがって、分野はINFERREDとして分類されます。
Note that the TCP checksum does not protect the whole TCP/IP
header, but only the TCP pseudo-header (and the payload).
Compare this with ROHC [31], which uses a CRC to verify the
uncompressed header. Given the need to validate the complete
TCP/IP header, the cost of computing the TCP checksum over the
entire payload, and known weaknesses in the TCP checksum [37],
an additional check is necessary. Therefore, it is highly
desirable that some additional checksum (such as a CRC) will be
used to validate correct decompression.
TCPチェックサムは全体のTCP/IPヘッダーを保護するのではなく、TCP疑似ヘッダー(そして、ペイロード)だけを保護することに注意してください。 ROHC[31]とこれを比べてください。(ROHCは、解凍されたヘッダーについて確かめるのにCRCを使用します)。 TCPチェックサム[37]における完全なTCP/IPヘッダーを有効にする必要性、TCPチェックサムを全体のペイロードの上計算する費用、および知られている弱点を考えて、追加チェックが必要です。 したがって、何らかの追加チェックサム(CRCなどの)が正しい減圧を有効にするのに使用されるのは、非常に望ましいです。
o Source and Destination Addresses
o ソースと送付先アドレス
These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
これらの分野は、流れの定義の一部であり、すべてのパケットに、その結果、流れで一定であるに違いありません。 したがって、分野はSTATIC-DEFとして分類されます。
The total size of the fields in each class is as follows:
各クラスにおける、分野の総サイズは以下の通りです:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC* | 1.5 |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 |
+--------------+--------------+
* Differs from RFC 3095 [31]
+--------------+--------------+ | クラス| サイズ(八重奏)| +--------------+--------------+ | 推論されます。| 4 | | 静電気*| 1.5 | | 静的にクールです。| 8 | | *を静電気で知っています。| 2.25 | | *を変えます。| 4.25 | +--------------+--------------+ *はRFC3095と異なっています。[31]
Figure 4. Field sizes
図4。 分野サイズ
West & McCann Informational [Page 9] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[9ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
2.2. TCP Header Fields
2.2. TCPヘッダーフィールド
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Sequence Number | 32 | CHANGING |
| Acknowledgement Num | 32 | CHANGING |
| Data Offset | 4 | INFERRED |
| Reserved | 4 | CHANGING |
| CWR flag | 1 | CHANGING |
| ECE flag | 1 | CHANGING |
| URG flag | 1 | CHANGING |
| ACK flag | 1 | CHANGING |
| PSH flag | 1 | CHANGING |
| RST flag | 1 | CHANGING |
| SYN flag | 1 | CHANGING |
| FIN flag | 1 | CHANGING |
| Window | 16 | CHANGING |
| Checksum | 16 | CHANGING |
| Urgent Pointer | 16 | CHANGING |
| Options | 0(-352) | CHANGING |
+---------------------+-------------+----------------+
+---------------------+-------------+----------------+ | 分野| サイズ(ビット)| クラス| +---------------------+-------------+----------------+ | ソース港| 16 | 静的にクールです。| | 仕向港| 16 | 静的にクールです。| | 一連番号| 32 | 変化します。| | Acknowledgementヌム| 32 | 変化します。| | データは相殺されます。| 4 | 推論されます。| | 予約されます。| 4 | 変化します。| | CWR旗| 1 | 変化します。| | ECE旗| 1 | 変化します。| | URG旗| 1 | 変化します。| | ACK旗| 1 | 変化します。| | PSH旗| 1 | 変化します。| | RST旗| 1 | 変化します。| | SYN旗| 1 | 変化します。| | FIN旗| 1 | 変化します。| | 窓| 16 | 変化します。| | チェックサム| 16 | 変化します。| | 緊急のポインタ| 16 | 変化します。| | オプション| 0(-352) | 変化します。| +---------------------+-------------+----------------+
Figure 5: TCP header fields
図5: TCPヘッダーフィールド
o Source and Destination ports
o ソースとDestinationポート
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
これらの分野は、流れの定義の一部であり、すべてのパケットに、その結果、流れで一定であるに違いありません。 したがって、分野はSTATIC-DEFとして分類されます。
o Data Offset
o データは相殺されます。
The number of 4 octet words in the TCP header, indicating the
start of the data. It is always a multiple of 4 octets. It can
be re-constructed from the length of any options, and thus it is
not necessary to carry this explicitly. The field is therefore
classified as INFERRED.
データの始まりを示すTCPヘッダーの4つの八重奏単語の数。 いつもそれは4つの八重奏の倍数です。 どんなオプションの長さからもそれを再建できます、そして、その結果、明らかにこれを運ぶのは必要ではありません。 したがって、分野はINFERREDとして分類されます。
West & McCann Informational [Page 10] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[10ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
2.3. Summary for IP/TCP
2.3. IP/TCPのための概要
Summarizing this for IP/TCP, one obtains the following:
IP/TCPのためにこれをまとめて、1つは以下を得ます:
+----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 4 bits | 19 + 6 bits |
+----------------+----------------+----------------+
| Totals | 60 | 40 |
+----------------+----------------+----------------+
(Excludes options, which are all classified as CHANGING).
+----------------+----------------+----------------+ | クラス\IP ver| IPv6(八重奏)| IPv4(八重奏)| +----------------+----------------+----------------+ | 推論されます。| 2+4ビット| 4+4ビット| | 静電気| 1+4ビット| 1+4ビット| | 静的にクールです。| 38+4ビット| 12 | | 静電気は知られています。| - | 2+2ビット| | 変化します。| 17+4ビット| 19+6ビット| +----------------+----------------+----------------+ | 合計| 60 | 40 | +----------------+----------------+----------------+(CHANGINGとしてすべて分類されるオプションを除きます)。
Figure 6. Overall field sizes
図6。 総合的な分野サイズ
3. Classification of Replicable Header Fields
3. Replicableヘッダーフィールドの分類
Where multiple flows either overlap in time or occur sequentially within a short space of time, there can be a great deal of similarity in header field values. Such commonality of field values is reflected in the compression context. Thus, it should be possible to utilise commonality between fields across different flows to improve the compression ratio. In order to do this, it is important to understand the 'replicable' characteristics of the various header fields.
複数の流れが短期間の中に時間内に、重なるか、または連続して起こるところに、ヘッダーフィールド値には多くの類似性があることができます。 分野値のそのような共通点は圧縮文脈に反映されます。 したがって、圧縮比を改良するのに異なった流れの向こう側に分野の間の共通点を利用するのは可能であるべきです。 これをするために、様々なヘッダーフィールドの'replicable'の特性を理解しているのは重要です。
The key concept is that of 'replication': an existing context is used as a baseline and replicated to initialise a new context. Those fields that are the same are then automatically initialised in the new context. Those that have changed will be updated or overwritten with values from the initialisation packet that triggered the replication. This section considers the commonality between fields in different flows.
重要な考えは'模写'のものです: 既存の文脈は、基線として使用されて、新しい関係を初期化するために模写されます。 そして、それらの同じである分野は新しい関係で自動的に初期化されます。 値で模写の引き金となった初期化処理パケットから、変化したものを、アップデートするか、または上書きするでしょう。 このセクションは異なった流れにおける分野の間の共通点を考えます。
Note, however, that replication is based on contexts (rather than on just field values), so compressor-created fields that are part of the context may also be included. These, of course, are dependent upon the nature of the compression protocol (ROHC profile) being applied.
しかしながら、模写が文脈に基づいていることに注意してください、(オンであるよりむしろ、まさしく分野値) また、文脈の一部である分野は含むことができるようにコンプレッサーによってあまりに作成されています。 適用されていて、これらはもちろん圧縮プロトコル(ROHCプロフィール)の本質に依存しています。
West & McCann Informational [Page 11] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[11ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
A brief analysis of the relationship of TCP/IP fields among 'replicable' packet streams follows.
'replicable'パケットの流れの中のTCP/IP分野の関係の簡潔な分析は続きます。
'N/A': The field need not be considered in the replication
process, as it is inferred or known 'a priori' (and,
therefore, does not appear in the context).
'/A': 分野は模写の過程で考えられる必要はありません、'先験的である'(そして、したがって、文脈では、現れない)が推論されるか、または知られているとき。
'No': The field cannot be replicated since its change pattern
between two packet flows is uncorrelated.
'いいえ': 2回のパケット流れの間の変化パターンが非相関であるので、分野を模写できません。
'Yes': The field may be replicated. This does not guarantee that
the field value will be the same across two candidate
streams, only that it might be possible to exploit
replication to increase the compression ratio. Specific
encoding methods can be used to improve the compression
efficiency.
'はい': 分野は模写されるかもしれません。 これは分野値が2候補の向こう側の同じくらいが流れるということであり、圧縮比を増加させるのに単に模写を利用するのが可能であるかもしれないことを保証しません。 圧縮効率を高めるのに特定のコード化方法を使用できます。
3.1. IPv4 Header (Inner and/or Outer)
3.1. IPv4ヘッダー(内側である、そして/または、外側)です。
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Header Length | STATIC-KNOWN | N/A |
| DSCP | ALTERNATING | No (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Packet Length | INFERRED | N/A |
| Identification | CHANGING | Yes (3) |
| Reserved flag | CHANGING | No (4) |
| Don't Fragment flag | CHANGING | Yes (5) |
| More Fragments flag | STATIC-KNOWN | N/A |
| Fragment Offset | STATIC-KNOWN | N/A |
| Time To Live | CHANGING | Yes |
| Protocol | STATIC | N/A |
| Header Checksum | INFERRED | N/A |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
+-----------------------+---------------+------------+ | 分野| クラス| Replicable| +-----------------------+---------------+------------+ | バージョン| 静電気| なし| | ヘッダ長| 静電気は知られています。| なし| | DSCP| 交替します。| (1)がありません。| | ECT旗| 変化します。| (2)がありません。| | CE旗| 変化します。| (2)がありません。| | パケット長| 推論されます。| なし| | 識別| 変化します。| はい(3)| | 予約された旗| 変化します。| (4)がありません。| | Fragmentは弛みませんか?| 変化します。| はい(5)| | より多くのFragments旗| 静電気は知られています。| なし| | 断片オフセット| 静電気は知られています。| なし| | 生きる時間| 変化します。| はい| | プロトコル| 静電気| なし| | ヘッダーチェックサム| 推論されます。| なし| | ソースアドレス| 静的にクールです。| はい| | 送付先アドレス| 静的にクールです。| はい| +-----------------------+---------------+------------+
Figure 7: IPv4 header
図7: IPv4ヘッダー
(1) The DSCP is marked according to the application's requirements.
If it can be assumed that replicable connections belong to the
same diffserv class, then it is likely that the DSCP will be
replicable. The DSCP can be set not only by the sender but by
any packet marker. Thus, a flow may have a number of DSCP values
at different points in the network. However, header compression
(1) アプリケーションの要件に従って、DSCPはマークされます。 replicable接続が同じdiffservのクラスに属すと思うことができるなら、DSCPがreplicableになるのは、ありそうです。 送付者は用意ができているだけではなく、どんなパケットマーカーもDSCPを用意ができさせることができます。 したがって、流れは異なったポイントにネットワークで多くのDSCP値を持っているかもしれません。 しかしながら、ヘッダー圧縮
West & McCann Informational [Page 12] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[12ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
operates on a point-to-point link and so would expect to see a
relatively stable value. If re-marking is being done based on
the state of a meter, then the value may change mid-flow.
Overall, though, we expect supporting replication of the DSCP to
be useful for header compression.
ポイントツーポイント接続を作動させるので、比較的安定した値を見ると予想するでしょう。 異状がすることであるなら、1メーターの状態に基づく値は中間の流れを変えるかもしれません。 もっとも、全体的に見て、私たちは、DSCPの模写を支持するのがヘッダー圧縮の役に立つと予想します。
(2) It is not possible for the ECN bits to be replicated (note that
use of the ECN nonce scheme [19] is anticipated). However, it
seems likely that all TCP flows between ECN-capable hosts will
use ECN, the use (or not) of ECN for flows between the same end-
points might be considered replicable. See also note (4).
(2) 電子証券取引ネットワークビットが模写されるのは、可能ではありません(電子証券取引ネットワークの一回だけの計画[19]の使用が予期されることに注意してください)。 しかしながら、電子証券取引ネットワーク有能なホストの間のすべてのTCP流れが電子証券取引ネットワークを使用しそうに思えて、同じ終わりの間の流れのための電子証券取引ネットワークの(or not)が指す使用はreplicableであると考えられるかもしれません。 また、注意(4)を見てください。
(3) The replicable context for this field includes the IP-ID, NBO,
and RND flags (as described in ROHC RTP). This highlights that
the replication is of the context, rather than just the header
field values and, as such, needs to be considered based on the
exact nature of compression applied to each field.
(3) この分野のためのreplicable文脈はIP-ID、NBO、およびRND旗を含んでいます(ROHC RTPで説明されるように)。 模写がまさしくヘッダーよりむしろ文脈のそうであるこのハイライトは値をさばきます、そして、そういうものとして、圧縮の正確な本質に基づいて考えられるべき必要性は各分野に適用されました。
(4) Since the possible future behavior of the 'Reserved Flag' cannot
be predicted, it is not considered as replicable. However, it
might be expected that the behavior of the reserved flag between
the same end-points will be similar. In this case, any selection
of packet formats (for example) based on this behavior might
carry across to the new flow. In the case of packet formats,
this can probably be considered as a compressor-local decision.
(4) '予約されたFlag'の可能な今後の振舞いを予測できないので、それはreplicableであるとみなされません。 しかしながら、同じエンドポイントの間の予約された旗の働きが同様になると予想されるかもしれません。 この場合、(例えば) この振舞いに基づくパケット・フォーマットのどんな品揃えも横切って新しい流れまで運ばれるかもしれません。 パケット・フォーマットの場合では、たぶんコンプレッサーローカルの決定であるとこれをみなすことができます。
(5) In theory, the DF bit may be replicable. However, this is not
guaranteed and, in practice, it is unlikely to be useful to do
this. From the perspective of header compression, having to
indicate whether or not a 1-bit flag should be replicated or
specified explicitly is likely to require more bits than simply
conveying the value of the flag. We do not rule out DF
replication.
(5) 理論上、DFビットはreplicableであるかもしれません。 しかしながら、これは保証されません、そして、実際には、それはこれをするために役に立ちそうにはありません。 見解..ヘッダー..圧縮..持つ..示す..ビット..旗..模写..指定..明らか..ありそう..必要..多い..ビット..単に..運ぶ..値..旗 私たちはDF模写を除外しません。
West & McCann Informational [Page 13] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[13ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
3.2. IPv6 Header (inner and/or outer)
3.2. IPv6ヘッダー(内側である、そして/または、外側)です。
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Traffic Class | CHANGING | Yes (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Flow Label | STATIC-DEF | N/A |
| Payload Length | INFERRED | N/A |
| Next Header | STATIC | N/A |
| Hop Limit | CHANGING | Yes |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
(1) See comment about DSCP field for IPv4, above.
(2) See comment about ECT and CE flags for IPv4, above.
+-----------------------+---------------+------------+ | 分野| クラス| Replicable| +-----------------------+---------------+------------+ | バージョン| 静電気| なし| | 交通のクラス| 変化します。| はい(1)| | ECT旗| 変化します。| (2)がありません。| | CE旗| 変化します。| (2)がありません。| | 流れラベル| 静的にクールです。| なし| | ペイロード長| 推論されます。| なし| | 次のヘッダー| 静電気| なし| | ホップ限界| 変化します。| はい| | ソースアドレス| 静的にクールです。| はい| | 送付先アドレス| 静的にクールです。| はい| +-----------------------+---------------+------------+ (1)はDSCP分野の周りで上のIPv4に関してコメントを見ます。 (2) ECTとCE旗の周りで上のIPv4に関してコメントを見てください。
Figure 8. IPv6 Header
エイト環。 IPv6ヘッダー
3.3. TCP Header
3.3. TCPヘッダー
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Source Port | STATIC-DEF | Yes (1) |
| Destination Port | STATIC-DEF | Yes (1) |
| Sequence Number | CHANGING | No (2) |
| Acknowledgement Number| CHANGING | No |
| Data Offset | INFERRED | N/A |
| Reserved Bits | CHANGING | No (3) |
| Flags | | |
| CWR | CHANGING | No (4) |
| ECE | CHANGING | No (4) |
| URG | CHANGING | No |
| ACK | CHANGING | No |
| PSH | CHANGING | No |
| RST | CHANGING | No |
| SYN | CHANGING | No |
| FIN | CHANGING | No |
| Window | CHANGING | Yes |
| Checksum | CHANGING | No |
| Urgent Pointer | CHANGING | Yes (5) |
+-----------------------+---------------+------------+
+-----------------------+---------------+------------+ | 分野| クラス| Replicable| +-----------------------+---------------+------------+ | ソース港| 静的にクールです。| はい(1)| | 仕向港| 静的にクールです。| はい(1)| | 一連番号| 変化します。| (2)がありません。| | 承認番号| 変化します。| いいえ| | データは相殺されます。| 推論されます。| なし| | 予約されたビット| 変化します。| (3)がありません。| | 旗| | | | CWR| 変化します。| (4)がありません。| | ECE| 変化します。| (4)がありません。| | URG| 変化します。| いいえ| | ACK| 変化します。| いいえ| | PSH| 変化します。| いいえ| | RST| 変化します。| いいえ| | SYN| 変化します。| いいえ| | フィン| 変化します。| いいえ| | 窓| 変化します。| はい| | チェックサム| 変化します。| いいえ| | 緊急のポインタ| 変化します。| はい(5)| +-----------------------+---------------+------------+
Figure 9: TCP Header
図9: TCPヘッダー
West & McCann Informational [Page 14] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[14ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
(1) On the server side, the port number is likely to be a well-known
value. On the client side, the port number is generally selected
by the stack automatically. Whether the port number is
replicable depends upon how the stack chooses the port number.
Whilst most implementations use a simple scheme that sequentially
picks the next available port number, it may not be desirable to
rely on this behavior.
(1) サーバ側では、ポートナンバーが周知の値である傾向があります。 一般に、クライアント側では、ポートナンバーがスタックによって自動的に選択されます。 ポートナンバーがreplicableであるかどうかがスタックがどうポートナンバーを選ぶかによります。 ほとんどの実現が次の有効なポートナンバーを連続して選ぶ簡単な計画を使用する間、この振舞いに依存するのは望ましくないかもしれません。
(2) With the recommendation (and expected deployment) of TCP Initial
Sequence Number randomization, defined in RFC 1948 [10], it will
be impossible to share the sequence number. Thus, this field
will not be regarded as replicable.
TCP Initial Sequence Number無作為化の推薦(そして、展開を予想する)がある(2)、RFC1948[10]で定義されています、一連番号を共有するのは不可能でしょう。 したがって、この分野はreplicableと見なされないでしょう。
(3) See comment (4) for the IPv4 header, above.
(3) 上のIPv4ヘッダーのためにコメント(4)を見てください。
(4) See comment (2) on ECN flags for the IPv4 header, above.
(4) 上のIPv4ヘッダーのために電子証券取引ネットワーク旗のコメント(2)を見てください。
(5) The urgent pointer is very rarely used. This means that, in
practice, the field may be considered replicable.
(5) 緊急のポインタはめったに使用されません。 これは、分野がreplicableであると実際には考えられるかもしれないことを意味します。
3.4. TCP Options
3.4. TCPオプション
+---------------------------+--------------+------------+
| Option | SYN-only (1) | Replicable |
+---------------------------+--------------+------------+
| End of Option List | No | No (2) |
| No-Operation | No | No (2) |
| Maximum Segment Size | Yes | Yes |
| Window Scale | Yes | Yes |
| SACK-Permitted | Yes | Yes |
| SACK | No | No |
| Timestamp | No | No |
+---------------------------+--------------+------------+
+---------------------------+--------------+------------+ | オプション| SYNだけ(1)| Replicable| +---------------------------+--------------+------------+ | オプションリストの終わり| いいえ| (2)がありません。| | 操作がありません。| いいえ| (2)がありません。| | 最大のセグメントサイズ| はい| はい| | 窓のスケール| はい| はい| | 袋で、受入れられます。| はい| はい| | 袋| いいえ| いいえ| | タイムスタンプ| いいえ| いいえ| +---------------------------+--------------+------------+
Figure 10. TCP Options
図10。 TCPオプション
(1) This indicates whether the option only appears in SYN packets.
Options that are not 'SYN-only' may appear in any packet. Many
TCP options are used only in SYN packets. Some options, such as
MSS, Window Scale, and SACK-Permitted, will tend to have the same
value among replicable packet streams.
(1) これは、オプションがSYNパケットに現れるだけであるかどうかを示します。 'SYN専用'でないオプションはどんなパケットにも現れるかもしれません。 多くのTCPオプションがSYNパケットだけで使用されます。 MSSなどのWindow Scaleであって、SACKによって可能にされたいくつかのオプションが、replicableパケットの流れの中に同じ値を持っている傾向があるでしょう。
Thus, to support context sharing, the compressor should maintain
such TCP options in the context (even though they only appear in
the SYN segment).
したがって、文脈共有を支持するために、コンプレッサーは文脈におけるそのようなTCPオプションを維持するはずです(SYNセグメントに現れるだけですが)。
(2) Since these options have fixed values, they could be regarded as
replicable. However, the only interesting thing to convey about
(2) これらのオプションが値を修理したので、それらをreplicableと見なすことができました。 しかしながら、運ぶ唯一のおもしろいおよそもの
West & McCann Informational [Page 15] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[15ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
these options is their presence. If it is known that such an
option exists, its value is defined.
これらのオプションはそれらの存在です。 そのようなオプションが存在するのが知られているなら、値は定義されます。
3.5. Summary of Replication
3.5. 模写の概要
From the above analysis, it can be seen that there are reasonable grounds for exploiting redundancy between flows as well as between packets within a flow. Simply consider the advantage of being able to elide the source and destination addresses for a repeated connection between two IPv6 endpoints. There will also be a cost (in terms of complexity and robustness) for replicating contexts, and this must be considered when one decides what constitutes an appropriate solution.
上の分析から、流れの中に流れの間と、そして、パケットの間には、冗長を利用する正当な理由があるのを見ることができます。 単にできるのが2つのIPv6終点の間の繰り返された接続のためにソースと送付先アドレスを削除する利点を考えてください。 また、費用が文脈を模写するためにあるでしょう、そして、(複雑さと丈夫さに関して)人が適切な解決策を構成することについて決めると、これは考えなければなりません。
Finally, note that the use of replication requires that the compressor have a suitable degree of confidence that the source data is present and correct at the decompressor. This may place some restrictions on which of the 'changing' fields, in particular, can be utilised during replication.
最終的に、模写の使用が、コンプレッサーにはソースデータが減圧装置で現在であって正しいという適当な度の信用があるのを必要とすることに注意してください。 これは模写の間'変化'分野のどれを特に利用できるかに関するいくつかの制限を置くかもしれません。
4. Analysis of Change Patterns of Header Fields
4. ヘッダーフィールドの変化パターンの分析
To design suitable mechanisms for efficient compression of all header fields, their change patterns must be analyzed. For this reason, an extended classification is done based on the general classification in 2, considering the fields that were labeled CHANGING in that classification.
すべてのヘッダーフィールドの効率的な圧縮のために適当なメカニズムを設計するために、それらの変化パターンを分析しなければなりません。 この理由で、2における大別に基づいて拡張分類をします、その分類でCHANGINGとラベルされた分野を考える場合。
The CHANGING fields are separated into five different subclasses:
CHANGING野原は5つの異なったサブクラスに分離されます:
o STATIC
o 静電気
These are fields that were classified as CHANGING on a general
basis, but that are classified as STATIC here due to certain
additional assumptions.
これらはCHANGINGとして一般的ベースで分類されましたが、ある追加仮定のためSTATICとしてここで分類される分野です。
o SEMISTATIC
o SEMISTATIC
These fields are STATIC most of the time. However, occasionally
the value changes but reverts to its original value after a known
number of packets.
たいていこれらの分野はSTATICです。 しかしながら、値は、パケットの既知数の後に時折、元の値に変化しますが、戻ります。
o RARELY-CHANGING (RC)
o めったに変化しません。(RC)
These are fields that change their values occasionally and then
keep their new values.
これらは時折それらの値を変えて、次にそれらの新しい値を保つ分野です。
West & McCann Informational [Page 16] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[16ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
o ALTERNATING
o 交替します。
These fields alternate between a small number of different values.
これらの分野は少ない数の異価の間を行き来します。
o IRREGULAR
o 不規則
These, finally, are the fields for which no useful change pattern
can be identified.
これらは最終的にどんな役に立つ変化パターンも特定できない分野です。
To further expand the classification possibilities without increasing complexity, the classification can be done either according to the values of the field and/or according to the values of the deltas for the field.
増加する複雑さなしで分類の可能性をさらに広げるために、分野の値デルタの値に従って、分野に分類できます。
When the classification is done, other details are also stated regarding possible additional knowledge about the field values and/or field deltas, according to the classification. For fields classified as STATIC or SEMISTATIC, the value of the field could be not only STATIC but also well-KNOWN a priori (two states for SEMISTATIC fields). For fields with non-irregular change behavior, it could be known that changes are usually within a LIMITED range compared to the maximal change for the field. For other fields, the values are completely UNKNOWN.
また、分類が完了していると、他の詳細は分野値、そして/または、分野デルタに関する可能な追加知識に関して述べられます、分類に従って。 STATICかSEMISTATICとして分類された分野に、分野の値はSTATICだけではなく、先験的(SEMISTATIC分野への2つの州)に井戸-KNOWNになりもするかもしれません。 非不規則な変化の振舞いがある分野において、分野のために最大限度の変化と比べて、通常株式会社範囲の中に変化があるのを知ることができました。 他の分野に、値は完全にUNKNOWNです。
Figure 11 classifies all the CHANGING fields on the basis of their expected change patterns. (4) refers to IPv4 fields and (6) refers to IPv6.
図11 それらの予想された変化パターンに基づいてすべてのCHANGING分野を分類します。 (4) 分野と(6)が参照するIPv4をIPv6と呼びます。
West & McCann Informational [Page 17] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[17ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
+------------------------+-------------+-------------+-------------+ | Field | Value/Delta | Class | Knowledge | +========================+=============+=============+=============+ | DSCP(4) / Tr.Class(6) | Value | ALTERNATING | UNKNOWN | +------------------------+-------------+-------------+-------------+ | IP ECT flag(4) | Value | RC | UNKNOWN | +------------------------+-------------+-------------+-------------+ | IP CE flag(4) | Value | RC | UNKNOWN | +------------------------+-------------+-------------+-------------+ | Sequential | Delta | STATIC | KNOWN | | -----------+-------------+-------------+-------------+ | IP Id(4) Seq. jump | Delta | RC | LIMITED | | -----------+-------------+-------------+-------------+ | Random | Value | IRREGULAR | UNKNOWN | +------------------------+-------------+-------------+-------------+ | IP DF flag(4) | Value | RC | UNKNOWN | +------------------------+-------------+-------------+-------------+ | IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED | +------------------------+-------------+-------------+-------------+ | TCP Sequence Number | Delta | IRREGULAR | LIMITED | +------------------------+-------------+-------------+-------------+ | TCP Acknowledgement Num| Delta | IRREGULAR | LIMITED | +------------------------+-------------+-------------+-------------+ | TCP Reserved | Value | RC | UNKNOWN | +------------------------+-------------+-------------+-------------+ | TCP flags | | | | | ECN flags | Value | IRREGULAR | UNKNOWN | | CWR flag | Value | IRREGULAR | UNKNOWN | | ECE flag | Value | IRREGULAR | UNKNOWN | | URG flag | Value | IRREGULAR | UNKNOWN | | ACK flag | Value | SEMISTATIC | KNOWN | | PSH flag | Value | IRREGULAR | UNKNOWN | | RST flag | Value | IRREGULAR | UNKNOWN | | SYN flag | Value | SEMISTATIC | KNOWN | | FIN flag | Value | SEMISTATIC | KNOWN | +------------------------+-------------+-------------+-------------+ | TCP Window | Value | ALTERNATING | KNOWN | +------------------------+-------------+-------------+-------------+ | TCP Checksum | Value | IRREGULAR | UNKNOWN | +------------------------+-------------+-------------+-------------+ | TCP Urgent Pointer | Value | IRREGULAR | KNOWN | +------------------------+-------------+-------------+-------------+ | TCP Options | Value | IRREGULAR | UNKNOWN | +------------------------+-------------+-------------+-------------+
+------------------------+-------------+-------------+-------------+ | 分野| 値/デルタ| クラス| 知識| +========================+=============+=============+=============+ | DSCP(4) / Tr.Class(6)| 値| 交替します。| 未知| +------------------------+-------------+-------------+-------------+ | IP ECT旗(4)| 値| RC| 未知| +------------------------+-------------+-------------+-------------+ | IP CE旗(4)| 値| RC| 未知| +------------------------+-------------+-------------+-------------+ | 連続する| デルタ| 静電気| 知られています。| | -----------+-------------+-------------+-------------+ | IP Id(4) Seqジャンプしてください。| デルタ| RC| 制限されます。| | -----------+-------------+-------------+-------------+ | 無作為| 値| 不規則| 未知| +------------------------+-------------+-------------+-------------+ | IP DF旗(4)| 値| RC| 未知| +------------------------+-------------+-------------+-------------+ | IP TTL(4)/ホップリム(6)| 値| 交替します。| 制限されます。| +------------------------+-------------+-------------+-------------+ | TCP一連番号| デルタ| 不規則| 制限されます。| +------------------------+-------------+-------------+-------------+ | TCP Acknowledgementヌム| デルタ| 不規則| 制限されます。| +------------------------+-------------+-------------+-------------+ | 予約されたTCP| 値| RC| 未知| +------------------------+-------------+-------------+-------------+ | TCP旗| | | | | 電子証券取引ネットワーク旗| 値| 不規則| 未知| | CWR旗| 値| 不規則| 未知| | ECE旗| 値| 不規則| 未知| | URG旗| 値| 不規則| 未知| | ACK旗| 値| SEMISTATIC| 知られています。| | PSH旗| 値| 不規則| 未知| | RST旗| 値| 不規則| 未知| | SYN旗| 値| SEMISTATIC| 知られています。| | FIN旗| 値| SEMISTATIC| 知られています。| +------------------------+-------------+-------------+-------------+ | TCPの窓| 値| 交替します。| 知られています。| +------------------------+-------------+-------------+-------------+ | TCPチェックサム| 値| 不規則| 未知| +------------------------+-------------+-------------+-------------+ | TCPの緊急のポインタ| 値| 不規則| 知られています。| +------------------------+-------------+-------------+-------------+ | TCPオプション| 値| 不規則| 未知| +------------------------+-------------+-------------+-------------+
Figure 11. Classification of CHANGING Fields
図11。 職業を替える分類
West & McCann Informational [Page 18] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[18ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
The following subsections discuss the various header fields in detail. Note that Table 1 and the discussion below do not consider changes caused by loss or reordering before the compression point.
以下の小区分は詳細に様々なヘッダーフィールドについて議論します。 Table1と以下での議論が圧密点の前で損失で引き起こすか、または再命令される変化を考えないことに注意してください。
4.1. IP Header
4.1. IPヘッダー
4.1.1. IP Traffic-Class / Type-Of-Service (TOS)
4.1.1. サービスのIP交通クラス/タイプ(TOS)
The Traffic-Class (IPv6) or Type-Of-Service/DSCP (IPv4) field might be expected to change during the lifetime of a packet stream. This analysis considers several RFCs that describe modifications to the original RFC 791 [1].
Traffic-クラス(IPv6)かサービスのType/DSCP(IPv4)分野がパケットの流れの生涯変化すると予想されるかもしれません。 この分析はオリジナルのRFC791[1]に変更を説明する数個のRFCsを考えます。
The TOS byte was initially described in RFC 791 [1] as 3 bits of precedence followed by 3 bits of TOS and 2 reserved bits (defined to be zero). RFC 1122 [21] extended this to specify 5 bits of TOS, although the meanings of the additional 2 bits were not defined. RFC 1349 [23] defined the 4th bit of TOS as 'minimize monetary cost'. The next significant change was in RFC 2474 [14] (obsoleting RFC 1349 [23]). RFC 2474 reworked the TOS octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits. Most recently, RFC 2780 [30] identified the 2 reserved bits in the TOS or traffic class octet for experimental use with ECN.
TOSの3ビットに従って先行の3ビットが続いて、2がビットを予約したとき(ゼロになるように、定義されます)、TOSバイトは初めは、RFC791[1]で説明されました。 RFC1122[21]はTOSの5ビットを指定するためにこれを広げました、追加2ビットの意味が定義されませんでしたが。 RFC1349[23]はTOSの4番目のビットを'貨幣原価を最小にしてください'と定義しました。 次の著しい変化はRFC2474[14]にありました。(RFC1349[23])を時代遅れにします。 RFC2474はDSCP(DiffServ Code Point)と未使用の2ビットの6ビットとしてTOS八重奏を作りなおしました。 ごく最近、RFC2780[30]は電子証券取引ネットワークと共に実験用のためのTOSか交通クラス八重奏で予約された2ビットを特定しました。
It is therefore proposed that the TOS (or traffic class) octet be classified as 6 bits for the DSCP and 2 additional bits. These 2 bits may be expected to be zero or to contain ECN data. From a future-proofing perspective, it is preferable to assume the use of ECN, especially with respect to TCP.
したがって、TOS(または、交通のクラス)八重奏がDSCPのための6ビットと追加2ビットとして分類されるよう提案されます。 これらの2ビットは、ゼロであるか電子証券取引ネットワークデータを含むと予想されるかもしれません。 未来を検査する見解から、特にTCPに関して電子証券取引ネットワークの使用を仮定するのは望ましいです。
It is also considered important that the profile work with legacy stacks, since these will be in existence for some considerable time to come. For simplicity, this will be considered as 6 bits of TOS information and 2 bits of ECN data, so the fields are always considered to be structured the same way.
また、プロフィールが遺産スタックで働いているのは重要であると考えられます、これらがいつかの来たるかなりの時間の間、現存するので。 簡単さにおいて、これが6ビットのTOS情報と2ビットの電子証券取引ネットワークデータであるとみなされるので、いつも同じように分野が構造化されると考えられます。
The DSCP (as for TOS in ROHC RTP) is not expected to change frequently (although it could change mid-flow, for example, as a result of a route change).
DSCP(ROHC RTPのTOSのような)が頻繁に変化しないと予想されます(例えば、ルート変化の結果、中間の流れを変えるかもしれませんが)。
4.1.2. ECN Flags
4.1.2. 電子証券取引ネットワーク旗
Initially, we describe the ECN flags as specified in RFC 2481 [15] and RFC 3168 [18]. Subsequently, a suggested update is described that would alter the behavior of the flags.
初めは、私たちは、電子証券取引ネットワーク旗がRFC2481[15]とRFC3168[18]で指定されていると記述します。 次に、旗の働きを変更する提案されたアップデートは説明されます。
In RFC 2481 [15] there are 2 separate flags, the ECT (ECN Capable Transport) flag and the CE (Congestion Experienced) flag. The ECT
RFC2481[15]に、2個の別々の旗、ECT(電子証券取引ネットワークCapable Transport)旗、およびCE(混雑Experienced)旗があります。 ECT
West & McCann Informational [Page 19] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[19ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
flag, if negotiated by the TCP stack, will be '1' for all data packets and '0' for all 'pure acknowledgement' packets. This means that the behavior of the ECT flag is linked to behavior in the TCP stack. Whether this can be exploited for compression is not clear.
TCPスタックによって交渉されるなら、旗は、すべての'純粋な承認'パケットのためにすべてのデータ・パケットのための'1'と'になるでしょう'0。 これは、ECT旗の働きがTCPスタックで振舞いにリンクされることを意味します。 圧縮にこれを利用できるかどうかは明確ではありません。
The CE flag is only used if ECT is set to '1'. It is set to '0' by the sender and can be set to '1' by an ECN-capable router in the network to indicate congestion. Thus the CE flag is expected to be randomly set to '1' with a probability dependent on the congestion state of the network and the position of the compressor in the path. Therefore, a compressor located close to the receiver in a congested network will see the CE bit set frequently, but a compressor located close to a sender will rarely, if ever, see the CE bit set to '1'.
ECTが'1'に用意ができている場合にだけ、CE旗は使用されます。 それは、混雑を示すためには送付者によって'0'に設定されて、ネットワークにおける電子証券取引ネットワークできるルータによる'1'へのセットであるかもしれません。 したがって、経路のネットワークの混雑事情とコンプレッサーの位置に依存する確率で'1'に設定されて、CE旗は手当たりしだいにである予想されます。 したがって、混雑しているネットワークにおける受信機の近くに位置するコンプレッサーは、CEビットが頻繁に設定されるのを見るでしょうが、かつてなら、送付者の近くに位置するコンプレッサーは、めったにCEビットが'1'に設定されるのを見ないでしょう。
A recent experimental proposal [19] suggests an alternative view of these 2 bits. This considers the two bits together to have 4 possible codepoints. Meanings are then assigned to the codepoints:
最近の実験的な提案[19]はこれらの2ビットの代替の視点を示します。 これは、4の可能なcodepointsを持つために2ビットを一緒に考えます。 次に、意味はcodepointsに割り当てられます:
00 Not ECN capable
01 ECN capable, no congestion (known as ECT(0))
10 ECN capable, no congestion (known as ECT(1))
11 Congestion experienced
できる電子証券取引ネットワークできる01電子証券取引ネットワークではなく、00、混雑がない、(できるECT(0))10電子証券取引ネットワーク、どんな混雑としても知られない、(経験されたECT(1))11Congestionとして、知られています。
The use of 2 codepoints for signaling ECT allows the sender to detect when a receiver is not reliably echoing congestion information.
2codepointsのシグナリングECTの使用で、送付者は、受信機がいつ混雑情報を確かに反映していないかを検出できます。
For the purposes of compression, this update means that ECT(0) and ECT(1) are equally likely (for an ECN capable flow) and that '11' will be seen relatively rarely. The probability of seeing a congestion indication is discussed above in the description of the CE flag.
''圧縮の目的のために、このアップデートは、ECT(0)とECT(1)が等しくありそうであることを(電子証券取引ネットワークのできる流動のための)意味します、そして、その11年に、比較的めったに見られないでしょう。 上でCE旗の記述で混雑指示を見るという確率について議論します。
It is suggested that, for the purposes of compression, ECN with nonces be assumed as the baseline, although the compression scheme must be able to compress the original ECN scheme transparently.
圧縮の目的のための一回だけがある電子証券取引ネットワークが基線として想定されることが提案されます、圧縮技術は透明にオリジナルの電子証券取引ネットワーク計画を圧縮できなければなりませんが。
4.1.3. IP Identification
4.1.3. IP識別
The Identification field (IP ID) of the IPv4 header identifies which fragments constitute a datagram, when fragmented datagrams are reassembled. The IPv4 specification does not specify exactly how this field is to be assigned values, only that each packet should get an IP ID that is unique for the source-destination pair and protocol for the time during which the datagram (or any of its fragments) could be alive in the network. This means that assignment of IP ID values can be done in various ways, which we have separated into three classes:
IPv4ヘッダーのIdentification分野(IP ID)は、断片化しているデータグラムが組み立て直されるとき、どの断片がデータグラムを構成するかを特定します。 IPv4仕様は、この分野がちょうどどのように割り当てられた値であるかことであると指定しないで、各パケットはデータグラム(または、断片のどれか)が生きるかもしれない時間のソース目的地組とプロトコルに、ネットワークでユニークなIP IDを得るだけであるはずです。 これは、私たちが3つのクラスに切り離した様々な方法でIP ID値の課題ができることを意味します:
West & McCann Informational [Page 20] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[20ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
o Sequential jump
o 連続したジャンプ
This is the most common assignment policy in today's IP stacks. A
single IP ID counter is used for all packet streams. When the
sender is running more than one packet stream simultaneously, the
IP ID can increase by more than one between packets in a stream.
The IP ID values will be much more predictable and will require
fewer bits to transfer than random values, and the packet-to-
packet increment (determined by the number of active outgoing
packet streams and sending frequencies) will usually be limited.
これは今日のIPスタックで最も一般的な課題方針です。 単一のIP IDカウンタはすべてのパケットの流れに使用されます。送付者が同時に1つ以上のパケットの流れを走らせるとき、IP IDは絶え間なくパケットの間の1つ以上以上増加できます。 IP ID値は、はるかに予測できて、移すために無作為の値より少ないビットを必要とするでしょう、そして、通常、パケットからパケットへの増分(断固とした活発な出発しているパケットの流れと送付頻度の数に従って)は制限されるでしょう。
o Random
o 無作為
Some IP stacks assign IP ID values by using a pseudo-random number
generator. There is thus no correlation between the ID values of
subsequent datagrams. Therefore, there is no way to predict the
IP ID value for the next datagram. For header compression
purposes, this means that the IP ID field needs to be sent
uncompressed with each datagram, resulting in two extra octets of
header. IP stacks in cellular terminals that need optimum header
compression efficiency should not use this IP ID assignment
policy.
いくつかのIPスタックが、疑似乱数生成器を使用することによって、IP ID値を割り当てます。 その結果、その後のデータグラムのID値の間には、相関関係が全くありません。したがって、次のデータグラムのためにIP ID価値を予測する方法が全くありません。 ヘッダー圧縮目的のために、これは、送られるべきIP ID分野の必要性が各データグラムで解凍したことを意味します、ヘッダーの2つの余分な八重奏をもたらして。 最適なヘッダー圧縮効率を必要とするセル端末でのIPスタックはこのIP ID課題方針を使用するはずがありません。
o Sequential
o 連続する
This assignment policy keeps a separate counter for each outgoing
packet stream, and thus the IP ID value will increment by one for
each packet in the stream, except at wrap around. Therefore, the
delta value of the field is constant and well known a priori.
This assignment policy is the most desirable for header
compression purposes. However, its usage is not as common as it
perhaps should be.
この課題方針は、各パケットのために流れでは、それぞれの出発しているパケットの流れのための別々のカウンタを保って、その結果、値が1つ増加するIP IDを保ちます、およそ包装を除いて。 したがって、分野のデルタ値は、先験的に一定であって、よく知られています。 この課題方針はヘッダー圧縮目的のために最も望ましいです。 しかしながら、用法はそれが恐らくそうであるべきであるほど一般的ではありません。
In order to avoid violating RFC 791 [1], packets sharing the same
IP address pair and IP protocol number cannot use the same IP ID
values. Therefore, implementations of sequential policies must
make the ID number spaces disjoint for packet streams of the same
IP protocol going between the same pair of nodes. This can be
done in a number of ways, all of which introduce occasional jumps
and thus make the policy less than perfectly sequential. For
header compression purposes, less frequent jumps are preferred.
RFC791[1]に違反するのを避けるために、同じIPアドレス組とIPプロトコル番号を共有するパケットは同じIP ID値を使用できません。 したがって、連続した方針の実現で、ID数の空間はノードの同じ組を取り持つ同じIPプロトコルのパケットの流れのためにばらばらにならなければなりません。 多くの方法でこれができます。時々のジャンプを導入します。その結果、それはそのすべてが、完全に連続するほど方針を作りません。 ヘッダー圧縮目的のために、それほど頻繁でないジャンプは好まれます。
Note that the ID is an IPv4 mechanism and is therefore not a problem for IPv6. For IPv4, the ID could be handled in three different ways. First, we have the inefficient but reliable solution where the ID field is sent as-is in all packets, increasing the compressed headers by two octets. This is the best way to handle the ID field if the sender uses random assignment of the ID field. Second, there can be
IDがIPv4メカニズムであり、したがって、IPv6のための問題でないことに注意してください。 IPv4に関しては、3つの異なった方法でIDを扱うことができました。 まず最初に、私たちには、ID野原がすべてのパケットでそのままで送られる効率の悪い、しかし、信頼できる解決策があります、2つの八重奏で圧縮されたヘッダーを増加させて。 送付者がID分野の無作為の課題を使用するなら、これはID分野を扱う最も良い方法です。 2番目に、あることができます。
West & McCann Informational [Page 21] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[21ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
solutions with more flexible mechanisms that require fewer bits for the ID handling as long as sequential jump assignment is used. Such solutions will probably require even more bits if random assignment is used by the sender. Knowledge about the sender's assignment policy could therefore be useful when choosing between the two solutions above. Finally, even for IPv4, header compression could be designed without any additional information for the ID field included in compressed headers. To use such schemes, it must be known which assignment policy for the ID field is being used by the sender. That might not be possible to know, which implies that the applicability of such solutions is very uncertain. However, designers of IPv4 stacks for cellular terminals should use an assignment policy close to sequential.
連続したジャンプ課題が使用されている限り、ID取り扱いのために、より少ないビットを必要とするよりフレキシブルなメカニズムがある解決策。 無作為の課題が送付者によって使用されると、そのような解決策はたぶんさらに多くのビットを必要とするでしょう。 したがって、上の2つの解決策を選ぶとき、送付者の課題方針に関する知識は役に立つかもしれません。 IPv4に関してはさえ、圧縮されたヘッダーにID分野を含むための少しも追加情報なしでヘッダー圧縮を設計できました。 そのような計画を使用するために、ID分野へのどの課題方針が送付者によって使用されているかを知っていなければなりません。 知るのにおいて可能でないかもしれなく、そのような解決策の適用性が非常に不確実であることを含意します。 しかしながら、セル端末へのIPv4スタックのデザイナーは連続する近くときに課題方針を使用するべきです。
With regard to TCP compression, the behavior of the IP ID field is essentially the same. However, in RFC 3095 [31], the IP ID is generally inferred from the RTP Sequence Number. There is no obvious candidate in the TCP case for a field to offer this 'master sequence number' role.
TCP圧縮に関して、IP ID分野の振舞いは本質的には同じです。 しかしながら、一般に、RFC3095[31]では、IP IDはRTP Sequence Numberから推論されます。 分野がこの'マスター一連番号'の役割を提供するように、TCP場合にはどんな明白な候補もいません。
Clearly, from a busy server, the observed behavior may well be quite erratic. This is a case where the ability to share the IP compression context between a number of flows (between the same end- points) could offer potential benefits. However, this would only have any real impact where there is a large number of flows between one machine and the server. If context sharing is being considered, then it is preferable to share the IP part of the context.
明確に、忙しいサーバから、観測された振舞いはたぶんかなり不安定でしょう。 これは多くの流れ(同じ終わりのポイントの間の)の間のIP圧縮文脈を共有する能力が潜在的利益を提供できたそうです。 しかしながら、1台のマシンとサーバの間には、多くの流れがあるところにこれはどんな本当の影響力も持っているだけでしょう。文脈共有が考えられるなら、文脈のIP部分を共有するのは望ましいです。
4.1.4. Don't Fragment (DF) flag
4.1.4. Fragment(DF)は弛みませんか?
Path-MTU discovery (RFC 1191 for IPv4 [6] and RFC 1981 for IPv6 [11]) is widely deployed for TCP, in contrast to little current use for UDP packet streams. This employs the DF flag value of '1' to detect the need for fragmentation in the end-to-end path and to probe the minimum MTU along the network path. End hosts using this technique may be expected to send all packets with DF set to '1', although a host may end PMTU discovery by clearing the DF bit to '0'. Thus, for compression, we expect the field value to be stable.
IPv6[11])のためのIPv4[6]とRFC1981のためのRFC1191はTCPのために広く配備されます、UDPパケットの流れの少ない現在の使用と対照して。経路MTU探索、(これは、終わらせる終わりの断片化経路の必要性を見つけて、ネットワーク経路に沿って最小のMTUを調べるのに'1'のDF旗の価値を使います。 このテクニックを使用している終わりのホストが'1'に用意ができているDFがあるすべてのパケットを送ると予想されるかもしれません、ホストはDFビットを'0'まできれいにすることによって、PMTU発見を終わらせるかもしれませんが。 したがって、圧縮のために、私たちは、分野値が安定していると予想します。
4.1.5. IP Hop-Limit / Time-To-Live (TTL)
4.1.5. 生きるIPホップ限界/時間(TTL)
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be constant during the lifetime of a packet stream or to alternate between a limited number of values due to route changes.
Hop-限界(IPv6)か生きるTime(IPv4)分野が、パケットの流れの生涯一定であるか、またはルート変化のため限られた数の値の間を行き来すると予想されます。
West & McCann Informational [Page 22] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[22ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
4.2. TCP Header
4.2. TCPヘッダー
Any discussion of compressability of TCP fields borrows heavily from RFC 1144 [22]. However, the premise of how the compression is performed is slightly different, and the protocol has evolved slightly in the intervening time.
TCP分野のcompressabilityのどんな議論もRFC1144[22]から大いに借ります。 しかしながら、圧縮がどう実行されるかに関する前提はわずかに異なっています、そして、プロトコルはわずかな介入している時間で発展しました。
4.2.1. Sequence Number
4.2.1. 一連番号
Understanding the sequence and acknowledgement number behavior is essential for a TCP compression scheme.
TCP圧縮技術に、系列と承認数の振舞いを理解しているのは不可欠です。
At the simplest level, the behavior of the sequence number can be described relatively easily. However, there are a number of complicating factors that also need to be considered.
最も簡単なレベルでは、比較的容易に一連番号の振舞いについて説明できます。 しかしながら、また、考えられる必要がある多くの複雑にする要素があります。
For transferring in-sequence data packets, the sequence number will increment for each packet by between 0 and an upper limit defined by the MSS (Maximum Segment Size) and, if it is being used, by Path-MTU discovery.
連続してデータ・パケットを移すために、一連番号は0上限の間でMSS(最大のSegment Size)によって定義されるのによる各パケットのために増加して、それであるなら、Path-MTUによって使用されるのは、発見ですか?
There are common MSS values, but these can be quite variable and unpredictable for any given flow. Given this variability and the range of window sizes, it is hard (compared with the RTP case, for example) to select a 'one size fits all' encoding for the sequence number. (The same argument applies equally to the acknowledgement number).
一般的なMSS値がありますが、どんな与えられた流れにおいても、これらは、かなり可変であって、予測できるはずがありません。 この可変性とウィンドウサイズの範囲を考えて、一連番号のための'フリーサイズ'コード化を選択しにくいです(RTPケースと比べて例えば)。 (同じ議論は等しく承認番号に適用されます。)
Note that the increment of the sequence number in a packet is the size of the data payload of that packet (including the SYN and FIN flags). This is, of course, exactly the relationship that RFC 1144 [22] exploits to compress the sequence number in the most efficient case. This technique may not be directly applicable to a robust solution, but it may be a useful relationship to consider.
パケットの一連番号の増分がそのパケットのデータペイロードのサイズであることに注意してください(SYNとFIN旗を含んでいて)。 これはもちろんまさにRFC1144[22]が最も効率的な場合における一連番号を圧縮するのに利用する関係です。 このテクニックは直接ロバスト解に適切でないかもしれませんが、考えるのは、役に立つ関係であるかもしれません。
However, at any point on the path (i.e., wherever a compressor might be deployed), the sequence number can be anywhere within a range defined by the TCP window. This is a combination of a number of values (buffer space at the sender; advertised buffer size at the receiver; and TCP congestion control algorithms). Missing packets or retransmissions can cause the TCP sequence number to fluctuate within the limits of this window.
しかしながら、経路(すなわち、コンプレッサーが配備されるどこ)の任意な点で、一連番号がTCPの窓によって定義された範囲の中でどこでもあることができるか。 これは多くの値(送付者のバッファ領域(受信機の広告を出しているバッファサイズ)とTCP輻輳制御アルゴリズム)の組み合わせです。 なくなったパケットか「再-トランスミッション」がこの窓の限界の中でTCP一連番号を変動させることができます。
It is desirable to be able to predict the sequence number with some regularity. However, this also appears to be difficult to do. For example, during bulk data transfer, the sequence number will tend to go up by 1 MSS per packet (assuming no packet loss). Higher layer values have been seen to have an impact as well, where sequence
何らかの規則性で一連番号を予測できるのは望ましいです。 しかしながら、また、これはするのが難しいように見えます。 例えば、バルク・データ転送の間、一連番号は、1パケットあたり1MSSで上がる傾向があるでしょう(どんなパケットも損失でないと仮定して)。 良い同じくらい衝撃、どこを持っているかをより高い層の値を見てある、系列
West & McCann Informational [Page 23] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[23ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
number behavior has been observed with an 8 kbyte repeating pattern -- 5 segments of 1460 bytes followed by 1 segment of 892 bytes. The implementation of TCP and the management of buffers within a protocol stack can affect the behavior of the sequence number.
数の振舞いは8キロバイトの繰り返しているパターンで観測されました--892バイトの1つのセグメントがあとに続いた1460バイトの5つのセグメント。 TCPの実現とプロトコル・スタックの中のバッファの管理は一連番号の振舞いに影響できます。
It may be possible to track the TCP window by the compressor, allowing it to bound the size of these jumps.
コンプレッサーでTCPの窓を追跡するのは可能であるかもしれません、それがバウンドするのを許容して。これらのジャンプのサイズ。
For interactive flows (for example, telnet), the sequence number will change by small, irregular amounts. In this case, the Nagle algorithm [3] commonly applies, coalescing small packets where possible in order to reduce the basic header overhead. This may also mean that predictable changes in the sequence number are less likely to occur. The Nagle algorithm is an optimisation and is not required to be used (applications can disable its use). However, it is turned on by default in all common TCP implementations.
対話的な流れ(例えば、telnet)のために、小さくて、不規則な量に応じて、一連番号は変化するでしょう。 この場合、ネーグルアルゴリズム[3]は一般的に適用されます、基本的なヘッダーオーバーヘッドを下げるために可能であるところと小型小包を合体させて。 また、これは、一連番号における予測できる変化が、より起こりそうにないことを意味するかもしれません。 ネーグルアルゴリズムは、最適化であり、使用されるのに必要ではありません(アプリケーションは使用を無効にすることができます)。 しかしながら、それはデフォルトですべての一般的なTCP実現でつけられています。
Note also that the SYN and FIN flags (which have to be acknowledged) each consume 1 byte of sequence space.
また、SYNとFIN旗(承認されなければならない)がそれぞれ1バイトの系列スペースを消費することに注意してください。
4.2.2. Acknowledgement Number
4.2.2. 承認番号
Much of the information about the sequence number applies equally to the acknowledgement number. However, there are some important differences.
一連番号の情報の多くが等しく承認番号に適用されます。 しかしながら、いくつかの重要な違いがあります。
For bulk data transfers, there will tend to be 1 acknowledgement for every 2 data segments. The algorithm is specified in RFC 2581 [16]. An ACK need not always be sent immediately on receipt of a data segment, but it must be sent within 500ms and should be generated for at least every second full-size segment (MSS) of received data. It may be seen from this that the delta for the acknowledgement number is roughly twice that of the sequence number. This is not always the case, and the discussion about sequence number irregularity should be applied.
バルク・データ転送のために、2つのデータ・セグメントあたり1つの承認がある傾向があるでしょう。 アルゴリズムはRFC2581[16]で指定されます。 すぐデータ・セグメントを受け取り次第いつもACKを送らなければならないというわけではありませんが、それは、500msの中で送らなければならなくて、受信データの少なくともあらゆる2番目のフルサイズセグメント(MSS)のために発生するべきです。 これから承認番号のためのデルタがおよそ一連番号のものの2倍であることがわかるかもしれません。 これはいつもそうであるというわけではありません、そして、一連番号不規則についての議論は適用されるべきです。
As an aside, a common implementation bug is 'stretch ACKs' [33] (acknowledgements may be generated less frequently than every two full-size data segments). This pattern can also occur following loss on the return path.
余談として、一般的な実現バグは'伸びACKs'[33](承認は2つのフルサイズデータ・セグメント毎よりどんな頻繁にも発生しないかもしれない)です。 また、リターンパスにおける損失に続いて、このパターンは起こることができます。
Since the acknowledgement number is cumulative, dropped packets in the forward path will result in the acknowledgement number remaining constant for a time in the reverse direction. Retransmission of a dropped segment can then cause a substantial jump in the acknowledgement number. These jumps in acknowledgement number are bounded by the TCP window, just as for the jumps in sequence number.
承認番号が累積しているので、フォワードパスの低下しているパケットは時間反対の方向に一定のままで残っている承認番号をもたらすでしょう。 そして、低下しているセグメントのRetransmissionは承認番号におけるかなりのジャンプを引き起こす場合があります。 承認番号におけるこれらのジャンプはまさしく系列番号におけるジャンプのようにTCPの窓のそばで境界があります。
West & McCann Informational [Page 24] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[24ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
In the acknowledgement case, information about the advertised received window gives a bound to the size of any ACK jump.
承認場合では、広告を出している容認された窓の情報はどんなACKジャンプのサイズにもバウンドを与えます。
4.2.3. Reserved
4.2.3. 予約されます。
This field is reserved, and it therefore might be expected to be zero. This can no longer be assumed, due to future-proofing. It is only a matter of time before a suggestion for using the flag is made.
この分野は予約されています、そして、したがって、それはゼロであると予想されるかもしれません。 未来を検査しているためもうこれを想定できません。 旗を使用するための提案をする前にそれは時間の問題にすぎません。
4.2.4. Flags
4.2.4. 旗
o ECN-E (Explicit Congestion Notification)
o 電子証券取引ネットワーク-E(明白な混雑通知)
'1' to echo CE bit in IP header. It will be set in several
consecutive headers (until 'acknowledged' by CWR). If ECN nonces
are used, then there will be a 'nonce-sum' (NS) bit in the flags,
as well. Again, transparency of the reserved bits is crucial for
future-proofing this compression scheme. From an
efficiency/compression standpoint, the NS bit will either be
unused (always '0') or randomly changing. The nonce sum is the
1-bit sum of the ECT codepoints, as described in [19].
'1'反響するように、CEはIPヘッダーで噛み付きました。 それは数個の連続したヘッダーに設定されるでしょう(CWRによって'承認される'まで)。 電子証券取引ネットワーク一回だけが使用されていると、また、旗には'一回だけの合計'(NS)ビットがあるでしょう。 一方、この圧縮技術を未来検査するには、予約されたビットの透明は重要です。 効率/圧縮見地から、NSビットは、未使用(いつも'0')か変えるように手当たりしだいになるでしょう。 一回だけの合計は[19]で説明されるようにECT codepointsの1ビットの合計です。
o CWR (Congestion Window Reduced)
o CWR(減少する混雑ウィンドウ)
'1' to signal congestion window reduced on ECN. It will generally
be set in individual packets. The flag will be set once per loss
event. Thus, the probability of its being set is proportional to
the degree of congestion in the network, but it is less likely to
be set than the CE flag.
'1'混雑ウィンドウに合図するのは電子証券取引ネットワークで減少しました。 一般に、それは個々のパケットに設定されるでしょう。 旗は損失出来事に一度設定されるでしょう。 したがって、存在セットの確率がネットワークにおける、混雑の学位に比例していますが、それはCE旗ほど設定されそうにはありません。
o ECE (Echo Congestion Experience)
o ECE(エコー混雑経験)
If 'congestion experienced' is signaled in a received IP header,
this is echoed through the ECE bit in segments sent by the
receiver until acknowledged by seeing the CWR bit set. Clearly,
in periods of high congestion and/or long RTT, this flag will
frequently be set to '1'.
'経験された混雑'が容認されたIPヘッダーで合図されるなら、これはECEビットを通して受信機によってCWRビットが設定されるのを見ることによって承認されるまで送られたセグメントで反響されます。 明確に、高い混雑、そして/または、長いRTTの時代に、この旗は頻繁に'1'に設定されるでしょう。
During connection open (SYN and SYN/ACK packets), the ECN bits
have special meaning:
接続戸外(SYNとSYN/ACKパケット)の間、電子証券取引ネットワークビットには、特別な意味があります:
* CWR and ECN-E are both set with SYN to indicate desire to use
ECN.
* CWRと電子証券取引ネットワーク-EはSYNと共に電子証券取引ネットワークを使用する願望を示すようにともに用意ができています。
West & McCann Informational [Page 25] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[25ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
* CWR only is set in SYN-ACK, to agree to ECN.
* CWRだけがSYN-ACKで電子証券取引ネットワークに同意するのを用意ができています。
(The difference in bit-patterns for the negotiation is such that
it will work with broken stacks that reflect the value of
reserved bits).
(交渉のためのビット・パターンの違いは予約されたビットの価値を反映する壊れているスタックで働くようにものです。)
o URG (Urgent Flag)
o URG(緊急の旗)
'1' to indicate urgent data (which is unlikely with any flag other
than ACK).
'1'緊急のデータ(ACK以外のどんな旗にもありそうもない)を示すために。
o ACK (Acknowledgement)
o ACK(承認)
'1' for all except the initial 'SYN' packet.
'1'初期の'SYN'パケット以外のすべてのために。
o PSH (Push Function Field)
o PSH(プッシュ機能フィールド)
Generally accepted to be randomly '0' or '1'. However, it may be
biased more to one value than the other (this is largely caused by
the implementation of the stack).
一般に、手当たりしだいに'0'か'1'であると受け入れます。 しかしながら、それはもう片方より1つの値に偏られるかもしれません(これはスタックの実現で大幅に引き起こされます)。
o RST (Reset Connection)
o RST(リセット接続)
'1' to reset a connection (unlikely with any flag other than ACK).
'1'接続(ACK以外のどんな旗にもありそうもない)をリセットするために。
o SYN (Synchronize Sequence Number)
o SYN(一連番号を同期させます)
'1' for the SYN/SYN-ACK, only at the start of a connection.
'1'SYN/SYN-ACKと、接続の始めだけで。
o FIN (End of Data: FINished)
o フィン(データを終わらせてください: 終わる)です。
'1' to indicate 'no more data' (unlikely with any flag other than
ACK).
'1''それ以上のデータがない'(ACK以外のどんな旗にもありそうもない)を示すために。
4.2.5. Checksum
4.2.5. チェックサム
Carried as the end-to-end check for the TCP data. See RFC 1144 [22] for a discussion of why this should be carried. A header compression scheme should not rely upon the TCP checksum for robustness, though, and should apply appropriate error-detection mechanisms of its own. The TCP checksum has to be considered to be randomly changing.
TCPデータのための終わりから終わりへのチェックとして、運ばれます。 これが運ばれるべきである理由に関する議論のためのRFC1144[22]を見てください。 もっとも、ヘッダー圧縮技術は丈夫さのためにTCPチェックサムを当てにされるべきではありません、そして、それ自身の適切な誤り検出メカニズムを適用するべきです。 TCPチェックサムが手当たりしだいに変化すると考えられなければなりません。
4.2.6. Window
4.2.6. 窓
This may oscillate randomly between 0 and the receiver's window limit (for the connection).
これは手当たりしだいに、0と受信機の窓の限界(接続のための)の間を揺れるかもしれません。
West & McCann Informational [Page 26] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[26ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
In practice, the window will either not change or alternate between a relatively small number of values. Particularly when the window is closing (its value is getting smaller), the change in window is likely to be related to the segment size, but it is not clear that this necessarily offers any compression advantage. When the window is opening, the effect of 'Silly-Window Syndrome' avoidance should be remembered. This prevents the window from opening by small amounts that would encourage the sender to clock out small segments.
実際には、窓は、比較的少ない数の値の変えもしませんし、間を行き来もしないでしょう。 特に窓が閉じているとき(値は、より小さくなっています)、窓の変化はセグメントサイズに関連しそうですが、これが必ずどんな圧縮利点も示すのは、明確ではありません。 窓が開いているとき、'愚かなウィンドウSyndrome'回避の効果は覚えていられるべきです。 これは、送付者が小さいセグメントの仕事を終えるよう奨励する少量に従って窓が開くのを防ぎます。
When thinking about what fields might change in a sequence of TCP segments, one should note that the receiver can generate 'window update' segments in which only the window advertisement changes.
分野がTCPセグメントの系列で変えるかもしれないものについて考えるとき、受信機が窓の広告だけが変化する'窓のアップデート'セグメントを発生させることができることに注意するべきです。
4.2.7. Urgent Pointer
4.2.7. 緊急のポインタ
From a compression point of view, the Urgent Pointer is interesting because it offers an example where 'semantically identical' compression is not the same as 'bitwise identical'. This is because the value of the Urgent Pointer is only valid if the URG flag is set.
視点の圧密点から、'同じ状態で、bitwiseする'とき'意味的に同じ'圧縮が同じでない例を提供するので、Urgent Pointerはおもしろいです。 これはURG旗が設定される場合にだけUrgent Pointerの値が有効であるからです。
However, the TCP checksum must be passed transparently, in order to maintain its end-to-end integrity checking property. Since the TCP checksum includes the Urgent Pointer in its coverage, this enforces bitwise transparency of the Urgent Pointer. Thus, the issue of 'semantic' vs. 'bitwise' identity is presented as a note: the Urgent Pointer must be compressed in a way that preserves its value.
しかしながら、終わりから終わりへの特性をチェックする保全を維持するために透明にTCPチェックサムを通過しなければなりません。 以来TCPチェックサムが適用範囲にUrgent Pointerを含んでいる、これが実施する、bitwiseする、Urgent Pointerの透明。 したがって、'bitwise'に対して'意味'のアイデンティティの問題は注意として提示されます: 価値を守る方法でUrgent Pointerを圧縮しなければなりません。
If the URG flag is set, then the Urgent Pointer indicates the end of the urgent data and thus can point anywhere in the window. It may be set (and changing) over several segments. Note that urgent data is rarely used, since it is not a particularly clean way of managing out-of-band data.
URG旗が設定されるなら、Urgent Pointerは緊急のデータの終わりを示して、その結果、窓でどこでも指すことができます。 それはいくつかのセグメントの上のセットであるかもしれません(そして、変化)。 緊急のデータがめったに使用されないことにそれがバンドの外でデータを管理する特に清潔な方法でないことで注意してください。
4.3. Options
4.3. オプション
Options occupy space at the end of the TCP header. All options are included in the checksum. An option may begin on any byte boundary. The TCP header must be padded with zeros to make the header length a multiple of 32 bits.
オプションはTCPヘッダーの端で場所を塞ぎます。 すべてのオプションがチェックサムに含まれています。 オプションはどんなバイト境界でも始まるかもしれません。 ゼロでTCPヘッダーを水増しして、ヘッダ長を32ビットの倍数にしなければなりません。
Optional header fields are identified by an option kind field. Options 0 and 1 are exactly one octet, which is their kind field. All other options have their one-octet kind field, followed by a one-octet length field, followed by length-2 octets of option data.
任意のヘッダーフィールドはオプション種類の分野によって特定されます。 オプション0と1はまさに1つの八重奏です。(その八重奏はそれらの親切な分野です)。 すべての別の選択肢には、オプションデータの長さ-2つの八重奏で1八重奏の長さの分野があとに続いた親切な分野が続いた彼らの1八重奏があります。
West & McCann Informational [Page 27] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[27ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
4.3.1. Options Overview
4.3.1. オプション概観
The IANA provides the authoritative list of TCP options. Figure 12 describes the current allocations at the time of publication. Any new option would have a 'kind' value assigned by IANA. The list is available at [20]. Where applicable, the associated RFC is also cited.
IANAはTCPオプションの正式のリストを提供します。 図12は公表時点で、現在の配分について説明します。 どんな新しいオプションでも、IANAは'親切な'値を割り当てるでしょう。 リストは[20]で利用可能です。 また、適切であるところでは、関連RFCが引用されます。
+----+-------+------------------------------------+----------+-----+ |Kind|Length | Meaning | RFC | Use | | |octets | | | | +----+-------+------------------------------------+----------+-----+ | 0 | - | End of Option List | RFC 793 | * | | 1 | - | No-Operation | RFC 793 | * | | 2 | 4 | Maximum Segment Size | RFC 793 | * | | 3 | 3 | WSopt - Window Scale | RFC 1323 | * | | 4 | 2 | SACK Permitted | RFC 2018 | * | | 5 | N | SACK | RFC 2018 | * | | 6 | 6 | Echo (obsoleted by option 8) | RFC 1072 | | | 7 | 6 | Echo Reply (obsoleted by option 8) | RFC 1072 | | | 8 | 10 | TSopt - Time Stamp Option | RFC 1323 | * | | 9 | 2 | Partial Order Connection Permitted | RFC 1693 | | | 10 | 3 | Partial Order Service Profile | RFC 1693 | | | 11 | 6 | CC | RFC 1644 | | | 12 | 6 | CC.NEW | RFC 1644 | | | 13 | 6 | CC.ECHO | RFC 1644 | | | 14 | 3 | Alternate Checksum Request | RFC 1146 | | | 15 | N | Alternate Checksum Data | RFC 1146 | | | 16 | | Skeeter | | | | 17 | | Bubba | | | | 18 | 3 | Trailer Checksum Option | | | | 19 | 18 | MD5 Signature Option | RFC 2385 | | | 20 | | SCPS Capabilities | | | | 21 | | Selective Negative Acks | | | | 22 | | Record Boundaries | | | | 23 | | Corruption experienced | | | | 24 | | SNAP | | | | 25 | | Unassigned (released 12/18/00) | | | | 26 | | TCP Compression Filter | | | +----+-------+------------------------------------+----------+-----+
+----+-------+------------------------------------+----------+-----+ |種類|長さ| 意味| RFC| 使用| | |八重奏| | | | +----+-------+------------------------------------+----------+-----+ | 0 | - | オプションリストの終わり| RFC793| * | | 1 | - | 操作がありません。| RFC793| * | | 2 | 4 | 最大のセグメントサイズ| RFC793| * | | 3 | 3 | WSopt--窓のスケール| RFC1323| * | | 4 | 2 | 袋は可能にしました。| RFC2018| * | | 5 | N| 袋| RFC2018| * | | 6 | 6 | 反響してください(オプション8で、時代遅れにされます)。| RFC1072| | | 7 | 6 | エコーReply(オプション8で、時代遅れにされます)| RFC1072| | | 8 | 10 | TSopt--タイムスタンプオプション| RFC1323| * | | 9 | 2 | 部分的なオーダー接続は可能にしました。| RFC1693| | | 10 | 3 | 部分的なオーダーサービスプロフィール| RFC1693| | | 11 | 6 | CC| RFC1644| | | 12 | 6 | CC.NEW| RFC1644| | | 13 | 6 | CC.ECHO| RFC1644| | | 14 | 3 | 交互のチェックサム要求| RFC1146| | | 15 | N| 交互のチェックサムデータ| RFC1146| | | 16 | | Skeeter| | | | 17 | | ババ| | | | 18 | 3 | トレーラチェックサムオプション| | | | 19 | 18 | MD5署名オプション| RFC2385| | | 20 | | SCPS能力| | | | 21 | | 選択している否定的Acks| | | | 22 | | 境界の記録| | | | 23 | | 経験された不正| | | | 24 | | スナップ| | | | 25 | | 割り当てられません(12/18/00にリリースされます)。| | | | 26 | | TCP圧縮フィルタ| | | +----+-------+------------------------------------+----------+-----+
Figure 12. Common TCP Options
図12。 一般的なTCPオプション
The 'use' column is marked with '*' to indicate options that are most likely to be seen in TCP flows. Also note that RFC 1072 [4] has been obsoleted by RFC 1323 [7], although the original bit usage is defined only in RFC 1072.
'使用'コラムは'*'でマークされて、TCP流れで最も見られそうなオプションを示します。 また、RFC1072[4]がRFC1323[7]によって時代遅れにされたことに注意してください、オリジナルの噛み付いている用法はRFC1072だけで定義されますが。
West & McCann Informational [Page 28] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[28ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
4.3.2. Option Field Behavior
4.3.2. オプション・フィールドの振舞い
Generally speaking, all option fields have been classified as changing. This section describes the behavior of each option referenced within an RFC, listed by 'kind' indicator.
概して、すべてのオプション・フィールドが変化するとして分類されました。 このセクションは'親切な'インディケータによって記載されたRFCの中で参照をつけられたそれぞれのオプションの振舞いについて説明します。
0: End of Option List
0: オプションリストの終わり
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to
the Data Offset field. This is used at the end of all options,
not at the end of each option, and it need only be used if the
end of the options would not otherwise coincide with the end of
the TCP header. Defined in RFC 793 [2].
このオプションコードはオプションリストの終わりを示します。 Data Offset分野に従って、これはTCPヘッダーの端と同時に起こらないかもしれません。 これはそれぞれのオプションの終わりに使用されるのではなく、すべてのオプションの終わりに使用されます、そして、そうでなければ、オプションの終わりがTCPヘッダーの端と同時に起こらないなら、それは使用されるだけでよいです。 RFC793[2]では、定義されます。
There is no data associated with this option, so a compression
scheme must simply be able to encode its presence. However,
note that since this option marks the end of the list and the
TCP options are 4-octet aligned, there may be octets of padding
(defined to be '0' in [2]) after this option.
このオプションに関連しているどんなデータもないので、圧縮技術は単に存在をコード化できなければなりません。 しかしながら、詰め物の八重奏がこのオプションがリストの終わりを示して、TCPオプションが並べられた、4八重奏であるのであるかもしれないことに注意してください。(このオプションの後に[2])の'0'になるように、定義されます。
1: No-Operation
1: 操作がありません。
This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary.
There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do
not begin on a word boundary RFC 793 [2]. There is no data
associated with this option, so a compression scheme must
simply be able to encode its presence. This may be done by
noting that the option simply maintains a certain alignment and
that compression need only convey this alignment. In this way,
padding can just be removed.
例えば、このオプションコードは、その後のオプションの始まりを語境界に並べるのにオプションの間で使用されるかもしれません。 送付者がこのオプションを使用するという保証が全くないので、語境界RFC793[2]で始まらないでも、オプションを処理するように受信機を準備しなければなりません。 このオプションに関連しているどんなデータもないので、圧縮技術は単に存在をコード化できなければなりません。 オプションが単にある整列を維持して、圧縮がこの整列を伝えるだけでよいことに注意することによって、これをするかもしれません。 このように、ただ詰め物を取り除くことができます。
2: Maximum Segment Size
2: 最大のセグメントサイズ
If this option is present, then it communicates the maximum
segment size that may be used to send a packet to this end-
host. This field must only be sent in the initial connection
request (i.e., in segments with the SYN control bit set). If
this option is not used, any segment size is allowed RFC 793
[2].
このオプションが存在しているなら、それはこの終わりのホストにパケットを送るのに使用されるかもしれない最大のセグメントサイズを伝えます。 初期の接続要求でこの野原を送るだけでよいです(すなわち、SYNコントロールビットがあるセグメントでは、セットしてください)。 このオプションが使用されていないなら、RFC793[2]はどんなセグメントサイズにも許容されています。
This option is very common. The segment size is a 16-bit
quantity. Theoretically, this could take any value; however
there are a number of values that are common. For example,
1460 bytes is very common for TCP/IPv4 over Ethernet (though
with the increased prevalence of tunnels, for example, smaller
このオプションは非常に一般的です。 セグメントサイズは16ビットの量です。 理論的に、これはどんな値も取るかもしれません。 しかしながら、多くの一般的な値があります。 例えば、TCP/IPv4に、1460バイトがイーサネットの上で非常に一般的である、(例えば、トンネルの増加する普及が、よりわずかな状態で
West & McCann Informational [Page 29] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[29ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
values such as 1400 have become more popular). 536 bytes is the
default MSS value. This may allow for common values to be
encoded more efficiently.
1400年などの値が、よりポピュラーになった、) 536バイトはデフォルトMSS価値です。 これは、共通の価値観が、より効率的にコード化されるのを許容するかもしれません。
3: Window Scale Option (WSopt)
3: 窓のスケールオプション(WSopt)
This option may be sent in a SYN segment by the TCP end-host
(1) to indicate that the sending TCP end-host is prepared to
perform both send and receive window scaling, and
(2) to communicate a scale factor to be applied to its receive
window.
このオプションがTCP終わりホスト(1)でSYNセグメントで送って、送付TCP終わりホストが働く用意ができているのを示して、両方が適用される位取り因数を伝えるために窓スケーリング、および(2)を送って、受けるということであるかもしれない、それ、窓を受けてください。
The scale factor is encoded logarithmically as a power of 2
(presumably to be implemented by binary shifts). Note that the
window in the SYN segment itself is never scaled (RFC 1072
[4]). This option may be sent in an initial segment (i.e., in
a segment with the SYN bit on and the ACK bit off). It may
also be sent in later segments, but only if a Window Scale
option was received in the initial segment. A Window Scale
option in a segment without a SYN bit should be ignored. The
Window field in a SYN segment itself is never scaled (RFC 1323
[7]).
位取り因数は2(おそらく、2進のシフトで実行される)のパワーとして対数関数的にコード化されます。 SYNセグメント自体の窓がそうであるというメモは決して比例しませんでした。(RFC1072[4])。 初期のセグメント(すなわち、SYNビットがオンであり、ACKビットが下にあるセグメントの)でこのオプションを送るかもしれません。 また、初期のセグメントでWindow Scaleオプションを受け取った場合にだけ、後のセグメントでそれを送るかもしれません。 SYNビットのないセグメントにおけるWindow Scaleオプションは無視されるべきです。 スケーリングされて、SYNセグメント自体のWindow分野は決してそうではありません。(RFC1323[7])。
The use of window scaling does not affect the encoding of any
other field during the lifetime of the flow. Only the encoding
of the window scaling option itself is important. The window
scale must be between 0 and 14 (inclusive). Generally, smaller
values would be expected (a window scale of 14 allows for a
1Gbyte window, which is extremely large).
窓のスケーリングの使用は流れの生涯いかなる他の分野のコード化にも影響しません。 窓のスケーリングオプション自体のコード化は重要であるだけです。 窓のスケールは、0〜14であるに違いありません(包括的な)。 一般に、より小さい値は予想されるでしょう(14の窓のスケールは1ギガバイトの非常に大きい窓を考慮します)。
4: SACK-Permitted
4: 袋で、受入れられます。
This option may be sent in a SYN by a TCP that has been
extended to receive (and presumably to process) the SACK option
once the connection has opened RFC 2018 [12]. There is no data
in this option all that is required is for the presence of the
option to be encoded.
接続がいったんRFC2018[12]を開くと、このオプションはSYNでSACKオプションを受け取る(おそらく、処理するために)ために広げられたTCPによって送られるかもしれません。 オプションの存在がコード化されるために、このオプションにおけるデータは全くありません。
5: SACK
5: 袋
This option is to be used to convey extended acknowledgment
information over an established connection. Specifically, it
is to be sent by a data receiver to inform the data transmitter
of non-contiguous blocks of data that have been received and
queued. The data receiver awaits the receipt of data in later
retransmissions to fill the gaps in sequence space between
these blocks. At that time, the data receiver acknowledges the
data, normally by advancing the left window edge in the
このオプションは拡張承認情報を確立した接続の上に伝えるのに使用されることです。 明確に、データ受信装置でそれを送って、受け取られて、列に並ばせられた非隣接のブロックのデータのデータ送信機を知らせることになっています。 データ受信装置は、これらのブロックの間の系列スペースに不足をいっぱいにするために後の「再-トランスミッション」のデータの領収書を待ちます。 その時、データ受信装置は、通常、左の窓の縁を中に進めることによって、データを承認します。
West & McCann Informational [Page 30] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[30ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
Acknowledgment Number field of the TCP header. It is important
to understand that the SACK option will not change the meaning
of the Acknowledgment Number field, whose value will still
specify the left window edge, i.e., one byte beyond the last
sequence number of fully received data (RFC 2018 [12]).
NumberがさばくTCPヘッダーの承認。 SACKオプションがそれでも、値が左の窓の縁を指定するAcknowledgment Number分野の意味を変えないのを理解しているのは重要です、すなわち、1バイト完全に受信されたデータの最後の一連番号を超えて。(RFC2018[12])。
If SACK has been negotiated (through an exchange of SACK-
Permitted options), then this option may occur when dropped
segments are noticed by the receiver. Because this identifies
ranges of blocks within the receiver's window, it can be viewed
as a base value with a number of offsets. The base value (left
edge of the first block) can be viewed as offset from the TCP
acknowledgement number. There can be up to 4 SACK blocks in a
single option. SACK blocks may occur in a number of segments
(if there is more out-of-order data 'on the wire'), and this
will typically extend the size of or add to the existing
blocks.
低下しているセグメントが受信機によって気付かれているとき、SACKが交渉されたなら(オプションが受入れられたSACKの交換を通して)、このオプションは起こるかもしれません。これが受信機の窓の中でブロックの範囲を特定するので、基礎点として多くのオフセットでそれは見なすことができます。 TCP承認番号から相殺されるように基礎点(最初のブロックの左の縁)を見ることができます。 ただ一つのオプションには最大4つのSACKブロックがあることができます。 SACKブロックが多くのセグメントで現れるかもしれなくて('ワイヤ'というより不適切なデータがあれば)、これは、既存のブロックにサイズを通常広げているか、または加えるでしょう。
Alternative proposals such as DSACK RFC 2883 [17] do not
fundamentally change the behavior of the SACK block, from the
point of view of the information contained within it.
DSACK RFC2883[17]などの代案は基本的にSACKブロックの動きを変えません、それの中に含まれた情報の観点から。
6: Echo
6: エコー
This option carries information that the receiving TCP may send
back in a subsequent TCP Echo Reply option (see below). A TCP
may send the TCP Echo option in any segment, but only if a TCP
Echo option was received in a SYN segment for the connection.
When the TCP echo option is used for RTT measurement, it will
be included in data segments, and the four information bytes
will define the time at which the data segment was transmitted
in any format convenient to the sender (see RFC 1072 [4]).
このオプションは受信TCPがその後のTCP Echo Replyオプションを送るかもしれないという(以下を見てください)情報を運びます。 接続のためにSYNセグメントでTCP Echoオプションを受け取った場合にだけ、TCPはどんなセグメントでもTCP Echoオプションを送るかもしれません。 TCPエコーオプションがRTT測定に使用されるとき、それはデータ・セグメントで含まれるでしょう、そして、4情報バイトはデータ・セグメントが送付者にとって、便利などんな形式でも伝えられた時を定義するでしょう。(RFC1072[4])を見てください。
The Echo option is generally not used in practice -- it is
obsoleted by the Timestamp option. However, for transparency
it is desirable that a compression scheme be able to transport
it. (However, there is no benefit in attempting any treatment
more sophisticated than viewing it as a generic 'option').
一般に、Echoオプションは実際には使用されません--それはTimestampオプションで時代遅れにされます。 しかしながら、透明において、圧縮技術がそれを輸送できるのは、望ましいです。 (しかしながら、一般的な'オプション'であるとそれをみなすより洗練されたどんな処理も試みるのにおいて利益が全くありません。)
7: Echo Reply
7: エコー・リプライ
A TCP that receives a TCP Echo option containing four
information bytes will return these same bytes in a TCP Echo
Reply option. This TCP Echo Reply option must be returned in
the next segment (e.g., an ACK segment) that is sent. If more
than one Echo option is received before a reply segment is
sent, the TCP must choose only one of the options to echo,
4情報バイトを含むTCP Echoオプションを受け取るTCPはTCP Echo Replyオプションでこれらの同じバイトを返すでしょう。 送られる次のセグメント(例えば、ACKセグメント)でこのTCP Echo Replyオプションを返さなければなりません。 回答セグメントを送る前に1つ以上のEchoオプションが受け取られているなら、TCPは、反響するようにオプションについて1つだけを選ばなければなりません。
West & McCann Informational [Page 31] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[31ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
ignoring the others; specifically, it must choose the newest
segment with the oldest sequence number (see RFC 1072 [4]).
他のものを無視します。 明確に、それは最も古い一連番号があるセグメントを最も新しく選ばなければなりません。(RFC1072[4])を見てください。
The Echo Reply option is generally not used in practice -- it
is obsoleted by the Timestamp option. However, for
transparency it is desirable that a compression scheme be able
to transport it. (However, there is no benefit in attempting
any more sophisticated treatment than viewing it as a generic
'option').
一般に、Echo Replyオプションは実際には使用されません--それはTimestampオプションで時代遅れにされます。 しかしながら、透明において、圧縮技術がそれを輸送できるのは、望ましいです。 (しかしながら、一般的な'オプション'であるとそれをみなすよりそれ以上の洗練された処理を試みるのにおいて利益が全くありません。)
8: Timestamps
8: タイムスタンプ
This option carries two four-byte timestamp fields. The
Timestamp Value field (TSval) contains the current value of the
timestamp clock of the TCP sending the option. The Timestamp
Echo Reply field (TSecr) is only valid if the ACK bit is set in
the TCP header; if it is valid, it echoes a timestamp value
that was sent by the remote TCP in the TSval field of a
Timestamps option. When TSecr is not valid, its value must be
zero. The TSecr value will generally be from the most recent
Timestamp option that was received; however, there are
exceptions that are explained below. A TCP may send the
Timestamps option (TSopt) in an initial segment (i.e., a
segment containing a SYN bit and no ACK bit), and it may send a
TSopt in other segments only if it received a TSopt in the
initial segment for the connection (see RFC 1323 [7]).
Timestamps are quite commonly used. If timestamp options are
exchanged in the connection set-up phase, then they are
expected to appear on all subsequent segments. If this
exchange does not happen, then they will not appear for the
remainder of the flow.
このオプションは2つの4バイトのタイムスタンプ野原を運びます。 Timestamp Value分野(TSval)はオプションを送るTCPのタイムスタンプ時計の現行価値を含んでいます。 ACKビットがTCPヘッダーに設定される場合にだけ、Timestamp Echo Reply分野(TSecr)は有効です。 有効であるなら、それはTimestampsオプションのTSval分野のリモートTCPによって送られたタイムスタンプ値を反響します。 TSecrが有効でないときに、値はゼロでなければなりません。 一般に、TSecr値は受け取られた最新のTimestampオプションから来ているでしょう。 しかしながら、以下で説明される例外があります。 TCPは初期のセグメント(すなわち、SYNビットを含んでいますが、どんなACKビットも含まないセグメント)でTimestampsオプション(TSopt)を送るかもしれません、そして、接続のために初期のセグメントでTSoptを受けた場合にだけ、それは他のセグメントでTSoptを送るかもしれません。(RFC1323[7])を見てください。 タイムスタンプは全く一般的に使用されます。 接続セットアップフェーズでタイムスタンプオプションを交換するなら、すべてのその後のセグメントに現れるとそれらを予想します。 この交換が起こらないと、彼らは流れの残りの弁護に出廷しないでしょう。
Because the value being carried is a timestamp, it is logical
to expect that the entire value need not be carried. There is
no obvious pattern of increments that might be expected,
however.
運ばれる値がタイムスタンプであるので、全体の値が運ばれる必要はないと予想するのは当然です。 しかしながら、期待されるかもしれない増分のどんな明白なパターンもありません。
An important reason for using the timestamp option is to allow
detection of sequence space wrap-around (Protection Against
Wrapped Sequence-number, or PAWS, see RFC 1323 [7]). It is not
expected that this is a serious concern on the links on which
TCP header compression would be deployed, but it is important
that the integrity of this option be maintained. This issue is
discussed in, for example, RFC 3150 [32]. However, the
proposed Eifel algorithm [35] makes use of timestamps, so it is
currently recommended that timestamps be used for cellular-type
links [34].
タイムスタンプオプションを使用する重要な理由は系列スペース巻きつけて着るドレスの検出を許すことです。(保護Against Wrapped Sequence-番号、またはPAWSがRFC1323[7])を見ます。 これがTCPヘッダー圧縮が配備されるリンクにおける真剣な関心でないと予想されますが、このオプションの保全が維持されるのは、重要です。 例えば、RFC3150[32]でこの問題について議論します。 しかしながら、提案されたアイフェル高原アルゴリズム[35]がタイムスタンプを利用するので、タイムスタンプがセルタイプのリンク[34]に使用されるのは、現在、お勧めです。
West & McCann Informational [Page 32] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[32ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
With regard to compression, note that the range of resolutions
for the timestamp suggested in RFC 1323 [7] is quite wide (1ms
to 1s per 'tick'). This (along with the perhaps wide variation
in RTT) makes it hard to select a set of encodings that will be
optimal in all cases.
圧縮に関して、RFC1323[7]に示されたタイムスタンプのための解決の範囲がかなり広いのであることに('カチカチする音'あたり1への1ms)注意してください。 中、これ、(恐らく広い変化、RTT) すべての場合で最適になるencodingsの1セットを選択するのを困難にします。
9: Partial Order Connection (POC) permitted
9: 部分的なOrder Connection(POC)は可能にしました。
This option represents a simple indicator communicated between
the two peer transport entities to establish the operation of
the POC protocol. See RFC 1693 [9].
このオプションはPOCプロトコルの操作を証明するために2つの同輩輸送実体の間で伝えられた簡単なインディケータを表します。 RFC1693[9]を見てください。
The Partial Order Connection option sees little (or no) use in
the current Internet, so the only requirement is that the
header compression scheme be able to encode it.
Partial Order Connectionオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
10: POC service profile
10: POCサービスプロフィール
This option serves to communicate the information necessary to
carry out the job of the protocol -- the type of information
that is typically found in the header of a TCP segment. The
Partial Order Connection option sees little (or no) use in the
current Internet, so the only requirement is that the header
compression scheme be able to encode it.
このオプションは、プロトコルの仕事を行うために必要情報を伝えるのに役立ちます--TCPセグメントのヘッダーで通常見つけられる情報の種類。 Partial Order Connectionオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
11: Connection Count (CC)
11: 接続カウント(CC)
This option is part of the implementation of TCP Accelerated
Open (TAO) that effectively bypasses the TCP Three-Way
Handshake (3WHS). TAO introduces a 32-bit incarnation number,
called a "connection count" (CC), that is carried in a TCP
option in each segment. A distinct CC value is assigned to
each direction of an open connection. The implementation
assigns monotonically increasing CC values to successive
connections that it opens actively or passively (see RFC 1644
[8]). This option sees little (or no) use in the current
Internet, so the only requirement is that the header
compression scheme be able to encode it.
このオプションは事実上、TCP Three-道のHandshake(3WHS)を迂回させるTCP Acceleratedオープン(TAO)の実現の一部です。 TAOはTCPオプションで各セグメントで運ばれる「接続カウント」(CC)と呼ばれる32ビットの肉体化番号を紹介します。 異なったCC値はオープンな接続の各方向に割り当てられます。 実現はそれが活発か受け身に開く連続した接続に増加するCC値を単調に割り当てます。(RFC1644[8])を見てください。 このオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
12: CC.NEW
12: CC.NEW
Correctness of the TAO mechanism requires that clients generate
monotonically increasing CC values for successive connection
initiations. Receiving a CC.NEW causes the server to
invalidate its cache entry and to do a 3WHS. See RFC 1644 [8].
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it.
TAOメカニズムの正当性は、クライアントが連続した接続開始のために増加するCC値を単調に発生させるのを必要とします。 CC.NEWを受けるのは、サーバがキャッシュエントリーを無効にして、3WHSをすることを引き起こします。 RFC1644[8]を見てください。 このオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
West & McCann Informational [Page 33] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[33ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
13: CC.ECHO
13: CC.ECHO
When a server host sends a segment, it echoes the connection
count from the initial in a CC.ECHO option, which is used by
the client host to validate the segment (see RFC 1644 [8]).
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it.
サーバー・ホストがセグメントを送るとき、CC.ECHOオプションにおける初期から接続カウントをまねます、セグメントを有効にするのにクライアントホストによって使用されるもの。(RFC1644[8])を見てください。 このオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
14: Alternate Checksum Request
14: 交互のチェックサム要求
This option may be sent in a SYN segment by a TCP to indicate
that the TCP is prepared to both generate and receive checksums
based on an alternate algorithm. During communication, the
alternate checksum replaces the regular TCP checksum in the
checksum field of the TCP header. Should the alternate
checksum require more than 2 octets to transmit, either the
checksum may be moved into a TCP Alternate Checksum Data Option
and the checksum field of the TCP header be sent as zero, or
the data may be split between the header field and the option.
Alternate checksums are computed over the same data as the
regular TCP checksum; see RFC 1146 [5].
このオプションはそれを示すためにSYNセグメントでTCPによって送られて、TCPがともに交互のアルゴリズムに基づくチェックサムを発生して、受けるように準備されるということであるかもしれません。 コミュニケーションの間、交互のチェックサムはTCPヘッダーのチェックサム分野で通常のTCPチェックサムを取り替えます。 TCPヘッダーでは、ゼロとして送るか、または交互のチェックサムが伝わるように2つ以上の八重奏を必要とするなら、チェックサムをTCP Alternate Checksum Data Optionとチェックサム分野に動かすかもしれません。ヘッダーフィールドとオプションの間でデータを分けるかもしれません。 交互のチェックサムは通常のTCPチェックサムと同じデータに関して計算されます。 RFC1146[5]を見てください。
This option sees little (or no) use in the current Internet, so
the only requirement is that the header compression scheme be
able to encode it. It would only occur in connection set-up
(SYN) packets. Even if this option were used, it would not
affect the handling of the checksum, since this should be
carried transparently in any case.
このオプションが現在のインターネットで少ししか(または、いいえ)使用を見ないので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。 それは接続セットアップ(SYN)パケットに起こるだけでしょう。 このオプションが使用されたとしても、チェックサムの取り扱いに影響しないでしょうに、これがどのような場合でも透明に運ばれるべきであるので。
15: Alternate Checksum Data
15: 交互のチェックサムデータ
This field is used only when the alternate checksum that is
negotiated is longer than 16 bits. These checksums will not
fit in the checksum field of the TCP header and thus at least
part of them must be put in an option. Whether the checksum is
split between the checksum field in the TCP header and the
option or the entire checksum is placed in the option is
determined on a checksum-by-checksum basis. The length of this
option will depend on the choice of alternate checksum
algorithm for this connection; see RFC 1146 [5].
交渉される交互のチェックサムが16ビットより長いときにだけ、この分野は使用されています。 これらのチェックサムはTCPヘッダーのチェックサム分野をうまくはめ込まないでしょう、そして、その結果、少なくともそれらの一部をオプションに入れなければなりません。 チェックサムがTCPヘッダーのチェックサム分野とオプションの間で分けられるか、または全体のチェックサムがオプションに置かれるかが、チェックサムごとのベースで決定しています。 このオプションの長さをこの接続のために交互のチェックサムアルゴリズムの選択に依存するでしょう。 RFC1146[5]を見てください。
If an alternative checksum was negotiated in the connection
set-up, then this option may appear on all subsequent packets
(if needed to carry the checksum data). However, this option
is in practice never seen, so the only requirement is that the
header compression scheme be able to encode it.
代替のチェックサムが接続セットアップで交渉されたなら、このオプションはすべてのその後のパケットの上に現れるかもしれません(チェックサムデータを運ぶのが必要であるなら)。 しかしながら、このオプションが実際には決して見られなかったあるので、唯一の要件はヘッダー圧縮技術がそれをコード化できるということです。
West & McCann Informational [Page 34] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[34ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
16 - 18:
16 - 18:
These non-RFC option types are not considered in this document.
これらの非RFCオプションタイプは本書では考えられません。
19: MD5 Digest
19: MD5ダイジェスト
Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by
applying the MD5 algorithm to a concatenated block of data
[13].
スプーフィングに対して保護されるためにTCP接続に送られたあらゆるセグメントがデータ[13]の連結されたブロックにMD5アルゴリズムを適用することによって製作された16バイトのMD5ダイジェストを含むでしょう。
Upon receiving a signed segment, the receiver must validate it
by calculating its own digest from the same data (using its own
key) and comparing the two digests. A failing comparison must
result in the segment's being dropped and must not produce any
response back to the sender. Logging the failure is probably
advisable.
サインされたセグメントを受けると、受信機は、同じデータ(それ自身のキーを使用する)からそれ自身のダイジェストについて計算して、2つのダイジェストを比較することによって、それを有効にしなければなりません。 失敗比較は、セグメントのもので落とされながらならなければならなくて、送付者への少しの応答も起こしてはいけません。 失敗を登録するのはたぶん賢明です。
Unlike other TCP extensions (e.g., the Window Scale option
[7]), the absence of the option in the SYN-ACK segment must not
cause the sender to disable its sending of signatures. This
negotiation is typically done to prevent some TCP
implementations from misbehaving upon receiving options in non-
SYN segments. This is not a problem for this option, since the
SYN-ACK sent during connection negotiation will not be signed
and will thus be ignored. The connection will never be made,
and non-SYN segments with options will never be sent. More
importantly, the sending of signatures must be under the
complete control of the application, not at the mercy of a
remote host not understanding the option. MD5 digest
information should, like any cryptographically secure data, be
incompressible. Therefore the compression scheme must simply
transparently carry this option, if it occurs.
他のTCP拡張子、(例えば、Window Scaleオプション[7])、SYN-ACKセグメントにおける、オプションの欠如で、送付者は署名の発信を無能にしてはいけません。 いくつかのTCP実現が受信オプションのときに非SYNのセグメントでふらちな事をするのを防ぐために通常この交渉をします。 これはこのオプションのための問題ではありません、接続交渉の間に送られたSYN-ACKがサインされないで、その結果、無視されるでしょう。 接続を決して作らないでしょう、そして、オプションがある非SYNセグメントを決して送らないでしょう。 アプリケーションの完全なコントロールの下で、より重要に、署名の発信がオプションを理解していないリモートホストの思うままにあるのではなく、あるに違いありません。 いずれも暗号でデータを保証するようにMD5ダイジェスト情報は圧縮不可能であるべきです。 したがって、起こるなら、圧縮技術は単に透明にこのオプションを運ばなければなりません。
20 - 26;
20 - 26;
Thse non-RFC option types are not considered in this document.
This only means that their behavior is not described in detail,
as a compression scheme is not expected to be optimised for
these options. However, any unrecognised option must be
carried by a TCP compression scheme transparently, in order to
work efficiently in the presence of new or rare options.
Thse非RFCオプションタイプは本書では考えられません。 これは、彼らの振舞いが詳細に説明されないことを意味するだけです、これらのオプションのために圧縮技術が最適化されないと予想されるとき。 しかしながら、TCP圧縮技術で透明にどんな認識されていないオプションも運ばなければなりません、新しいかまれなオプションがあるとき効率的に働くために。
The above list covers options known at the time of writing. Other options are expected to be defined. It is important that any future options can be handled by a header compression scheme. The processing of as-yet undefined options cannot be optimised but, at the very least, unknown options should be carried transparently.
上記のリストはこれを書いている時点で知られているオプションをカバーしています。 別の選択肢が定義されると予想されます。 ヘッダー圧縮技術でどんな今後のオプションも扱うことができるのは重要です。 まだ未定義のオプションの処理を最適化できませんが、少なくとも、未知のオプションは透明に運ばれるべきです。
West & McCann Informational [Page 35] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[35ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
The current model for TCP options is that an option is negotiated in the SYN exchange and used thereafter, if the negotiation succeeds. This leads to some assumptions about the presence of options (being only on packets with the SYN flag set, or appearing on every packet, for example). Where such assumptions hold true, it may be possible to optimise compression of options slightly. However, it is seen as undesirable to be so constrained, as there is no guarantee that option handling and negotiation will remain the same in the future. Also note that a compressor may not process the SYN packets of a flow and cannot, therefore, be assumed to know which options have been negotiated.
TCPオプションのための現在のモデルはオプションがSYN交換で交渉されて、その後使用されるということです、交渉が成功するなら。 これはオプション(例えば、SYN旗があらゆるパケットの上に設定されるか、または現れているパケットだけの上にある)の存在に関するいくつかの仮定に通じます。 そのような仮定が有効であるところでは、オプションの要約をわずかに最適化するのは可能であるかもしれません。 しかしながら、それはそのように抑制されるために望ましくないとみなされます、オプション取り扱いと交渉が将来同じままで残るという保証が全くないとき。 また、コンプレッサーを流れのSYNパケットを処理しないかもしれなくて、したがって、どのオプションが交渉されたかを知っていると思うことができないことに注意してください。
5. Other Observations
5. 他の観測
5.1. Implicit Acknowledgements
5.1. 暗黙の承認
There may be a small number of cues for 'implicit acknowledgements' in a TCP flow. Even if the compressor only sees the data transfer direction, for example, seeing a packet without the SYN flag set implies that the SYN packet has been received.
TCP流動には'暗黙の承認'のための少ない数の手がかりがあるかもしれません。 コンプレッサーがデータ転送指示を見るだけであっても、例えば、SYN旗のないパケットが設定されるのを見るのがSYNパケットが受け取られたのを含意します。
There is a clear requirement for the deployment of compression to be topologically independent. This means that it is not actually possible to be sure that seeing a data packet at the compressor guarantees that the SYN packet has been correctly received by the decompressor (as the SYN packet may have taken an alternative path).
圧縮の展開が位相的にそうであるという明確な要件があります。独立。 これは、コンプレッサーでデータ・パケットを見るのが、SYNパケットが減圧装置によって正しく受け取られたのを保証するのが(SYNパケットが迂回経路を取ったとき)、実際にいかにも可能でないことを意味します。
However, there may be other such cues, which may be used in certain circumstances to improve compression efficiency.
しかしながら、他のそのような手がかりがあるかもしれません。(手がかりは、圧縮効率を高めるのにある特定の状況では使用されるかもしれません)。
5.2. Shared Data
5.2. 共有データ
It can be seen that there are two distinct deployments (i) where the forward (data) and reverse (ACK) path are both carried over a common link, and (ii) where the forward (data) and reverse (ACK) path are carried over different paths, with a specific link carrying packets corresponding to only one direction of communication.
2つの異なった展開が(i) 前進(データ)の、そして、逆(ACK)の経路が普通リンクの上まで運ばれた両方と、前進(データ)の、そして、逆(ACK)の経路が異なった経路の上まで運ばれる(ii)であるところにあるのを見ることができます、特定のリンクがコミュニケーションの一方向だけに対応するパケットを運んでいて。
In the former case, a compressor and decompressor could be colocated. It may then be possible for the compressor and decompressor at each end of the link to exchange information. This could lead to possible optimizations.
前の場合では、コンプレッサーと減圧装置をcolocatedされることができました。 リンクの各端のコンプレッサーと減圧装置が情報交換するのは、その時、可能であるかもしれません。 これは可能な最適化に通じるかもしれません。
For example, acknowledgement numbers are generally taken from the sequence numbers in the opposite direction. Since an acknowledgement cannot be generated for a packet that has not passed across the link, this offers an efficient way of encoding acknowledgements.
例えば、一般に、一連番号から逆方向に承認番号を取ります。 承認がリンクの向こう側に通っていないパケットのために発生できないので、これは承認をコード化する効率的な方法を提供します。
West & McCann Informational [Page 36] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[36ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
5.3. TCP Header Overhead
5.3. TCPヘッダーオーバーヘッド
For a TCP bulk data-transfer, the overhead of the TCP header does not form a large proportion of the data packet (e.g., < 3% for a 1460 octet packet), particularly compared to the typical RTP voice case. Spectral efficiency is clearly an important goal. However, extracting every last bit of compression gain offers only marginal benefit at a considerable cost in complexity. This trade-off, of efficiency and complexity, must be addressed in the design of a TCP compression profile.
TCPの大量のデータ転送のために、TCPヘッダーのオーバーヘッドはデータ・パケット(例えば、1460年の八重奏パケットのための<3%)の大部分を形成しません、特に典型的なRTP声のケースと比べて。 スペクトル効率は明確に重要な目標です。 しかしながら、圧縮の最後のあらゆるビットを抽出して、複雑さにおける巨額の費用におけるマージンの利益だけを申し出に獲得してください。 効率と複雑さについてTCP圧縮プロフィールのデザインでこのトレードオフを記述しなければなりません。
However, in the acknowledgement direction (i.e., for 'pure' acknowledgement headers), the overhead could be said to be infinite (since there is no data being carried). This is why optimizations for the acknowledgement path may be considered useful.
しかしながら、承認方向(すなわち、'純粋な'承認ヘッダーのための)に、無限であるとオーバーヘッドを言うことができました(運ばれるデータが全くないので)。 これは承認経路のための最適化が役に立つと考えられるかもしれない理由です。
There are a number of schemes for manipulating TCP acknowledgements to reduce the ACK bandwidth. Many of these are documented in [33] and [32]. Most of these schemes are entirely compatible with header compression, without requiring any particular support. While it is not expected that a compression scheme will be optimised for experimental options, it is useful to consider these when developing header compression schemes, and vice versa. A header compression scheme must be able to support any option (including ones as yet undefined).
ACK帯域幅を減少させるためにTCP承認を操ることの多くの計画があります。 これらの多くが[33]と[32]に記録されます。 特定のサポートを必要としないで、これらの計画の大部分はヘッダー圧縮と完全に互換性があります。 圧縮技術が実験的なオプションのために最適化されないと予想されますが、ヘッダー圧縮技術を開発するとき、これらを考えるのは役に立ちます、逆もまた同様に。 ヘッダー圧縮技術はどんなオプションもサポートできなければなりません(まだ未定義の状態でものを含んでいて)。
5.4. Field Independence and Packet Behavior
5.4. 分野独立とパケットの振舞い
It should be apparent that direct comparisons with the highly 'packet'-based view of RTP compression are hard. RTP header fields tend to change regularly per-packet, and many fields (IPv4 IP ID, RTP sequence number, and RTP timestamp, for example) typically change in a dependent manner. However, TCP fields, such as sequence number tend to change more unpredictably, partly because of the influence of external factors (size of TCP windows, application behavior, etc.). Also, the field values tend to change independently. Overall, this makes compression more challenging and makes it harder to select a set of encodings that can successfully trade off efficiency and robustness.
RTP圧縮の非常に'パケット'ベースの視点がある直接比較が困難であることは、明らかであるべきです。 RTPヘッダーフィールドは、定期的にパケットを変える傾向があります、そして、多くの分野(例えば、IPv4IP ID、RTP一連番号、およびRTPタイムスタンプ)が依存する方法で通常変化します。 しかしながら、一連番号などのTCP分野は、より予想外に変化する傾向があります、一部外部の要素(TCPの窓、アプリケーションの振舞いなどのサイズ)の影響のために。 また、分野値は、独自に変化する傾向があります。 全体的に見て、これは、圧縮をよりやりがいがあるようにして、首尾よく効率と丈夫さを交換できるencodingsの1セットを選択するのは、より困難になります。
5.5. Short-Lived Flows
5.5. 短命な流れ
It is hard to see what can be done to improve performance for a single, unpredictable, short-lived connection. However, there are commonly cases where there will be multiple TCP connections between the same pair of hosts. As a particular example, consider web browsing (this is more the case with HTTP/1.0 [25] than with HTTP/1.1 [26]).
単一の、そして、予測できないで、短命な接続のために性能を向上させるために何ができるかわかりにくいです。 しかしながら、一般的にケースが同じ組のホストの間に複数のTCP接続があるところにあります。 特定の例として、ウェブがブラウジングであると考えてください。(これはHTTP/1.0がある[25] HTTP/1.1[26])より多くのそうです。
West & McCann Informational [Page 37] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[37ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
When a connection closes, either it is the last connection between that pair of hosts or it is likely that another connection will open within a relatively short space of time. In this case, the IP header part of the context (i.e., those fields characterised in Section 2.1) will probably be almost identical. Certain aspects of the TCP context may also be similar.
接続が閉じるとき、それはその組のホストの間の最後の接続であるか別の接続が時間の比較的短いスペースの中で開きそうでしょう。 この場合、文脈(すなわち、セクション2.1で特徴付けられたそれらの分野)のIPヘッダー部分はたぶんほとんど同じになるでしょう。 また、TCP文脈のある一定の局面も同様であるかもしれません。
Support for context replication is discussed in more detail in Section 3. Overall, support for sub-context sharing or initializing one context from another offers useful optimizations for a sequence of short-lived connections.
さらに詳細にセクション3で文脈模写のサポートについて議論します。 全体的に見て、サブ文脈共有か別のものからの1つの文脈を初期化するサポートは短命な接続の系列のために役に立つ最適化を提供します。
Note that, although TCP is connection oriented, it is hard for a compressor to tell whether a TCP flow has finished. For example, even in the 'bi-directional' link case, seeing a FIN and the ACK of the FIN at the compressor/decompressor does not mean that the FIN cannot be retransmitted. Thus, it may be more useful to think about initializing a new context from an existing one, rather than re-using an existing one.
TCPが適応する接続ですが、コンプレッサーが、TCP流動が終わったかどうか言いにくいことに注意してください。 例えば、'双方向'のリンク場合でさえFINのFINとACKをコンプレッサー/減圧装置における見るのは、FINを再送できないことを意味しません。 したがって、既存のものを再使用するよりむしろ既存のものからの新しい関係を初期化すると考えるのはさらに役に立つかもしれません。
As mentioned previously in Section 4.1.3, the IP header can clearly be shared between any transport-layer flows between the same two end-points. There may be limited scope for initialisation of a new TCP header from an existing one. The port numbers are the most obvious starting point.
既述のとおりセクション4.1.3では、同じ2つのエンドポイントの間のどんなトランスポート層流れの間でも明確にIPヘッダーを共有できます。 既存のものからの新しいTCPヘッダーの初期化処理のための限られた範囲があるかもしれません。 ポートナンバーは最も明白な出発点です。
5.6. Master Sequence Number
5.6. マスター配列番号
As pointed out earlier, in Section 4.1.3, there is no obvious candidate for a 'master sequence number' in TCP. Moreover, it is noted that such a master sequence number is only required to allow a decompressor to acknowledge packets in bi-directional mode. It can also be seen that such a sequence number would not be required for every packet.
セクション4.1.3で、より早く指摘されるように、'マスター一連番号'のどんな明白な候補もTCPにいません。 そのうえ、そのようなマスター一連番号が双方向のモードでパケットを承認するために減圧装置を許容するのに必要であるだけであることに注意されます。 また、そのような一連番号があらゆるパケットに必要であるというわけではないことを見ることができます。
While the sequence number only needs to be 'sparse', it is clear that there is a requirement for an explicitly added sequence number. There are no obvious ways to guarantee the unique identity of a packet other than by adding such a sequence number (sequence and acknowledgement numbers can both remain the same, for example).
一連番号は、'まばらである'必要があるだけですが、明らかに加えられた一連番号のための要件があるのは、明確です。 付加以外のパケットのユニークなアイデンティティにそのような一連番号を保証する当たり前の方法が全くありません(系列と承認番号は同じに、例えばともに残ることができます)。
5.7. Size Constraint for TCP Options
5.7. TCPオプションのサイズ規制
As can be seen from the above analysis, most TCP options, such as MSS, WSopt, or SACK-Permitted, may appear only on a SYN segment. Every implementation should (and we expect that most will) ignore unknown options on SYN segments. TCP options will be sent on non-SYN segments only when an exchange of options on the SYN segments has
上の分析から見ることができるように、MSSなどのほとんどのWSoptの、または、SACKによって可能にされたTCPオプションが、SYNセグメントだけで見えるかもしれません。 あらゆる実現がSYNセグメントで未知のオプションを無視するべきです(私たちは、大部分がそうすると予想します)。 SYNセグメントにおけるオプションの交換が送ったときだけ、非SYNセグメントでTCPオプションを送るでしょう。
West & McCann Informational [Page 38] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[38ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
indicated that both sides understand the extension. Other TCP options, such as MD5 Digest or Timestamp, also tend to be sent when the connection is initiated (i.e., in the SYN packet).
両側が拡大を理解しているのを示しました。 また、MD5 DigestかTimestampなどの他のTCPオプションは、接続が開始されるとき(すなわち、SYNパケットで)、送られる傾向があります。
The total header size is also an issue. The TCP header specifies where segment data starts with a 4-bit field that gives the total size of the header (including options) in 32-bit words. This means that the total size of the header plus option must be less than or equal to 60 bytes. This leaves 40 bytes for options.
また、総ヘッダーサイズは問題です。 TCPヘッダーは、セグメントデータがどこでヘッダーの総サイズを与える4ビットの野原から始まるか(オプションを含んでいて)を32ビットの単語で指定します。 これは、ヘッダーとオプションの総サイズが60バイト以下でなければならないことを意味します。 これは40バイトをオプションに残します。
6. Security Considerations
6. セキュリティ問題
Since this document only describes TCP field behavior, it raises no direct security concerns.
このドキュメントがTCP分野の振舞いについて説明するだけであるので、それはどんなダイレクト安全上の配慮も上げません。
This memo is intended to be used to aid the compression of TCP/IP headers. Where authentication mechanisms such as IPsec AH [24] are used, it is important that compression be transparent. Where encryption methods such as IPsec ESP [27] are used, the TCP fields may not be visible, preventing compression.
TCP/IPヘッダーの圧縮を支援するのにこのメモが使用されることを意図します。 IPsec AH[24]などの認証機構が使用されているところでは、圧縮がわかりやすいのは、重要です。 どこ、目に見えて、圧縮を防いでいますが、使用される超能力[27]、分野がそうしないいずれのIPsec TCPなどの暗号化方法。
7. Acknowledgements
7. 承認
Many IP and TCP RFCs (hopefully all of which have been collated below), together with header compression schemes from RFC 1144 [22], RFC 3544 [36], and RFC 3095 [31], and of course the detailed analysis of RTP/UDP/IP in RFC 3095, have been sources of ideas and knowledge. Further background information can also be found in [28] and [29].
RFC1144[22]、RFC3544[36]、およびRFC3095[31]からのヘッダー圧縮技術、およびもちろんRFC3095のRTP/UDP/IPの詳細に渡る分析と共に多くのIPとTCP RFCs(うまくいけばそれのすべてが以下で照合された)は考えと知識の源です。 また、[28]と[29]でさらなる基礎的な情報を見つけることができます。
This document also benefited from discussion on the ROHC mailing list and in various corridors (virtual or otherwise) about many key issues; special thanks go to Qian Zhang, Carsten Bormann, and Gorry Fairhurst.
また、このドキュメントはROHCメーリングリストの上と、そして、多くの主要な問題に関する(仮想かそうではありません)の様々な廊下で議論の利益を得ました。 特別な感謝はチエン・チャン、カルステン・ボルマン、およびゴーリーFairhurstに行きます。
Qian Zhang and Hongbin Liao contributed the extensive analysis of shareable header fields.
チエン・チャンとHongbinリャオは共有可能ヘッダーフィールドの大規模な分析を寄付しました。
Any remaining misrepresentation or misinterpretation of information is entirely the fault of the authors.
情報の誤伝か誤解のままで残るのは、完全にいくらか、作者のせいです。
West & McCann Informational [Page 39] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[39ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[1] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[2] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
896, January 1984.
[3] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, October 1988.
[4] ジェーコブソンとV.とR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」、RFC1072、1988年10月。
[5] Zweig, J. and C. Partridge, "TCP alternate checksum options",
RFC 1146, March 1990.
[5] ツバイクとJ.とC.Partridge、「TCPの交互のチェックサムオプション」、RFC1146、1990年3月。
[6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[6] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[7] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[7] ジェーコブソン(V.とブレーデン、B.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[8] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[8] ブレーデン、B.、「T/TCP--、取引に、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
[9] Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP:
Partial Order Service", RFC 1693, November 1994.
[9] コノリー、T.、アメア、P.、およびP.コンラッド、「TCPへの拡大:」 「部分的なオーダーサービス」、RFC1693、1994年11月。
[10] Bellovin, S., "Defending Against Sequence Number Attacks", RFC
1948, May 1996.
[10] Bellovin S. (「一連番号攻撃に対して防御すること」でのRFC1948)は1996がそうするかもしれません。
[11] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[11] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[12] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[12] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[13] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[14] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
West & McCann Informational [Page 40] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[40ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
[15] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[15]Ramakrishnan、K.とS.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481、1999年1月。
[16] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[16] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[17] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[17] フロイド、S.、Mahdavi、J.、マシス、M.、およびM.ポドルスキー、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883(2000年7月)。
[18] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[18]Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
[19] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003.
[19] スプリング、N.、Wetherall、D.、およびD.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、2003年6月。
8.2. Informative References
8.2. 有益な参照
[20] IANA, "IANA", IANA TCP options, February 1998,
<http://www.iana.org/assignments/tcp-parameters>.
[20]IANA、"IANA"、IANA TCPオプション、1998年2月、<tcp http://www.iana.org/課題/パラメタ>。
[21] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[21] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[22] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[22] ジェーコブソン、V.、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月。
[23] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[23]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
[24] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[24] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[25] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[25] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[27] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[27] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[26] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[26] フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
[28] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[28] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
West & McCann Informational [Page 41] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[41ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
[29] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[29]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[30] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[30] ブラドナー、S.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、BCP37、RFC2780(2000年3月)対パクソン
[31] 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.
[31] ボルマン、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日
[32] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
end Performance Implications of Slow Links", BCP 48, RFC 3150,
July 2001.
[32] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、およびV.Magret、「終わりから終わりへのSlowリンクスのパフォーマンスImplications」、BCP48、RFC3150(2001年7月)。
[33] Balakrishnan, Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Path
Asymmetry", RFC 3449, December 2002.
[33] Balakrishnan、Padmanabhan、V.、Fairhurst、G.、およびM.Sooriyabandara、「ネットワーク経路非対称のTCPパフォーマンス含意」、RFC3449、2002年12月。
[34] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F.
Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks", RFC 3481, February 2003.
[34]Inamura、H.、モンテネグロ、G.、ラドウィグ、R.、Gurtov、A.、およびF.Khafizov、「2番目の(2.5G)と第3(3G)世代ワイヤレス・ネットワークの上のTCP」、RFC3481(2003年2月)。
[35] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522, April 2003.
[35] ラドウィグとR.とM.マイヤー、「TCPのためのアイフェル高原検出アルゴリズム」、RFC3522、2003年4月。
[36] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header
Compression over PPP", RFC 3544, July 2003.
2003年7月の[36]EnganとM.とCasnerとS.とボルマン、C.とT.コーレン、「pppの上のIPヘッダー圧縮」RFC3544。
[37] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R.,
Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice
for Internet Subnetwork Designers", BCP 89, RFC 3819, July
2004.
[37]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。
West & McCann Informational [Page 42] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[42ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
Authors' Addresses
作者のアドレス
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
マーク・A.の西シーメンス/Roke Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833311はメールされます: mark.a.west@roke.co.uk ユリ: http://www.roke.co.uk
Stephen McCann Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
スティーブンマッキャンシーメンス/Roke Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833341 EMail: stephen.mccann@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833341はメールされます: stephen.mccann@roke.co.uk ユリ: http://www.roke.co.uk
West & McCann Informational [Page 43] RFC 4413 TCP/IP Field Behavior March 2006
西洋とマッキャン情報[43ページ]のRFC4413TCP/IPは2006年3月に振舞いをさばきます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
West & McCann Informational [Page 44]
西であってマッキャンInformationalです。[44ページ]
一覧
スポンサーリンク
