Network Working Group M. West
Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
TCP/IP Field Behavior
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).
著作権（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フィールドの動作を説明します。ほとんどのヘッダフィールドは、パケットからパケットにランダムに変化していないので、ヘッダ圧縮が可能です。フィールドの多くは、多かれ少なかれ予測可能な方法で静的な動作や変化を示します。ヘッダ圧縮スキームを設計するとき、それは詳細フィールドの挙動を理解するために基本的に重要です。この分析の例は、このメモはTCP / IPヘッダの圧縮のために同様の役割を行うRFC 3095.に見ることができます。
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
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のためのRFC 3095 [31]に示され、また、この文書に含まれています。
This document borrows much of the classification text from RFC 3095 [31], rather than inserting many references to that document.
このドキュメントではなく、その文書への多くの参照を挿入するよりも、RFC 3095 [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.
RFC 3095に提示フォーマット[31]によれば、TCP / IPヘッダフィールドは二段階に分類され、分析されます。まず、フィールドが安定した知識や仮定に基づいて分類されている第2節では、一般的な分類を、持っています。これらは、多かれ少なかれ、実装上、使用用途に応じて変化しますので、この一般的な分類は、考慮に変化するフィールドの変化特性を取ることはありません。第3節では、フィールドの値が短命の流れを最適化するために使用することができますどのように考えています。変化特性のより詳細な分析は、次いで最後に、第5節では、様々なヘッダフィールドは、圧縮を最適化するために、ヘッダ圧縮方式で処理されるべきかについての結論と要約セクション4で行われます。
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 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.
予約ビットの数は、将来の拡張のために利用可能です。フィールド行動の治療は、このようなビットの今後の使用を予測することはできませんが、我々は、彼らはいくつかの点で使用されることを期待しています。この所定の圧縮方式は、現在の状況に最適化することができるが、予約ビットの任意の使用をサポートすることができなければなりません。しかし、定義するまだ持って使用パターンを最適化することは不可能です。
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.
以下の定義（およびいくつかのテキスト）はRFC 3095 [31]からコピーされ、RFC 3095の間でIPフィールド行動の付録A.の違い[31]（すなわち、オーディオおよびビデオアプリケーションのためのIP / UDP / RTPの動作）と、この文書います特定されて。
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.
以下の場合、我々は、同じIPアドレスとポート番号を持つ一連のパケットであること、TCPパケットストリームとして「セッション」を定義します。パケットフローは、特定のフィールドによって定義される（以下、STATIC-DEFを参照）、セッションのサブセットとみなすことができます。ヘッダ圧縮のためにパケットのストリームにセッションの分離のより完全な議論については[31]を参照。
At a general level, the header fields are separated into 5 classes:
一般的なレベルでは、ヘッダフィールドは5つのクラスに分けられます：
o INFERRED
O INFERRED
These fields contain values that can be inferred from other
values (for example, the size of the frame carrying the packet)
and thus do not have to be handled at all by the compression
scheme.
o STATIC
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-DEF
STATIC fields whose values define a packet stream. They are in
general handled as STATIC.
o STATIC-KNOWN
O STATIC知られています
These STATIC fields are expected to have well-known values and
therefore do not need to be communicated at all.
o CHANGING
OのCHANGING
These fields are expected to vary randomly within a limited
value set or range or in some other manner.
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では、変化するフィールドは、さらに検討され、それらの予想される変化の挙動に基づいて分類しました。
+---------------------+-------------+----------------+
| 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).
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.
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.
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.
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.
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.
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アドレスは、トランスポート層接続に関連付けられたフローの定義の一部であると仮定されます。より複雑なフロー分離は、当然のことながら、考えることができる（この問題のより多くの議論のためにも、[31] RFC 3095を参照してください）。トンネリングが行われている場合、外側のトンネルヘッダ内の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 |
+--------------+--------------+
Figure 2: Field sizes
図2：フィールドサイズ
+---------------------+-------------+----------------+
| 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).
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.
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.
o Packet Length
Oのパケット長
Information about packet length is expected to be provided by
the link layer. The field is therefore classified as 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).
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.
以上のフラグメント（MF）フラグがフラグメンテーションは、理想的には、予想されないので、ゼロであると予想されます。しかし、また、いくつかのシナリオは、（例えば、いくつかのトンネリング・アーキテクチャ）は、断片化を引き起こすないことが理解されます。一般的に、しかし、断片化が原因初期MSSネゴシエーションおよびパスMTUディスカバリのその後の使用の組み合わせに、インターネットで一般的であることが予想されていません。 RFC 3095 [31] RTPのために、最初のフラグメントがトランスポート層プロトコルのヘッダを含むであろう、と指摘します。その後の断片は、別のプロファイルで圧縮しなければならないであろう。これは明らかにも、TCPの場合です。フラグメンテーションが発生した場合、最初のフラグメントは、定義により、ヘッダのオーバーヘッドを最小限に、比較的大きいであろう。後続のフラグメントは、別のプロファイルを使用して圧縮されます。従って、ヘッダ圧縮を実行する際にフラグメンテーションのために最適化するために望ましくないと考えられます。モアフラグメントフラグが故にSTATIC-公知のように分類されます。
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.
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.
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.
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疑似ヘッダ（およびペイロード）。非圧縮ヘッダを検証するCRCを使用ROHC [31]、とこれを比較します。 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.
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]
Figure 4. Field sizes
図4.フィールドサイズ
+---------------------+-------------+----------------+
| 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 |
+---------------------+-------------+----------------+
Figure 5: TCP header fields
図5：TCPヘッダフィールド
o Source and Destination ports
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として分類されています。
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として分類されています。
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).
Figure 6. Overall field sizes
図6.全体的なフィールドサイズ
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.
複数のフローが時間的に重複または時間の短い間隔内で順次発生するいずれかの場合、ヘッダフィールド値に類似多大あり得ます。フィールド値のような共通性は、圧縮コンテキストに反映されます。これにより、圧縮率を向上させるために異なるフローを横切ってフィールド間の共通性を利用することが可能であるべきです。これを実行するためには、様々なヘッダフィールドの「複製」の特性を理解することが重要です。
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プロファイル）の性質に依存します。
A brief analysis of the relationship of TCP/IP fields among 'replicable' packet streams follows.
「複製」パケットストリームの中で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).
「N / 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つの候補ストリーム間で同じであることを保証するものではありません。特定の符号化方法は、圧縮効率を向上させるために使用することができます。
+-----------------------+---------------+------------+
| 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 |
+-----------------------+---------------+------------+
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 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は、アプリケーションの要件に応じてマークされます。それは複製の接続が同じDiffServクラスに属していると仮定することができるなら、DSCPが複製される可能性があります。 DSCPは、送信者ではなく、任意のパケットマーカーではないだけに設定することができます。したがって、フローは、ネットワーク内の異なる点でのDSCP値の数を有していてもよいです。しかし、ヘッダ圧縮は、ポイントツーポイントリンク上で動作し、したがって、比較的安定した値を表示することが期待されます。再マーキングメーターの状態に基づいて行われている場合、その値は半ばフローを変更することがあります。全体的に、しかし、我々は、ヘッダー圧縮のために有用であることが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).
ECNビットが複製されるため、（2）それが不可能である（ECNノンススキームの使用に注意してください[19]予想されます）。しかし、それはTCPがECN対応のホストとの間を流れるすべてのECNを使用する可能性が高いと思われる、同じエンドポイント間のフローのECNの使用（またはしない）が複製と見なされる可能性があります。 （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.
（ROHC RTPに記載されているように）（3）このフィールドの複製コンテキストは、IP-ID、NBO、およびRNDフラグを含みます。これは、複製が単にヘッダフィールド値とは、例えば、各フィールドに適用される圧縮の正確な性質に基づいて検討する必要があるのではなく、文脈であることを強調しています。
(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）、それが複製と見なされません。しかし、同一のエンドポイント間の予約フラグの挙動は同様であろうと予想されるかもしれません。この場合に、この現象に基づいて（例えば）パケット・フォーマットの任意の選択は、新しいフローに横切って運ぶかもしれません。パケットフォーマットの場合、これはおそらく、コンプレッサー、地元の意思決定とみなすことができます。
(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ビットが複製であってもよいです。しかし、これは実際には、これを実行するのに便利になることはほとんどありません、保証されていません。ヘッダ圧縮の観点から、1ビットのフラグが複製または明示的に指定する必要があるかどうかを示すために有する単にフラグの値を搬送するよりも多くのビットを必要とする可能性があります。私たちは、DFの複製を排除していません。
+-----------------------+---------------+------------+
| 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.
Figure 8. IPv6 Header
図8のIPv6ヘッダー
+-----------------------+---------------+------------+
| 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) |
+-----------------------+---------------+------------+
Figure 9: TCP Header
図9：TCPヘッダー
(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）サーバ側で、ポート番号は、よく知られた値である可能性があります。クライアント側では、ポート番号は、一般的に、自動的にスタックによって選択されています。ポート番号は、複製可能であるかどうかは、スタックは、ポート番号を選択する方法に依存します。ほとんどの実装は、順次、次の使用可能なポート番号を選ぶ簡単なスキームを使用しながら、この動作に依存することは望ましくないであろう。
(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.
（2）TCP初期シーケンス番号のランダム化の勧告（及び予想展開）で、RFC 1948 [10]で定義され、シーケンス番号を共有することは不可能であろう。したがって、このフィールドは複製とみなされることはありません。
(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ヘッダーのためのECNフラグにコメント（2）を参照。
(5) The urgent pointer is very rarely used. This means that, in practice, the field may be considered replicable.
（5）緊急ポインタが非常にほとんど使用されません。これは実際には、フィールドが複製と見なすことができる、ということを意味します。
+---------------------------+--------------+------------+
| 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 |
+---------------------------+--------------+------------+
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、ウィンドウスケール、およびSACK許可などの一部のオプションは、複製パケットストリームの中で同じ値を持つ傾向があります。
Thus, to support context sharing, the compressor should maintain
such TCP options in the context (even though they only appear in
the SYN segment).
(2) Since these options have fixed values, they could be regarded as replicable. However, the only interesting thing to convey about these options is their presence. If it is known that such an option exists, its value is defined.
これらのオプションは、値を修正したので、（2）、それらは複製と見なすことができます。しかし、これらのオプションについて伝えるための唯一の興味深いのは、彼らの存在です。それはそのようなオプションが存在することが知られている場合は、その値が定義されています。
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のエンドポイント間の繰り返しの接続のための送信元アドレスと宛先アドレスをElideのすることができるという利点を考えます。そこにもコンテキストを複製するため（複雑さと堅牢性の点で）コストとなり、もう1つは、適切なソリューションを構成するものを決定したとき、これは考慮されなければなりません。
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.
最後に、複製の使用は、コンプレッサは、ソースデータが伸長器に存在し、正しいことを確信適切な学位を持っている必要があることに注意してください。これは、「変更」のフィールドで、特に、複製中に利用可能ないくつかの制限を課すことがあります。
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の一般的な分類に基づいて行われます。
The CHANGING fields are separated into five different subclasses:
変化するフィールドは、5つの異なるサブクラスに分けられます：
o STATIC
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.
これらは一般的に変更するなど、分類されたが、原因特定の追加の前提条件に、ここでSTATICとして分類されているフィールドです。
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.
これらは、時折、それらの値を変更して、その新しい値を保つフィールドです。
o ALTERNATING
交互O
These fields alternate between a small number of different values.
これらのフィールドは、異なる値の数が少ない交互。
o IRREGULAR
不定期
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.
分類が行われた場合、その他の詳細は、分類に従って、フィールド値および/またはフィールドデルタについての可能な追加の知識に関して記載されています。静的または半静的に分類フィールドについて、フィールドの値は、先験的（半静的フィールドの二つの状態）は、静的にもよく知られていないだけかもしれません。非不規則な変化挙動を持つフィールドの場合は、変更は、フィールドの最大の変化と比べて限られた範囲内通常であることが知られてすることができます。他のフィールドの場合、値は完全に不明です。
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）のIPv4フィールドを参照し、（6）は、IPv6を指します。
+------------------------+-------------+-------------+-------------+
| 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 |
+------------------------+-------------+-------------+-------------+
Figure 11. Classification of CHANGING Fields
変化するフィールドの図11の分類
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.
以下のサブセクションでは、詳細に、様々なヘッダフィールドを議論します。その表1および以下の議論は、圧縮ポイントの前損失や並べ替えにより生じた変化を考慮していない注意してください。
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].
トラフィッククラス（IPv6）のまたはサービス型/ DSCP（IPv4）のフィールドは、パケットストリームの存続期間中に変化することが予想される場合があります。この分析は、元のRFC 791に変更を記述するいくつかのRFCを考慮[1]。
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のバイトは、最初TOSの3ビット、（ゼロになるように定義）2予約ビットに続く優先順位の3ビットとして[1] RFC 791に記述されました。 [21] RFC 1122は、追加の2ビットの意味が定義されていなかったが、これは、TOSの5ビットを指定するように拡張しました。 [23] RFC 1349「は、金銭的コストを最小化」としてTOSの4ビットを定義しました。次の有意な変化は、（RFC 1349 [23]時代遅れ）[14] RFC 2474でした。 RFC 2474は、DSCPの6ビット（のDiffServコードポイント）を加え2つの未使用ビットとしてTOSオクテットを再加工しました。最近では、RFC 2780 [30] TOSまたはECNと実験用のトラフィッククラスオクテットの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ビットはゼロであること、またはECNデータを含むことが期待されてもよいです。将来プルーフ観点からは、特にTCPに関して、ECNの使用を想定することが好ましいです。
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.
これらが来て、いくつかのかなりの時間のために存在になりますので、それはまた、従来のスタックとプロファイル作業することが重要と考えられています。簡単にするため、このことは、TOS情報の6ビットとECNデータの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).
（ROHC RTPにおけるTOSのような）DSCPは、（それが経路変更の結果として、例えば、中間の流れを変えることができるが）頻繁に変更しないと予想されます。
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.
RFC 2481 [15]およびRFC 3168 [18]で指定されるように、最初に、我々は、ECNフラグを記述する。その後、提案の更新はフラグの動作を変更するであろうことが記載されています。
In RFC 2481 [15] there are 2 separate flags, the ECT (ECN Capable Transport) flag and the CE (Congestion Experienced) flag. The ECT 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.
RFC 2481 [15]に2つの独立したフラグ、ECT（ECN可能なトランスポート）フラグ及びCE（輻輳が経験）フラグがあります。 ECTフラグは、TCPスタックによってネゴシエートされた場合、すべての「純粋確認」パケットのためのすべてのデータパケットと「0」の「1」になります。これは、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」に設定されており、輻輳を示すために、ネットワーク内のECN対応ルータで「1」に設定することができます。したがってCEフラグがランダムネットワークの輻輳状態と経路における圧縮機の位置に依存する確率で「1」に設定されることが期待されます。そのため、混雑したネットワークに近い受信機に位置コンプレッサーは、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つの可能なコードポイントを有するように2つのビットを考慮する。意味はその後、コードポイントに割り当てられます。
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
00の可能な可能な01 ECNをECNていない、10 ECNできる（ECT（0）としても知られる）は、輻輳は、11輻輳（ECT（1）としても知られる）は、輻輳を経験していません
The use of 2 codepoints for signaling ECT allows the sender to detect when a receiver is not reliably echoing congestion information.
ECTをシグナリングするための2つのコードポイントを使用することは、受信機が確実に渋滞情報をエコーされていない場合、送信者が検出することを可能にします。
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）（ECN可能な流れのために）等しくありそうと「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.
圧縮方式は透過オリジナルECN方式を圧縮することができなければならないが、圧縮の目的のために、ノンスとECNを基準として想定される、ことが示唆されます。
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: o Sequential jump
断片化されたデータグラムが再構築されるときに、IPv4ヘッダの識別フィールド（IP ID）は、データグラムを構成するフラグメントを識別する。 IPv4の仕様では、各パケットが、時間のソースと宛先のペアとプロトコルに固有のIP IDを取得すべきであるだけで、このフィールドに値を代入する方法を正確に指定しない間にデータグラム（またはそのフラグメントのいずれか）ネットワークに生きている可能性があります。これは、IP ID値の割り当ては、我々は3つのクラスに分けている様々な方法で行うことができることを意味します：シーケンシャルジャンプ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カウンタは、すべてのパケットストリームのために使用されています。送信者が同時に複数のパケットストリームを実行している場合は、IP IDは、ストリーム内のパケットの間に複数のことで増やすことができます。 IP IDの値ははるかに予測可能になり、ランダムな値よりも転送するために少ないビットを必要とする、及び（アクティブ発信パケットストリームと送信周波数の数によって決定される）パケット間増分は通常制限されます。
o Random
お らんどｍ
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.
この割り当てポリシーは、各発信パケットストリーム用に別のカウンタを保持し、これによりIP IDの値は、ラップアラウンドを除き、ストリーム内の各パケットに対して1ずつ増加します。したがって、フィールドのデルタ値は一定でよく事前に知られています。この割り当てポリシーは、ヘッダ圧縮の目的のために最も望ましいです。しかし、その使用は、それはおそらくあるべきほど一般的ではありません。
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.
RFC 791に違反しないようにするために[1]、同一のIPアドレス対とIPプロトコル番号を共有するパケットが同じIP ID値を使用することはできません。したがって、連続的な政策の実装は、ノードの同じペアの間に行くのと同じIPプロトコルのパケットストリームのためのID番号スペースがばらばらにする必要があります。これは、時折ジャンプを紹介するので、完全にシーケンシャルよりもポリシーが少ない作るすべてが多くの方法で行うことができます。ヘッダ圧縮の目的のために、より少ない頻度のジャンプが好ましいです。
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 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がIPv4機構であるため、IPv6のための問題ではないことに留意されたいです。 IPv4の場合、IDは、3つの異なる方法で処理することができます。まず、IDフィールドは2つのオクテットで圧縮されたヘッダを高め、すべてのパケットにそのまま送信される非効率的なが、信頼性の高いソリューションを持っています。これは、送信者がIDフィールドのランダムな割り当てを使用している場合、IDフィールドを処理するための最良の方法です。第二に、限り順次ジャンプ割り当てが使用されるIDの処理のために少ないビットを必要とする、より柔軟なメカニズムを有する溶液が存在し得ます。ランダムな割り当ては、送信者によって使用されている場合、このようなソリューションは、おそらく多くのビットを必要とします。上記の二つのソリューションの間で選択する際に、送信者の割り当てポリシーについての知識が有用である可能性があります。最後に、偶数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フィールドの動作は、本質的に同じです。しかし、RFC 3095 [31]で、IP IDは、一般的にRTPシーケンス番号から推測されます。この「マスターシーケンス番号の役割を提供するために、フィールドのための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の一部を共有することが好ましいです。
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.
パスMTU探索（IPv6のIPv4の[6]のためにRFC 1191及びRFC 1981 [11]）が広くUDPパケットストリームの少ない現在の使用とは対照的に、TCPのために配備されます。これは、エンドツーエンドパスの断片化の必要性を検出し、ネットワーク経路に沿って最小のMTUを探索するために「1」のDFフラグの値を採用しています。ホストが「0」にDFビットをクリアすることによりPMTU探索を終了してもよいが、この技術を使用して、エンドホストは、「1」にDFセットですべてのパケットを送信することが期待されてもよいです。したがって、圧縮のために、我々は、フィールドの値が安定していることを期待しています。
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.
ホップリミット（IPv6）のまたはタイム・ツー・ライブ（IPv4）のフィールドは、パケットストリームの存続期間中に一定に又はルート変更に起因する値の制限された数との間で交互することが期待されます。
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フィールドの圧縮性のいずれかの議論はRFC 1144 [22]から大いに借ります。しかし、圧縮が行われたかの前提は若干異なっている、とプロトコルが介在時間に少し進化してきました。
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〜それはパスMTU発見により、使用されている場合、MSS（最大セグメントサイズ）と、によって定義される上限によりパケット毎に増加します。
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フラグを含む）、そのパケットのデータペイロードのサイズであることに留意されたいです。これは、もちろん、最も効率的な場合には、シーケンス番号を圧縮するRFC 1144 [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 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.
いくつかの規則性とシーケンス番号を予測できることが望ましいです。しかし、これも行うことが困難であると思われます。例えば、バルクデータ転送中に、シーケンス番号（パケットロスを想定していない）パケットあたり1つのMSSが上がる傾向があります。 892バイトの1つのセグメントに続く1460バイトの5つのセグメント - 上位レイヤ値は、同様に、シーケンス番号動作は8Kバイトの繰り返しパターンで観察された場合に影響を有することが見られています。 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.
対話フロー（例えば、テルネット）のために、シーケンス番号が小さい、不規則な量だけ変化します。この場合、Nagleアルゴリズム[3]一般ために基本ヘッダのオーバーヘッドを低減することができる小さなパケットを合体、適用します。また、これは、シーケンス番号で予測可能な変更が発生する可能性が低いことを意味します。 Nagleアルゴリズムは、最適化され、（アプリケーションがその使用を無効にすることができます）を使用する必要がありません。しかし、それはすべての一般的なTCPの実装では、デフォルトでオンになっています。
Note also that the SYN and FIN flags (which have to be acknowledged) each consume 1 byte of sequence space.
SYNと（肯定応答されなければならない）FINフラグ各シーケンススペースの1つのバイトを消費することにも留意されたいです。
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つの確認応答があるようになる傾向があります。アルゴリズムは、RFC 2581 [16]で指定されています。 ACKは、常にデータ・セグメントの受信時に直ちに送信される必要はないが、それは500ミリ秒以内に送信されなければならず、受信したデータの少なくとも毎秒フルサイズのセグメント（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.
余談として、一般的な実装のバグが「ストレッチのACK」である[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.
確認応答番号は累積的であるため、逆方向の時間定数を残りの確認応答番号になりフォワードパス内のパケットを落としました。ドロップされたセグメントの再送信は、確認番号の大幅なジャンプを引き起こす可能性があります。承認番号におけるこれらのジャンプは、単にシーケンス番号でジャンプ用として、TCPウィンドウで囲まれています。
In the acknowledgement case, information about the advertised received window gives a bound to the size of any ACK jump.
承認の場合は、広告を出して受信ウィンドウの情報は、任意のACKジャンプの大きさにバウンドを与えます。
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.
このフィールドは予約されており、それゆえ、ゼロであることが予想される場合があります。これはもはや、今後プルーフに、と仮定することはできません。フラグを使用するための提案が行われる前に、それは時間の問題です。
o ECN-E (Explicit Congestion Notification)
E-ECN（明示的輻輳通知）O
'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」は、IPヘッダのCEビットをエコーします。これは、（CWRによって「認知」まで）、いくつかの連続したヘッダに設定されます。 ECNのナンスが使用される場合、次いで同様に、フラグに「ノンス和」（NS）ビットが存在することになります。再度、予約ビットの透明度は、将来のプルーフこの圧縮方式のために重要です。効率/圧縮の観点から、NSビットは未使用であろういずれか（常に「0」）又はランダムに変化します。ノンス和[19]に記載されているように、ECTコードポイントの1ビットの合計です。
o CWR (Congestion Window Reduced)
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.
ECNに減少し、信号の輻輳ウィンドウに「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ヘッダでシグナリングされる場合CWRビットセットを見て確認応答されるまで、これは、受信機によって送信されたセグメントでECEビットを介してエコーれます。明らかに、高い混雑及び/又は長いRTTの期間に、このフラグが頻繁に「1」に設定されます。
During connection open (SYN and SYN/ACK packets), the ECN bits have special meaning:
（SYNおよびSYN / ACKパケット）オープン接続時には、ECNビットは特別な意味を持っています：
* CWR and ECN-E are both set with SYN to indicate desire to use ECN.
* CWRとECN-Eは、両方のECNを使用したいという願望を示すために、SYNで設定されています。
* CWR only is set in SYN-ACK, to agree to ECN.
* CWRだけECNに同意し、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.
最初の「SYN」パケットを除くすべてのための「1」。
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)
FIN O（データの終了：終了）
'1' to indicate 'no more data' (unlikely with any flag other than ACK).
「これ以上データ」（ACK以外のフラグ付きにくい）を示さないため、「1」。
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データのためのエンドツーエンドのチェックとして実施しました。これが実施されなければならない理由についての説明はRFC 1144 [22]を参照してください。ヘッダ圧縮スキームは、しかし、ロバスト性のためにTCPチェックサムに依存しないはずであり、それ自身の適切な誤り検出機構を適用すべきです。 TCPチェックサムがランダムに変化するように考慮しなければなりません。
This may oscillate randomly between 0 and the receiver's window limit (for the connection).
これは、0と（接続用）受信機のウィンドウ限界値との間でランダムに振動することができます。
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.
実際には、ウィンドウは、いずれかの値が、比較的少数の間で変更または代替はありません。ウィンドウが閉じているとき、特に（その値が小さくなっている）、ウィンドウの変化は、セグメントサイズに関連する可能性があるが、これは必ずしも圧縮利点を提供することは明らかではありません。ウィンドウが開いている場合は、「愚かなウィンドウ症候群」回避の効果を忘れてはなりません。これは、クロックアウト小さなセグメントをに送信者を励ます少量で開口部からウィンドウを防ぐことができます。
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セグメントのシーケンスに変更される可能性があります何について考えるとき、1は受信機が「ウィンドウ更新」セグメントにおける唯一の窓広告の変更を生成できることに注意してください。
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.
それは意味的に同じ「圧縮「は、同一のビット単位の」と同じではない例を提供していますので、ビューの圧縮の観点から、緊急ポインタは面白いです。 URGフラグが設定されている場合、緊急ポインタの値がのみ有効であるためです。
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チェックサムがその適用範囲で緊急ポインタが含まれているので、これは緊急ポインタのビット単位の透明度を適用します。このように、「ビット単位の」対「セマンティック」アイデンティティの問題は、ノートとして提示される：緊急ポインタはその値を保持する方法で圧縮されなければなりません。
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フラグが設定されている場合、緊急ポインタは、緊急データの終わりを示し、したがって、ウィンドウ内の任意の場所を指し示すことができます。これは、設定（および変更）複数のセグメントにわたってもよいです。それはアウトオブバンドデータを管理するための、特にきれいな方法ではないので、緊急のデータはほとんど使用されていないことに注意してください。
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オクテット種類のフィールドを、持っています。
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 | | |
+----+-------+------------------------------------+----------+-----+
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フローで見られる可能性が最も高いオプションを示すために、「*」でマークされます。また、RFC 1072 [4] RFC 1323によって廃止されたことに注意し[7]、元のビットの使用のみRFC 1072で定義されていません。
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].
このオプションコードはオプションリストの終わりを示します。これは、フィールドオフセットデータに係るTCPヘッダの終わりと一致しない場合があります。これはありません各オプションの終わりに、すべてのオプションの終わりに使用され、オプションの終わりがそうでなければTCPヘッダの最後と一致していないならば、それにのみ使用される必要があります。 RFC 793で定義された[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.
このオプションコードは、ワード境界上の次のオプションの開始を整列させるために、例えば、オプションの間で使用されてもよいです。受信機は、彼らがワード境界のRFC 793で始まらない場合でも、オプションを処理するために準備しなければならないので、送信者は、このオプションを使用するという保証はありませんが、[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制御ビットが設定されたセグメントで）。このオプションを使用しない場合、任意のセグメントサイズが許可されているRFC 793 [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 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.
このオプションは、非常に一般的です。セグメントのサイズは、16ビット量です。理論的には、これは任意の値を取ることができます。しかし、共通している値の数があります。 （トンネルの増加罹患率と、例えば、1400より小さい値は、より一般的になっているが）、例えば、1460のバイトは、イーサネット上のTCP / IPv4のための非常に一般的です。 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.
このオプションは、（1）送信側TCPエンドホストは、両方の実行ウィンドウスケーリングを送信および受信する用意し、（2）適用されるスケール係数を通信することを示すために、TCPエンドホストがSYNセグメント内で送信されてもよいですその受信ウィンドウへ。
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の累乗として対数符号化される（おそらくバイナリシフトによって実装されます）。 SYNセグメント自体の窓がスケーリングされることはないことに注意してください（RFC 1072 [4]）。このオプションは、（すなわち、上のSYNビットとACKとセグメントオフビット）の最初のセグメントで送られてもよいです。また、後セグメントで送信されてもよいが、ウィンドウスケールオプションは、最初のセグメントで受信された場合にのみ。 SYNビットなしのセグメントにウィンドウスケールオプションは無視されるべきです。 SYNセグメント自体におけるウィンドウフィールドは、スケーリングされたことがない（RFC 1323 [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の窓規模が非常に大きい1Gバイトのウィンドウを可能にする）ことが予想されます。
4: SACK-Permitted
4：SACK許可
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.
このオプションは、接続は、RFC 2018 [12]開いた後SACKオプションを受信するように拡張された（おそらく処理する）TCPがSYNで送られてもよいです。このオプションではデータが必要とされるすべてが符号化するオプションの存在のためであるがありません。
5: SACK
5：SACK
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
このオプションは、確立された接続を介して拡張された送達確認情報を伝達するために使用されます。具体的には、受信されたとキューイングされたデータの非連続ブロックのデータ送信を通知するデータ受信装置によって送信されます。データ受信機はこれらのブロック間の配列スペースのギャップを埋めるために、後で再送信中のデータの受信を待ちます。その際、データ受信が正常に左ウィンドウエッジを進めることによって、データを承認します
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]).
TCPヘッダの確認応答番号フィールド。 SACKオプションは、値がまだ残って窓のエッジを指定します確認応答番号フィールドの意味は、変更されないことを理解することが重要である、すなわち、完全に受信したデータの最後のシーケンス番号を越えて1バイト（RFC 2018 [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確認応答番号からのオフセットとして、ベース値（第1ブロックの左端）を見ることができます。 1つのオプションで最大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のRFC 2883 [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エコー応答オプションに送り返すことが情報を運びます。 TCPはなくTCPエコーオプションを接続するためのSYNセグメントで受信された場合にのみ、任意のセグメントでTCPエコーオプションを送信してもよいです。 TCPエコーオプションはRTT測定のために使用される場合、それはデータセグメントに含まれると、4つの情報バイトはデータセグメントが送信者に便利な任意の形式で送信された時間を定義する（RFC 1072を参照[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').
エコーオプションは、一般的に、実際に使用されていない - それは、タイムスタンプオプションで廃止されます。しかし、透明性のためには、圧縮方式がそれを輸送することができることが望ましいです。 （ただし、一般的な「オプション」としてそれを見るよりも、より洗練された任意の治療を試みるにおける利点はありません）。
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, ignoring the others; specifically, it must choose the newest segment with the oldest sequence number (see RFC 1072 [4]).
TCPエコー応答オプションでこれらの同じバイトを返します4つの情報バイトを含むTCPエコーオプションを受け取るTCP。このTCPエコー応答オプションが送信される次のセグメント（例えば、ACKセグメント）に戻らなければなりません。複数のエコーオプションは、応答セグメントが送信される前に受信した場合、TCPは、他の人を無視して、エコーするオプションのうち1つだけ選択する必要があります。具体的には、最も古いシーケンス番号の最新のセグメントを選択しなければならない（RFC 1072 [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').
エコー応答オプションは、一般的に、実際に使用されていない - それは、タイムスタンプオプションで廃止されます。しかし、透明性のためには、圧縮方式がそれを輸送することができることが望ましいです。 （ただし、一般的な「オプション」としてそれを見るよりも、任意のより洗練された治療を試みるにおける利点はありません）。
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バイトのタイムスタンプフィールドを運びます。タイムスタンプ値フィールド（TSval）がオプションを送信してTCPのタイムスタンプクロックの現在の値が含まれています。 ACKビットはTCPヘッダに設定されている場合、タイムスタンプエコー応答フィールド（TSecrは）のみ有効です。それが有効であれば、それはタイムスタンプオプションのTSvalフィールドに、リモートTCPによって送信されたタイムスタンプ値をエコーします。 TSecrが有効でない場合は、その値はゼロでなければなりません。 TSecr値は、一般的に受け取られた最新のタイムスタンプオプションからなります。しかし、以下に説明されている例外があります。 TCPは、最初のセグメント（すなわち、SYNビットと無ACKビットを含むセグメント）のタイムスタンプオプション（TSopt）を送信することができ、それはのための初期セグメントにTSoptを受信した場合にのみ、それは他のセグメントにTSoptを送信することができます接続（[7] RFC 1323を参照）。タイムスタンプは、非常に一般的に使用されています。タイムスタンプオプションは、接続セットアップフェーズで交換されている場合、それらは後続のすべてのセグメントに表示されることが期待されています。この交換が行われない場合、それらは流れの残りの部分は表示されません。
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].
タイムスタンプオプションを使用するための重要な理由は、（RFC 1323 [7]を参照してください、に対する保護包まれたシーケンス番号、またはPAWS）ラップアラウンド配列スペースの検出を可能にすることです。 TCPヘッダー圧縮が展開されるであろう上のリンク上の重大な関心事であるが、このオプションの整合性が維持されることが重要であることが期待されていません。この問題は、例えば、RFC 3150 [32]に記載されています。しかし、提案されたアイフェルアルゴリズム[35]タイムスタンプを利用しているので、現在のタイムスタンプは、細胞型リンク[34]のために使用することが推奨されます。
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.
圧縮に関しては、タイムスタンプのための解像度の範囲は、RFC 1323で提案されていることに注意してください[7]（「ダニ」あたり1秒に1ミリ秒）非常に広いです。これは、（RTTでおそらく幅広いバリエーションと一緒に）それはハードすべての場合に最適になりますエンコーディングのセットを選択することが可能となります。
9: Partial Order Connection (POC) permitted
9：許可半順序接続（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つのピアトランスポートエンティティとの間で通信簡単インジケータを表します。 RFC 1693 [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.
半順序接続オプションは、ほとんど（又は全く）は、現在のインターネットでは使用しないので、唯一の要件は、ヘッダ圧縮方式は、それをコードすることができるということである見ます。
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セグメントのヘッダに見出される情報の種類 - このオプションは、プロトコルのジョブを実行するために必要な情報を伝達するのに役立ちます。半順序接続オプションは、ほとんど（又は全く）は、現在のインターネットでは使用しないので、唯一の要件は、ヘッダ圧縮方式は、それをコードすることができるということである見ます。
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 3ウェイハンドシェイク（3WHS）をバイパスTCPアクセラオープン（TAO）の実装の一部です。 TAOは、32ビットの化身番号を導入し、各セグメントにおけるTCPオプションで搭載された「接続数」（CC）と呼ばれます。異なるCC値がオープン接続の各方向に割り当てられます。実装は単調それは能動的又は受動的に開く連続接続（[8] RFC 1644を参照）CC値を増加させる割り当てます。このオプションは、ほとんど（又は全く）は、現在のインターネットでは使用しないので、唯一の要件は、ヘッダ圧縮方式は、それをコードすることができるということである見ます。
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を行うには、サーバーが発生します。 RFC 1644 [8]を参照してください。このオプションは、ほとんど（又は全く）は、現在のインターネットでは使用しないので、唯一の要件は、ヘッダ圧縮方式は、それをコードすることができるということである見ます。
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オプション、初期からの接続数をエコー（RFC 1644を参照してください[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].
このオプションは、TCPが生成し、代替アルゴリズムに基づいてチェックサムを受信の両方に用意されていることを示すためにTCPがSYNセグメントで送られてもよいです。通信中に、代替のチェックサムは、TCPヘッダのチェックサムフィールドに正規TCPチェックサムに置き換わります。代替のチェックサムが送信するために2つの以上のオクテットが必要な場合、いずれかのチェックサムをゼロとして送信されるTCP代替のチェックサム・データ・オプションとTCPヘッダのチェックサムフィールドに移動させてもよいし、データは、ヘッダフィールドとの間で分割することができますオプション。代替のチェックサムは、通常のTCPチェックサムと同じデータに対して計算されます。 RFC 1146 [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ヘッダのチェックサムフィールドとオプションまたは全体チェックサムの間で分割されているかどうかチェックサム・バイ・チェックサムに基づいて決定されるオプションに配置されます。このオプションの長さは、この接続のための代替のチェックサムアルゴリズムの選択に依存します。 RFC 1146 [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.
代替のチェックサムが接続セットアップ中に交渉された場合（チェックサムデータを運ぶために必要な場合）、このオプションは、後続のすべてのパケットに表示されることがあります。ただし、このオプションは見たことがない、実際には、その唯一の要件はヘッダー圧縮方式は、それをコード化することができるということです。
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拡張（例えば、ウィンドウスケールオプション[7]）とは異なり、SYN-ACKセグメント内のオプションが存在しないことは、送信者が、そのシグネチャの送信を無効にさせてはなりません。この交渉は、典型的には、非SYNセグメント内のオプションを受信すると、不正な動作から、いくつかのTCP実装を防止するために行われます。接続ネゴシエーション中に送信されるSYN-ACKが署名されませんので、無視されるので、これは、このオプションの問題ではありません。接続が行われることはありません、およびオプションを使用して、非SYNセグメントが送信されません。さらに重要なのは、署名の送付ないオプションを理解していないリモートホストのなすがままに、アプリケーションの完全な制御下でなければなりません。 MD5は、任意の暗号化された安全なデータのように、非圧縮性であるべき情報をダイジェスト。それが発生した場合、そのための圧縮方式は、単純に透過的に、このオプションを運ばなければなりません。
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.
上記のリストは、執筆時点では知られているオプションをカバーしています。その他のオプションを定義することが期待されています。任意の将来のオプションは、ヘッダ圧縮方式で処理できることが重要です。未定義のオプションは、最適化することはできませんが、非常に少なくとも、未知のオプションが透過的に実行されるべきであるとして、まだの処理。
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パケットを処理しないことがあり、したがって、オプションがネゴシエートされている知っていると仮定することができないことに注意してください。
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.
しかし、圧縮効率を向上させるために、特定の状況で使用することができる他のそのような合図があってもよいです。
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.
そこフォワード（データ）および逆方向（ACK）経路の両方が共通のリンク上で実施される2つの別個の展開（I）であり、および（ii）フォワード（データ）および逆方向（ACK）パスがどこことがわかります通信の一方向のみに対応するパケットを運ぶ特定のリンクで、異なる経路を介して搬送されます。
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.
前者の場合、コンプレッサとデコンプレッサは、同じ場所に配置することができます。これは、情報を交換するために、リンクの各端部で圧縮と解凍のために可能です。これは、可能な最適化につながる可能性があります。
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.
例えば、確認応答番号は、一般的に反対方向にシーケンス番号から取られます。承認は、リンクを通過していないパケットのために生成することができないので、これは、確認応答を符号化する効率的な方法を提供しています。
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オクテットパケットの10％）、特に一般的な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]に記載されています。これらの方式のほとんどは、任意の特定のサポートを必要とせずに、ヘッダ圧縮と完全に互換性があります。圧縮方式は、実験的なオプションのために最適化されることが期待されていないが、ヘッダ圧縮方式、およびその逆を開発する際にこれらを考慮することが有用です。ヘッダ圧縮スキームは、（まだ未定義のようなものを含む）の任意のオプションをサポートすることができなければなりません。
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圧縮性の高い「packet'ベースのビューとの直接の比較は困難であることは明らかです。 RTPヘッダフィールドは、（例えばIPv4のIP ID、RTPシーケンス番号、RTPタイムスタンプ）ごとにパケット定期的に変更する傾向があり、多くの分野、典型的に依存的な様式で変化します。しかし、このようなシーケンス番号などのTCPフィールドは、一部のための外部要因（TCPウィンドウのサイズ、アプリケーションの動作など）の影響により、より予測不可能に変更する傾向があります。また、フィールドの値は、独立して変化する傾向。全体的に、これは圧縮がより困難になり、それが困難に成功し、効率性と堅牢性をトレードオフすることができますエンコーディングのセットを選択することが可能となります。
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.1 [26]に比べ、これはHTTP / 1.0とより同様である[25]）、ウェブブラウジングを考えます。
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項で前述したように、IPヘッダは明らか同じ2つのエンドポイント間の任意のトランスポート・レイヤ・フロー間で共有することができます。既存のものから新しいTCPヘッダの初期化のために限られた範囲が存在してもよいです。ポート番号は、最も明白な出発点です。
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).
シーケンス番号は唯一「スパース」にする必要があるが、明示的に追加シーケンス番号のための要件があることは明らかです。このようなシーケンス番号（シーケンスおよび確認応答番号は、たとえば、同じまますることができます両方）を追加することによって以外のパケットの一意のIDを保証する明白な方法はありません。
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 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).
上記の分析から分かるように、このようなMSS、WSopt、またはSACK許可などのほとんどのTCPオプションは、のみSYNセグメントに表示されてもよいです。すべての実装は、SYNセグメント上の未知のオプションを無視する（そして、私たちはほとんどがなることを期待する）必要があります。 TCPオプションがSYNセグメントのオプションの交換は両側が拡張を理解することが示された場合にのみ、非SYNセグメント上で送信されます。例えばMD5ダイジェストやタイムスタンプなどの他の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.
総ヘッダサイズも問題です。セグメント・データは32ビットワードで（オプションを含む）ヘッダの合計サイズを与える4ビットのフィールドで始まるTCPヘッダが指定します。これは、ヘッダーとオプションの合計サイズが60バイト以下でなければならないことを意味します。これはオプションのための40のバイトを残します。
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]などの認証メカニズムが使用される場合、圧縮が透明であることが重要です。このようにIPsec ESP [27]などの暗号化方式が使用される場合、TCPフィールドは、圧縮を防止し、表示されないかもしれません。
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].
一緒にRFC 1144からヘッダ圧縮スキームと（以下照合されているできればすべてが）多くのIPとTCPのRFC、[22]、RFC 3544 [36]、およびRFC 3095 [31]、及びRTPのコースの詳細な分析/ UDP / IPは、RFC 3095で、アイデアや知識の源となっています。さらなる背景情報はまた、[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メーリングリストで、多くの重要な問題について、様々な回廊（仮想またはそれ以外）での議論の恩恵を受けました。特別な感謝は銭張、カルステンボルマン、およびGorry 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.
情報の残りの不当表示や誤解は完全に作者のせいです。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[3]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[4]ジェーコブソン、V.およびR.ブレーデン、RFC 1072 "長い遅延パスのためのTCP拡張"、1988年10月。
[5] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990.
[5]ツヴァイク、J.とC.ヤマウズラ、 "TCP代替のチェックサムオプション"、RFC 1146、1990年3月を。
[6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[6]モーグル、J.およびS.デアリングを、 "経路MTUディスカバリ"、RFC 1191、1990年11月。
[7] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992月。
[8] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[8]ブレーデン、B.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[9] Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP: Partial Order Service", RFC 1693, November 1994.
[9]コノリー、T.、アメール、P.、およびP.コンラッド、 "TCPへの拡張：部分的なオーダーサービス"、RFC 1693、1994年11月に。
[10] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[10] Bellovin氏、S.、RFC 1948、1996年5月 "シーケンス番号攻撃からの保護"。
[11] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[11]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、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の選択確認応答オプション"、RFC 2018、1996年10月。
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[13] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、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.ブラック、RFC 2474、1998年12月 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"。
[15] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[15]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[16] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[16]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、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のための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[18] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[18] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、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.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[20] IANA, "IANA", IANA TCP options, February 1998, <http://www.iana.org/assignments/tcp-parameters>.
[20] IANA、 "IANA"、IANAのTCPオプション、1998年2月、<http://www.iana.org/assignments/tcp-parameters>。
[21] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[21]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[22] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[22]ジェーコブソン、V.、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[23] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[23] Almquist、P.、 "インターネットプロトコルスイートでサービスの種類"、RFC 1349、1992年7月。
[24] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[24]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、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.0"、RFC 1945、1996年5月。
[27] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[27]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、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.、ゲティス、J.、モーグル、J.、ニールセン、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[28] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[28] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[29] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[29] Casner、S.とV.ヤコブソン、RFC 2508、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.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、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.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[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.、古城、M.、およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、BCP 48、RFC 3150、2001年7月。
[33] Balakrishnan, Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", RFC 3449, December 2002.
[33]バラクリシュナン、Padmanabhan、V.、Fairhurst、G.、およびM. Sooriyabandara、RFC 3449 "ネットワークパス非対称のTCPパフォーマンスへの影響"、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]稲村、H.、モンテネグロ、G.、ルートヴィヒ、R.、Gurtov、A.、およびF. Khafizov、 "セカンド（2.5G）と第3（3G）世代無線ネットワーク上でTCP"、RFC 3481年2月2003。
[35] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[35]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、RFC 3522、2003年4月。
[36] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[36] Engan、M.、Casner、S.、ボルマン、C.、およびT.コレン、 "PPP上のIPヘッダー圧縮"、RFC 3544、2003年7月。
[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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
Authors' Addresses
著者のアドレス
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
マーク・A.西シーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833311 Eメール：mark.a.west@roke.co.uk URI：http://www.roke.co.uk
Stephen McCann Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
スティーブン・マッキャンシーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833341 EMail: stephen.mccann@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833341 Eメール：stephen.mccann@roke.co.uk URI：http://www.roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。