[要約] RFC 4163は、TCP/IPヘッダー圧縮に関する要件を定義しており、ROHC（Robust Header Compression）のためのガイドラインを提供しています。このRFCの目的は、効果的なヘッダー圧縮アルゴリズムの開発と実装を促進することです。
Network Working Group L-E. Jonsson
Request for Comments: 4163 Ericsson
Category: Informational August 2005
RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression
堅牢なヘッダー圧縮（ROHC）：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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.
このドキュメントには、堅牢なヘッダー圧縮（ROHC）ワーキンググループによって開発されるTCP/IPヘッダー圧縮スキーム（プロファイル）の要件が含まれています。このドキュメントでは、TCP圧縮の範囲、パフォーマンスに関する考慮事項、周囲の環境に関する仮定、および知的財産権の懸念について説明します。このドキュメントの構造は、ROHCのIP/UDP/RTP要件を定義するRFC 3096から継承されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration ..........................................7
4. IANA Considerations .............................................7
5. Acknowledgements ................................................7
6. Informative References ..........................................7
The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link roundtrip times. The schemes must perform well for cellular links that use technologies such as Wideband Code Division Multiple Access (W-CDMA), Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000. However, the schemes should also be applicable to other link technologies with high loss and long roundtrip times.
ROHC WGの目標は、高いエラー率と長いリンクの往復時間を伴うリンクでうまく機能するヘッダー圧縮スキームを開発することです。このスキームは、ワイドバンドコード分裂マルチアクセス（W-CDMA）、GSM進化（EDGE）の強化されたデータレート、CDMA2000などのテクノロジーを使用するセルラーリンクでうまく機能する必要があります。ただし、スキームは、高い損失と長い往復時間を持つ他のリンクテクノロジーにも適用する必要があります。
The main objective for ROHC has been robust compression of IP/UDP/RTP
[5], but the WG is also chartered to develop new header compression
solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to
RTP, has usually been sent over reliable links, existing schemes for
TCP, [3] and [4], have not experienced the same robustness problems
as RTP compression. However, there are still many scenarios where
TCP header compression will be implemented over less reliable links
[11], [12], making robustness an important objective for the new TCP
compression scheme. Other, equally important, objectives for ROHC
TCP compression are: improved compression efficiency, enhanced
capabilities for compression of header fields including TCP options,
and finally incorporation of TCP compression into the ROHC framework
[6].
The following requirements have, more or less arbitrarily, been divided into five groups. The first group deals with requirements concerning the impact of a header compression scheme on the rest of the Internet infrastructure. The second group defines what kind of headers must be compressed efficiently. The third and fourth groups concern performance requirements and capability requirements that stem from the properties of link technologies where ROHC TCP is expected to be used. Finally, the fifth section discusses Intellectual Property Rights related to ROHC TCP compression.
次の要件は、多かれ少なかれarbitrarily意的に、5つのグループに分けられています。最初のグループは、インターネットインフラストラクチャの残りの部分に対するヘッダー圧縮スキームの影響に関する要件を扱います。2番目のグループは、どのようなヘッダーを効率的に圧縮する必要があるかを定義します。3番目と4番目のグループは、ROHC TCPが使用されると予想されるリンクテクノロジーのプロパティに由来するパフォーマンス要件と機能要件に関係しています。最後に、5番目のセクションでは、ROHC TCP圧縮に関連する知的財産権について説明します。
1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded.
1. 透明性：ヘッダーが圧縮されてから減圧されている場合、結果のヘッダーは元のヘッダーと意味的に同一でなければなりません。これを達成できない場合、誤ったヘッダーを含むパケットを破棄する必要があります。
Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.
正当化：ヘッダー圧縮プロセスは、インターネットインフラストラクチャの現在または将来の部分に問題を引き起こす可能性のあるヘッダーを生成してはなりません。
Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical".
注：ROHC WGは、「セマンティックに同一」が「ビットワイズ同一」と同じではない場合を発見していません。
2. Ubiquity: Must not require modifications to existing IP (v4 or v6) or TCP implementations.
2. 普及：既存のIP（V4またはV6）またはTCP実装の変更を必要としないでください。
Justification: Ease of deployment.
正当化：展開の容易さ。
Note: The ROHC WG may recommend changes that would increase the compression efficiency for the TCP streams emitted by implementations. However, ROHC cannot assume such recommendations will be followed.
注：ROHC WGは、実装によって放出されるTCPストリームの圧縮効率を高める変更を推奨する場合があります。ただし、ROHCはそのような推奨事項に従うことを想定できません。
Note: Several TCP variants are currently in use on the Internet. This requirement implies that the header compression scheme must work efficiently and correctly for all expected TCP variants.
注：現在、いくつかのTCPバリアントがインターネットで使用されています。この要件は、ヘッダー圧縮スキームが予想されるすべてのTCPバリアントに対して効率的かつ正しく機能する必要があることを意味します。
1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all expected changes in the IP header fields must be handled by the compression scheme, and commonly changing fields should be compressed efficiently. Compression must still be possible when IPv6 Extensions are present in the header. When designing the compression scheme, the usage of Explicit Congestion Notification (ECN) [10] should be considered as a common behavior. Therefore, the scheme must also compress efficiently in the case when the ECN bits are used.
1. IPv4およびIPv6：IPv4とIPv6の両方をサポートする必要があります。これは、IPヘッダーフィールドの予想されるすべての変更を圧縮スキームによって処理する必要があり、一般に変化するフィールドを効率的に圧縮する必要があることを意味します。IPv6拡張機能がヘッダーに存在する場合、圧縮はまだ可能です。圧縮スキームを設計する場合、明示的な輻輳通知（ECN）[10]の使用は、共通の動作と見なされるべきです。したがって、スキームは、ECNビットが使用されている場合にも効率的に圧縮する必要があります。
Justification: IPv4 and IPv6 will both be around for the foreseeable future, and Options/Extensions are expected to be more commonly used. ECN is expected to have a breakthrough and be widely deployed, especially in combination with TCP.
正当化：IPv4とIPv6は、予見可能な将来の両方で存在し、オプション/拡張機能がより一般的に使用されると予想されます。ECNは、特にTCPと組み合わせて、ブレークスルーを持ち、広く展開されると予想されます。
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be supported and should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 they include headers containing the Routing Header and the Home Address Option.
2. モバイルIP：モバイルIP {V4、V6}で使用されるヘッダーの種類をサポートする必要があり、効率的に圧縮する必要があります。IPv4の場合、これらにはトンネルパケットのヘッダーが含まれます。IPv6の場合、ルーティングヘッダーとホームアドレスオプションを含むヘッダーが含まれます。
Justification: It is very likely that Mobile IP will be used by cellular devices.
正当化：モバイルIPがセルラーデバイスで使用される可能性が非常に高いです。
3. Generality: Must handle all headers from arbitrary TCP streams.
3. 一般性：任意のTCPストリームからすべてのヘッダーを処理する必要があります。
Justification: There must be a generic scheme that can compress reasonably well for any TCP traffic pattern. This does not preclude optimizations for certain traffic patterns.
正当化：TCPトラフィックパターンに合理的によく圧縮できる一般的なスキームが必要です。これは、特定のトラフィックパターンの最適化を排除するものではありません。
4. IPSEC: The scheme should be able to compress headers containing IPSEC subheaders where the NULL encryption algorithm is used.
4. IPSEC：スキームは、null暗号化アルゴリズムが使用されているIPSECサブヘッダーを含むヘッダーを圧縮できるはずです。
Justification: IPSEC is expected to be used to provide necessary end-to-end security.
正当化：IPSECは、必要なエンドツーエンドのセキュリティを提供するために使用されることが期待されています。
Note: It is not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
注：ESPヘッダーの暗号化された部分や、AHヘッダーの暗号化データを圧縮することはできません。
5. TCP: All fields supported by [4] should be handled with efficient compression, as should be the cases when the SYN, FIN or TCP ECN [10] bits are set.
5. TCP：[4]でサポートされているすべてのフィールドは、Syn、Fin、またはTCP ECN [10]ビットが設定されている場合と同様に、効率的な圧縮で処理する必要があります。
Justification: These bits are expected to be commonly used.
正当化：これらのビットは一般的に使用されると予想されます。
6. TCP options: The scheme must support compression of packets with any TCP option present, even if the option itself is not compressed. Further, for some commonly used options the scheme should also provide compression mechanisms for the options.
6. TCPオプション：スキームは、オプション自体が圧縮されていなくても、任意のTCPオプションが存在するパケットの圧縮をサポートする必要があります。さらに、いくつかの一般的に使用されるオプションでは、スキームはオプションの圧縮メカニズムも提供する必要があります。
Justification: Because various TCP options are commonly used, applicability of the compression scheme would be significantly reduced if packets with options could not be compressed.
正当化：さまざまなTCPオプションが一般的に使用されるため、オプションを持つパケットを圧縮できないと、圧縮スキームの適用性が大幅に低下します。
Note: Options that should be compressed are: - Selective Acknowledgement (SACK), [8], [9] - Timestamp, [7]
注：圧縮する必要があるオプションは次のとおりです。
1. Performance/Spectral Efficiency: The scheme must provide low relative overhead under expected operating conditions; compression efficiency should be better than for RFC 2507 [4] under equivalent operating conditions.
1. パフォーマンス/スペクトル効率：スキームは、予想される動作条件下で低い相対オーバーヘッドを提供する必要があります。圧縮効率は、同等の動作条件下でRFC 2507 [4]よりも優れている必要があります。
Justification: Spectrum efficiency is a primary goal.
正当化：スペクトル効率が主な目標です。
Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.
注：相対的なオーバーヘッドは、ペイロードに対する平均ヘッダーオーバーヘッドです。スキームで使用される補助（コントロールまたはフィードバックなど）チャネルは、ヘッダーのオーバーヘッドを計算する際に考慮する必要があります。
2. Losses between compressor and decompressor: The scheme should make sure losses between compressor and decompressor do not result in losses of subsequent packets, or cause damage to the context that results in incorrect decompression of subsequent packet headers.
2. コンプレッサーと減圧器間の損失：スキームは、コンプレッサーと減圧装置間の損失が後続のパケットの損失をもたらさないことを確認するか、後続のパケットヘッダーの誤った減圧をもたらすコンテキストに損傷を与えることを確認する必要があります。
Justification: Even though link layer retransmission in most cases is expected to almost eliminate losses between compressor and decompressor, there are still many scenarios where TCP header compression will be implemented over less reliable links [11], [12]. In such cases, loss propagation due to header compression could affect certain TCP mechanisms that are capable of handling some losses; loss propagation could also have a negative impact on the performance of TCP loss recovery.
正当化：ほとんどの場合、リンク層の再送信はコンプレッサーと減圧装置間の損失をほぼ排除すると予想されていますが、信頼性の低いリンクでTCPヘッダー圧縮が実装されるシナリオはまだたくさんあります[11]、[12]。そのような場合、ヘッダー圧縮による損失伝播は、いくつかの損失を処理できる特定のTCPメカニズムに影響を与える可能性があります。損失伝播は、TCP損失回復のパフォーマンスにも悪影響を与える可能性があります。
3. Residual errors in compressed headers: Residual errors in compressed headers may result in delivery of incorrectly decompressed headers not only for the damaged packet itself, but also for subsequent packets, because errors may be saved in the context state. For TCP, the compression scheme is not required to implement explicit mechanisms for residual error detection, but the compression scheme must not affect TCP's end-to-end mechanisms for error detection.
3. 圧縮ヘッダーの残留エラー：圧縮ヘッダーの残留エラーは、破損したパケット自体だけでなく、コンテキスト状態にエラーが保存される可能性があるため、後続のパケットの場合にも誤って減圧されたヘッダーが届く可能性があります。TCPの場合、残留エラー検出のための明示的なメカニズムを実装するために圧縮スキームは必要ありませんが、圧縮スキームはエラー検出のためのTCPのエンドツーエンドメカニズムに影響を与えてはなりません。
Justification: For links carrying TCP traffic, the residual error rate is expected to be insignificant. However, residual errors may still occur, especially in the end-to-end path. Therefore, it is crucial that TCP is not prevented from handling these.
正当化：TCPトラフィックを運ぶリンクの場合、残留エラー率は取るに足らないものであると予想されます。ただし、特にエンドツーエンドのパスでは、残留エラーが依然として発生する可能性があります。したがって、TCPがこれらの処理を妨げられないことが重要です。
Note: This requirement implies that the TCP checksum must be carried unmodified in all compressed headers.
注：この要件は、TCPチェックサムをすべての圧縮ヘッダーで変更していないことを意味します。
Note: The error detection mechanism in TCP may be able to detect residual bit errors, but the mechanism is not designed for this purpose, and might actually provide rather weak protection. Therefore, although it is not a requirement of the compression scheme, it should be possible for the decompressor to detect residual errors and discard such packets.
注：TCPのエラー検出メカニズムは、残差ビットエラーを検出できる可能性がありますが、メカニズムはこの目的のために設計されておらず、実際にはかなり弱い保護を提供する可能性があります。したがって、圧縮スキームの要件ではありませんが、減圧装置が残留エラーを検出してそのようなパケットを破棄することは可能です。
4. Short-lived TCP transfers: The scheme should provide mechanisms for efficient compression of short-lived TCP transfers, minimizing the size of context initiation headers.
4. 短命のTCP転送：スキームは、短命のTCP転送の効率的な圧縮のメカニズムを提供し、コンテキスト開始ヘッダーのサイズを最小限に抑える必要があります。
Justification: Many TCP transfers are short-lived. This may lead to a low gain for header compression schemes that, for each new packet stream, requires full headers to be sent initially and allows small compressed headers only after the initialization phase.
正当化：多くのTCP転送は短命です。これにより、ヘッダー圧縮スキームのゲインが低くなる可能性があり、新しいパケットストリームごとに最初にフルヘッダーを送信し、初期化フェーズ後にのみ小さな圧縮ヘッダーを許可する必要があります。
Note: This requirement implies that mechanisms for building new contexts that are based on information from previous contexts or for concurrent packet streams to share context information should be considered.
注：この要件は、以前のコンテキストからの情報に基づいた新しいコンテキストを構築するためのメカニズム、またはコンテキスト情報を共有するための同時パケットストリームを考慮する必要があることを意味します。
5a. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
5a。中程度のパケットの誤用：スキームは、コンプレッサーに到達するパケットストリームの中程度の誤用（2-3パケット）を効率的に処理する必要があります。
Justification: This kind of misordering is common.
正当化：この種の誤用は一般的です。
5b. Packet Misordering: The scheme must be able to correctly handle packet misordering and preferably compress when misordered packets are in the TCP stream reaching the compressor.
5b。パケットの誤用：スキームは、パケットの誤用替えを正しく処理し、好ましくは誤ったパケットがコンプレッサーに到達しているTCPストリームにあるときに圧縮することができなければなりません。
Justification: Misordering happens regularly in the Internet. However, because the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiency.
正当化：インターネットでは定期的に誤用が起こります。ただし、インターネットはTCPを合理的にうまく実行するように設計されているため、過度の誤った順序は一般的ではなく、最適な効率で処理する必要はありません。
6. Processing delay: The scheme should not contribute significantly to the system delay budget.
6. 処理遅延：スキームは、システム遅延予算に大きく貢献してはなりません。
1. Unidirectional links: Must be possible to implement (possibly with less efficiency) without explicit feedback messages from decompressor to compressor.
1. 単方向リンク：Decompressorからコンプレッサーへの明示的なフィードバックメッセージなしで（おそらく効率が低い）実装できる必要があります。
Justification: There are links that do not provide a feedback channel or where feedback is not desirable for other reasons.
正当化：フィードバックチャネルを提供しないリンクや、他の理由でフィードバックが望ましくない場合があります。
2. Link delay: Must operate under all expected link delay conditions.
2. リンク遅延：予想されるすべてのリンク遅延条件の下で動作する必要があります。
3. Header compression coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles (e.g., [6]).
3. ヘッダー圧縮の共存：スキームは、他のROHCプロファイル（[6]など）とともにROHCフレームワークに適合する必要があります。
4. Note on misordering between compressor and decompressor:
4. コンプレッサーと減圧器間の誤用順についての注意：
When compression is applied over tunnels, misordering often cannot be completely avoided. The header compression scheme should not prohibit misordering between compressor and decompressor, as it would therefore not be applicable in many tunneling scenarios. However, in the case of tunneling, it is usually possible to get misordering indications. Therefore, the compression scheme does not have to support detection of misordering, but can assume that such information is available from lower layers when misordering occurs.
トンネルに圧縮が適用される場合、誤った順序は完全に回避することはできません。したがって、ヘッダー圧縮スキームは、コンプレッサーと減圧装置間の誤った秩序を禁止すべきではありません。したがって、多くのトンネリングシナリオに適用できないためです。ただし、トンネリングの場合、通常、誤った兆候を得ることができます。したがって、圧縮スキームは、誤った順序の検出をサポートする必要はありませんが、そのような情報は、誤った秩序が発生したときに下層から利用できると想定できます。
The ROHC WG must spend effort to achieve a high degree of confidence that there are no known IPR claims that cover the final compression solution for TCP.
ROHC WGは、TCPの最終圧縮ソリューションをカバーするIPRの主張が既知ではないという高度な自信を達成するために努力を費やさなければなりません。
Justification: Currently there is no TCP header compression scheme available that can efficiently compress the packet headers of modern TCP, e.g., with SACK, ECN, etc. ROHC is expected to fill this gap by providing a ROHC TCP scheme that is applicable in the wide area Internet, not only over error-prone radio links. It must thus attempt to be as future-proof as possible, and only unencumbered solutions, or solutions where the terms of any IPR are such that there is no hindrance on implementation and deployment, will be acceptable to the Internet at large.
正当化：現在、最新のTCPのパケットヘッダーを効率的に圧縮できるTCPヘッダー圧縮スキームはありません。エラーインターネット、エラーが発生しやすいラジオリンクだけでなく。したがって、可能な限り将来の防止解決策のみを試みなければならず、IPRの条件が実装と展開に障害がないようなものであるという解決策のみが、インターネット全体に受け入れられるようにしなければなりません。
A protocol specified to meet these requirements must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.
これらの要件を満たすために指定されたプロトコルは、IPSEC要件2.2.4に従ってIPSECヘッダーを含むパケットを圧縮できる必要があります。このようなプロトコルで考慮すべき他のセキュリティの側面があるかもしれません。ただし、このドキュメント自体は、セキュリティリスクを追加しません。
A protocol that meets these requirements will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
これらの要件を満たすプロトコルでは、IANAがさまざまな数値を割り当てる必要があります。ただし、このドキュメント自体は、IANAの関与を必要としません。
This document has evolved through fruitful discussions with and input from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The document quality was significantly improved thanks to Peter Eriksson, who made a thorough linguistic review.
この文書は、Gorry Fairhurst、Carsten Bormann、Mikael DeGermark、Mark West、Jan Kullander、Qian Zhang、Richard Price、Aaron Falkとの実りある議論と意見を通じて進化しました。文書の品質は、徹底的な言語レビューを行ったピーター・エリクソンのおかげで大幅に改善されました。
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served as committed working group document reviewers.
最後になりましたが、Ghyslain PelletierとKristofer Sandlundは、コミットメントされたワーキンググループドキュメントレビュー担当者を務めました。
[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] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[3] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[4] Degermark、M.、Nordgren、B。、およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[5] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[5] Degermark、M。、「堅牢なIP/UDP/RTPヘッダー圧縮の要件」、RFC 3096、2001年7月。
[6] 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.
[6] 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月。
[7] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[8] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[8] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ancoundage Options」、RFC 2018、1996年10月。
[9] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[9] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、2000年7月。
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[10] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[11] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 48、RFC 3150、2001年7月。
[12] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[12] Fairhurst、G。およびL. Wood、「リンク自動リピートリクエスト（ARQ）でデザイナーをリンクするアドバイス」、BCP 62、RFC 3366、2002年8月。
Author's Address
著者の連絡先
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。