[要約] RFC 4413は、TCP/IPフィールドの動作に関するガイドラインであり、フィールドの使用方法と互換性を確保するための推奨事項を提供しています。このRFCの目的は、TCP/IPプロトコルの実装者が一貫した動作を実現し、ネットワーク間の相互運用性を向上させることです。
Network Working Group M. West
Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
TCP/IP Field Behavior
TCP/IPフィールドの動作
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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フィールドの動作について説明します。ほとんどのヘッダーフィールドはパケットからパケットまでランダムに変化しないため、ヘッダー圧縮が可能です。フィールドの多くは、多かれ少なかれ予測可能な方法で静的な動作または変化を示します。ヘッダー圧縮スキームが設計されている場合、フィールドの動作を詳細に理解することが根本的に重要です。この分析の例は、RFC 3095で見ることができます。このメモは、TCP/IPヘッダーの圧縮に同様の役割を実行します。
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/IPヘッダーの形式とヘッダーフィールドの動作、つまりTCPフロー内でフィールドがどのように変化するかについて説明します。説明は、ヘッダー圧縮のコンテキストで表示されます。
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つのステップで分類および分析されます。まず、セクション2には一般的な分類があります。ここでは、フィールドは安定した知識と仮定に基づいて分類されます。この一般的な分類は、変化するフィールドの変更特性を考慮していません。これらは、実装と使用されるアプリケーションによって多かれ少なかれ異なるためです。セクション3では、短命のフローを最適化するためにフィールド値を使用する方法を検討します。次に、セクション4で変更特性のより詳細な分析を行います。最後に、セクション5は、圧縮を最適化するために、ヘッダー圧縮スキームによってさまざまなヘッダーフィールドをどのように処理するかについての結論をまとめたものです。
A general question raised by this analysis is: what 'baseline' definition of all possible TCP/IP implementations is to be considered? This review is based on an analysis of currently deployed TCP implementations supporting mechanisms standardised by the IETF.
この分析で提起された一般的な質問は、可能なすべてのTCP/IP実装の「ベースライン」の定義を考慮する必要がありますか？このレビューは、IETFによって標準化されたメカニズムをサポートする現在展開されているTCP実装の分析に基づいています。
The general requirement for transparency is also interesting. A number of recent proposals for extensions to TCP use some of the previously 'reserved' bits in the TCP packet header. Therefore, a 'reserved' bit cannot be taken to have a guaranteed zero value; it may change. Ideally, this should be accommodated by the compression profile.
透明性の一般的な要件も興味深いものです。TCPへの拡張に関する最近の提案の多くは、TCPパケットヘッダーの以前の「予約済み」ビットの一部を使用しています。したがって、「予約済み」ビットをゼロ値を保証することはできません。それは変わるかもしれません。理想的には、これは圧縮プロファイルによって対応する必要があります。
A 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]、付録Aからコピーされています。RFC3095[31]（つまり、オーディオおよびビデオアプリケーションのIP/UDP/RTP動作）とこのドキュメント間のIPフィールドの動作の違いがあります。特定されました。
For the following, we define "session" as a TCP packet stream, being a series of packets with the same IP addresses and port numbers. A packet flow is defined by certain fields (see STATIC-DEF, below) and may be considered a subset of a session. See [31] for a fuller discussion of separation of sessions into streams of packets for header compression.
以下では、「セッション」をTCPパケットストリームとして定義し、同じIPアドレスとポート番号を持つ一連のパケットです。パケットフローは、特定のフィールドで定義されています（static-def、以下を参照）、セッションのサブセットと見なされる場合があります。ヘッダー圧縮のためのパケットのストリームへのセッションの分離の完全な議論については、[31]を参照してください。
At a general level, the header fields are separated into 5 classes:
一般レベルでは、ヘッダーフィールドは5つのクラスに分けられます。
o INFERRED
o 推測
These fields contain values that can be inferred from other values (for example, the size of the frame carrying the packet) and thus do not have to be handled at all by the compression scheme.
これらのフィールドには、他の値（たとえば、パケットを運ぶフレームのサイズ）から推測できる値が含まれているため、圧縮スキームではまったく処理する必要はありません。
o STATIC
o 静的
These fields are expected to be constant throughout the lifetime of the packet stream. Static information must in some way be communicated once.
これらのフィールドは、パケットストリームの生涯を通じて一定になると予想されます。静的情報は、何らかの方法で一度通信する必要があります。
o STATIC-DEF
o static-def
STATIC fields whose values define a packet stream. They are in general handled as STATIC.
値がパケットストリームを定義する静的フィールド。それらは一般に静的として処理されます。
o STATIC-KNOWN
o 静的
These STATIC fields are expected to have well-known values and therefore do not need to be communicated at all.
これらの静的フィールドにはよく知られている値があると予想されるため、まったく通信する必要はありません。
o CHANGING
o 変化
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ヘッダーフィールドのそれぞれがこれらのクラスのいずれかに割り当てられています。変更として分類された分野を除くすべてのフィールドについて、分類の動機も述べられています。セクション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.
バージョンフィールドは、どのIPバージョンが使用されるかを示しています。このフィールドに異なる値を持つパケットは、異なるIPスタックで処理する必要があります。したがって、パケットストリームのすべてのパケットは同じIPバージョンでなければなりません。したがって、フィールドは静的に分類されます。
o Flow Label
o フローラベル
This field may be used to identify packets belonging to a specific packet stream. If the field is not used, its value should be zero. Otherwise, all packets belonging to the same stream must have the same value in this field, it being one of the fields that define the stream. The field is therefore classified as STATIC-DEF.
このフィールドは、特定のパケットストリームに属するパケットを識別するために使用できます。フィールドが使用されない場合、その値はゼロでなければなりません。それ以外の場合、同じストリームに属するすべてのパケットは、このフィールドで同じ値を持っている必要があります。これは、ストリームを定義するフィールドの1つです。したがって、フィールドはstatic-defに分類されます。
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.
このフィールドは通常、パケットストリームのすべてのパケットで同じ値を持ちます。後続のヘッダーのタイプをエンコードします。拡張ヘッダーが不在の場合にのみ、フィールドはストリームの存続期間中にその値を変更します。したがって、フィールドは静的に分類されます。静的の分類は、RFC 3095 [31]から継承されます。ただし、次のヘッダーフィールドは、実際には次のヘッダーのタイプによって決定されることに注意してください。したがって、これを推論と見なす方が適切かもしれませんが、これは圧縮スキームの特定の実装に依存します。
o Source and Destination Addresses
o ソースおよび宛先アドレス
These fields are part of the definition of a stream and therefore must be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、ストリームの定義の一部であるため、ストリーム内のすべてのパケットに対して一定でなければなりません。したがって、フィールドはstatic-defに分類されます。
This might be considered as a slightly simplistic view. In this document, the IP addresses are associated with the transport layer connection and assumed to be part of the definition of a flow. More complex flow-separation could, of course, be considered (see also RFC 3095 [31] for more discussion of this issue). Where tunneling is being performed, the use of the IP addresses in outer tunnel headers is also assumed to be STATIC-DEF.
これは、わずかに単純な見方と見なされる場合があります。このドキュメントでは、IPアドレスは輸送層接続に関連付けられており、フローの定義の一部であると想定されています。もちろん、より複雑なフロー分離を考慮することができます（この問題の詳細については、RFC 3095 [31]も参照してください）。トンネルが実行されている場合、外側のトンネルヘッダーでのIPアドレスの使用も静的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.
バージョンフィールドは、どのIPバージョンが使用されるかを示しています。このフィールドに異なる値を持つパケットは、異なるIPスタックで処理する必要があります。したがって、パケットストリームのすべてのパケットは同じIPバージョンでなければなりません。したがって、フィールドは静的に分類されます。
o Header Length
o ヘッダー長
As long as no options are present in the IP header, the header length is constant and well known. If there are options, the fields would be STATIC, but it is assumed here that there are no options. The field is therefore classified as STATIC-KNOWN.
IPヘッダーにオプションが存在しない限り、ヘッダーの長さは一定でよく知られています。オプションがある場合、フィールドは静的になりますが、ここではオプションがないと想定されています。したがって、このフィールドは静的な既知として分類されます。
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).
RFC 791 [1]で定義されているように、予約されたフラグをゼロに設定する必要があります。したがって、RFC 3095 [31]では、フィールドは静的な既知として分類されます。ただし、予約済みフィールドは、将来のある時点で使用される場合があります。予約済みフィールドの使用における将来の変化のために圧縮プロファイルの使用を妨げるエンコードを選択することは望ましくありません。このため、変更の代替エンコードが使用されます。（もちろん、圧縮プロファイルは、フィールド値が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交渉とその後のPath-MTU発見の使用の組み合わせにより、インターネットでは断片化が一般的であるとは予想されていません。RFC 3095 [31]は、RTPの場合、最初のフラグメントのみが輸送層プロトコルヘッダーを含むことを指摘しています。後続のフラグメントは、別のプロファイルで圧縮する必要があります。これは明らかにTCPの場合です。断片化が発生した場合、定義上、最初のフラグメントは比較的大きく、ヘッダーのオーバーヘッドを最小限に抑えます。後続のフラグメントは、別のプロファイルで圧縮されます。したがって、ヘッダー圧縮を実行する際に断片化を最適化することは望ましくないと考えられています。したがって、より多くのフラグメントフラグは、静的な既知として分類されます。
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.
フラグメンテーションが発生しないという仮定の下では、フラグメントオフセットは常にゼロです。したがって、このフィールドは静的な既知として分類されます。断片化がさらに考慮されたとしても、最初のフラグメントのみがTCPヘッダーを含み、このパケットのフラグメントオフセットは依然としてゼロになります。
o Protocol
o プロトコル
This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header.
このフィールドは通常、パケットストリームのすべてのパケットで同じ値を持ちます。後続のヘッダーのタイプをエンコードします。
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.
ヘッダーのシーケンスが変更された場合（たとえば、拡張ヘッダーが挿入または削除されるか、トンネルヘッダーが追加または削除されます）、フィールドはその値を変更します。したがって、フィールドは静的に分類されます。このような変更がパケットのシーケンスを新しいフローとして（ヘッダー圧縮用）扱うことになるかどうかは、プロファイル設計の問題です。ROHCプロファイルは、拡張ヘッダーとトンネルに対処できる必要がありますが、戦略の選択はこのドキュメントの範囲外です。
o Header Checksum
o ヘッダーチェックサム
The header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, there is no point in having this additional checksum. Instead, it can be regenerated at the decompressor side. The field is therefore classified as INFERRED.
ヘッダーチェックサムは、個々のホップが破損したヘッダーの処理から保護します。ほとんどすべてのIPヘッダー情報が圧縮されている場合、この追加チェックサムを持つことには意味がありません。代わりに、減圧器側で再生できます。したがって、フィールドは推測されているように分類されます。
Note that the TCP checksum does not protect the whole TCP/IP header, but only the TCP pseudo-header (and the payload). Compare this with ROHC [31], which uses a CRC to verify the uncompressed header. Given the need to validate the complete TCP/IP header, the cost of computing the TCP checksum over the entire payload, and known weaknesses in the TCP checksum [37], an additional check is necessary. Therefore, it is highly desirable that some additional checksum (such as a CRC) will be used to validate correct decompression.
TCPチェックサムは、TCP/IPヘッダー全体を保護するのではなく、TCP擬似ヘッダー（およびペイロード）のみを保護することに注意してください。これをROHC [31]と比較します。ROHCは、CRCを使用して非圧縮ヘッダーを検証します。完全なTCP/IPヘッダー、ペイロード全体にわたってTCPチェックサムを計算するコスト、およびTCPチェックサムの既知の弱点[37]を検証する必要があることを考えると、追加のチェックが必要です。したがって、正しい減圧を検証するためにいくつかの追加のチェックサム（CRCなど）を使用することが非常に望ましいです。
o Source and Destination Addresses
o ソースおよび宛先アドレス
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、ストリームの定義の一部であるため、ストリーム内のすべてのパケットに対して一定でなければなりません。したがって、フィールドはstatic-defに分類されます。
The total size of the fields in each class is as follows:
各クラスのフィールドの合計サイズは次のとおりです。
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC* | 1.5 |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 |
+--------------+--------------+
* Differs from RFC 3095 [31]
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オクテットの倍数です。オプションの長さから再構築することができるため、これを明示的に運ぶ必要はありません。したがって、フィールドは推測されているように分類されます。
Summarizing this for IP/TCP, one obtains the following:
これをIP/TCPに要約すると、次のようになります。
+----------------+----------------+----------------+
| 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).
(2) ECNビットを複製することは不可能です（ECN NonCeスキーム[19]の使用が予想されることに注意してください）。ただし、ECN対応ホスト間のすべてのTCPフローが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.
(3) このフィールドの複製可能なコンテキストには、IP-ID、NBO、およびRNDフラグが含まれます（ROHC RTPで説明されています）。これは、レプリケーションがヘッダーフィールド値だけでなくコンテキストのものであり、そのため、各フィールドに適用される圧縮の正確な性質に基づいて考慮する必要があることを強調しています。
(4) Since the possible future behavior of the 'Reserved Flag' cannot be predicted, it is not considered as replicable. However, it might be expected that the behavior of the reserved flag between the same end-points will be similar. In this case, any selection of packet formats (for example) based on this behavior might carry across to the new flow. In the case of packet formats, this can probably be considered as a compressor-local decision.
(4) 「予約された旗」の将来の動作の可能性は予測できないため、複製可能とは見なされません。ただし、同じエンドポイント間の予約されたフラグの動作は類似していると予想される場合があります。この場合、この動作に基づいたパケット形式の選択（たとえば）は、新しいフローに引き継がれる可能性があります。パケット形式の場合、これはおそらくコンプレッサーローカルの決定と見なすことができます。
(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) RFC 1948 [10]で定義されているTCP初期シーケンス数のランダム化の推奨（および予想される展開）により、シーケンス番号を共有することは不可能です。したがって、このフィールドは複製可能とは見なされません。
(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、ウィンドウスケール、サックが許可するなどの一部のオプションは、複製可能なパケットストリーム間で同じ値を持つ傾向があります。
Thus, to support context sharing, the compressor should maintain such TCP options in the context (even though they only appear in the SYN segment).
したがって、コンテキスト共有をサポートするには、コンプレッサーはコンテキストでこのようなTCPオプションを維持する必要があります（Synセグメントにのみ表示されていても）。
(2) Since these options have fixed values, they could be regarded as replicable. However, the only interesting thing to convey about 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エンドポイント間の繰り返し接続のために、ソースと宛先アドレスを排除できるという利点を考慮するだけです。また、コンテキストを複製するためのコスト（複雑さと堅牢性の点で）もあります。これは、適切なソリューションを構成するものを決定した場合に考慮する必要があります。
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
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.
これらは、一般的に変更されていると分類されたフィールドですが、特定の追加の仮定により、ここでは静的として分類されます。
o SEMISTATIC
o 半ゆがみ
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.
これらのフィールドはほとんどの場合静的です。ただし、値が変更されますが、既知の数のパケットの後に元の値に戻ります。
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
o 不規則
These, finally, are the fields for which no useful change pattern can be identified.
これらは、最後に、有用な変更パターンを特定できないフィールドです。
To further expand the classification possibilities without increasing complexity, the classification can be done either according to the values of the field and/or according to the values of the deltas for the field.
複雑さを高めることなく分類の可能性をさらに拡大するために、分類は、フィールドの値に従って、および/またはフィールドのデルタの値に従って行うことができます。
When the classification is done, other details are also stated regarding possible additional knowledge about the field values and/or field deltas, according to the classification. For fields classified as STATIC or SEMISTATIC, the value of the field could be not only STATIC but also well-KNOWN a priori (two states for SEMISTATIC fields). For fields with non-irregular change behavior, it could be known that changes are usually within a LIMITED range compared to the maximal change for the field. For other fields, the values are completely UNKNOWN.
分類が行われると、分類に従って、フィールド値および/またはフィールドデルタに関する追加の知識の可能性に関して、その他の詳細も記載されています。静的または半骨として分類されたフィールドの場合、フィールドの値は静的であるだけでなく、よく知られている先験的である可能性があります（半骨磁場の2つの状態）。非不規則な変更動作を持つフィールドの場合、変化は通常、フィールドの最大の変化と比較して限られた範囲内であることが知られています。他のフィールドの場合、値は完全に不明です。
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は、予想される変更パターンに基づいて、変化するすべてのフィールドを分類します。（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 [1]の変更を説明するいくつかのRFCを考慮します。
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バイトは、最初にRFC 791 [1]で3ビットの優先順位として説明され、その後3ビットのTOSと2つの予約ビット（ゼロと定義）が続きました。RFC 1122 [21]はこれを拡張して5ビットのTOSを指定しましたが、追加の2ビットの意味は定義されていません。RFC 1349 [23]は、TOSの4番目のビットを「金銭的コストを最小化する」と定義しました。次の重要な変化は、RFC 2474 [14]（廃止RFC 1349 [23]）でした。RFC 2474は、TOSオクテットを6ビットのDSCP（DiffServ Code Point）と2つの未使用ビットとして作り直しました。最近では、RFC 2780 [30]は、ECNで実験的に使用するために、TOSまたはトラフィッククラスのオクテットの2つの予約ビットを特定しました。
It is therefore proposed that the TOS (or traffic class) octet be classified as 6 bits for the DSCP and 2 additional bits. These 2 bits may be expected to be zero or to contain ECN data. From a future-proofing perspective, it is preferable to assume the use of ECN, especially with respect to TCP.
したがって、TOS（またはトラフィッククラス）のオクテットをDSCPの6ビットと2つの追加ビットに分類することが提案されています。これらの2つのビットは、ゼロまたは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.
また、プロファイルがレガシースタックで機能することも重要であると考えられています。これは、これらが今後かなりの時間存在するため、存在するからです。簡単にするために、これは6ビットのTOS情報と2ビットのECNデータと見なされるため、フィールドは常に同じ方法で構造化されていると見なされます。
The DSCP (as for TOS in ROHC RTP) is not expected to change frequently (although it could change mid-flow, for example, as a result of a route change).
DSCP（ROHC RTPのTOSの場合）は、頻繁に変更されるとは予想されていません（たとえば、ルートの変更の結果として、フローの途中で変化する可能性があります）。
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スタックによってネゴシエートされた場合、すべてのデータパケットの「1」、すべての「純粋な確認」パケットで「0」になります。これは、ECTフラグの動作がTCPスタックの動作にリンクされていることを意味します。これを圧縮のために悪用できるかどうかは明らかではありません。
The CE flag is only used if ECT is set to '1'. It is set to '0' by the sender and can be set to '1' by an ECN-capable router in the network to indicate congestion. Thus the CE flag is expected to be randomly set to '1' with a probability dependent on the congestion state of the network and the position of the compressor in the path. Therefore, a compressor located close to the receiver in a congested network will see the CE bit set frequently, but a compressor located close to a sender will rarely, if ever, see the CE bit set to '1'.
CEフラグは、ECTが「1」に設定されている場合にのみ使用されます。送信者によって「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ビットの代替ビューを示唆しています。これにより、2つのビットが4つの可能なコードポイントがあると考えています。その後、意味はコードポイントに割り当てられます。
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 ECN能力がない01 ECN能力、混雑なし（ECT（0）と呼ばれる）10 ECN能力、混雑なし（ECT（1）として知られています）11輻輳が発生しました
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つのクラスに分かれています。
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
o ランダム
Some IP stacks assign IP ID values by using a pseudo-random number generator. There is thus no correlation between the ID values of subsequent datagrams. Therefore, there is no way to predict the IP ID value for the next datagram. For header compression purposes, this means that the IP ID field needs to be sent uncompressed with each datagram, resulting in two extra octets of header. IP stacks in cellular terminals that need optimum header compression efficiency should not use this IP ID assignment policy.
一部のIPスタックは、擬似ランダム番号ジェネレーターを使用してIP ID値を割り当てます。したがって、後続のデータグラムのID値の間に相関はありません。したがって、次のデータグラムのIP ID値を予測する方法はありません。ヘッダー圧縮目的のために、これは、IP IDフィールドを各データグラムで非圧縮せずに送信する必要があるため、2つの余分なオクテットのヘッダーが表示されることを意味します。最適なヘッダー圧縮効率を必要とするセルラー端子のIPスタックは、このIP ID割り当てポリシーを使用しないでください。
o Sequential
o 一連
This assignment policy keeps a separate counter for each outgoing packet stream, and thus the IP ID value will increment by one for each packet in the stream, except at wrap around. Therefore, the delta value of the field is constant and well known a priori. This assignment policy is the most desirable for header compression purposes. However, its usage is not as common as it perhaps should be.
この割り当てポリシーは、発信パケットストリームごとに個別のカウンターを保持しているため、ラップアワーを除き、ストリーム内のパケットごとに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フィールドがすべてのパケットでISに送信される非効率的で信頼性の高いソリューションがあり、圧縮ヘッダーが2オクターで増加します。これは、送信者がIDフィールドのランダム割り当てを使用する場合、IDフィールドを処理する最良の方法です。第二に、シーケンシャルジャンプ割り当てが使用されている限り、ID処理に必要なビットが少ないより柔軟なメカニズムを備えたソリューションがあります。このようなソリューションは、送信者がランダム割り当てを使用する場合、おそらくさらに多くのビットを必要とします。したがって、送信者の割り当てポリシーに関する知識は、上記の2つのソリューションを選択する場合に役立ちます。最後に、IPv4の場合でも、ヘッダー圧縮は、圧縮ヘッダーに含まれるIDフィールドの追加情報なしで設計できます。このようなスキームを使用するには、送信者が使用しているIDフィールドの割り当てポリシーを知っている必要があります。それは知ることができないかもしれませんが、これはそのようなソリューションの適用性が非常に不確実であることを意味します。ただし、セルラー端子のIPv4スタックの設計者は、シーケンシャルに近い割り当てポリシーを使用する必要があります。
With regard to TCP compression, the behavior of the IP ID field is essentially the same. However, in RFC 3095 [31], the IP ID is generally inferred from the RTP Sequence Number. There is no obvious candidate in the TCP case for a field to offer this 'master sequence number' role.
TCP圧縮に関しては、IP IDフィールドの動作は本質的に同じです。ただし、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.
PATH-MTUディスカバリー（IPv4のRFC 1191 [6]およびIPv6のRFC 1981 [11]のRFC 1981）は、UDPパケットストリームでの現在の使用とは対照的に、TCP用に広く展開されています。これにより、dfフラグ値「1」を使用して、エンドツーエンドパスでの断片化の必要性を検出し、ネットワークパスに沿って最小MTUをプローブします。この手法を使用したエンドホストは、DFセットを備えたすべてのパケットを「1」に送信することが期待される場合がありますが、ホストはDFビットを「0」にクリアすることによりPMTU発見を終了する場合があります。したがって、圧縮の場合、フィールド値が安定していると予想されます。
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から0から上限（最大セグメントサイズ）、および使用中の場合はPath-MTUディスカバリーによって増加します。
There are common MSS values, but these can be quite variable and unpredictable for any given flow. Given this variability and the range of window sizes, it is hard (compared with the RTP case, for example) to select a 'one size fits all' encoding for the sequence number. (The same argument applies equally to the acknowledgement number).
一般的なMSS値がありますが、これらは非常に変動し、特定のフローでは予測不可能です。この変動性とウィンドウサイズの範囲を考えると、シーケンス番号の「1つのサイズがすべて適合する」エンコードを選択するのは困難です（たとえば、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ミリ秒上昇する傾向があります（パケット損失がないと仮定）。8 kbyteの繰り返しパターンでシーケンス数の動作が観察されているため、より高い層の値も衝撃を与えていると見られています - 1460バイトの5つのセグメントと892バイトの1セグメントが続きます。TCPの実装とプロトコルスタック内のバッファーの管理は、シーケンス番号の動作に影響を与える可能性があります。
It may be possible to track the TCP window by the compressor, allowing it to bound the size of these jumps.
コンプレッサーによってTCPウィンドウを追跡して、これらのジャンプのサイズをバインドできるようにすることができる場合があります。
For interactive flows (for example, telnet), the sequence number will change by small, irregular amounts. In this case, the Nagle algorithm [3] commonly applies, coalescing small packets where possible in order to reduce the basic header overhead. This may also mean that predictable changes in the sequence number are less likely to occur. The Nagle algorithm is an optimisation and is not required to be used (applications can disable its use). However, it is turned on by default in all common TCP implementations.
インタラクティブフロー（たとえば、Telnet）の場合、シーケンス数は少量の不規則な量だけ変化します。この場合、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は常にデータセグメントの受領時に直ちに送信する必要はありませんが、500ms以内に送信する必要があり、少なくとも2秒ごとのフルサイズセグメント（MSS）の受信データを生成する必要があります。これから、確認番号のデルタは、シーケンス番号のほぼ2倍であることがわかります。これは必ずしもそうではありません。シーケンス数の不規則性に関する議論を適用する必要があります。
As an aside, a common implementation bug is 'stretch ACKs' [33] (acknowledgements may be generated less frequently than every two full-size data segments). This pattern can also occur following loss on the return path.
余談ですが、一般的な実装バグは「ストレッチアクック」です[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)
o ECN-E（明示的な混雑通知）
'1' to echo CE bit in IP header. It will be set in several consecutive headers (until 'acknowledged' by CWR). If ECN nonces are used, then there will be a 'nonce-sum' (NS) bit in the flags, as well. Again, transparency of the reserved bits is crucial for future-proofing this compression scheme. From an efficiency/compression standpoint, the NS bit will either be unused (always '0') or randomly changing. The nonce sum is the 1-bit sum of the ECT codepoints, as described in [19].
IPヘッダーにceビットをエコーする '1'。いくつかの連続したヘッダーに設定されます（CWRによって「認められる」まで）。ECN Noncesを使用すると、フラグにも「NonCe-Sum」（NS）ビットがあります。繰り返しますが、予約されたビットの透明性は、この圧縮スキームを将来的に防ぐために重要です。効率/圧縮の観点から、NSビットは未使用（常に「0」）またはランダムに変更されます。[19]に記載されているように、非CEの合計はECTコードポイントの1ビット合計です。
o CWR (Congestion Window Reduced)
o CWR（混雑ウィンドウが減少）
'1' to signal congestion window reduced on ECN. It will generally be set in individual packets. The flag will be set once per loss event. Thus, the probability of its being set is proportional to the degree of congestion in the network, but it is less likely to be set than the CE flag.
eCNで縮小された輻輳ウィンドウを信号する「1」。通常、個々のパケットで設定されます。フラグは、損失イベントごとに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のみがsyn-ackで設定され、ECNに同意します。
(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.
syn/syn-ackの場合、接続の開始時のみ。
o FIN (End of Data: FINished)
o FIN（データの終わり：終了）
'1' to indicate 'no more data' (unlikely with any flag other than ACK).
「1」を示すための「もうデータなし」（ACK以外のフラグではありそうもない）。
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セグメントのシーケンスでどのフィールドが変化するかを考えるとき、受信者はウィンドウ広告のみが変更される「ウィンドウアップデート」セグメントを生成できることに注意する必要があります。
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つのオクテットであり、これが親切なフィールドです。他のすべてのオプションには、1オクセットの種類のフィールドがあり、その後1オクセットの長さフィールドが続き、その後にオプションデータの長さ2オクテットが続きます。
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内で参照される各オプションの動作について、「DISC」インジケーターでリストされています。
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-OCTETアラインドされているため、このオプションの後にパディングのオクテット（[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 Control Bit Setのセグメント）でのみ送信する必要があります。このオプションが使用されない場合、セグメントサイズは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ビット数量です。理論的には、これは任意の価値をとる可能性があります。ただし、一般的な値はたくさんあります。たとえば、1460バイトはイーサネットを介したTCP/IPv4で非常に一般的です（たとえば、トンネルの有病率が増加するため、たとえば、1400などの小さな値がより一般的になりました）。536バイトはデフォルトのMSS値です。これにより、一般的な値をより効率的にエンコードすることができます。
3: Window Scale Option (WSopt)
3：ウィンドウスケールオプション（WSOPT）
This option may be sent in a SYN segment by the TCP end-host (1) to indicate that the sending TCP end-host is prepared to perform both send and receive window scaling, and (2) to communicate a scale factor to be applied to its receive window.
このオプションは、TCPエンドホスト（1）によってSynセグメントで送信され、送信TCPエンドホストが送信および受信の両方を実行するように準備されていることを示しています。受信ウィンドウに。
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のウィンドウスケールでは、1GByteウィンドウが可能になります。これは非常に大きいです）。
4: SACK-Permitted
4：サックが許可しました
This option may be sent in a SYN by a TCP that has been extended to receive (and presumably to process) the SACK option once the connection has opened RFC 2018 [12]. There is no data in this option all that is required is for the presence of the option to be encoded.
このオプションは、接続がRFC 2018を開いた後、SACKオプションを受信する（そしておそらく処理するために）拡張されたTCPによってSynで送信される場合があります[12]。このオプションには、必要なのはオプションの存在がエンコードされるためだけのデータがありません。
5: SACK
5：袋
This option is to be used to convey extended acknowledgment information over an established connection. Specifically, it is to be sent by a data receiver to inform the data transmitter of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data in later retransmissions to fill the gaps in sequence space between these blocks. At that time, the data receiver acknowledges the data, normally by advancing the left window edge in the 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確認番号からオフセットとして表示できます。単一のオプションには、最大4つのサックブロックがあります。サックブロックは、多くのセグメントで発生する可能性があります（「ワイヤーに」より多くのオーダーデータがある場合）。これにより、通常、既存のブロックのサイズが拡張または追加されます。
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]などの代替提案は、その中に含まれる情報の観点から、サックブロックの動作を根本的に変更しません。
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]).
4つの情報バイトを含むTCPエコーオプションを受信する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').
Echo Replyオプションは通常、実際には使用されていません。タイムスタンプオプションによって廃止されています。ただし、透明性のために、圧縮スキームがそれを輸送できることが望ましいです。（ただし、それを一般的な「オプション」と見なすよりも、洗練された治療を試みることに利点はありません）。
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のタイムスタンプ時計の現在の値が含まれています。タイムスタンプエコー応答フィールド（TSECR）は、ACKビットがTCPヘッダーに設定されている場合にのみ有効です。有効な場合、タイムスタンプオプションのTSVALフィールドでリモートTCPによって送信されたタイムスタンプ値をエコーします。TSECRが有効でない場合、その値はゼロでなければなりません。TSECR値は、通常、受信した最新のタイムスタンプオプションからのものです。ただし、以下に説明する例外があります。TCPは、タイムスタンプオプション（TSOPT）を初期セグメント（つまり、synビットとACKビットを含むセグメント）に送信する場合があり、他のセグメントにTSOPTを送信する場合があります。接続（RFC 1323 [7]を参照）。タイムスタンプは非常に一般的に使用されています。接続セットアップフェーズでタイムスタンプのオプションが交換される場合、それらはすべての後続のセグメントに表示されると予想されます。この交換が発生しない場合、それらは残りの流れに現れません。
Because the value being carried is a timestamp, it is logical to expect that the entire value need not be carried. There is no obvious pattern of increments that might be expected, however.
運ばれる値はタイムスタンプであるため、値全体を運ぶ必要がないことを期待するのは論理的です。ただし、予想される増分の明らかなパターンはありません。
An important reason for using the timestamp option is to allow detection of sequence space wrap-around (Protection Against Wrapped Sequence-number, or PAWS, see RFC 1323 [7]). It is not expected that this is a serious concern on the links on which TCP header compression would be deployed, but it is important that the integrity of this option be maintained. This issue is discussed in, for example, RFC 3150 [32]. However, the proposed Eifel algorithm [35] makes use of timestamps, so it is currently recommended that timestamps be used for cellular-type links [34].
タイムスタンプオプションを使用する重要な理由は、シーケンススペースラップアラウンドの検出を許可することです（ラップシーケンス番号またはPAWに対する保護、RFC 1323 [7]を参照）。これは、TCPヘッダー圧縮が展開されるリンクに関する深刻な懸念であるとは予想されていませんが、このオプションの完全性を維持することが重要です。この問題については、たとえばRFC 3150 [32]で議論されています。ただし、提案されたeifelアルゴリズム[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]で提案されているタイムスタンプの解像度の範囲は非常に広い（「ティック」あたり1ms〜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方向握手（3WH）を効果的にバイパスするTCP加速オープン（TAO）の実装の一部です。TAOは、各セグメントのTCPオプションで運ばれる「接続カウント」（CC）と呼ばれる32ビットの化身数を導入します。異なるCC値は、オープン接続の各方向に割り当てられます。この実装は、CC値を単調に増加させ、連続的な接続に割り当て、それが積極的または受動的に開く（RFC 1644 [8]を参照）。このオプションでは、現在のインターネットではほとんど使用されていない（またはまったく）使用されるため、唯一の要件は、ヘッダー圧縮スキームがエンコードできることです。
12: CC.NEW
12：CC.New
Correctness of the TAO mechanism requires that clients generate monotonically increasing CC values for successive connection initiations. Receiving a CC.NEW causes the server to invalidate its cache entry and to do a 3WHS. See RFC 1644 [8]. This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
TAOメカニズムの正しさには、クライアントが連続的な接続開始のために単調に増加するCC値を生成する必要があります。CC.Newを受信すると、サーバーはキャッシュエントリを無効にし、3Whsを実行します。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によってSynセグメントで送信され、TCPが代替アルゴリズムに基づいてチェックサムを生成および受信する準備ができていることを示しています。通信中、代替チェックサムは、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:
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接続で送信されるすべてのセグメントには、MD5アルゴリズムを連結したデータブロックに適用することにより生成される16バイトのMD5ダイジェストが含まれます[13]。
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セグメントにオプションがないため、送信者が署名の送信を無効にしてはなりません。この交渉は、通常、一部のTCP実装が非シンセグメントでオプションを受信することで誤動作するのを防ぐために行われます。接続交渉中に送信されたsyn-ackが署名されず、したがって無視されるため、これはこのオプションの問題ではありません。接続が行われることはなく、オプションを備えた非シンセグメントは送信されません。さらに重要なことは、署名の送信は、オプションを理解していないリモートホストの慈悲ではなく、アプリケーションの完全な制御下にある必要があります。MD5ダイジェスト情報は、暗号化されたデータと同様に、非圧縮性である必要があります。したがって、圧縮スキームが発生した場合、このオプションを単純に透過的に運ぶ必要があります。
20 - 26;
20-26;
Thse non-RFC option types are not considered in this document. This only means that their behavior is not described in detail, as a compression scheme is not expected to be optimised for these options. However, any unrecognised option must be carried by a TCP compression scheme transparently, in order to work efficiently in the presence of new or rare options.
THSE非RFCオプションタイプは、このドキュメントでは考慮されていません。これは、圧縮スキームがこれらのオプションに対して最適化されることは期待されていないため、それらの動作が詳細に説明されていないことを意味します。ただし、新しいまたはまれなオプションが存在する場合に効率的に作業するためには、認識されていないオプションを透過的に透過的に運ぶ必要があります。
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 Exchangeでネゴシエートされ、その後、交渉が成功した場合に使用されることです。これは、オプションの存在に関するいくつかの仮定につながります（たとえば、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.
2つの異なる展開（i）フォワード（データ）とリバース（ACK）パスが共通のリンクに掲載されていることがわかります。さまざまなパスを搭載し、特定のリンクがパケットを運ぶパケットは、1つの通信方向のみに対応しています。
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ヘッダーのオーバーヘッドは、特に典型的なRTP音声ケースと比較して、データパケットの大部分を形成しません（たとえば、1460オクテットパケットでは3％未満）。スペクトル効率は明らかに重要な目標です。ただし、圧縮ゲインのすべての最後のビットを抽出すると、複雑さのかなりのコストでわずかな利益のみが提供されます。効率と複雑さのこのトレードオフは、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圧縮の高度に「パケット」ベースのビューとの直接的な比較が難しいことは明らかです。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]).
1つの予測不可能な短命の接続のパフォーマンスを改善するために何ができるかを見るのは難しいです。ただし、一般に、同じホストのペア間に複数のTCP接続がある場合があります。特定の例として、Webブラウジングを検討します（これは、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.
接続が閉じると、そのホストのペア間の最後の接続であるか、比較的短い時間内に別の接続が開く可能性があります。この場合、コンテキストのIPヘッダー部分（つまり、セクション2.1で特徴付けられたフィールド）は、おそらくほぼ同じです。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で詳細に説明します。全体的に、サブコンテキスト共有または別のコンテキストの初期化のサポートは、短命の接続のシーケンスに対して有用な最適化を提供します。
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フローが終了したかどうかを判断するのは難しいことに注意してください。たとえば、「双方向」リンクケースでさえ、コンプレッサー/分解器でフィンとフィンのACKを見ることは、フィンを再送信できないという意味ではありません。したがって、既存のコンテキストを再利用するのではなく、既存のコンテキストから新しいコンテキストを初期化することについて考える方が便利かもしれません。
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ヘッダーからの新しい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).
シーケンス番号は「スパース」のみである必要がありますが、明示的に追加されたシーケンス番号の要件があることは明らかです。このようなシーケンス番号を追加する以外に、パケットのユニークなアイデンティティを保証する明白な方法はありません（たとえば、シーケンスと確認番号は同じままです）。
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.
総ヘッダーサイズも問題です。TCPヘッダーは、セグメントデータが32ビットワードでヘッダーの合計サイズ（オプションを含む）を与える4ビットフィールドで始まる場所を指定します。これは、ヘッダープラスオプションの合計サイズが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 [22]、RFC 3544 [36]、およびRFC 3095 [31]、そしてもちろんRTP/の詳細な分析からのヘッダー圧縮スキームとともに、多くのIPおよびTCP RFC（できればすべてが以下に照合されています）とともにRFC 3095のUDP/IPは、アイデアと知識の源です。さらに背景情報は[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メーリングリストとさまざまな廊下（仮想またはその他）での多くの重要な問題に関する議論の恩恵も受けました。Qian Zhang、Carsten Bormann、Gorry Fairhurstに感謝します。
Qian Zhang and Hongbin Liao contributed the extensive analysis of shareable header fields.
Qian ZhangとHongbin Liaoは、共有可能なヘッダーフィールドの広範な分析に貢献しました。
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] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[3] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[4] Jacobson、V。およびR. Braden、「長距離パスのTCP拡張」、RFC 1072、1988年10月。
[5] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990.
[5] Zweig、J。およびC. Partridge、「TCP Alternate Checksum Options」、RFC 1146、1990年3月。
[6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[6] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[7] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7] Jacobson、V.、Braden、B。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[8] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[8] Braden、B。、「T/TCP -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] Connolly、T.、Amer、P。、およびP. Conrad、「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] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[12] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[12] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ancoundage Options」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[15] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[15] Ramakrishnan、K。およびS. Floyd、「IPに明示的な混雑通知（ECN）を追加する提案」、RFC 2481、1999年1月。
[16] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[16] Allman、M.、Paxson、V。、およびW. Stevens、「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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「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] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Spring、N.、Wetherall、D。、およびD. Ely、「堅牢な明示的な混雑通知（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] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[22] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[22] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[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] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[25] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[25] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[27] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[27] Kent、S。およびR. Atkinson、「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] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「HyperText Transfer Protocol-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. Pink、「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. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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] Bradner、S。and V. Paxson、「インターネットプロトコルおよび関連するヘッダーの価値に関する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] 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.、およびH. Zheng、 "Robust Header圧縮（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] Dawkins、S.、Montenegro、G.、Kojo、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] Balakrishnan、Padmanabhan、V.、Fairhurst、G。、およびM. Sooriyabandara、「TCPパフォーマンスの非対称性のパフォーマンスの影響」、RFC 3449、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。、ガルトフ、A。、およびF.カフィゾフ、「TCPオーバー（2.5g）および3番目（3G）世代ワイヤレスネットワーク」、RFC 3481、2003年2月。
[35] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[35] Ludwig、R。およびM. Meyer、「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.、Bormann、C。、およびT. Koren、「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] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J。、およびL. Wood、「インターネットサブネットワークのアドバイスデザイナー」、BCP 89、RFC 3819、2004年7月。
Authors' Addresses
著者のアドレス
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey、Hants SO51 0ZN UK
Phone: +44 (0)1794 833311
EMail: 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
Stephen McCann Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey、Hants SO51 0ZN UK
Phone: +44 (0)1794 833341
EMail: stephen.mccann@roke.co.uk
URI: http://www.roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。