Network Working Group P. Karn, Ed.
Request for Comments: 3819 Qualcomm
BCP: 89 C. Bormann
Category: Best Current Practice Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
July 2004
Advice for Internet Subnetwork Designers
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet.
この文書は、インターネットプロトコルをサポートすることを望むが、インターネットアーキテクチャとの意味に不慣れであってもよいデジタル通信機器の設計者、リンク層プロトコル、およびパケット交換ローカルネットワーク（集合的にサブネットワークと呼ぶ）へのアドバイスを提供しますインターネットのパフォーマンスと効率性の彼らのデザイン選択。
Table of Contents
目次
1. Introduction and Overview. . . . . . . . . . . . . . . . . . . 2
2. Maximum Transmission Units (MTUs) and IP Fragmentation . . . . 4
2.1. Choosing the MTU in Slow Networks. . . . . . . . . . . . 6
3. Framing on Connection-Oriented Subnetworks . . . . . . . . . . 7
4. Connection-Oriented Subnetworks. . . . . . . . . . . . . . . . 9
5. Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
6. Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
8. Reliability and Error Control. . . . . . . . . . . . . . . . . 14
8.1. TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
8.2. Recovery from Subnetwork Outages . . . . . . . . . . . . 17
8.3. CRCs, Checksums and Error Detection. . . . . . . . . . . 18
8.4. How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
8.5. TCP Performance Characteristics. . . . . . . . . . . . . 22
8.5.1. The Formulae . . . . . . . . . . . . . . . . . . 22
8.5.2. Assumptions. . . . . . . . . . . . . . . . . . . 23
8.5.3. Analysis of Link-Layer Effects on TCP
Performance. . . . . . . . . . . . . . . . . . . 24
9. Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . . 45
21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
IP, the Internet Protocol [RFC791] [RFC2460], is the core protocol of the Internet. IP defines a simple "connectionless" packet-switched network. The success of the Internet is largely attributed to IP's simplicity, the "end-to-end principle" [SRC81] on which the Internet is based, and the resulting ease of carrying IP on a wide variety of subnetworks, not necessarily designed with IP in mind. A subnetwork refers to any network operating immediately below the IP layer to connect two or more systems using IP (i.e., end hosts or routers). In its simplest form, this may be a direct connection between the IP systems (e.g., using a length of cable or a wireless medium).
IPは、インターネットプロトコル[RFC791] [RFC2460]は、インターネットのコアプロトコルです。 IPは、単純な「コネクション」、パケット交換ネットワークを定義します。インターネットの成功は、主にIPのシンプルさ、インターネットが基になっている「エンド・ツー・エンド原理」[SRC81]、およびサブネットワークの多種多様なIPを運ぶの結果やすさに起因して、必ずしもIPに設計されていません念頭に置いて。サブネットワークは、IP（すなわち、エンドホストまたはルータ）を使用して二つ以上のシステムを接続するためにIP層の直下に動作する任意のネットワークを指します。その最も単純な形態では、これは、（例えば、ケーブルの長さまたは無線媒体を使用して）IPシステムとの間の直接接続であってもよいです。
This document defines a subnetwork as a layer 2 network, which is a network that does not rely upon the services of IP routers to forward packets between parts of the subnetwork. However, IP routers may bridge frames at Layer 2 between parts of a subnetwork. Sometimes, it is convenient to aggregate a group of such subnetworks into a single logical subnetwork. IP routing protocols (e.g., OSPF, IS-IS, and PIM) can be configured to support this aggregation, but typically present a layer-3 subnetwork rather than a layer-2 subnetwork. This may also result in a specific packet passing several times over the same layer-2 subnetwork via an intermediate layer-3 gateway (router). Because that aggregation requires layer-3 components, issues thereof are beyond the scope of this document.
この文書では、サブネットワークの部分間でパケットを転送するためにIPルータのサービスに依存しないネットワークであるレイヤ2ネットワークとしてサブネットワークを定義します。しかし、IPルータは、サブネットワークの部品間のレイヤ2でのフレームを埋めることがあります。時には、単一の論理サブネットワークに、このようなサブネットワークのグループを集約すると便利です。 IPルーティングプロトコル（例えば、OSPFは、IS-IS、およびPIM）は、この集約をサポートするが、典型的にはレイヤ2のサブネットワークではなく、レイヤ3サブネットワークを提供するように構成することができます。これはまた、中間層3のゲートウェイ（ルーター）を介して同じレイヤ2サブネットワーク上を数回通過する特定のパケットをもたらすことができます。その凝集がレイヤ3の構成要素を必要とするため、問題は、この文書の範囲を超えています。
However, while many subnetworks carry IP, they do not necessarily do so with maximum efficiency, minimum complexity, or cost, nor do they implement certain features to efficiently support newer Internet features of increasing importance, such as multicasting or quality of service.
多くのサブネットワークはIPを運ぶながら、しかし、彼らは必ずしも最大効率、最小の複雑さ、またはコストでそうしていない、また彼らは、効率的なマルチキャスティングやサービスの品質として重要性が高まっての新しいインターネット機能を、サポートするために特定の機能を実装します。
With the explosive growth of the Internet, IP packets comprise an increasingly large fraction of the traffic carried by the world's telecommunications networks. It therefore makes sense to optimize both existing and new subnetwork technologies for IP as much as possible.
インターネットの爆発的な増加に伴い、IPパケットは、世界の通信ネットワークによって運ばれるトラフィックのますます大きな割合を含みます。したがって、可能な限りIP用の両方の既存および新規のサブネットワーク技術を最適化するために理にかなっています。
Optimizing a subnetwork for IP involves three complementary considerations:
IPのためのサブネットワークを最適化する3個の相補的な考慮事項が含まれます。
2. Eliminating unnecessary functions that increase cost or complexity.
2.コストや複雑さを増す不要な機能を排除。
3. Choosing subnetwork parameters that maximize the performance of the Internet protocols.
3.インターネット・プロトコルのパフォーマンスを最大化サブネットワークパラメータを選択します。
Because IP is so simple, consideration 2 is more of an issue than consideration 1. That is to say, subnetwork designers make many more errors of commission than errors of omission. However, certain enhancements to Internet features, such as multicasting and quality-of-service, benefit significantly from support given by the underlying subnetworks beyond that necessary to carry "traditional" unicast, best-effort IP.
IPはとてもシンプルなので、配慮2は、サブネットワークの設計者は脱落のエラーよりも手数料の多くのより多くのエラーを作る、と言うことです対価1よりも、問題の詳細です。しかし、そのようなマルチキャスティングやサービス品質などのインターネット機能に特定の機能強化は、「伝統的な」ユニキャスト、ベストエフォートIPを運ぶために必要なものを超えた基礎となるサブネットワークによって与えられた支援から大幅に恩恵を受ける。
A major consideration in the efficient design of any layered communication network is the appropriate layer(s) in which to implement a given function. This issue was first addressed in the seminal paper, "End-to-End Arguments in System Design" [SRC81]. That paper argued that many functions can be implemented properly *only* on an end-to-end basis, i.e., at the highest protocol layers, outside the subnetwork. These functions include ensuring the reliable delivery of data and the use of cryptography to provide confidentiality and message integrity.
任意の階層化通信網の効率的な設計における主要な考慮事項は、所定の機能を実現するためにどのの適切な層（単数または複数）です。この問題は、最初の[SRC81]精液紙、「システム設計におけるエンドツーエンドの引数」で対処されました。その論文は、多くの機能がサブネットワークの外に、最上位のプロトコル層で、すなわち、エンドツーエンドベースで*のみ*適切に実施することができると主張しました。これらの機能は、機密性とメッセージの完全性を提供するために、データの信頼性の高い配信と暗号の使用を確実に含まれています。
Such functions cannot be provided solely by the concatenation of hop-by-hop services; duplicating these functions at the lower protocol layers (i.e., within the subnetwork) can be needlessly redundant or even harmful to cost and performance.
そのような機能は、ホップバイホップ・サービスの連結によってのみ提供することができません。 （すなわち、サブネットワーク内の）下位のプロトコル層でこれらの機能を複製することは、コストおよび性能に不冗長またはさらに有害であることができます。
However, partial duplication of functionality in a lower layer can *sometimes* be justified by performance, security, or availability considerations. Examples include link-layer retransmission to improve the performance of an unusually lossy channel, e.g., mobile radio, link-level encryption intended to thwart traffic analysis, and redundant transmission links to improve availability, increase throughput, or to guarantee performance for certain classes of traffic. Duplication of protocol functions should be done only with an understanding of system-level implications, including possible interactions with higher-layer mechanisms.
しかし、下層の機能を部分的に重複は*時々*パフォーマンス、セキュリティ、または可用性を考慮して正当化することができます。例としては、非常に非可逆チャネル、例えば、移動無線、トラフィック分析を阻止することを目的とリンクレベルの暗号化、および可用性を向上させるための冗長伝送リンクの性能を向上さスループットを向上させる、または特定のクラスのパフォーマンスを保証するためにリンク層の再送を含めますトラフィック。プロトコル機能の複製は、上位層メカニズムとの相互作用の可能性など、システム・レベルの意味の理解のみ行われるべきです。
The original architecture of the Internet was influenced by the end-to-end principle [SRC81], and has been, in our view, part of the reason for the Internet's success.
インターネットの本来のアーキテクチャは、エンド・ツー・エンド原理[SRC81]の影響を受けた、とされている、我々の見解では、インターネットの成功の理由の一部。
The remainder of this document discusses the various subnetwork design issues that the authors consider relevant to efficient IP support.
この文書の残りの部分は、著者が、効率的なIPのサポートに関連すると考えられる様々なサブネットワーク設計の問題について説明します。
IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not support maximum-sized (64KB) IP packets, as IP provides a scheme that breaks packets that are too large for a given subnetwork into fragments that travel as independent IP packets and are reassembled at the destination. The maximum packet size supported by a subnetwork is known as its Maximum Transmission Unit (MTU).
IPv4パケット（データグラム）は、20バイト（単独で、IPv4ヘッダのサイズ）から65535バイトの最大サイズが変わります。サブネットワークは、IPは、独立したIPパケットを移動し、移動先で再構築される断片に与えられたサブネットワークには大きすぎるパケットを壊しスキームを提供するよう、最大サイズ（64キロバイト）IPパケットをサポートする必要はありません。サブネットワークによってサポートされる最大パケット・サイズは、最大転送単位（MTU）として知られています。
Subnetworks may, but are not required to, indicate the length of each packet they carry. One example is Ethernet with the widely used DIX [DIX82] (not IEEE 802.3 [IEEE8023]) header, which lacks a length
サブネットワークは、それだけに必要とされていない、彼らが運ぶ各パケットの長さを示しています。一例では、長さを欠いて広く使用されているDIX [DIX82]（ないIEEE 802.3 [IEEE8023]）ヘッダとイーサネット（登録商標）であります
field to indicate the true data length when the packet is padded to a minimum of 60 bytes. This is not a problem for uncompressed IP because each IP packet carries its own length field.
パケットは60バイトの最小値に埋め込まれたときに真のデータ長を示すフィールド。各IPパケットは、自身の長さフィールドを運ぶので、これは非圧縮IPのための問題ではありません。
If optional header compression [RFC1144] [RFC2507] [RFC2508] [RFC3095] is used, however, it is required that the link framing indicate frame length because that is needed for the reconstruction of the original header.
オプショナルヘッダー圧縮[RFC1144]、[RFC2507]、[RFC2508]、[RFC3095]を使用する場合、しかし、それは、元のヘッダの再構成のために必要とされるので、リンクフレーミングは、フレーム長さを示すことが必要です。
In IP version 4 (the version now in widespread use), fragmentation can occur at either the sending host or in an intermediate router, and fragments can be further fragmented at subsequent routers if necessary.
IPバージョン4（現在広く使用されているバージョン）において、フラグメンテーションは、送信ホストのいずれかで、または中間ルータで発生することができ、必要に応じて断片はさらに、後続のルータに断片化することができます。
In IP version 6 [RFC2460], fragmentation can occur only at the sending host; it cannot occur in a router (called "router fragmentation" in this document).
IPバージョン6 [RFC2460]に、フラグメンテーションは、送信ホストにおいてのみ起こり得ます。それは（このドキュメントの「ルータの断片化」と呼ばれる）は、ルータで発生することはできません。
Both IPv4 and IPv6 provide a "path MTU discovery" procedure [RFC1191] [RFC1435] [RFC1981] that allows the sending host to avoid fragmentation by discovering the minimum MTU along a given path and reduce its packet sizes accordingly. This procedure is optional in IPv4 and IPv6.
IPv4とIPv6の両方は、送信側ホストは、指定された経路に沿って最小のMTUを発見することにより断片化を回避し、それに応じてパケットサイズを低減することを可能にする「経路MTUディスカバリ」手順[RFC1191]、[RFC1435]、[RFC1981]を提供します。この手順では、IPv4とIPv6ではオプションです。
Path MTU discovery is widely deployed, but it sometimes encounters problems. Some routers fail to generate the ICMP messages that convey path MTU information to the sender, and sometimes the ICMP messages are blocked by overly restrictive firewalls. The result can be a "Path MTU Black Hole" [RFC2923] [RFC1435].
パスMTUディスカバリを広く展開が、それは時々問題に遭遇しています。一部のルータは、送信者にパスMTU情報を伝えるICMPメッセージを生成するために失敗し、そして時にはICMPメッセージは過度に制限するファイアウォールによってブロックされています。その結果は、「パスMTUブラックホール」[RFC2923] [RFC1435]することができます。
The Path MTU Discovery procedure, the persistence of path MTU black holes, and the deletion of router fragmentation in IPv6 reflect a consensus of the Internet technical community that router fragmentation is best avoided. This requires that subnetworks support MTUs that are "reasonably" large. All IPv4 end hosts are required to accept and reassemble IP packets of size 576 bytes [RFC791], but such a small value would clearly be inefficient. Because IPv6 omits fragmentation by routers, [RFC2460] specifies a larger minimum MTU of 1280 bytes. Any subnetwork with an internal packet payload smaller than 1280 bytes must implement a mechanism that performs fragmentation/reassembly of IP packets to/from subnetwork frames if it is to support IPv6.
パスMTUディスカバリ手順、パスMTUブラックホールの持続性、およびIPv6のルータ断片化の削除は、断片化が最善の回避されたルータのインターネット技術コミュニティの総意を反映しています。これは、サブネットワークは、「合理的に」大きいのMTUをサポートする必要があります。すべてのIPv4エンドホストは、サイズ576バイト[RFC791]のIPパケットを受信し、再構築する必要があり、そのような小さな値は、明らかに非効率的であろう。 IPv6はルータによって断片化を省略するので、[RFC2460]は1280バイトより大きな最小のMTUを指定します。 1280バイトより小さい内部パケットのペイロードを有する任意のサブネットワークは、IPv6をサポートする場合に/サブフレームからIPパケットの断片化/再アセンブリを実行する機構を実装する必要があります。
If a subnetwork cannot directly support a "reasonable" MTU with native framing mechanisms, it should internally fragment. That is, it should transparently break IP packets into internal data elements and reassemble them at the other end of the subnetwork.
サブネットワークが直接ネイティブのフレーミングメカニズムと「合理的な」MTUをサポートできない場合、それは内部的にフラグメントする必要があります。つまり、それは透過的に内部のデータ要素にIPパケットを分割し、サブネットワークのもう一方の端でそれらを再構築する必要があります。
This leaves the question of what is a "reasonable" MTU. Ethernet (10 and 100 Mb/s) has an MTU of 1500 bytes, and because of the ubiquity of Ethernet few Internet paths currently have MTUs larger than this value. This severely limits the utility of larger MTUs provided by other subnetworks. Meanwhile, larger MTUs are increasingly desirable on high-speed subnetworks to reduce the per-packet processing overhead in host computers, and implementers are encouraged to provide them even though they may not be usable when Ethernet is also in the path.
これは、「合理的」MTUは何かという疑問が残ります。イーサネット（10および100 MB /秒）は、1500バイトのMTUを有し、なぜならイーサネット少数のインターネットパスの普及により、現在、この値よりも大きいのMTUを有します。これは、深刻な他のサブネットワークによって提供されるより大きなMTUの有用性を制限します。一方、大きい方のMTUは、ホストコンピュータにパケットごとの処理オーバヘッドを低減するために高速サブネットワークにますます望ましく、実装者はイーサネットパスでもあるときに使用できない場合でも、それらを提供することが奨励されます。
Various "tunneling" schemes, such as GRE [RFC2784] or IP Security in tunnel mode [RFC2406], treat IP as a subnetwork for IP. Since tunneling adds header overhead, it can trigger fragmentation, even when the same physical subnetworks (e.g., Ethernet) are used on both sides of the host performing IPsec encapsulation. Tunneling has made it more difficult to avoid router fragmentation and has increased the incidence of path MTU black holes [RFC2401] [RFC2923]. Larger subnetwork MTUs may help to alleviate this problem.
例えばGREなどの様々な「トンネリング」方式、[RFC2784]、またはIPセキュリティトンネルモードで[RFC2406]、IPのためのサブネットワークとしてIPを扱います。トンネリングは、ヘッダーオーバーヘッドを付加するので、同一の物理的サブネットワーク（例えば、イーサネット（登録商標））はIPsecのカプセル化を行うホストの両側で使用される場合であっても、断片化を誘発することができます。トンネリングは、それがより困難ルータ断片化を回避するためになされており、経路MTUブラックホール[RFC2401]、[RFC2923]の発生率が増加しています。大きなサブネットワークのMTUは、この問題を軽減するのに役立つかもしれません。
In slow networks, the largest possible packet may take a considerable amount of time to send. This is known as channelisation or serialisation delay. Total end-to-end interactive response time should not exceed the well-known human factors limit of 100 to 200 ms. This includes all sources of delay: electromagnetic propagation delay, queuing delay, serialisation delay, and the store-and-forward time, i.e., the time to transmit a packet at link speed.
低速のネットワークでは、可能な限り最大のパケットが送信するためにかなりの時間がかかる場合があります。これは、チャまたはシリアル化遅延として知られています。合計のエンドツーエンドのインタラクティブ応答時間は100〜200ミリ秒のよく知られた人的要因の制限を超えてはなりません。電磁伝搬遅延、キューイング遅延、シリアル化遅延、およびストアアンドフォワード時間、即ち、時間は、リンク速度でパケットを送信する：これは、遅延のすべてのソースを含みます。
At low link speeds, store-and-forward delays can dominate total end-to-end delay; these are in turn directly influenced by the maximum transmission unit (MTU) size. Even when an interactive packet is given a higher queuing priority, it may have to wait for a large bulk transfer packet to finish transmission. This worst-case wait can be set by an appropriate choice of MTU.
低いリンク速度で、ストア・アンド・フォワード遅延は、全エンドツーエンド遅延を支配することができます。これらは、順番に直接最大伝送単位（MTU）サイズによって影響されます。インタラクティブパケットがより高いキューイング優先度を与えられている場合でも、送信を完了するために大バルク転送パケットを待つ必要ができます。この最悪の場合の待ち時間は、MTUを適切に選択することにより設定することができます。
For example, if the MTU is set to 1500 bytes, then an MTU-sized packet will take about 8 milliseconds to send on a T1 (1.536 Mb/s) link. But if the link speed is 19.2kb/s, then the transmission time becomes 625 ms -- well above our 100-200ms limit. A 256-byte MTU would lower this delay to a little over 100 ms. However, care should be taken not to lower the MTU excessively, as this will increase header overhead and trigger frequent router fragmentation (if Path MTU discovery is not in use). This is likely to be the case with multicast, where Path MTU discovery is ineffective.
MTUは1500バイトに設定されている場合、例えば、そのMTUサイズのパケットは、T1（1.536 MB /秒）リンク上で送信するために、約8ミリ秒かかります。よく私たちの100-200ms限界を超える - リンク速度が19.2キロバイト/秒である場合しかし、その後、送信時間が625ミリ秒になります。 256バイトのMTUは100ミリ秒を少し超えるまでこの遅延を下げてしまいます。 （パスMTU探索を使用していない場合）、これはオーバーヘッドヘッダを増加させ、頻繁なルータの断片をトリガするようしかし、ケアは、過度MTUを低下しないように注意すべきです。これは、パスMTUディスカバリが無効であるマルチキャストの場合、可能性があります。
One way to limit delay for interactive traffic without imposing a small MTU is to give priority to this traffic and to preempt (abort) the transmission of a lower-priority packet when a higher priority packet arrives in the queue. However, the link resources used to send the aborted packet are lost, and overall throughput will decrease.
小さなMTUをかけることなく、対話型トラフィックの遅延を制限する一つの方法は、このトラフィックを優先して、より高い優先度のパケットがキューに到着したときより低い優先度のパケットの送信を先取り（中止）することです。しかし、中断されたパケットを送信するために使用されるリンクリソースが失われ、全体的なスループットが低下します。
Another way to limit delay is to implement a link-level multiplexing scheme that allows several packets to be in progress simultaneously, with transmission priority given to segments of higher-priority IP packets. For links using the Point-To-Point Protocol (PPP) [RFC1661], multi-class multilink [RFC2686] [RFC2687] [RFC2689] provides such a facility.
遅延を制限する別の方法は、より高い優先度のIPパケットのセグメントに与えられた送信優先度を用いて、いくつかのパケットが同時に進行中であることを可能にするリンクレベルの多重化方式を実装することです。ポイントツーポイントプロトコル（PPP）[RFC1661]、多クラスマルチ[RFC2686]、[RFC2687]、[RFC2689]を提供そのような機能を使用してリンクするため。
ATM (asynchronous transfer mode), where SNDUs are fragmented and interleaved across smaller 53-byte ATM cells, is another example of this technique. However, ATM is generally used on high-speed links where the store-and-forward delays are already minimal, and it introduces significant (~9%) increases in overhead due to the addition of 5-byte cell overhead to each 48-byte ATM cell.
SNDUsが断片化され、より小さな53バイトのATMセルにわたってインターリーブATM（非同期転送モード）は、この技術の別の例です。しかし、ATMは、一般的にストアアンドフォワード遅延が既に最小である高速リンク上で使用され、それは有意な（〜9％）を導入により、各48バイトの5バイトのセルのオーバーヘッドを添加するオーバーヘッドが増加しますATMセル。
A third example is the Data-Over-Cable Service Interface Specification (DOCSIS) with typical upstream bandwidths of 2.56 Mb/s or 5.12 Mb/s. To reduce the impact of a 1500-byte MTU in DOCSIS 1.0 [DOCSIS1], a data link layer fragmentation mechanism is specified in DOCSIS 1.1 [DOCSIS2]. To accommodate the installed base, DOCSIS 1.1 must be backward compatible with DOCSIS 1.0 cable modems, which generally do not support fragmentation. Under the co-existence of DOCSIS 1.0 and DOCSIS 1.1, the unfragmented large data packets from DOCSIS 1.0 cable modems may affect the quality of service for voice packets from DOCSIS 1.1 cable modems. In this case, it has been shown in [DOCSIS3] that the use of bandwidth allocation algorithms can mitigate this effect.
第3の例は、2.56 Mb /秒または5.12 Mb /秒の典型的なアップストリーム帯域幅を有するデータオーバーケーブルサービスインターフェース仕様（DOCSIS）です。 【DOCSIS1] DOCSIS 1.0で1500バイトのMTUの影響を低減するために、データリンク層フラグメンテーションメカニズムは[DOCSIS2] DOCSIS 1.1で指定されています。インストールベースに対応するために、DOCSIS 1.1は、一般的に断片化をサポートしていないDOCSIS 1.0ケーブルモデム、との下位互換性がなければなりません。 DOCSIS 1.0およびDOCSIS 1.1の共存下では、DOCSIS 1.0ケーブルモデムからの断片化されていない大きなデータパケットは、DOCSIS 1.1ケーブルモデムからの音声パケットのためのサービスの品質に影響を与える可能性があります。この場合には、帯域幅割り当てアルゴリズムの使用はこの効果を軽減することができる[DOCSIS3]に示されています。
To summarize, there is a fundamental tradeoff between efficiency and latency in the design of a subnetwork, and the designer should keep this tradeoff in mind.
要約すると、そこにサブネットワークの設計の効率化と待ち時間の間の基本的なトレードオフがあり、デザイナーが心の中で、このトレードオフを維持する必要があります。
IP requires that subnetworks mark the beginning and end of each variable-length, asynchronous IP packet. Some examples of links and subnetworks that do not provide this as an intrinsic feature include:
IPはサブネットワークは、各可変長、非同期IPパケットの始まりと終わりをマークする必要があります。固有の機能としてこれを提供していないリンクとサブネットワークのいくつかの例は次のとおりです。
and
そして
4. Asynchronous Transfer Mode (ATM) networks carrying an asynchronous stream of fixed-sized "cells".
固定サイズの「セル」の非同期ストリームを運ぶ4.非同期転送モード（ATM）ネットワーク。
The Internet community has defined packet framing methods for all these subnetworks. The Point-To-Point Protocol (PPP) [RFC1661], which uses a variant of HDLC, is applicable to bit synchronous, octet-synchronous, and octet asynchronous links (i.e., examples 1-3 above). PPP is one preferred framing method for IP, since a large number of systems interoperate with PPP. ATM has its own framing methods, described in [RFC2684] [RFC2364].
インターネットコミュニティは、これらすべてのサブネットワークのためのパケットフレーミング・メソッドを定義しています。 HDLCの変異体を使用するポイントツーポイントプロトコル（PPP）[RFC1661]は、ビット同期、オクテット同期、および非同期オクテットリンク（すなわち、実施例上記1-3）にも適用可能です。多数のシステムがPPPと相互運用するためPPPは、IPのための1つの好ましいフレーミング方法です。 ATMは、[RFC2684]、[RFC2364]に記載され、自身のフレーミング方法を有しています。
At high speeds, a subnetwork should provide a framed interface capable of carrying asynchronous, variable-length IP datagrams. The maximum packet size supported by this interface is discussed above in the MTU/Fragmentation section. The subnetwork may implement this facility in any convenient manner.
高速で、サブネットワークは、非同期、可変長のIPデータグラムを運ぶことができるフレームインタフェースを提供すべきです。このインタフェースによってサポートされる最大パケットサイズがMTU /フラグメンテーションセクションで上述されています。サブネットワークは、任意の便利な方法でこの機能を実装することができます。
IP packet boundaries need not coincide with any framing or synchronization mechanisms internal to the subnetwork. When the subnetwork implements variable sized data units, the most straightforward approach is to place exactly one IP packet into each subnetwork data unit (SNDU), and to rely on the subnetwork's existing ability to delimit SNDUs to also delimit IP packets. A good example is Ethernet. However, some subnetworks have SNDUs of one or more fixed sizes, as dictated by switching, forward error correction and/or interleaving considerations. Examples of such subnetworks include ATM, with a single cell payload size of 48 octets plus a 5- octet header, and IS-95 digital cellular, with two "rate sets" of four fixed frame sizes each that may be selected on 20 millisecond boundaries.
IPパケットの境界は、サブネットワーク内部の任意のフレームや同期のメカニズムと一致する必要はありません。サブネットワークは、可変サイズのデータユニットを実装する場合、最も簡単な方法は、各サブネットワークデータユニット（SNDU）に正確に1つのIPパケットを配置するために、また、IPパケットを区切るためにSNDUsを区切るために、サブネットワークの既存の能力に依存することです。良い例は、イーサネットです。しかし、いくつかのサブネットワークは、スイッチング、前方誤り訂正および/またはインターリーブを考慮して決定されるように、一方のSNDUs以上の固定サイズを有します。そのようなサブネットワークの例は、20ミリ秒の境界に選択することができる4つの固定フレームサイズ毎の二つの「レート・セット」と、48オクテットの単一セルのペイロードサイズプラス5オクテットのヘッダとATM、およびIS-95デジタルセルラーを含みます。
Because IP packets are of variable length, they may not necessarily fit into an integer multiple of fixed-sized SNDUs. An "adaptation layer" is needed to convert IP packets into SNDUs while marking the boundary between each IP packet in some manner.
IPパケットは可変長であるため、それらは必ずしも固定サイズSNDUsの整数倍に収まらない可能性があります。いくつかの方法で、各IPパケットの間の境界をマークしながら、「アダプテーション層は」SNDUsにIPパケットを変換するために必要とされます。
There are several approaches to this problem. The first is to encode each IP packet into one or more SNDUs with no SNDU containing pieces of more than one IP packet, and to pad out the last SNDU of the packet as needed. Bits in a control header added to each SNDU indicate where the data segment belongs in the IP packet. If the subnetwork provides in-order, at-most-once delivery, the header can be as simple as a pair of bits indicating whether the SNDU is the first and/or the last in the IP packet. Alternatively, for subnetworks that do not reorder the fragments of an SNDU, only the last SNDU of the packet could be marked, as this would implicitly indicate the next SNDU as the first in a new IP packet. The AAL5 (ATM Adaptation Layer 5) scheme used with ATM is an example of this approach, though it adds other features, including a payload length field and a payload CRC.
この問題にはいくつかの方法があります。最初は、必要に応じて、パケットの最後のSNDUうち複数のIPパケットの断片を含むないSNDUと、パッドへの1つ以上のSNDUsに各IPパケットを符号化することです。各SNDUに付加制御ヘッダ内のビットは、データ・セグメントは、IPパケットに属している場所を示します。サブネットワークは、AT-最もワンス送達、インオーダー提供する場合、ヘッダは、SNDUは、IPパケットの最初及び/又は最後であるか否かを示すビットのペアのように単純であってもよいです。これは暗黙のうちに新しいIPパケット内の最初のように次のSNDUを示すだろうと別の方法として、SNDUの断片を並べ替えていないサブネットワークのために、パケットの最後のSNDUは、マークすることができます。 ATMで使用AAL5（ATMアダプテーション・レイヤ5）方式がペイロード長フィールドとペイロードCRCを含む他の機能を追加しても、このアプローチの一例です。
In AAL5, the ATM User-User Indication, which is encoded in the Payload Type field of an ATM cell, indicates the last cell of a packet. The packet trailer is located at the end of the SNDU and contains the packet length and a CRC.
AAL5においては、ATMセルのペイロードタイプフィールドに符号化されたATMユーザ - ユーザ指示は、パケットの最後のセルを示します。パケットトレーラは、SNDUの端に位置し、パケット長およびCRCを含みます。
Another framing technique is to insert per-segment overhead to indicate the presence of a segment option. When present, the option carries a pointer to the end of the packet. This differs from AAL5 in that it permits another packet to follow within the same segment. MPEG-2 Transport Streams [EN301192] [ISO13818] support this style of fragmentation, and may either use padding (limiting each MPEG transport stream packet to carry only part of one IP packet), or allow a second IP packet to start in the same Transport Stream packet (no padding).
別のフレーミング技法セグメントオプションの存在を示すために当たりセグメントオーバヘッドを挿入することです。存在する場合、このオプションは、パケットの最後にポインタを運びます。これは、同じセグメント内に従うように他のパケットを許可することでAAL5は異なります。 MPEG-2トランスポートストリーム[EN301192] [ISO13818]は、断片化のこのスタイルをサポートし、（1つのIPパケットの一部だけを運ぶ各MPEGトランスポート・ストリーム・パケットを制限する）パディングを使用することができるか、第2のIPパケットが同じで開始することを可能にしますトランスポートストリームパケット（なしパディング）。
A third approach is to insert a special flag sequence into the data stream between each IP packet, and to pack the resulting data stream into SNDUs without regard to SNDU boundaries. This may have implications when frames are lost. The flag sequence can also pad unused space at the end of an SNDU. If the special flag appears in the user data, it is escaped to an alternate sequence (usually larger than a flag) to avoid being misinterpreted as a flag. The HDLC-based framing schemes used in PPP are all examples of this approach.
第三のアプローチは、各IPパケットとの間のデータ・ストリームに特別なフラグシーケンスを挿入すること、およびSNDUの境界に関係なくSNDUsに結果のデータストリームをパックすることです。フレームが失われたとき、これが意味を持っていることがあります。 FLAG配列SNDUの終わりにすることもできパッド未使用スペース。特別なフラグは、ユーザデータに表示されている場合、フラグとして誤って解釈されることを回避する代替配列（FLAGより通常大きい）に逃げています。 PPPで使用されるHDLCベースのフレーミング方式は、このアプローチのすべての例です。
All three adaptation schemes introduce overhead; how much depends on the distribution of IP packet sizes, the size(s) of the SNDUs, and in the HDLC-like approaches, the content of the IP packet (since flag-like sequences occurring in the packet must be escaped, which expands them). The designer must also weigh implementation complexity and performance in the choice and design of an adaptation layer.
すべての3つの適応方式は、オーバーヘッドをご紹介します。どのくらいSNDUsの大きさ（S）は、IPパケットサイズの分布に依存し、HDLCのようなアプローチ、IPパケットの内容（パケットにおいて発生フラグ様配列は、膨張する、エスケープされなければならないためそれら）。設計者はまた、アダプテーション層の選択や設計に実装の複雑さと性能を比較検討しなければなりません。
IP has no notion of a "connection"; it is a purely connectionless protocol. When a connection is required by an application, it is usually provided by TCP [RFC793], the Transmission Control Protocol, running atop IP on an end-to-end basis.
IPは、「接続」の概念がありません。それは純粋にコネクションレスプロトコルです。接続がアプリケーションによって要求される場合、それは通常、エンドツーエンドベースでIPの上に実行されている、TCP [RFC793]、伝送制御プロトコルによって提供されます。
Connection-oriented subnetworks can be (and are widely) used to carry IP, but often with considerable complexity. Subnetworks consisting of few nodes can simply open a permanent connection between each pair of nodes. This is frequently done with ATM. However, the number of connections increases as the square of the number of nodes, so this is clearly impractical for large subnetworks. A "shim" layer between IP and the subnetwork is therefore required to manage connections. This is one of the most common functions of a Subnetwork Dependent Convergence Function (SNDCF) sublayer between IP and a subnetwork.
コネクション指向のサブネットワークがあること（そして広くしている）ことができますIPを運ぶために使用されるが、多くの場合、かなりの複雑さを持ちます。少数のノードからなるサブネットワークは、単に、ノードの各対の間の永続的な接続を開くことができます。これは、頻繁にATMで行われます。しかし、接続の数はノード数の二乗として増加するので、これは明らかに大きなサブネットワークのために非実用的です。 IPサブネットワーク間の「シム」層は、そのための接続を管理する必要があります。これは、IPサブネットワークとの間でサブネットワーク依存収束機能（SNDCF）副層の最も一般的な機能の一つです。
SNDCFs typically open subnetwork connections as needed when an IP packet is queued for transmission and close them after an idle timeout. There is no relation between subnetwork connections and any connections that may exist at higher layers (e.g., TCP).
IPパケットが送信用にキューに入れられ、アイドルタイムアウト後にそれらを閉じているときに、必要に応じSNDCFs通常のオープンサブネットワークコネクション。サブネットワーク接続と上位レイヤ（例えば、TCP）に存在し得る任意の接続との間には関係がありません。
Because Internet traffic is typically bursty and transaction-oriented, it is often difficult to pick an optimal idle timeout. If the timeout is too short, subnetwork connections are opened and closed rapidly, possibly over-stressing the subnetwork connection management system (especially if it was designed for voice traffic call holding times). If the timeout is too long, subnetwork connections are idle much of the time, wasting any resources dedicated to them by the subnetwork.
インターネットトラフィックは通常、バースト性とトランザクション指向であるため、最適なアイドルタイムアウトを選択することが困難な場合が多いです。タイムアウトが短すぎると、サブネットワーク接続が開かれ、おそらく過強調（それは音声トラフィックの呼び出し回数を保持するために設計された場合は特に）、サブネットワーク接続管理システムを、急速に閉じました。タイムアウトが長すぎる場合、サブネットワーク接続は、サブネットワークによってそれらに専用の任意のリソースを無駄に、多くの時間アイドル状態になっています。
Purely connectionless subnets (such as Ethernet), which have no state and dynamically share resources, are optimal for supporting best-effort IP, which is stateless and dynamically shares resources. Connection-oriented packet networks (such as ATM and Frame Relay), which have state and dynamically share resources, are less optimal, since best-effort IP does not benefit from the overhead of creating and maintaining state. Connection-oriented circuit-switched networks (including the PSTN and ISDN) have state and statically allocate resources for a call, and thus require state creation and maintenance overhead, but do not benefit from the efficiencies of statistical multiplexing sharing of capacity inherent in IP.
状態がないし、動的にリソースを共有（イーサネットなど）純粋にコネクションレスのサブネットは、ステートレスで、動的にリソースを共有するベストエフォート型のIPをサポートするために最適です。ベストエフォートIPを作成し、状態を維持するオーバーヘッドの恩恵を受けていないので、状態を持っており、動的にリソースを共有する（例えばATMやフレームリレーなど）の接続指向のパケットネットワークは、、より最適です。 （PSTNおよびISDN含む）コネクション型の回線交換網は、状態を持っており、静的呼び出しのためのリソースを割り当て、ひいては国家の作成とメンテナンスのオーバーヘッドを必要とするが、IPに固有の能力の統計多重共有の効率化の恩恵を受けません。
In any event, if an SNDCF that opens and closes subnet connections is used to support IP, care should be taken to make sure that connection processing in the subnet can keep up with relatively short holding times.
サブネットの接続を開閉するSNDCFは、IPをサポートするために使用されている場合いずれにせよ、ケアは、サブネット内の接続処理が比較的短い保持時間に追いつくことができていることを確認するために取られるべきです。
Subnetworks fall into two categories: point-to-point and shared. A point-to-point subnet has exactly two endpoint components (hosts or routers); a shared link has more than two endpoint components, using either an inherently broadcast medium (e.g., Ethernet, radio) or a switching layer hidden from the network layer (e.g., switched Ethernet, Myrinet [MYR95], ATM). Switched subnetworks handle broadcast by copying broadcast packets, providing each interface that supports one, or more, systems (hosts or routers) with a copy of each packet.
ポイントツーポイントおよび共有：サブネットワークは、2つのカテゴリに分類されます。ポイントツーポイントサブネットはちょうど二つのエンドポイントのコンポーネント（ホスト又はルータ）を有します。共有リンクは、本質的に放送媒体（例えば、イーサネット、無線）、またはネットワーク層から隠さスイッチング層のいずれかを使用して、二つ以上のエンドポイントの構成要素を有している（例えば、イーサネット（登録商標）、Myrinetの[MYR95]、ATM交換）。切り替えサブネットワークは、ブロードキャストパケットをコピーし、各パケットのコピーを一つ又はそれ以上の、システム（ホスト又はルータ）をサポートする各インタフェースを提供することによって、放送ハンドル。
Several Internet protocols for IPv4 make use of broadcast capabilities, including link-layer address lookup (ARP), auto-configuration (RARP, BOOTP, DHCP), and routing (RIP).
IPv4のためのいくつかのインターネットプロトコルはリンク層アドレス検索（ARP）、自動構成（RARP、BOOTP、DHCP）、およびルーティング（RIP）を含むブロードキャスト機能、を利用します。
A lack of broadcast capability can impede the performance of these protocols, or render them inoperable (e.g., DHCP). ARP-like link address lookup can be provided by a centralized database, but at the expense of potentially higher response latency and the need for nodes to have explicit knowledge of the ARP server address. Shared links should support native, link-layer subnet broadcast.
ブロードキャスト機能の欠如は、これらのプロトコルのパフォーマンスを妨げる、またはそれら動作不能（例えば、DHCP）をレンダリングすることができます。 ARPのようなリンク・アドレス・ルックアップは、集中データベースが提供するが、潜在的に高い応答遅延とノードがARPサーバーアドレスの明示的な知識を持っている必要性を犠牲にすることができます。共有リンクは、ネイティブ、リンク層サブネットブロードキャストをサポートする必要があります。
A corresponding set of IPv6 protocols uses multicasting (see next section) instead of broadcasting to provide similar functions with improved scaling in large networks.
IPv6プロトコルの対応するセットは、大規模ネットワークにおける改善されたスケーリングと同様の機能を提供する代わりに、放送の（次のセクションを参照）マルチキャストを使用します。
The Internet model includes "multicasting", where IP packets are sent to all the members of a multicast group [RFC1112] [RFC3376] [RFC2710]. Multicast is an option in IPv4, but a standard feature of IPv6. IPv4 multicast is currently used by multimedia, teleconferencing, gaming, and file distribution (web, peer-to-peer sharing) applications, as well as by some key network and host protocols (e.g., RIPv2, OSPF, NTP). IPv6 additionally relies on multicast for network configuration (DHCP-like autoconfiguration) and link-layer address discovery [RFC2461] (replacing ARP). In the case of IPv6, this can allow autoconfiguration and address discovery to span across routers, whereas the IPv4 broadcast-based services cannot without ad-hoc router support [RFC1812].
インターネットモデルでは、IPパケットがマルチキャストグループのすべてのメンバーに送信された「マルチキャスティング」、[RFC1112] [RFC3376] [RFC2710]を含んでいます。マルチキャストは、IPv4のオプションが、IPv6の標準機能です。 IPv4マルチキャストは、現在だけでなく、いくつかの主要なネットワークおよびホストプロトコルによって、マルチメディア、電話会議、ゲーム、ファイル配信（ウェブ、ピアツーピア共有）アプリケーションによって使用される（例えば、RIPv2の、OSPF、NTP）。 IPv6は、さらに、ネットワーク設定（DHCPのような自動設定）とリンク層アドレス発見[RFC2461]（ARPを交換）するためのマルチキャストに依存しています。 IPv6の場合には、これは、IPv4ブロードキャストベースのサービスは、アドホックルータのサポート[RFC1812]なしにはできないのに対し、自動設定やアドレスの発見は、ルーターにまたがるできるようにすることができます。
Multicast-enabled IP routers organize each multicast group into a spanning tree, and route multicast packets by making copies of each multicast packet and forwarding the copies to each output interface that includes at least one downstream member of the multicast group.
マルチキャスト対応のIPルータの各マルチキャストパケットのコピーを作成し、マルチキャストグループの少なくとも一つの下流側部材を含む各出力インタフェースにコピーを転送することによって、スパニングツリーに各マルチキャストグループを編成し、ルートマルチキャストパケット。
Multicasting is considerably more efficient when a subnetwork explicitly supports it. For example, a router relaying a multicast packet onto an Ethernet segment need send only one copy of the packet, no matter how many members of the multicast group are connected to the segment. Without native multicast support, routers and switches on shared links would need to use broadcast with software filters, such that every multicast packet sent incurs software overhead for every node on the subnetwork, even if a node is not a member of the multicast group. Alternately, the router would transmit a separate copy to every member of the multicast group on the segment, as is done on multicast-incapable switched subnets.
サブネットワークが明示的にサポートしているとき、マルチキャストはかなり効率的です。たとえば、イーサネットセグメント上にマルチキャストパケットを中継するルータは関係なく、セグメントに接続されているどのように多くのマルチキャストグループのメンバー、パケットのコピーを1つだけ送信しない必要があります。ネイティブマルチキャストサポートがなければ、ルータと共有リンクを上のスイッチは、ソフトウェアフィルタとブロードキャストを使用する必要があり、すべてのマルチキャストパケットが送信されるように、ノードがマルチキャストグループのメンバーでない場合でも、サブネットワーク上のすべてのノードのためのソフトウェアのオーバーヘッドが発生します。代替的に、ルータは、マルチキャスト非対応切り替えサブネット上に行われているように、セグメント上のマルチキャストグループのすべてのメンバに別々のコピーを送信するであろう。
Subnetworks using shared channels (e.g., radio LANs, Ethernets) are especially suitable for native multicasting, and their designers should make every effort to support it. This involves designating a section of the subnetwork's own address space for multicasting. On these networks, multicast is basically broadcast on the medium, with Layer-2 receiver filters.
（例えば、ラジオのLAN、イーサネット）共有チャネルを用いたサブネットワークは、ネイティブマルチキャスティングのために特に適しており、その設計者はそれをサポートするためにあらゆる努力をするべきです。これは、マルチキャストのためのサブネットワーク自身のアドレス空間の部分を指定する必要。これらのネットワークでは、マルチキャストは、基本的には、レイヤ2の受信フィルタと、メディアで放送されます。
Subnet interfaces also need to be designed to accept packets addressed to some number of multicast addresses, in addition to the unicast packets specifically addressed to them. The number of multicast addresses that needs to be supported by a host depends on the requirements of the associated host; at least several dozen will meet most current needs.
サブネット・インターフェースはまた、パケットは、具体的には、それらに宛てたユニキャストパケットに加えて、マルチキャストアドレスの一部番号宛て受け入れるように設計される必要があります。ホストによってサポートされる必要がマルチキャストアドレスの数は、関連するホストの要件によって異なります。少なくとも数十は、ほとんどの現在のニーズを満たします。
On low-speed networks, the multicast address recognition function may be readily implemented in host software, but on high-speed networks, it should be implemented in subnetwork hardware. This hardware need not be complete; for example, many Ethernet interfaces implement a "hashing" function where the IP layer receives all of the multicast (and unicast) traffic to which the associated host subscribes, plus some small fraction of multicast traffic to which the host does not subscribe. Host/router software then has to discard the unwanted packets that pass the Layer-2 multicast address filter [RFC1112].
低速ネットワークでは、マルチキャストアドレス認識機能を容易にホストソフトウェアで実装されてもよいが、高速ネットワークでは、サブネットワークハードウェアに実装されるべきです。このハードウェアは、完全である必要はありません。例えば、多くのイーサネットインターフェイスは、IP層が関連付けられているすべてのホストが加入、プラスマルチキャストトラフィックのいくつかの小さな画分は、ホストが加入していないためにマルチキャスト（ユニキャスト）トラフィックの受信「ハッシュ」機能を実現します。ホスト/ルータソフトウェアは、レイヤ2マルチキャストアドレスフィルタ[RFC1112]を通過し、不要なパケットを破棄しなければなりません。
There does not need to be a one-to-one mapping between a Layer-2 multicast address and an IP multicast address. An address overlap may significantly degrade the filtering capability of a receiver's hardware multicast address filter. A subnetwork supporting only broadcast should use this service for multicast and must rely on software filtering.
レイヤ2マルチキャストアドレスとIPマルチキャストアドレスの間に1対1のマッピングがあるように必要はありません。アドレス重複を大幅に受信機のハードウェアマルチキャストアドレスフィルタの濾過能力を低下させることができます。唯一のブロードキャストをサポートするサブネットワークがマルチキャストのため、このサービスを使用する必要があり、ソフトウェアのフィルタリングに依存する必要があります。
Switched subnetworks must also provide a mechanism for copying multicast packets to ensure the packets reach at least all members of a multicast group. One option is to "flood" multicast packets in the same manner as broadcast. This can lead to unnecessary transmissions on some subnetwork links (notably non-multicast-aware Ethernet switches). Some subnetworks therefore allow multicast filter tables to control which links receive packets belonging to a specific group. To configure this automatically requires access to Layer-3 group membership information (e.g., IGMP [RFC3376], or MLD [RFC2710]). Various implementation options currently exist to provide a subnet node with a list of mappings of multicast addresses to ports/interfaces. These employ a range of approaches, including signaling from end hosts (e.g., IEEE 802 GARP/GMRP [802.1p]), signaling from switches (e.g., CGMP [CGMP] and RGMP [RFC3488]), interception and proxy of IP group membership packets (e.g., IGMP/MLD Proxy [MAGMA-PROXY]), and enabling Layer-2 devices to snoop/inspect/peek into forwarded Layer-3 protocol headers (e.g.,
スイッチドサブネットワークは、パケットがマルチキャストグループの少なくともすべてのメンバーに届くことを確認するために、マルチキャストパケットをコピーするためのメカニズムを提供しなければなりません。 1つのオプションは、放送と同様に「洪水」のマルチキャストパケットにあります。これは、いくつかのサブリンク（特に非マルチキャスト対応のイーサネットスイッチ）上の不要な送信につながることができます。いくつかのサブネットワークは、したがって、特定のグループに属するパケットを受信リンクするマルチキャストフィルタテーブルを制御することができます。これは自動的にレイヤ3グループメンバーシップ情報（例えば、IGMP [RFC3376]、またはMLD [RFC2710]）へのアクセスを必要と設定します。様々な実装オプションは、現在のポート/インターフェースへのマルチキャストアドレスのマッピングのリストをサブネットノードを提供することに存在します。これらは、エンドホストからのシグナリングを含む、アプローチの範囲を使用する（例えば、IEEE 802 GARP / GMRP [802.1P]）、スイッチからのシグナリング（例えば、CGMP [CGMP]とRGMP [RFC3488]）、傍受及びIPグループメンバシップのプロキシパケット（例えば、IGMP / MLDプロキシ[MAGMA-PROXY]）、及び転送レイヤ3プロトコルヘッダ（例えば、内覗く/検査/スヌープするレイヤ2デバイスを可能にします
IGMP, MLD, PIM) so that they may infer Layer-3 multicast group membership [MAGMA-SNOOP]. These approaches differ in their complexity, flexibility, and ability to support new protocols.
IGMP、MLD、PIM）は、レイヤ3マルチキャストグループメンバーシップ[MAGMAスヌープ]を推測することができるようになっています。これらのアプローチは、その複雑さ、柔軟性、および新しいプロトコルをサポートする機能が異なります。
Some subnets allow a number of subnet nodes to share a channel efficiently by assigning transmission opportunities dynamically. Transmission opportunities are requested by a subnet node when it has packets to send. The subnet schedules and grants transmission opportunities sufficient to allow the transmitting subnet node to send one or more packets (or packet fragments). We call these subnets Bandwidth on Demand (BoD) subnets. Examples of BoD subnets include Demand Assignment Multiple Access (DAMA) satellite and terrestrial wireless networks, IEEE 802.11 point coordination function (PCF) mode, and DOCSIS. A connection-oriented network (such as the PSTN, ATM or Frame Relay) reserves resources on a much longer timescale, and is therefore not a BoD subnet in our taxonomy.
いくつかのサブネットは、サブネットノードの数が動的に送信機会を割り当てることによって、効率的にチャネルを共有することを可能にします。送信機会は、それが送信するパケットを持っているサブネットノードにより要求されます。送信サブネットノードは、1つまたは複数のパケット（又はパケットフラグメント）を送信するのに十分なサブネットスケジュールおよびグラント送信機会。私たちは、需要量（BOD）のサブネット上のこれらのサブネットの帯域幅を呼び出します。 BODサブネットの例は、オンデマンド割り当て多重アクセス（DAMA）衛星と地上無線ネットワーク、IEEE 802.11ポイント調整機能（PCF）モード、及びDOCSISを含みます。 （例えばPSTN、ATMやフレームリレーのような）接続指向のネットワーク埋蔵資源はるかに長い時間スケールで、したがって私たちの分類でのBODサブネットではありません。
The design parameters for BoD are similar to those in connection-oriented subnetworks, although the implementations may vary significantly. In BoD, the user typically requests access to the shared channel for some duration. Access may be allocated for a period of time at a specific rate, for a certain number of packets, or until the user releases the channel. Access may be coordinated through a central management entity or with a distributed algorithm amongst the users. Examples of the resource that may be shared include a terrestrial wireless hop, an upstream channel in a cable television system, a satellite uplink, and an end-to-end satellite channel.
実装が大幅に変化し得るが取締役会のための設計パラメータは、コネクション指向のサブネットワークと同様です。取締役会では、ユーザは、典型的には、いくつかの期間のための共有チャネルへのアクセスを要求します。アクセスは、パケットの特定の数のために、特定の速度で時間の期間のために割り当てられた、又はユーザまでのチャネルを解放することができます。アクセスは、中央管理エンティティを介して、またはユーザの間で分散アルゴリズムを用いて調整することができます。共有されるリソースの例としては、地上無線ホップ、ケーブルテレビシステム、衛星アップリンク、およびエンドツーエンドの衛星チャネルにおけるアップストリームチャネルを含みます。
Long-delay BoD subnets pose problems similar to connection-oriented subnets in anticipating traffic. While connection-oriented subnets hold idle channels open expecting new data to arrive, BoD subnets request channel access based on buffer occupancy (or expected buffer occupancy) on the sending port. Poor performance will likely result if the sender does not anticipate additional traffic arriving at that port during the time it takes to grant a transmission request. It is recommended that the algorithm have the capability to extend a hold on the channel for data that has arrived after the original request was generated (this may be done by piggybacking new requests on user data).
長期遅延のBODサブネットは、トラフィックを予想におけるコネクション指向のサブネットに同様の問題を提起します。コネクション型サブネットが到着する新しいデータを期待して空きチャネルが開いて保持しながら、取締役会のサブネットは、送信ポート上のバッファ占有率（または予想されるバッファ占有量）に基づいてチャネルアクセスを要求します。送信者は、それが送信要求を許可するのにかかる時間の間、そのポートに到着する追加のトラフィックを予想していない場合、パフォーマンスの低下はおそらくなります。これは、アルゴリズムは、元の要求が生成された後に到着したデータのためのチャネル上のホールドを延長する能力を持つことをお勧めします（これは、ユーザデータの新しい要求をピギーバックすることによって行うことができます）。
There is a wide variety of BoD protocols available. However, there has been relatively little comprehensive research on the interactions between BoD mechanisms and Internet protocol performance. Research on some specific mechanisms is available (e.g., [AR02]). One item that has been studied is TCP's retransmission timer [KY02]. BoD
利用可能取締役会のさまざまなプロトコルがあります。ただし、取締役会の仕組みとインターネットプロトコルのパフォーマンスの間の相互作用の比較的少ない総合的な研究が行われています。いくつかの特定のメカニズムに関する研究が利用可能である（例えば、[AR02]）。研究されている1つの項目は、TCPの再送タイマ[KY02]です。取締役会
systems can cause spurious timeouts when adjusting from a relatively high data rate, to a relatively low data rate. In this case, TCP's transmitted data takes longer to get through the network than predicted by the TCP sender's computed retransmission timeout. Therefore, the TCP sender is prone to resending a segment prematurely.
比較的高いデータ・レートから調整するときのシステムは、比較的低いデータレートに、スプリアスタイムアウトが発生する可能性があります。この場合、TCPの送信データは、TCP送信者の計算された再送タイムアウトによって予測よりも、ネットワークを介して取得に時間がかかります。そのため、TCPの送信者は早まってセグメントを再送する傾向があります。
In the Internet architecture, the ultimate responsibility for error recovery is at the end points [SRC81]. The Internet may occasionally drop, corrupt, duplicate, or reorder packets, and the transport protocol (e.g., TCP) or application (e.g., if UDP is used as the transport protocol) must recover from these errors on an end-to-end basis [RFC3155]. Error recovery in the subnetwork is therefore justifiable only to the extent that it can enhance overall performance. It is important to recognize that a subnetwork can go too far in attempting to provide error recovery services in the Internet environment. Subnet reliability should be "lightweight", i.e., it only has to be "good enough", *not* perfect.
インターネットアーキテクチャでは、エラー回復のための最終的な責任は、エンドポイント[SRC81]です。インターネットは時折、落下、破損、複製、またはパケットの順序を変更、およびトランスポートプロトコル（例えば、TCP）または（UDPはトランスポートプロトコルとして使用されている場合など、）アプリケーションのエンドツーエンドベースでこれらのエラーから回復しなければならないことがあり[RFC3155]。サブネットワーク内のエラー回復は、それが全体のパフォーマンスを向上させることができます程度のため、正当です。サブネットワークは、インターネット環境でエラー復旧サービスを提供しようとするにはあまりにも遠くに行くことができることを認識することが重要です。サブネットの信頼性は、すなわち、それだけで、「十分に良い」* *完璧ではないことがあり、「軽量」でなければなりません。
In this section, we discuss how to analyze characteristics of a subnetwork to determine what is "good enough". The discussion below focuses on TCP, which is the most widely-used transport protocol in the Internet. It is widely believed (and is a stated goal within the IETF) that non-TCP transport protocols should attempt to be "TCP-friendly" and have many of the same performance characteristics. Thus, the discussion below should be applicable, even to portions of the Internet where TCP may not be the predominant protocol.
このセクションでは、「十分」であるかを決定するためにサブネットワークの特性を分析する方法について説明します。以下の説明は、インターネットで最も広く使用されているトランスポートプロトコルであるTCP、に焦点を当てています。広く非TCPトランスポートプロトコルは「TCPフレンドリー」であることを試み、同じパフォーマンス特性の多くを持つべきであると考えられ（およびIETF内で定められた目標である）されます。したがって、以下の説明でもTCPが優勢なプロトコルではないかもしれないインターネットの部分に、適用可能であるべきです。
Error recovery involves the generation and transmission of redundant information computed from user data. Depending on how much redundant information is sent and how it is generated, the receiver can use it to reliably detect transmission errors, correct up to some maximum number of transmission errors, or both. The general approach is known as Error Control Coding, or ECC.
エラー回復は、生成およびユーザデータから計算された冗長な情報の送信を含みます。送信され、それがどのように生成されるか、受信機が確実に伝送エラーを検出するために使用することができるどのくらいの冗長情報に応じて、伝送エラー、または両方の何らかの最大数まで訂正します。一般的なアプローチは、エラー制御符号化、またはECCとして知られています。
The use of ECC to detect transmission errors so that retransmissions (hopefully without errors) can be requested is widely known as "ARQ" (Automatic Repeat Request).
（うまくいけばエラーなし）の再送信を要求することができるように、伝送エラーを検出するために、ECCの使用は、広く「ARQ」（自動再送要求）として知られています。
When enough ECC information is available to permit the receiver to correct some transmission errors without a retransmission, the approach is known as Forward Error Correction (FEC). Due to the greater complexity of the required ECC and the need to tailor its design to the characteristics of a specific modem and channel, FEC has traditionally been implemented in special-purpose hardware integral to a modem. This effectively makes it part of the physical layer.
十分なECC情報が再送することなく、いくつかの伝送エラーを訂正するために受信機を可能にするのに利用可能である場合、アプローチは、前方誤り訂正（FEC）として知られています。必要なECCのより複雑かつ特定のモデムとチャネルの特性にその設計を調整する必要があるため、FECは、伝統的に、モデムと一体の専用のハードウェアで実装されています。これは、効果的、物理層の一部になります。
Unlike ARQ, FEC was rarely used for telecommunications outside of space links prior to the 1990s. It is now nearly universal in telephone, cable and DSL modems, digital satellite links, and digital mobile telephones. FEC is also heavily used in optical and magnetic storage where "retransmissions" are not possible.
ARQとは異なり、FECはめったに外1990年代の前にスペースリンクの通信のために使用されませんでした。それは今、電話、ケーブルやDSLモデム、デジタル衛星リンク、およびデジタル携帯電話ではほぼ普遍的です。 FECも重く、「再送信」はできません、光磁気記憶装置に使用されています。
Some systems use hybrid combinations of ARQ layered atop FEC; V.90 dialup modems (in the upstream direction) with V.42 error control are one example. Most errors are corrected by the trellis (FEC) code within the V.90 modem, and most remaining errors are detected and corrected by the ARQ mechanisms in V.42.
いくつかのシステムでは、FECの上に積層ARQのハイブリッドな組み合わせを使用します。 V.42エラー制御と（上流方向）V.90ダイヤルアップモデムは一例です。ほとんどのエラーは、V.90モデム内のトレリス（FEC）符号により補正され、最も残りのエラーが検出され、V.42にARQメカニズムによって補正されます。
Work is now underway to apply FEC above the physical layer, primarily in connection with reliable multicasting [RFC3048] [RFC3450-RFC3453] where conventional ARQ mechanisms are inefficient or difficult to implement. However, in this discussion, we will assume that if FEC is present, it is implemented within the physical layer.
仕事は、主に信頼性の高いマルチキャスト[RFC3048]従来のARQメカニズムが非効率または実装することは困難である[RFC3450、RFC3453]に関連して、物理層の上にFECを適用することが現在進行中です。しかし、この議論では、我々は、FECが存在する場合、それは物理層内に実装されていると仮定します。
Depending on the layer in which it is implemented, error control can operate on an end-to-end basis or over a shorter span, such as a single link. TCP is the most important example of an end-to-end protocol that uses an ARQ strategy.
それが実装されている層に応じて、エラー制御は、単一のリンクとして、エンドツーエンドベースでまたはより短いスパンで動作することができます。 TCPは、ARQ戦略を使用して、エンドツーエンドのプロトコルの最も重要な例です。
Many link-layer protocols use ARQ, usually some flavor of HDLC [ISO3309]. Examples include the X.25 link layer, the AX.25 protocol used in amateur packet radio, 802.11 wireless LANs, and the reliable link layer specified in IEEE 802.2.
多くのリンク層プロトコルはARQ、HDLC [ISO3309]の通常いくつかのフレーバーを使用します。例としては、X.25リンク層、アマチュアパケット無線で使用AX.25プロトコル、802.11無線LAN、およびIEEE 802.2で指定された信頼性の高いリンク層を含みます。
Only end-to-end error recovery can ensure reliable service to the application (see Section 8). However, some subnetworks (e.g., many wireless links) also have link-layer error recovery as a performance enhancement [RFC3366]. For example, many cellular links have small physical frame sizes (< 100 bytes) and relatively high frame loss rates. Relying solely on end-to-end error recovery can clearly yield a performance degradation, as retransmissions across the end-to-end path take much longer to be received than when link layer retransmissions are used. Thus, link-layer error recovery can often increase end-to-end performance. As a result, link-layer and end-to-end recovery often co-exist; this can lead to the possibility of inefficient interactions between the two layers of ARQ protocols.
唯一のエンドツーエンドのエラー回復がアプリケーションに信頼性の高いサービスを確保することができます（セクション8を参照）。しかし、いくつかのサブネットワーク（例えば、多くの無線リンク）も、性能向上[RFC3366]などのリンク層エラー回復を有します。例えば、多くのセルラーリンクが小さな物理フレームサイズ（<100バイト）と、比較的高いフレーム損失率を有します。エンドツーエンドのパス間で再送信がリンク層の再送が使用されている場合よりも受信することが非常に長い時間がかかるようなエンドツーエンドのエラー回復のみに依存することは明らかに、パフォーマンスの低下をもたらすことができます。このように、リンク層のエラー回復は、多くの場合、エンドツーエンドのパフォーマンスを向上させることができます。その結果、リンク層とエンドツーエンドの回復しばしば共存します。これは、ARQプロトコルの2つの層の間の非効率的な相互作用の可能性をもたらすことができます。
This inter-layer "competition" might lead to the following wasteful situation. When the link layer retransmits (parts of) a packet, the link latency momentarily increases. Since TCP bases its retransmission timeout on prior measurements of total end-to-end latency, including that of the link in question, this sudden increase in latency may trigger an unnecessary retransmission by TCP of a packet that the link layer is still retransmitting. Such spurious end-to-end retransmissions generate unnecessary load and reduce end-to-end throughput. As a result, the link layer may even have multiple copies of the same packet in the same link queue at the same time. In general, one could say the competing error recovery is caused by an inner control loop (link-layer error recovery) reacting to the same signal as an outer control loop (end-to-end error recovery) without any coordination between the loops. Note that this is solely an efficiency issue; TCP continues to provide reliable end-to-end delivery over such links.
この層間「競争」とは、以下の無駄な状況につながる可能性があります。リンク層（の一部）パケットを再送信するとき、リンク・レイテンシは、瞬間的に増大します。 TCPは、当該リンクのことを含む全エンドツーエンド待ち時間の測定前に、その再送タイムアウトを基づかせているので、待ち時間のこの突然の増加は、リンク層がまだ再送されたパケットのTCPによる不要な再送をトリガすることができます。そのような偽のエンドツーエンドの再送信は、不要な負荷を生成し、エンドツーエンドのスループットを低下させます。その結果、リンク層であっても、同じ時間に同じリンクキュー内の同じパケットの複数のコピーを有することができます。一般に、一方が競合エラー回復がループ間の任意の調整なし外部制御ループ（エンド・ツー・エンドのエラー回復）と同じ信号に反応する内部制御ループ（リンク層エラー回復）によるものであると言うことができます。これは、単に効率の問題であることに注意してください。 TCPは、そのようなリンクの上に信頼性の高いエンドツーエンドの配信を提供し続けています。
This raises the question of how persistent a link-layer sender should be in performing retransmission [RFC3366]. We define the link-layer (LL) ARQ persistency as the maximum time that a particular link will spend trying to transfer a packet before it can be discarded. This deliberately simplified definition says nothing about the maximum number of retransmissions, retransmission strategies, queue sizes, queuing disciplines, transmission delays, or the like. The reason we use the term LL ARQ persistency, instead of a term such as "maximum link-layer packet holding time," is that the definition closely relates to link-layer error recovery. For example, on links that implement straightforward error recovery strategies, LL ARQ persistency will often correspond to a maximum number of retransmissions permitted per link-layer frame.
これは、リンク層の送信者が再送信[RFC3366]を実行するにはどうあるべきか、永続の問題を提起します。私たちは、特定のリンクは、それが破棄される前にパケットを転送しようとして過ごすことになることを最大時間としてリンク層（LL）ARQの永続性を定義します。この意図的に簡略化定義は、最大再送回数、再送戦略、キューサイズ、規律をキューイング、伝送遅延等については何も言いません。代わりのような用語の我々は長期LLのARQの永続性を使用する理由は、「最大リンク層パケット保持時間は、」定義が密接にリンク層エラー回復に関連することです。例えば、簡単なエラー回復戦略を実装するリンクで、LL ARQの持続性は、多くの場合、リンク層フレームごとに許可再送信の最大数に対応させていただきます。
For link layers that do not or cannot differentiate between flows (e.g., due to network layer encryption), the LL ARQ persistency should be small. This avoids any harmful effects or performance degradation resulting from indiscriminate high persistence. A detailed discussion of these issues is provided in [RFC3366].
または（原因ネットワーク層暗号化に、例えば）のフローを区別することはできませんていないリンク層のために、LLのARQの永続性は小さくすべきです。これは、任意の有害な影響や無差別高い持続性に起因する性能の低下を回避することができます。これらの問題の詳細な議論は[RFC3366]で提供されています。
However, when a link layer can identify individual flows and apply ARQ selectively [LKJK02], then the link ARQ persistency should be high for a flow using reliable unicast transport protocols (e.g., TCP) and must be low for all other flows. Setting the link ARQ persistency larger than the largest link outage allows TCP to rapidly restore transmission without needing to wait for a retransmission time out. This generally improves TCP performance in the face of transient outages. However, excessively high persistence may be disadvantageous; a practical upper limit of 30-60 seconds may be desirable. Implementation of such schemes remains a research issue. (See also the following section "Recovery from Subnetwork Outages").
しかしながら、リンク層は、個々のフローを識別し、ARQを適用することができたときに選択[LKJK02]、リンクARQ永続性は、信頼性の高いユニキャストトランスポートプロトコル（例えば、TCP）を使用して、流れのために高くなければならないし、他のすべてのフローに低くなければなりません。最大のリンク停止よりも大きな持続リンクARQを設定すると、TCPは急速に再送タイムアウトを待つ必要がなく、送信を復元することができます。これは、一般的に、過渡停止の顔にTCPのパフォーマンスが向上します。しかし、過度に高い持続性は不利であってもよいです。 30〜60秒の実用的な上限は望ましいかもしれません。そのようなスキームの実装は、研究課題のまま。 （また、次のセクション「サブネットワークの停止からのリカバリ」を参照してください）。
Many subnetwork designers have opportunities to reduce the probability of packet loss, e.g., with FEC, ARQ, and interleaving, at the cost of increased delay. TCP performance improves with decreasing loss but worsens with increasing end-to-end delay, so it is important to find the proper balance through analysis and simulation.
多くのサブネットワークの設計者は増加遅延のコストで、FEC、ARQ、およびインターリーブで、例えば、パケット損失の確率を低減する機会を持っています。 TCPの性能は損失の減少とともに向上しますが、エンドツーエンド遅延の増加に伴って悪化するので、解析およびシミュレーションにより適切なバランスを見つけることが重要です。
Some types of subnetworks, particularly mobile radio, are subject to frequent temporary outages. For example, an active cellular data user may drive or walk into an area (such as a tunnel) that is out of range of any base station. No packets will be delivered successfully until the user returns to an area with coverage.
サブネットワーク、特に移動無線の種類によっては、頻繁に一時的な停電の対象となっています。例えば、活性セルラーデータユーザが駆動することができる、または任意の基地局の範囲外である（例えば、トンネルのような）エリアに入ります。ユーザーはカバレッジと地域に戻るまで何パケットが正常に配信されません。
The Internet protocols currently provide no standard way for a subnetwork to explicitly notify an upper layer protocol (e.g., TCP) that it is experiencing an outage rather than severe congestion.
インターネットプロトコルは、現在、明示的に停止ではなく、重度の輻輳が発生して上位層プロトコル（例えば、TCP）を通知するサブネットワークのための標準的な方法を提供しません。
Under these circumstances TCP will, after each unsuccessful retransmission, wait even longer before trying again; this is its "exponential back-off" algorithm. Furthermore, TCP will not discover that the subnetwork outage has ended until its next retransmission attempt. If TCP has backed off, this may take some time. This can lead to extremely poor TCP performance over such subnetworks.
このような状況下ではTCPは、各失敗した再送信した後、再試行する前に、より長く待つことになります。これは、「指数バックオフ」アルゴリズムです。さらに、TCPは、サブネットワークの停止は、その次の再試行まで終了したことを検出しません。 TCPがオフに裏打ちされた場合、これは時間がかかる場合があります。これは、サブネットワークの上に極めて悪いTCPのパフォーマンスにつながることができます。
It is therefore highly desirable that a subnetwork subject to outages does not silently discard packets during an outage. Ideally, the subnetwork should define an interface to the next higher layer (i.e., IP) that allows it to refuse packets during an outage, and to automatically ask IP for new packets when it is again able to deliver them. If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the outage ends. When packets are discarded, IP should be notified so that the appropriate ICMP messages can be sent.
停止対象のサブネットワークは、サイレント停止中にパケットを廃棄しないことが非常に望ましいです。理想的には、サブネットワークは、それが停止中のパケットを拒否することができます次の上位層（すなわち、IP）へのインタフェースを定義する必要があり、再びそれらを提供することができたときに自動的に新しいパケットにIPを依頼します。それがこれを行うことができない場合は、サブネットワークは、停電時に、それが受け入れたパケットの少なくとも一部の上に保持し、停電が終了したときにそれらを提供しようとしなければなりません。パケットが破棄された場合、適切なICMPメッセージを送ることができるように、IPを通知する必要があります。
Note that it is *not* necessary to completely avoid dropping packets during an outage. The purpose of holding onto a packet during an outage, either in the subnetwork or at the IP layer, is so that its eventual delivery will implicitly notify TCP that the subnetwork is again operational. This is to enhance performance, not to ensure reliability -- reliability, as discussed earlier, can only be ensured on an end-to-end basis.
完全に停止時にパケットを落とさないように* *必要はないことに注意してください。その最終的な送達は、暗黙的にサブネットワークが再び動作しているTCPに通知するようにサブネットワークまたはIP層のいずれかで、停止中のパケットに保持する目的です。前述したようにのみエンドツーエンドで確保することができ、信頼性 - これがない信頼性を確保するため、パフォーマンスを向上させることです。
Only a few packets per TCP connection, including ACKs, need be held in this way to cause the TCP sender to recover from the additional losses once the flow resumes [RFC3366].
ACKを含むTCPコネクションあたりわずか数パケットは、フローは[RFC3366]を再開したら、TCPの送信者は、追加の損失から回復させるため、このように開催される必要があります。
Because it would be a layering violation (and possibly a performance hit) for IP or a subnetwork layer to look at TCP headers (which would in any event be impossible if IPsec encryption [RFC2401] is in use), it would be reasonable for the IP or subnetwork layers to choose, as a design parameter, some small number of packets that will be retained during an outage.
それは（IPsec暗号化[RFC2401]が使用されている場合は任意のイベントでは不可能であろう）TCPヘッダを見てIPまたはサブネットワーク層のためのレイヤー違反（そしておそらくパフォーマンスヒット）となりますので、それがために合理的ですIPまたはサブレイヤーを選択するには、設計パラメータとして、停電時に保持されるパケットのいくつかの小さな数。
The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all use the same simple 16-bit 1's complement checksum algorithm [RFC1071] to detect corrupted packets. The IPv4 header checksum protects only the IPv4 header, while the TCP, ICMP, and UDP checksums provide end-to-end error detection for both the transport pseudo header (including network and transport layer information) and the transport payload data. Protection of the data is optional for applications using UDP [RFC768] for IPv4, but is required for IPv6.
TCPは、[RFC793]、UDP [RFC768]、ICMP、とIPv4 [RFC791]のプロトコルすべてが破損したパケットを検出するために、同じシンプルな16ビットの1の補数チェックサムアルゴリズム[RFC1071]を使用します。 TCP、ICMP、およびUDPチェックサムは、（ネットワークおよびトランスポート層情報を含む）輸送疑似ヘッダとトランスポートペイロードデータの両方のためのエンドツーエンドのエラー検出を提供しながら、IPv4ヘッダチェックサムは、唯一のIPv4ヘッダを保護します。データの保護は、IPv4のUDP [RFC768]を使用して、アプリケーションのためのオプションであるが、IPv6のために必要とされます。
The Internet checksum is not very strong from a coding theory standpoint, but it is easy to compute in software, and various proposals to replace the Internet checksums with stronger checksums have failed. However, it is known that undetected errors can and do occur in packets received by end hosts [SP2000].
インターネットチェックサムは、符号理論の観点から非常に強力ではありませんが、ソフトウェアで計算しやすく、より強力なチェックサムでのインターネットチェックサムを置き換えるために、様々な提案が失敗しています。しかし、検出されないエラーがとエンドホスト[SP2000]によって受信されたパケットに発生したことが知られています。
To reduce processing costs, IPv6 has no IP header checksum. The destination host detects "important" errors in the IP header, such as the delivery of the packet to the wrong destination. This is done by including the IP source and destination addresses (pseudo header) in the computation of the checksum in the TCP or UDP header, a practice already performed in IPv4. Errors in other IPv6 header fields may go undetected within the network; this was considered a reasonable price to pay for a considerable reduction in the processing required by each router, and it was assumed that subnetworks would use a strong link CRC.
処理コストを削減するために、IPv6は何のIPヘッダのチェックサムを持っていません。宛先ホストは、このような誤った宛先へのパケットの配信などIPヘッダ内の「重要」のエラーを検出します。これは、TCPまたはUDPヘッダ内のチェックサムの計算にIP送信元アドレスと宛先アドレス（疑似ヘッダ）を含むことにより、既にIPv4の実行練習を行っています。他のIPv6ヘッダフィールド内のエラーは、ネットワーク内で検出されないことができます。これは、各ルータが必要とする処理を大幅に削減するために支払うために合理的な価格と考えられていた、そしてそれは、サブネットワークが強いリンクCRCを使用すると仮定しました。
One way to provide additional protection for an IPv4 or IPv6 header is by the authentication and packet integrity services of the IP Security (IPsec) protocol [RFC2401]. However, this may not be a choice available to the subnetwork designer.
IPv4またはIPv6ヘッダのための追加の保護を提供する1つの方法は、IPセキュリティ（IPsec）のプロトコル[RFC2401]の認証とパケット整合性サービスです。しかし、これはサブネットワークの設計者が利用可能な選択肢ではないかもしれません。
Most subnetworks implement error detection just above the physical layer. Packets corrupted in transmission are detected and discarded before delivery to the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the minimum for error detection. This is significantly more robust against most patterns of errors than the 16-bit Internet checksum. Note that the error detection properties of a specific CRC code diminish with increasing frame size. The Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC
ほとんどのサブネットワークは、単に物理層の上のエラー検出を実現します。伝送中に破損したパケットを検出し、IP層への配信前に廃棄されています。 16ビット巡回冗長検査（CRC）は、通常、エラー検出のための最小値です。これは、16ビットのインターネットチェックサムよりもエラーのほとんどのパターンに対してはるかに堅牢です。特定CRC符号の誤り検出特性は、フレームサイズの増加に伴って減少することに留意されたいです。ポイントツーポイントプロトコル[RFC1662]は、16ビットCRCのサポートを必要と
for each link frame, with a 32-bit CRC as an option. (PPP is often used in conjunction with a dialup modem, which provides its own error control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM, FDDI, Token Ring, and PPP over SONET/SDH all use a 32-bit CRC. Many subnetworks can also use other mechanisms to enhance the error detection capability of the link CRC (e.g., FEC in dialup modems, mobile radio and satellite channels).
オプションとして、32ビットのCRCを有する各リンクフレーム用。 （PPPはしばしば独自のエラー制御を提供するダイヤルアップモデムと組み合わせて使用されています）。 SONET / SDH 802.3 /イーサネット（登録商標）を含む他のサブネットワーク、AAL5 / ATM、FDDI、トークンリング、およびPPPのすべては、32ビットのCRCを使用します。多くのサブネットワークは、リンクのCRCのエラー検出能力を強化するために他のメカニズムを使用することができる（例えば、FECダイヤルアップモデム、携帯ラジオ、衛星放送で）。
Any new subnetwork designed to carry IP should therefore provide error detection for each IP packet that is at least as strong as the 32-bit CRC specified in [ISO3309]. While this will achieve a very low undetected packet error rate due to transmission errors, it will not (and need not) achieve a very low packet loss rate as the Internet protocols are better suited to dealing with lost packets than to dealing with corrupted packets [SRC81].
IPを運ぶために設計された任意の新しいサブネットワークは、従って、[ISO3309]で指定された32ビットCRCと少なくとも同じくらい強力である各IPパケットのエラー検出を提供するべきです。これは、伝送エラーのために非常に低い検出されなかったパケットエラーレートを実現しますが、それはしません（とする必要はありません）、インターネット・プロトコルは、破損したパケットを扱うよりも、失われたパケットを扱うに適していますように非常に低いパケット損失率を達成SRC81]。
Packet corruption may be, and is, also caused by bugs in host and router hardware and software. Even if every subnetwork implemented strong error detection, it is still essential that end-to-end checksums are used at the receiving end host [SP2000].
パケットの破損があってもよく、また、ホストおよびルータハードウェアとソフトウェアのバグによって引き起こされます。すべてのサブネットワークが強力なエラー検出を実現したとしても、エンド・ツー・エンドのチェックサムが受信側ホスト[SP2000]で使用されていることをまだ必要不可欠です。
Designers of complex subnetworks consisting of internal links and packet switches should consider implementing error detection on an edge-to-edge basis to cover an entire SNDU (or IP packet). A CRC would be generated at the entry point to the subnetwork and checked at the exit endpoint. This may be used instead of, or in combination with, error detection at the interface to each physical link. An edge-to-edge check has the significant advantage of protecting against errors introduced anywhere within the subnetwork, not just within its transmission links. Examples of this approach include the way in which the Ethernet CRC-32 is handled by LAN bridges [802.1D]. ATM AAL5 [ITU-I363] also uses an edge-to-edge CRC-32.
内部リンクとパケットスイッチからなる複合サブネットワークの設計者は、全体SNDU（又はIPパケット）を覆うようにエッジ・ツー・エッジに基づいて、エラー検出の実装を検討すべきです。 CRCは、サブネットワークへのエントリポイントで発生して終了エンドポイントでチェックされます。この代わりに、または組み合わせて、各物理リンクへのインタフェースにおけるエラー検出とを用いてもよいです。端から端までのチェックだけではなく、その伝送リンク内、サブネットワーク内のどこにでも導入されたエラーに対する保護の重要な利点があります。このアプローチの例は、イーサネットCRC-32は、LANブリッジ[802.1D]によって処理される方法が挙げられます。 ATM AAL5 [ITU-I363]は、エッジ・ツー・エッジCRC-32を使用します。
Some specific applications may be tolerant of residual errors in the data they exchange, but removal of the link CRC may expose the network to an undesirable increase in undetected errors in the IP and transport headers. Applications may also require a high level of error protection for control information exchanged by protocols acting above the transport layer. One example is a voice codec, which is robust against bit errors in the speech samples. For such mechanisms to work, the receiving application must be able to tolerate receiving corrupted data. This also requires that an application uses a mechanism to signal that payload corruption is permitted and to indicate the coverage (headers and data) required to be protected by the subnetwork CRC. The UDP-Lite protocol [RFC3828] is the first Internet standards track transport protocol supporting partial payload protection. Receipt of corrupt data by arbitrary application protocols carries a serious danger that a subnet delivers data with errors that remain undetected by the application and hence corrupt the communicated data [SRC81].
いくつかの特定のアプリケーションは、交換するデータ中の残留エラーの寛容かもしれませんが、リンクCRCの除去は、IPおよびトランスポート・ヘッダーに検出されないエラーの望ましくない増加にネットワークを公開することがあります。また、アプリケーションは、トランスポート層の上に動作するプロトコルによって交換される制御情報のエラー、高レベルの保護を必要とするかもしれません。一例では、音声サンプルのビット誤りに対してロバストである音声コーデックです。そのようなメカニズムが機能するために、受信アプリケーションが破損データを受信した許容できなければなりません。これはまた、アプリケーションがそのペイロードの破損が許可され知らせるために、カバレッジサブネットCRCによって保護する必要が（ヘッダとデータ）を示すために、メカニズムを使用することを必要とします。 UDP-Liteのプロトコル[RFC3828]は、部分的ペイロードの保護を支持する第1のインターネット標準トラックトランスポートプロトコルです。任意のアプリケーションプロトコルによる破損データの受信は、サブネットが通信データ[SRC81]を適用することによって検出されない、従って壊れたままエラーが発生したデータを配信することを深刻な危険を運びます。
One of TCP's functions is end-host based congestion control for the Internet. This is a critical part of the overall stability of the Internet, so it is important that link-layer designers understand TCP's congestion control algorithms.
TCPの機能の一つは、インターネットのためのエンドホストベースの輻輳制御です。これは、インターネットの全体的な安定性の重要な部分ですので、リンク層の設計者は、TCPの輻輳制御アルゴリズムを理解することが重要です。
TCP assumes that, at the most abstract level, the network consists of links and queues. Queues provide output-buffering on links that are momentarily oversubscribed. They smooth instantaneous traffic bursts to fit the link bandwidth. When demand exceeds link capacity long enough to fill the queue, packets must be dropped. The traditional action of dropping the most recent packet ("tail dropping") is no longer recommended [RFC2309] [RFC2914], but it is still widely practiced.
TCPは最も抽象的なレベルでは、ネットワークはリンクとキューから構成さ、ということを前提としています。キューは一時的にオーバーサブスクライブされているリンク上で出力バッファリングを提供します。彼らは、なめらかな瞬間のトラフィックは、リンクの帯域幅に合わせてバースト。需要がキューを埋めるために十分な長リンク容量を超えた場合、パケットは廃棄されなければなりません。 （「テールドロップ」）の最新のパケットを落とすの伝統的なアクションは、もはや[RFC2309] [RFC2914]は推奨されていないが、それはまだ広く実施されています。
TCP uses sequence numbering and acknowledgments (ACKs) on an end-to-end basis to provide reliable, sequenced delivery. TCP ACKs are cumulative, i.e., each implicitly ACKs every segment received so far. If a packet with an unexpected sequence number is received, the ACK field in the packets returned by the receiver will cease to advance. Using an optional enhancement, TCP can send selective acknowledgments (SACKs) [RFC2018] to indicate which segments have arrived at the receiver.
TCPは、信頼性の高い、配列を決定送達を提供するために、エンドツーエンドベースでシーケンス番号と確認応答（ACKを）使用しています。 TCP ACKはそれぞれ、暗黙すべてのセグメントは、これまでに受信したACK、すなわち、累積的です。予想外のシーケンス番号を持つパケットを受信した場合、受信側によって返されたパケット内のACKフィールドには、事前に中止します。オプションの拡張を使用して、TCPは、受信機に到着しているセグメントを示すために、選択的肯定応答（サック）[RFC2018]を送ることができます。
Since the most common cause of packet loss is congestion, TCP treats packet loss as an indication of potential Internet congestion along the path between TCP end hosts. This happens automatically, and the subnetwork need not know anything about IP or TCP. A subnetwork node simply drops packets whenever it must, though some packet-dropping strategies (e.g., RED) are more fair to competing flows than others.
パケット損失の最も一般的な原因は、輻輳があるので、TCPはTCPのエンドホスト間のパスに沿ったポテンシャルインターネット輻輳の指標としてパケットロスを扱います。これは自動的に行われ、サブネットワークは、IPやTCPについて何を知っている必要はありません。サブネットワーク・ノードは、単にパケットをドロップしたときに、それがなければならない、いくつかのパケットドロップ戦略（例えば、RED）が他よりもフローを競争により公平あるけれども。
TCP recovers from packet losses in two different ways. The most important mechanism is the retransmission timeout. If an ACK fails to arrive after a certain period of time, TCP retransmits the oldest unacked packet. Taking this as a hint that the network is congested, TCP waits for the retransmission to be ACKed before it continues, and it gradually increases the number of packets in flight as long as a timeout does not occur again.
TCPは、2つの異なる方法でのパケット損失から回復します。最も重要なメカニズムは、再送タイムアウトです。 ACKは、一定期間後に到着しなかった場合、TCPは最も古いunackedパケットを再送します。ネットワークが輻輳していることをヒントとしてこれを取る、TCPは、それが継続する前にACKされるべき再送を待ち、それが徐々に限りタイムアウトが再び発生しないように飛行中のパケットの数を増加させます。
A retransmission timeout can impose a significant performance penalty, as the sender is idle during the timeout interval and restarts with a congestion window of one TCP segment following the timeout. To allow faster recovery from the occasional lost packet in a bulk transfer, an alternate scheme, known as "fast recovery", was introduced [RFC2581] [RFC2582] [RFC2914] [TCPF98].
送信者がタイムアウト次の1つのTCPセグメントの輻輳ウィンドウでタイムアウト間隔と再起動の間アイドル状態であるように再送タイムアウトは、大幅なパフォーマンスのペナルティを課すことができます。バルク転送で時折失われたパケットからの迅速な復旧を可能にするには、「高速回復」として知られている別のスキームは、導入された[RFC2581] [RFC2582] [RFC2914] [TCPF98]。
Fast recovery relies on the fact that when a single packet is lost in a bulk transfer, the receiver continues to return ACKs to subsequent data packets that do not actually acknowledge any newly-received data. These are known as "duplicate acknowledgments" or "dupacks". The sending TCP can use dupacks as a hint that a packet has been lost and retransmit it without waiting for a timeout. Dupacks effectively constitute a negative acknowledgment (NAK) for the packet sequence number in the acknowledgment field. TCP waits until a certain number of dupacks (currently 3) are seen prior to assuming a loss has occurred; this helps avoid an unnecessary retransmission during out-of-sequence delivery.
高速回復は、単一のパケットがバルク転送で失われたとき、受信機は、実際にどの新しく受信したデータを確認していない後続のデータパケットにACKを返すように続けているという事実に依存しています。これらは、「重複確認応答」または「dupacks」として知られています。送信TCPパケットが失われたことをヒントとしてdupacks使用し、タイムアウトを待たずに、それを再送することができます。 Dupacksを効果的に確認応答フィールドでパケットシーケンス番号のために否定応答（NAK）を構成します。 dupacks（現在3）の特定の数は、損失が発生したと仮定する前に見られるまで、TCP待機します。これはアウトオブシーケンス配信中の不要な再送信を回避するのに役立ちます。
A technique called "Explicit Congestion Notification" (ECN) [RFC3168] allows routers to directly signal congestion to hosts without dropping packets. This is done by setting a bit in the IP header. Since ECN support is likely to remain optional, the lack of an ECN bit must *never* be interpreted as a lack of congestion. Thus, for the foreseeable future, TCP must interpret a lost packet as a signal of congestion.
「明示的輻輳通知」（ECN）[RFC3168]と呼ばれる技術は、ルータがパケットを直接落とすことなくホストに輻輳を通知することを可能にします。これは、IPヘッダ内のビットをセットすることによって行われます。 ECNのサポートは、オプションのままにする可能性があるので、ECNビットの欠如は、* *混雑の欠如と解釈してはなりません。このように、予見可能な将来のために、TCPは輻輳の信号として失われたパケットを解釈する必要があります。
The TCP "congestion avoidance" [RFC2581] algorithm maintains a congestion window (cwnd) controlling the amount of data TCP may have in flight at any moment. Reducing cwnd reduces the overall bandwidth obtained by the connection; similarly, raising cwnd increases performance, up to the limit of the available capacity.
TCP「輻輳回避」は、[RFC2581]は、アルゴリズムは、任意の瞬間に飛行中に有していてもよいデータTCPの量を制御する輻輳ウィンドウ（CWND）を維持します。 cwndを減らすとの接続によって得られた全体の帯域幅を減少させ、同様に、CWNDを上げると利用可能な容量の限界まで、性能を向上させます。
TCP probes for available network capacity by initially setting cwnd to one or two packets and then increasing cwnd by one packet for each ACK returned from the receiver. This is TCP's "slow start" mechanism. When a packet loss is detected (or congestion is signaled by other mechanisms), cwnd is reset to one and the slow start process is repeated until cwnd reaches one half of its previous setting before the reset. Cwnd continues to increase past this point, but at a much slower rate than before. If no further losses occur, cwnd will ultimately reach the window size advertised by the receiver.
最初に一つまたは二つのパケットにCWNDを設定し、各ACKのための1つのパケットによってCWNDを増加させることによって利用可能なネットワーク容量のためのTCPプローブは、受信機から戻さ。これは、TCPの「スロースタート」メカニズムです。パケットロスが検出された（又は輻輳が他のメカニズムによって信号伝達される）場合、CWNDが1にリセットされ、CWNDがリセット前に前回の設定の半分に達するまでスロースタートプロセスが繰り返されます。 CWNDは、この点を過ぎて増加し続けますが、以前よりもはるかに遅い速度で。それ以上の損失が発生しない場合、cwndのは、最終的には受信機によって広告ウィンドウサイズに到達します。
This is an "Additive Increase, Multiplicative Decrease" (AIMD) algorithm. The steep decrease of cwnd in response to congestion provides for network stability; the AIMD algorithm also provides for fairness between long running TCP connections sharing the same path.
これは、「添加物の増加、乗算減少」（AIMD）アルゴリズムです。輻輳に応答してCWNDの急激な減少は、ネットワークの安定性を提供します。 AIMDアルゴリズムはまた、長い同じパスを共有してTCP接続を実行している間の公平性のために用意されています。
Caveat
警告
Here we present a current "state-of-the-art" understanding of TCP performance. This analysis attempts to characterize the performance of TCP connections over links of varying characteristics.
ここでは、TCPのパフォーマンスの現在の「最先端の」の理解を提示します。この分析は、様々な特性のリンク上のTCP接続のパフォーマンスを特徴づけるためにしようとします。
Link designers may wish to use the techniques in this section to predict what performance TCP/IP may achieve over a new link-layer design. Such analysis is encouraged. Because this is a relatively new analysis, and the theory is based on single-stream TCP connections under "ideal" conditions, it should be recognized that the results of such analysis may differ from actual performance in the Internet. That being said, we have done our best to provide the designers with helpful information to get an accurate picture of the capabilities and limitations of TCP under various conditions.
リンク設計者はどのようなパフォーマンスTCPを予測するには、このセクションの技術を使用することをお勧めします/ IPは、新しいリンク層設計上達成することができます。このような分析が奨励されています。これは比較的新しい分析し、理論は「理想的な」条件の下で、単一ストリームTCPコネクションに基づいているため、そのような分析の結果は、インターネットでの実際の業績と異なる場合がありますことを認識すべきです。言われていることを、私たちは様々な条件下でのTCPの機能と制限の正確な画像を取得するために役立つ情報を設計者に提供するために最善を行っています。
The performance of TCP's AIMD Congestion Avoidance algorithm has been extensively analyzed. The current best formula for the performance of the specific algorithms used by Reno TCP (i.e., the TCP specified in [RFC2581]) is given by Padhye, et al. [PFTK98]. This formula is:
TCPのAIMD輻輳回避アルゴリズムの性能は、広範囲に分析されています。リノTCPによって使用される特定のアルゴリズムの性能のための現在の最良の式（すなわち、[RFC2581]で指定されたTCPは）らPadhye、によって与えられます。 【PFTK98]。この式は、次のとおりです。
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
where
どこ
BW is the maximum TCP throughout achievable by an
individual TCP flow
MSS is the TCP segment size being used by the connection
RTT is the end-to-end round trip time of the TCP connection
RTO is the packet timeout (based on RTT)
p is the packet loss rate for the path
(i.e., .01 if there is 1% packet loss)
Note that the speed of the links making up the Internet path does not explicitly appear in this formula. Attempting to send faster than the slowest link in the path causes the queue to grow at the transmitter driving the bottleneck. This increases the RTT, which in turn reduces the achievable throughput.
インターネットパスを構成するリンクの速度が明示的にこの式には表示されないことに注意してください。パス内の最も遅いリンクより速くを送信しようとすると、キューがボトルネックを駆動するトランスミッタで成長する原因となります。これは、順番に達成可能なスループットを低減RTTが増加します。
This is currently considered to be the best approximate formula for Reno TCP performance. A further simplification of this formula is generally made by assuming that RTO is approximately 5*RTT.
これは、現在、リノTCPのパフォーマンスのための最良の近似式であると考えられています。この式の更なる簡素化は、一般に、RTOは、約5×RTTであると仮定することによって行われます。
TCP is constantly being improved. A simpler formula, which gives an upper bound on the performance of any AIMD algorithm which is likely to be implemented in TCP in the future, was derived by Ott, et al. [MSMO97].
TCPは絶えず改善されています。将来的にはTCPに実装される可能性がある任意のAIMDアルゴリズムの性能の上限を与える単純な式は、、、らOTTで誘導しました。 【MSMO97]。
MSS 1
BW = C --- -------
RTT sqrt(p)
where C is 0.93.
Cは0.93です。
Both formulae assume that the TCP Receiver Window is not limiting the performance of the connection. Because the receiver window is entirely determined by end-hosts, we assume that hosts will maximize the announced receiver window to maximize their network performance.
どちらの式はTCP受信側ウィンドウの接続の性能を制限されていないことを前提としています。受信ウィンドウが完全にエンドホストによって決定されているので、私たちは、ホストは、ネットワークのパフォーマンスを最大化すると発表受信ウィンドウを最大化することを前提としています。
Both of these formulae allow BW to become infinite if there is no loss. However, an Internet path will drop packets at bottlenecked queues if the load is too high. Thus, a completely lossless TCP/IP network can never occur (unless the network is being underutilized).
これらの式のどちらも、損失がない場合はBWが無限になることができます。負荷が高すぎる場合は、インターネットパスがボトルネックキューでパケットをドロップします。 （ネットワークが十分に活用されていない限り）このように、完全にロスレスTCP / IPネットワークでは発生しないことができます。
The RTT used is the arithmetic average, including queuing delays.
RTTは、キューイング遅延を含む算術平均して、使用されます。
The formulae are for a single TCP connection. If a path carries many TCP connections, each will follow the formulae above independently.
式は、単一のTCP接続のためのものです。パスは、多くのTCPコネクションを運ぶ場合は、それぞれが独立して上記の式に従います。
The formulae assume long-running TCP connections. For connections that are extremely short (<10 packets) and don't lose any packets, performance is driven by the TCP slow-start algorithm. For connections of medium length, where on average only a few segments are lost, single connection performance will actually be slightly better than given by the formulae above.
式には、長時間実行されるTCP接続を前提としています。非常に短い（<10個のパケット）であり、任意のパケットを失うことはありません接続の場合、パフォーマンスはTCPスロースタートアルゴリズムによって駆動されます。平均してわずか数のセグメントが失われた媒体長さの接続のために、単一の接続のパフォーマンスは、実際、上記の式によって与えられるよりもわずかに良くなります。
The difference between the simple and complex formulae above is that the complex formula includes the effects of TCP retransmission timeouts. For very low levels of packet loss (significantly less than 1%), timeouts are unlikely to occur, and the formulae lead to very similar results. At higher packet losses (1% and above), the complex formula gives a more accurate estimate of performance (which will always be significantly lower than the result from the simple formula).
単純および複雑な式の違いは、上記複合式はTCP再送タイムアウトの影響を含むことです。パケット損失（有意に1％未満）の非常に低いレベルのために、タイムアウトが発生しにくい、及び式が非常に類似の結果をもたらします。より高いパケット損失（上記1％）で、複合式は（常に簡単な式の結果よりも有意に低いであろう）の性能のより正確な推定値を与えます。
Note that these formulae break down as p approaches 100%.
pが100％に近づくにつれて、これらの式を打破することに注意してください。
Consider the following example:
次の例を考えてみます。
A designer invents a new wireless link layer which, on average, loses 1% of IP packets. The link layer supports packets of up to 1040 bytes, and has a one-way delay of 20 msec.
設計者は、平均して、IPパケットの1％を失い、新たな無線リンク層を発明します。リンク層は、最大1040バイトのパケットをサポートしており、20ミリ秒の一方向遅延を持っています。
If this link were to be used on an Internet path with a round trip time greater than 80ms, the upper bound may be computed by:
このリンクは80ミリ秒よりも大きい往復時間とインターネットパス上で使用された場合は、上限がによって計算することができます。
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and TCP headers.
MSSの場合、最小IPv4およびTCPヘッダの40のバイトを除外するために1000バイトを使用します。
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec each way for the new wireless link).
RTTは、120ミリ秒（インターネット部80ミリ秒、20ミリ秒プラス新しい無線リンクのための各方法）を使用します。
For p, use .01. For C, assume 1.
Pについては、0.01を使用します。 Cの場合は、1を想定しています。
The simple formula gives:
簡単な式が得られます。
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
BW =（1,000×8ビット）/（0.120秒*のSQRT（0.01））= 666キロビット/秒
The more complex formula gives:
より複雑な式が得られます。
BW = 402.9 kbit/sec
BW = 402.9キロビット/秒
If this were a 2 Mb/s wireless LAN, the designers might be somewhat disappointed.
これは2 Mb /秒の無線LANであれば、設計者は、ややがっかりかもしれません。
Some observations on performance:
パフォーマンス上のいくつかの所見：
1. We have assumed that the packet losses on the link layer are interpreted as congestion by TCP. This is a "fact of life" that must be accepted.
1.当社は、リンク層でのパケット損失がTCPで輻輳として解釈されることを想定しています。これが受け入れられなければならない「人生の事実」です。
2. The equations for TCP performance are all expressed in terms of packet loss, but many subnetwork designers think in terms of bit-error ratio. *If* channel bit errors are independent, then the probability of a packet being corrupted is:
2. TCPのパフォーマンスのための方程式は、すべてのパケットロスで表現されているが、多くのサブネットワークの設計者は、ビット誤り率の観点から考えます。 *チャネルのビットエラーが独立している場合は*、その後、破壊されるパケットの確率は次のとおりです。
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
P = 1 - （[1 - BER] ^ [FRAME_SIZE * 8]）
Here we assume FRAME_SIZE is in bytes and "^" represents exponentiation. It includes the user data and all headers (TCP,IP and subnetwork). (Note: this analysis assumes the subnetwork does not perform ARQ or transparent fragmentation [RFC3366].) If the inequality
ここでは、FRAME_SIZEはバイト単位であり、「^」は、べき乗を表していると仮定します。これは、ユーザデータとすべてのヘッダー（TCP、IPサブネットワーク）が含まれています。 （注：この分析はARQ又は透明フラグメンテーション[RFC3366]を実行しないサブネットワークを想定している。）不等式場合
BER * [FRAME_SIZE*8] << 1
BER * [FRAME_SIZE * 8] << 1
holds, the packet loss probability p can be approximated by:
パケット損失確率pがで近似することができ、保持しています。
p = BER * [FRAME_SIZE*8]
P = BER * [FRAME_SIZE * 8]
These equations can be used to apply BER to the performance equations above.
これらの式は、上記のパフォーマンス方程式にBERを適用するために使用することができます。
Note that FRAME_SIZE can vary from one packet to the next. Small packets (such as TCP acks) generally have a smaller probability of packet error than, say, a TCP packet carrying one MSS (maximum segment size) of user data. A flow of small TCP acks can be expected to be slightly more reliable than a stream of larger TCP data segments.
FRAME_SIZEは1つのパケットから次へと変化することに注意してください。 （例えば、TCPのACKのような）小さなパケットは、一般に、ユーザデータのMSS（最大セグメントサイズ）を運ぶTCPパケット、たとえば、よりパケットエラーの小さい確率を有します。小さなTCPのACKの流れは、より大きなTCPデータセグメントのストリームよりもわずかにより信頼性が期待できます。
It bears repeating that the above analysis assumes that bit errors are statistically independent. Because this is not true for many real links, our computation of p is actually an upper bound, not the exact probability of packet loss.
なお、上記の分析は、ビットエラーが統計的に独立であると仮定していることを繰り返す負担します。これは、多くの実際のリンクには当てはまりませんので、Pの私たちの計算は、実際には、パケット損失の上限ではなく、正確な確率です。
There are many reasons why bit errors are not independent on real links. Many radio links are affected by propagation fading or by interference that lasts over many bit times. Also, links with Forward Error Correction (FEC) generally have very non-uniform bit error distributions that depend on the type of FEC, but in general the uncorrected errors tend to occur in bursts even when channel symbol errors are independent. In all such cases, our computation of p from BER can only place an upper limit on the packet loss rate.
ビットエラーは、実際のリンクで独立していない多くの理由があります。多くの無線リンクは、伝搬フェージングによって、または多くのビット時間にわたって持続干渉によって影響を受けます。また、前方誤り訂正（FEC）とのリンクは、一般に、FECのタイプに依存する非常に不均一なビットエラー分布を有するが、一般的に補正されていないエラーがチャネルシンボルエラーが独立している場合でも、バースト的に発生する傾向があります。すべてのそのような場合には、BERからのpの私たちの計算は、パケット損失率に上限を置くことができます。
If the distribution of errors under the FEC scheme is known, one could apply the same type of analysis as above, using the correct distribution function for the BER. It is more likely in these FEC cases, however, that empirical methods are needed to determine the actual packet loss rate.
FECスキームの下でのエラーの分布が知られている場合、一方がBERの正しい分布関数を用いて、上記のように分析の同じタイプを適用することができます。これは、経験的な方法は、実際のパケットロス率を決定するために必要であること、しかし、これらのFECのケースで可能性が高いです。
3. Note that the packet size plays an important role. If the subnetwork loss characteristics are such that large packets have the same probability of loss as smaller packets, then larger packets will yield improved performance.
パケットサイズが重要な役割を果たしていることに留意されたいです。サブ損失特性が大きなパケットを小さなパケットとして損失の同じ確率を有するようなものである場合には、より大きなパケットは、改善された性能をもたらします。
4. We have chosen a specific RTT that might occur on a wide-area Internet path within the USA. It is important to recognize that a variety of RTT values are experienced in the Internet.
4.私たちは、米国内の広域インターネットパス上で発生する可能性のある特定のRTTを選択しました。 RTT値の様々なインターネットで経験していることを認識することが重要です。
For example, RTTs are typically less than 10 msec in a wired LAN
environment when communicating with a local host. International
connections may have RTTs of 200 msec or more. Modems and other
low-capacity links can add considerable delay due to their long
packet transmission (serialisation) times.
Links over geostationary repeater satellites have one-way speed-of-light delays of around 250ms, a minimum of 125ms propagation delay up to the satellite and 125ms down. The RTT of an end-to-end TCP connection that includes such a link can be expected to be greater than 250ms.
静止中継衛星上のリンクは一方向速度の光の周りに250ミリ秒の遅延、ダウン衛星及び125msの最大125msの伝播遅延の最小値を有します。そのようなリンクを含むエンドツーエンドのTCPコネクションのRTTが250ミリ秒よりも大きくなることが期待できます。
Queues on heavily-congested links may back up, increasing RTTs. Finally, virtual private networks (VPNs) and other forms of encryption and tunneling can add significant end-to-end delay to network connections.
重く、輻輳したリンク上のキューは、のRTTが増加し、バックアップすることがあります。最後に、仮想プライベートネットワーク（VPN）と暗号化とトンネリングの他の形態は、ネットワーク接続に重要なエンド・ツー・エンドの遅延を追加することができます。
It is generally recognized that specific service guarantees are needed to support real-time multimedia, toll-quality telephony, and other performance-critical applications. The provision of such Quality of Service guarantees in the Internet is an active area of research and standardization. The IETF has not converged on a single service model, set of services, or single mechanism that will offer useful guarantees to applications and be scalable to the Internet. Indeed, the IETF does not have a single definition of Quality of Service. [RFC2990] represents a current understanding of the challenges in architecting QoS for the Internet.
一般的に、特定のサービス保証は、リアルタイムマルチメディア、トール品質電話、およびその他のパフォーマンス・クリティカルなアプリケーションをサポートするために必要であることが認識されています。インターネットでのサービス保証などの品質の提供は、研究と標準化の活性領域です。 IETFは、単一のサービスモデル、サービスのセット、またはアプリケーションに有益な保証を提供し、インターネットにスケーラブルになり、単一のメカニズムに収束していません。確かに、IETFは、サービス品質の単一の定義はありません。 [RFC2990]はインターネットのためのQoSを設計する際の課題の現在の理解を表します。
There are presently two architectural approaches to providing mechanisms for QoS support in the Internet.
インターネットでQoSをサポートするためのメカニズムを提供するには、2つのアーキテクチャのアプローチが現在あります。
IP Integrated Services (Intserv) [RFC1633] provides fine-grained service guarantees to individual flows. Flows are identified by a flow specification (flowspec), which creates a stateful association between individual packets by matching fields in the packet header. Capacity is reserved for the flow, and appropriate traffic conditioning and scheduling is installed in routers along the path. The ReSerVation Protocol (RSVP) [RFC2205] [RFC2210] is usually, but need not necessarily be, used to install the flow QoS state. Intserv defines two services, in addition to the Default (best effort) service.
IP統合サービス（IntServの）[RFC1633]は、個々のフローにきめ細かなサービス保証を提供します。フローは、パケットヘッダー内のフィールドを照合することによって、個々のパケット間のステートフルな関連付けを作成するフロー仕様（フロースペック）によって識別されます。容量は、フローのために予約され、そして適切なトラフィック調整およびスケジューリングは、経路に沿ってルータにインストールされています。予約プロトコル（RSVP）[RFC2205]、[RFC2210]は通常であるが、フローのQoS状態をインストールするために使用することは必ずしも必要はありません。イントサーブは、デフォルト（ベストエフォート）のサービスに加えて、2つのサービスを定義します。
1. Guaranteed Service (GS) [RFC2212] offers hard upper bounds on delay to flows that conform to a traffic specification (TSpec). It uses a fluid-flow model to relate the TSpec and reserved bandwidth (RSpec) to variable delay. Non-conforming packets are forwarded on a best-effort basis.
[RFC2212] 1.保証サービス（GS）は、トラフィック仕様（TSpecの）に準拠するフローに遅延にハード上限を提供しています。これは、可変遅延TSpecのと予約帯域幅（RSpecの）を関連する流体流モデルを使用します。不適合パケットは、ベストエフォート方式で転送されます。
2. Controlled Load Service (CLS) [RFC2211] offers delay and packet loss equivalent to that of an unloaded network to flows that conform to a TSpec, but no hard bounds. Non-conforming packets are forwarded on a best-effort basis.
2.制御ロード・サービス（CLS）[RFC2211]は、遅延やパケットロスTSpecのに適合フローに対する無負荷ネットワークと同等、ないハード限界を提供します。不適合パケットは、ベストエフォート方式で転送されます。
Intserv requires installation of state information in every participating router. Performance guarantees cannot be made unless this state is present in every router along the path. This, along with RSVP processing and the need for usage-based accounting, is believed to have scalability problems, particularly in the core of the Internet [RFC2208].
イントサーブは、すべての参加ルータの状態情報をインストールする必要があります。この状態は、パスに沿ったすべてのルータに存在しない限り、パフォーマンスの保証はできません。これは、RSVP処理や従量課金の必要性とともに、特にインターネット[RFC2208]のコアで、スケーラビリティの問題があると考えられています。
IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit" offering coarse-grained controls to aggregates of flows. Diffserv in itself does *not* provide QoS guarantees, but can be used to construct services with QoS guarantees across a Diffserv domain. Diffserv attempts to address the scaling issues associated with Intserv by requiring state awareness only at the edge of a Diffserv domain. At the edge, packets are classified into flows, and the flows are conditioned (marked, policed, or shaped) to a traffic conditioning specification (TCS). A Diffserv Codepoint (DSCP), identifying a per-hop behavior (PHB), is set in each packet header. The DSCP is carried in the DS-field, subsuming six bits of the former Type-of-Service (ToS) byte [RFC791] of the IP header [RFC2474]. The PHB denotes the forwarding behavior to be applied to the packet in each node in the Diffserv domain. Although there is a "recommended" DSCP associated with each PHB, the mappings from DSCPs to PHBs are defined by the DS-domain. In fact, there can be several DSCPs associated with the same PHB. Diffserv presently defines three PHBs.
IP差別化サービス（DiffServ）の[RFC2475]はフローの集合体に粗粒のコントロールを提供する「ツールキット」を提供します。それ自体はDiffserv * * QoS保証を提供しませんが、することはDiffservのドメイン間でQoS保証とサービスを構築するために使用することができます。 DiffServは唯一のDiffServドメインのエッジで状態の認識を必要とすることによってのIntServに関連付けられたスケーリングの問題に対処しようと試みます。エッジで、パケットが流れに分類され、そしてフローがトラフィック調整仕様（TCS）に調整（マークされ、ポリシング、または成形）されています。 Diffservのコードポイント（DSCP）は、ホップごとのふるまい（PHB）を識別する、各パケットのヘッダに設定されています。 DSCPは、前者のタイプオブサービス（TOS）[RFC791] IPヘッダ[RFC2474]のバイトの6ビットを包摂、DSフィールドで搬送されます。 PHBは、Diffservのドメイン内の各ノードでパケットに適用される転送動作を示しています。各PHBに関連付けられている「推奨」DSCPがあるが、PHBのへのDSCPからのマッピングは、DS-ドメインによって定義されています。実際には、同じPHBに関連するいくつかのDSCPがあることができます。 DiffServは現在、3つのPHBを定義します。
1. The class selector PHB [RFC2474] replaces the IP precedence field of the former ToS byte. It offers relative forwarding priorities.
1.クラスセレクタPHB [RFC2474]は前者のToSバイトのIP優先順位フィールドを置き換えます。これは、相対的な転送の優先順位を提供しています。
2. The Expedited Forwarding (EF) PHB [RFC3246] [RFC3248] guarantees that packets will have a well-defined minimum departure rate which, if not exceeded, ensures that the associated queues are short or empty. EF is intended to support services that offer tightly-bounded loss, delay, and delay jitter.
2.緊急転送（EF）PHB [RFC3246]、[RFC3248]はパケットを超えていない場合は、明確に定義された最小の出発速度を有するであろうことを保証する、関連するキューが短いか、空であることを保証します。 EFは、緊密に有界損失、遅延、および遅延ジッタを提供するサービスをサポートすることを目的としています。
3. The Assured Forwarding (AF) PHB group [RFC2597] offers different levels of forwarding assurance for each aggregated flow of packets. Each AF group is independently allocated forwarding resources. Packets are marked with one of three drop precedences; those with the highest drop precedence are dropped with lower probability than those marked with the lowest drop precedence. DSCPs are recommended for four independent AF groups, although a DS domain can have more or fewer AF groups.
3.保証転送（AF）PHB基[RFC2597]はパケットの各集約フローのための保証を転送するの異なるレベルを提供しています。各AF基は、独立して、転送リソースを割り当てられています。パケットは3つの廃棄優先順位の1が付いています。最高廃棄優先順位を持つものは最低の廃棄優先順位でマークされたものよりも低い確率でドロップされます。 DSドメインは、より多くのまたはより少ないAF基を有することができるが、DSCPをは、四つの独立AFグループのために推奨されています。
Ongoing work in the IETF is addressing ways to support Intserv with Diffserv. There is some belief (e.g., as expressed in [RFC2990]) that such an approach will allow individual flows to receive service guarantees and scale to the global Internet.
IETFで進行中の作業は、Diffservのでイントサーブをサポートする方法に取り組んでいます。いくつかの信念がある（例えば、[RFC2990]で表現されるように）そのようなアプローチは、個々のフローがグローバルなインターネットにサービス保証およびスケールを受け取ることを可能にすること。
The QoS guarantees that can be offered by the IP layer are a product of two factors:
IP層で提供できるQoS保証は、二つの要因の産物であります：
1. the concatenation of the QoS guarantees offered by the subnets along the path of a flow. This implies that a subnet may wish to offer multiple services (with different QoS guarantees) to the IP layer, which can then determine which flows use which subnet service. To put it another way, forwarding behavior in the subnet needs to be "clued" by the forwarding behavior (service or PHB) at the IP layer, and
流れの経路に沿ってサブネットが提供するQoS保証の1連結。これは、サブネットはその後、サブネットサービス利用を流れるかを決定することができますIP層に（異なるQoS保証付き）複数のサービスを提供することを望むかもしれないことを示唆しています。別の言い方をすると、サブネット内の転送動作は、IP層での転送動作（サービスまたはPHB）で「clued」する必要があり、
2. the operation of a set of cooperating mechanisms, such as bandwidth reservation and admission control, policy management, traffic classification, traffic conditioning (marking, policing and/or shaping), selective discard, queuing, and scheduling. Note that support for QoS in subnets may require similar mechanisms, especially when these subnets are general topology subnets (e.g., ATM, frame relay, or MPLS) or shared media subnets.
そのような帯域予約および入場制御、ポリシー管理、トラフィック分類、トラフィックコンディショニングとして協働機構の組の動作は2、選択的廃棄、キューイングおよびスケジューリング（マーキング、ポリシング、および/またはシェーピング）。これらのサブネットは、一般的なトポロジーサブネット（例えば、ATM、フレームリレー、またはMPLS）または共有メディアサブネットである場合は特に、サブネット内のQoSのその支持体は同様のメカニズムを必要とする場合があります。
Many subnetwork designers face inherent tradeoffs between delay, throughput, reliability, and cost. Other subnetworks have parameters that manage bandwidth, internal connection state, and the like. Therefore, the following subnetwork capabilities may be desirable, although some might be trivial or moot if the subnet is a dedicated point-to-point link.
多くのサブネットワークの設計者は、遅延、スループット、信頼性、およびコストの間の固有のトレードオフに直面しています。他のサブネットワークは、帯域幅、内部の接続状態などを管理するパラメータを持っています。サブネットは、専用のポイントツーポイントリンクである場合、いくつかの些細な又は議論の余地があるかもしれないため、次のサブ機能が、望ましいかもしれません。
1. The subnetwork should have the ability to reserve bandwidth for a connection or flow and schedule packets accordingly.
1.サブネットワークは、それに応じて接続またはフローのための帯域幅を予約する機能とスケジュールパケットを有していなければなりません。
2. Bandwidth reservations should be based on a one- or two-token bucket model, depending on whether the service is intended to support constant-rate or bursty traffic.
2.帯域幅の予約は、サービスが一定レートまたはバースト性トラフィックをサポートすることを意図しているかどうかに応じて、一次元又は二トークンバケットモデルに基づいている必要があります。
3. If a connection or flow does not use its reserved bandwidth at a given time, the unused bandwidth should be available for other flows.
3.接続またはフローが所定の時間にその予約帯域を使用しない場合、未使用の帯域幅は、他のフローのために利用可能であるべきです。
4. Packets in excess of a connection or flow's agreed rate should be forwarded as best-effort or discarded, depending on the service offered by the subnet to the IP layer.
接続またはフローの合意された割合を超える4.パケットはベストエフォート型として転送やIP層にサブネットが提供するサービスに応じて、破棄されなければなりません。
5. If a subnet contains error control mechanisms (retransmission and/or FEC), it should be possible for the IP layer to influence the inherent tradeoffs between uncorrected errors, packet losses, and delay. These capabilities at the subnet/IP layer service boundary correspond to selection of more or less error control and/or to selection of particular error control mechanisms within the subnetwork.
5.サブネットがエラー制御メカニズム（再送及び/又はFEC）が含まれている場合、それは未訂正のエラー、パケット損失、遅延の間の固有のトレードオフに影響を与えるIP層に可能であるべきです。サブネット/ IP層サービス境界でこれらの機能および/またはサブネットワーク内の特定の誤り制御機構の選択に多少誤り制御の選択に対応します。
6. The subnet layer should know, and be able to inform the IP layer, how much fixed delay and delay jitter it offers for a flow or connection. If the Intserv model is used, the delay jitter component may be best expressed in terms of the TSpec/RSpec model described in [RFC2212].
6.サブネット層は、それが流れたり、接続のために提供していますどのくらいの固定遅延と遅延ジッタ、知っている、とIP層に通知することができるはずです。 IntServモデルが使用される場合、遅延ジッタ成分は、最良[RFC2212]に記載TSpecの/ RSpecのモデルで表現することができます。
7. Support of the Diffserv class selectors [RFC2474] suggests that the subnet might consider mechanisms that support priorities.
DiffServクラスセレクタ[RFC2474]の7のサポートは、サブネットが優先順位をサポートする仕組みを検討するかもしれないことを示唆しています。
Subnetwork designers should be aware of the tradeoffs between fairness and efficiency inherent in many transmission scheduling algorithms. For example, many local area networks use contention protocols to resolve access to a shared transmission channel. These protocols represent overhead. While limiting the amount of data that a subnet node may transmit per contention cycle helps assure timely access to the channel for each subnet node, it also increases contention overhead per unit of data sent.
サブネットワークの設計者は、公平性と多くの送信スケジューリングアルゴリズムに固有の効率の間のトレードオフに注意する必要があります。例えば、多くのローカルエリアネットワークは、共有伝送チャネルへのアクセスを解決するために、競合プロトコルを使用します。これらのプロトコルは、オーバーヘッドを表しています。サブネットノードは各サブネットノードのチャネルへのタイムリーなアクセスを保証するのに役立つ競合サイクル当たりの送信できるデータの量を制限しながら、それはまた、送信されたデータの単位当たりの競合オーバーヘッドを増加させます。
In some mobile radio networks, capacity is limited by interference, which in turn depends on average transmitter power. Some receivers may require considerably more transmitter power (generating more interference and consuming more channel capacity) than others.
いくつかの移動無線ネットワークでは、容量が順番に平均送信電力に依存する干渉によって制限されます。いくつかの受信機は、他のものよりもかなり多くの送信電力（より多くの干渉を発生させ、より多くのチャネル容量を消費する）を必要とするかもしれません。
In each case, the scheduling algorithm designer must balance competing objectives: providing a fair share of capacity to each subnet node while maximizing the total capacity of the network. One approach for balancing performance and fairness is outlined in [ES00].
それぞれのケースにおいて、スケジューリングアルゴリズムの設計者は競合する目的のバランスをとる必要があります。ネットワークの総容量を最大化しながら、各サブネットのノードに容量の公正なシェアを提供します。パフォーマンスと公平性のバランスをとるための一つの方法は、[ES00]に概説されています。
The TCP sender bases its retransmission timeout (RTO) on measurements of the round trip delay experienced by previous packets. This allows TCP to adapt automatically to the very wide range of delays found on the Internet. The recommended algorithms are described in [RFC2988]. Evaluations of TCP's retransmission timer can be found in [AP99] and [LS00].
TCPの送信者は、前のパケットによって経験されたラウンドトリップ遅延の測定にその再送タイムアウト（RTO）を基づか。これは、TCPは、インターネット上で見つけ遅延の非常に広い範囲に自動的に適応することができます。推奨アルゴリズムは、[RFC2988]に記載されています。 TCPの再送タイマの評価は[AP99]と[LS00]で見つけることができます。
These algorithms model the delay along an Internet path as a normally-distributed random variable with a slowly-varying mean and standard deviation. TCP estimates these two parameters by exponentially smoothing individual delay measurements, and it sets the RTO to the estimated mean delay plus some fixed number of standard deviations. (The algorithm actually uses mean deviation as an approximation to standard deviation, because it is easier to compute.)
これらのアルゴリズムモデルゆっくり変化する平均値および標準偏差が正規分布ランダム変数としてインターネット経路に沿って遅延。 TCPは、指数関数的に個々の遅延測定を平滑化することによって、これら2つのパラメータを推定し、それが推定平均遅延と標準偏差のいくつかの固定数にRTOを設定します。 （計算が容易であるので、アルゴリズムは、実際に、標準偏差の近似として、平均偏差を使用します。）
The goal is to compute an RTO that is small enough to detect and recover from packet losses while minimizing unnecessary ("spurious") retransmissions when packets are unexpectedly delayed but not lost. Although these goals conflict, the algorithm works well when the delay variance along the Internet path is low, or the packet loss rate is low.
目標は、パケットが予想外に遅れたが失われていない場合、不要な（「偽」）の再送信を最小限に抑えながら検出し、パケット損失から回復するために十分に小さいRTOを計算することです。これらの目標の競合がインターネット経路に沿って、遅延分散が低い場合、またはパケット損失率が低い場合には、このアルゴリズムはうまく動作します。
If the path delay variance is high, TCP sets an RTO that is much larger than the mean of the measured delays. If the packet loss rate is low, the large RTO is of little consequence, as timeouts occur only rarely. Conversely, if the path delay variance is low, then TCP recovers quickly from lost packets; again, the algorithm works well. However, when delay variance and the packet loss rate are both high, these algorithms perform poorly, especially when the mean delay is also high.
パス遅延の変動が大きい場合は、TCPは、測定された遅延の平均値よりもはるかに大きいRTOを設定します。パケットロス率が低い場合はタイムアウトがまれにしか発生しないよう、大規模RTOは、少しの結果です。パス遅延分散が低い場合は逆に、その後、TCPが失われたパケットから迅速に回復します。再び、このアルゴリズムはうまく動作します。しかし、遅延分散とパケット損失率の両方が高い場合、これらのアルゴリズムは、平均遅延も高い場合は特に、十分に機能しません。
Because TCP uses returning acknowledgments as a "clock" to time the transmission of additional data, excessively high delays (even if the delay variance is low) also affect TCP's ability to fully utilize a high-speed transmission pipe. It also slows the recovery of lost packets, even when delay variance is small.
TCPは、追加データの伝送時に「時計」として戻って確認応答を使用しているため、過度に高い遅延が（遅延分散が低い場合であっても）にも完全に高速伝送パイプを利用するTCPの能力に影響を与えます。また、遅延分散が小さい場合であっても、失われたパケットの回復が遅くなります。
Subnetwork designers should therefore minimize all three parameters (delay, delay variance, and packet loss) as much as possible.
サブネットワークの設計者は、したがって、可能な限りすべての3つのパラメータ（遅延、遅延変動、及びパケットロス）を最小化する必要があります。
In many subnetworks, these parameters are inherently in conflict. For example, on a mobile radio channel, the subnetwork designer can use retransmission (ARQ) and/or forward error correction (FEC) to trade off delay, delay variance, and packet loss in an effort to improve TCP performance. While ARQ increases delay variance, FEC does not. However, FEC (especially when combined with interleaving) often increases mean delay, even on good channels where ARQ retransmissions are not needed and ARQ would not increase either the delay or the delay variance.
多くのサブネットワークでは、これらのパラメータは、紛争中に本質的にあります。例えば、移動無線チャネル上で、サブネットワーク設計者は、TCPの性能を改善するために遅延、遅延変動、及びパケットロスをトレードオフする再送（ARQ）及び/又は前方誤り訂正（FEC）を使用することができます。 ARQは、遅延変動を大きくしながら、FECはしていません。しかし、（インターリーブと組み合わせて特に）FECは、多くの場合でも、ARQの再送が必要とされていない良いチャンネルで、遅延を意味増加し、ARQは、遅延や遅延変動のいずれかを増加させないでしょう。
The tradeoffs among these error control mechanisms and their interactions with TCP can be quite complex, and are the subject of much ongoing research. We therefore recommend that subnetwork designers provide as much flexibility as possible in the implementation of these mechanisms, and provide access to them as discussed above in the section on Quality of Service.
これらのエラー制御機構とTCPとの相互作用の間のトレードオフは非常に複雑であること、そして多くの進行中の研究の対象となっていることができます。したがって、我々は、サブネットワークの設計者は、これらのメカニズムの実装では、できるだけ多くの柔軟性を提供することをお勧めしますし、サービス品質に関するセクションで前述したようにそれらへのアクセスを提供します。
Some subnetworks may provide asymmetric bandwidth (or may cause TCP packet flows to experience asymmetry in the capacity) and the Internet protocol suite will generally still work fine. However, there is a case when such a scenario reduces TCP performance. Since TCP data segments are "clocked" out by returning acknowledgments, TCP senders are limited by the rate at which ACKs can be returned [BPK98]. Therefore, when the ratio of the available capacity of the Internet path carrying the data to the bandwidth of the return path of the acknowledgments is too large, the slow return of the ACKs directly impacts performance. Since ACKs are generally smaller than data segments, TCP can tolerate some asymmetry, but as a general rule, designers of subnetworks should be aware that subnetworks with significant asymmetry can result in reduced performance, unless issues are taken to mitigate this [RFC3449].
いくつかのサブネットワークが非対称の帯域幅を提供することができる（またはTCPパケットの容量が非対称性を体験して流れて発生することがあり）、インターネットプロトコルスイートは、一般的にまだ正常に動作します。しかし、このようなシナリオは、TCPのパフォーマンスが低下する場合があります。 TCPデータセグメントが肯定応答を返すことによって「クロックされる」ので、TCP送信者は、ACKが[BPK98]戻すことができる速度によって制限されます。したがって、肯定応答のリターンパスの帯域幅にデータを搬送するインターネットパスの利用可能な容量の割合が多すぎると、ACKを直接影響性能のスローリターン。 ACKがデータセグメントよりも一般的に小さいので、TCPは、いくつかの非対称性を許容することができるが、問題は、この[RFC3449]を軽減するためにとられない限り、原則として、サブネットワークの設計者は、有意な非対称性を持つサブネットワークが性能低下をもたらすことができることに注意すべきです。
Several strategies have been identified for reducing the impact of asymmetry of the network path between two TCP end hosts, e.g., [RFC3449]. These techniques attempt to reduce the number of ACKs transmitted over the return path (low bandwidth channel) by changes at the end host(s), and/or by modification of subnetwork packet forwarding. While these solutions may mitigate the performance issues caused by asymmetric subnetworks, they do have associated cost and may have other implications. A fuller discussion of strategies and their implications is provided in [RFC3449].
いくつかの戦略は、例えば、[RFC3449]を2つのTCPエンドホスト間のネットワークパスの非対称性の影響を低減するために同定されています。これらの技術は、エンドホストでの変化（S）で、および/またはサブパケット転送の修飾によってリターンパス（低帯域幅チャネル）を介して送信ACKの数を削減することを試みます。これらのソリューションは、非対称サブネットワークに起因するパフォーマンスの問題を軽減するかもしれないが、彼らは関連するコストを持っていますし、他の意味を持っていることがあります。戦略とその影響のより完全な議論は[RFC3449]で提供されています。
Many subnets include multiple links with varying traffic demands and possibly different transmission speeds. At each link there must be a queuing system, including buffering, scheduling, and a capability to discard excess subnet packets. These queues may also be part of a subnet flow control or congestion control scheme.
多くのサブネットは、様々な交通需要と、おそらく異なる伝送速度を持つ複数のリンクが含まれています。各リンクでは、バッファリング、スケジューリング、および過剰サブネットのパケットを破棄する機能など、キューイング・システム、存在しなければなりません。これらのキューはまた、サブネットフロー制御や輻輳制御方式の一部であってもよいです。
For the purpose of this discussion, we talk about packets without regard to whether they refer to a complete IP packet or a subnetwork frame. At each queue, a packet experiences a delay that depends on competing traffic and the scheduling discipline, and is subjected to a local discarding policy.
この議論の目的のために、我々は、彼らが完全なIPパケットまたはサブフレームを参照しているかどうかに関係なく、パケットについて話しています。各キューには、パケットが競合するトラフィックとスケジューリング規律に依存遅延が発生し、ローカル廃棄ポリシーに供されます。
Some subnets may have flow or congestion control mechanisms in addition to packet dropping. Such mechanisms can operate on components in the subnet layer, such as schedulers, shapers, or discarders, and can affect the operation of IP forwarders at the edges of the subnet. However, with the exception of Explicit Congestion Notification [RFC3168] (discussed below), IP has no way to pass explicit congestion or flow control signals to TCP.
いくつかのサブネットには、パケット廃棄に加えて、流れや輻輳制御機構を有することができます。このような機構は、スケジューラ、シェーパ、又はdiscardersとしてサブネット層中の成分、上で動作することができ、およびサブネットのエッジでIPフォワーダの動作に影響を与えることができます。しかし、明示的輻輳通知の例外[RFC3168]（後述）と、IPは明示的輻輳を渡すか、TCPに制御信号を流す方法がありません。
TCP traffic, especially aggregated TCP traffic, is bursty. As a result, instantaneous queue depths can vary dramatically, even in nominally stable networks. For optimal performance, packets should be dropped in a controlled fashion, not just when buffer space is unavailable. How much buffer space should be supplied is still a matter of debate, but as a rule of thumb, each node should have enough buffering to hold one link_bandwidth*link_delay product's worth of data for each TCP connection sharing the link.
TCPトラフィック、特に集約TCPトラフィックは、バースト性です。その結果、瞬時のキューの深さも、名目上は安定したネットワークで、劇的に変化することができます。最適なパフォーマンスを得るために、パケットがバッファスペースが利用できないときだけでなく、制御された方法で廃棄されるべきです。どのくらいのバッファスペースが供給されなければならない、まだ議論の問題ですが、経験則として、各ノードは、リンクを共有し、各TCPコネクションのためのデータの1つのlink_bandwidth * link_delay製品の価値を保持するのに十分なバッファリングを持っている必要があります。
This is often difficult to estimate, since it depends on parameters beyond the subnetwork's control or knowledge. Internet nodes generally do not implement admission control policies, and cannot limit the number of TCP connections that use them. In general, it is wise to err in favor of too much buffering rather than too little. It may also be useful for subnets to incorporate mechanisms that measure propagation delays to assist in buffer sizing calculations.
それはサブネットワークの制御や知識を超えたパラメータに依存するので、これは、多くの場合、推定することは困難です。インターネットノードは、一般的にアドミッションコントロールポリシーを実装していない、とそれらを使用するTCP接続の数を制限することはできません。一般的に、あまりにも少ないのではなく、あまりにも多くのバッファリングの賛成で誤ることが賢明です。サブネットは、バッファサイズの計算を支援するために、伝播遅延を測定する機構を組み込むことも有用であり得ます。
There is a rough consensus in the research community that active queue management is important to improving fairness, link utilization, and throughput [RFC2309]. Although there are questions and concerns about the effectiveness of active queue management (e.g., [MBDL99]), it is widely considered an improvement over tail-drop discard policies.
アクティブキュー管理が公正、リンク使用率、およびスループット[RFC2309]を改善するために重要であり、研究コミュニティの荒いコンセンサスがあります。アクティブキュー管理（例えば、[MBDL99]）の有効性についての質問や懸念がありますが、それは広くテールドロップ廃棄ポリシーを超える改善と考えられています。
One form of active queue management is the Random Early Detection (RED) algorithm [RED93], a family of related algorithms. In one version of RED, an exponentially-weighted moving average of the queue depth is maintained:
アクティブキュー管理の一の形態は、ランダム早期検出（RED）アルゴリズム[RED93]、関連するアルゴリズムのファミリーです。 REDの1つのバージョンでは、キューの深さの指数関数的加重移動平均が維持されます。
When this average queue depth is between a maximum threshold max_th and a minimum threshold min_th, the probability of packets that are dropped is proportional to the amount by which the average queue depth exceeds min_th.
この平均キュー深度が最大しきい値MAX_THと最小閾値MIN_TH間にある場合、ドロップされたパケットの確率は、平均キュー深度がMIN_THを超える量に比例します。
When this average queue depth is equal to max_th, the drop probability is equal to a configurable parameter max_p.
この平均キュー深度がMAX_THに等しい場合、廃棄確率は、設定可能なパラメータmax_pに等しいです。
When this average queue depth is greater than max_th, packets are always dropped.
この平均キュー深度がMAX_THよりも大きい場合、パケットは、常にドロップされます。
Numerous variants on RED appear in the literature, and there are other active queue management algorithms which claim various advantages over RED [GM02].
REDに多数の変異体が文献に現れ、そしてRED [GM02]を超える様々な利点を主張する他のアクティブキュー管理アルゴリズムが存在します。
With an active queue management algorithm, dropped packets become a feedback signal to trigger more appropriate congestion behavior by the TCPs in the end hosts. Randomization of dropping tends to break up the observed tendency of TCP windows belonging to different TCP connections to become synchronized by correlated drops, and it also imposes a degree of fairness on those connections that implement TCP congestion avoidance properly. Another important property of active queue management algorithms is that they attempt to keep average queue depths short while accommodating large short-term bursts.
アクティブキュー管理アルゴリズムを用いて、パケットがエンドホストでのTCPによって、より適切な渋滞の動作をトリガするためのフィードバック信号となるドロップ。ドロップのランダム化は、相関滴によって同期になるために別のTCP接続に属するTCPウィンドウの観測傾向を分割する傾向があり、それはまた、適切にTCPの輻輳回避を実装し、それらの接続で、公平性の度合いを課します。アクティブキュー管理アルゴリズムのもう一つの重要な特性は、大規模な短期的なバーストを収容している間、彼らは短い平均キュー深度を維持しようとしていることです。
Since TCP neither knows nor cares whether congestive packet loss occurs at the IP layer or in a subnet, it may be advisable for subnets that perform queuing and discarding to consider implementing some form of active queue management. This is especially true if large aggregates of TCP connections are likely to share the same queue. However, active queue management may be less effective in the case of many queues carrying smaller aggregates of TCP connections, e.g., in an ATM switch that implements per-VC queuing.
TCPは、どちらも知っていることも、うっ血性パケット損失がIP層で、またはサブネット内に発生したかどうかを気にかけているので、それには、キューイングおよびアクティブキュー管理のいくつかのフォームを実装することを検討するために廃棄行うサブネットのが賢明かもしれません。 TCPコネクションの大きな凝集体が同じキューを共有する可能性がある場合、これは特にそうです。しかし、アクティブキュー管理は、VC単位のキューイングを実現するATMスイッチにおいて、例えば、TCP接続の小さな凝集体を運ぶ多くのキューの場合にはあまり有効であり得ます。
Note that the performance of active queue management algorithms is highly sensitive to settings of configurable parameters, and also to factors such as RTT [MBB00] [FB00].
アクティブキュー管理アルゴリズムの性能は、構成可能なパラメータの設定に、また、そのようなRTT [MBB00] [FB00]などの要因に対して非常に敏感であることに留意されたいです。
Some subnets, most notably ATM, perform segmentation and reassembly at the subnetwork edges. Care should be taken here in designing discard policies. If the subnet discards a fragment of an IP packet, then the remaining fragments become an unproductive load on the subnet that can markedly degrade end-to-end performance [RF95]. Subnetworks should therefore attempt to discard these extra fragments whenever one of them must be discarded. If the IP packet has already been partially forwarded when discarding becomes necessary, then every remaining fragment except the one marking the end of the IP packet should also be discarded. For ATM subnets, this specifically means using Early Packet Discard and Partial Packet Discard [ATMFTM].
いくつかのサブネット、最も顕著なのATMは、サブネットワークのエッジでセグメント化および再組み立てを行います。ケアは、廃棄ポリシーを設計する際に、ここで注意が必要です。サブネットがIPパケットのフラグメントを破棄する場合は、残りのフラグメントは、[RF95]著しくエンドツーエンドのパフォーマンスが低下する可能性がサブネット上の非生産的な負荷になります。サブネットワークは、したがって、そのうちの一つは、廃棄しなければならない時はいつでもこれらの余分の断片を破棄しようとしなければなりません。 IPパケットがすでに部分的に転送された場合は廃棄が必要になった場合、その後、IPパケットの終わりをマークするものを除くすべての残りのフラグメントはまた、廃棄されなければなりません。 ATMサブネットのために、これは、特に早期パケット廃棄と部分パケット廃棄[ATMFTM]を使用して意味します。
Some subnets include flow control mechanisms that effectively require that the rate of traffic flows be shaped upon entry to the subnet. One example of such a subnet mechanism is in the ATM Available Bit rate (ABR) service category [ATMFTM]. Such flow control mechanisms have the effect of making the subnet nearly lossless by pushing congestion into the IP routers at the edges of the subnet. In such a case, adequate buffering and discard policies are needed in these routers to deal with a subnet that appears to have varying bandwidth. Whether there is a benefit in this kind of flow control is controversial; there are numerous simulation and analytical studies that go both ways. It appears that some of the issues leading to such different results include sensitivity to ABR parameters, use of binary rather than explicit rate feedback, use (or not) of per-VC queuing, and the specific ATM switch algorithms selected for the study. Anecdotally, some large networks that used IP over ABR to carry TCP traffic have claimed it to be successful, but have published no results.
いくつかのサブネットが有効トラフィックのレートがサブネットへのエントリ時に成形することが流れることを必要とするフロー制御機構を含みます。そのようなサブネット機構の一例は、ATM利用可能ビットレート（ABR）サービスカテゴリ[ATMFTM]です。そのようなフロー制御メカニズムは、サブネットのエッジでIPルータに輻輳を押してサブネットがほぼ無損失にする効果を有します。そのような場合には、十分なバッファリングおよび廃棄ポリシーは、さまざまな帯域幅を持っているように見えますサブネットに対処するためにこれらのルータで必要とされています。フロー制御のこの種では利益が論争のですがあるかどうか。数多くのシミュレーションとの両方の道を行く分析的研究があります。異なる結果につながる問題のいくつかは、ABRパラメータ、バイナリの使用ではなく、明示的なレートフィードバック、VC単位のキューイングを使用する（またはしない）、そして研究のために選択された特定のATMスイッチアルゴリズムに対する感度を含むと思われます。ちなみに、TCPトラフィックを運ぶためにABR上でIPを使用し、いくつかの大規模なネットワークでは、成功するためにそれを主張しているが、何の結果を公表しませんでした。
Another possible approach to flow control in the subnet would be to work with TCP Explicit Congestion Notification (ECN) semantics [RFC3168] through utilizing explicit congestion indicators in subnet frames. Routers at the edges of the subnet, rather than shaping, would set the explicit congestion bit in those IP packets that are received in subnet frames that have an ECN indication. Nodes in the subnet would need to implement an active queue management protocol that marks subnet frames instead of dropping them.
サブネット内のフロー制御するための別の可能なアプローチは、サブネットフレームに明示的輻輳指標を利用を通じてTCP明示的輻輳通知（ECN）意味論[RFC3168]で動作するであろう。サブネットのエッジにおけるルータは、むしろ成形より、ECN指示を有するサブネットフレームで受信されたこれらのIPパケットに明示的輻輳ビットを設定します。サブネット内のノードは、それらを落とすのではなく、サブネットフレームをマークアクティブキュー管理プロトコルを実装する必要があります。
ECN is currently a proposed standard, but it is not yet widely deployed.
ECNは、現在提案されている標準ですが、それはまだ広く展開されていません。
Application data compression is a function that can usually be omitted in the subnetwork. The endpoints typically have more CPU and memory resources to run a compression algorithm and a better understanding of what is being compressed. End-to-end compression benefits every network element in the path, while subnetwork-layer compression, by definition, benefits only a single subnetwork.
アプリケーションデータの圧縮は、通常、サブネットワークに省略することができる機能です。エンドポイントは、通常の圧縮アルゴリズムと圧縮されているもののより良い理解を実行するために、より多くのCPUとメモリリソースを持っています。エンドツーエンドの圧縮は、単一のサブネットワークの定義、恩恵により、サブネットワーク層圧縮しながら、パス内のすべてのネットワーク要素に利益をもたらします。
Data presented to the subnetwork layer may already be in a compressed format (e.g., a JPEG file), compressed at the application layer (e.g., the optional "gzip", "compress", and "deflate" compression in HTTP/1.1 [RFC2616]), or compressed at the IP layer (the IP Payload Compression Protocol [RFC3173] supports DEFLATE [RFC2394] and LZS [RFC2395]). Compression at the subnetwork edges is of no benefit for any of these cases.
サブネットワークレイヤに提示されたデータは、既にアプリケーション層（例えば、オプション「GZIP」、「圧縮」で圧縮された圧縮フォーマット（例えば、JPEGファイル）であること、およびHTTPで圧縮を「収縮」することができる/ 1.1 [RFC2616 ]）、またはIPレイヤで圧縮（IPペイロード圧縮プロトコル[RFC3173]をサポートしているDEFLATE [RFC2394]とLZS [RFC2395]）。サブネットワークエッジでの圧縮は、これらのケースのいずれかのために利益がありません。
The subnetwork may also process data that has been encrypted by the application (OpenPGP [RFC2440] or S/MIME [RFC2633]), just above TCP (SSL, TLS [RFC2246]), or just above IP (IPsec ESP [RFC2406]).
アプリケーション（のOpenPGP [RFC2440]またはS / MIME [RFC2633]）によって、単にTCP（SSL、TLS [RFC2246]）上、または単にIP（IPsecのESP [RFC2406]）上に暗号化されたサブネットワークはまた、プロセスデータ。
Ciphers generate high-entropy bit streams lacking any patterns that can be exploited by a compression algorithm.
暗号は、圧縮アルゴリズムによって利用することができる任意のパターンを欠いた高エントロピービットストリームを生成します。
However, much data is still transmitted uncompressed over the Internet, so subnetwork compression may be beneficial. Any subnetwork compression algorithm must not expand uncompressible data, e.g., data that has already been compressed or encrypted.
しかし、多くのデータはまだインターネット上で非圧縮伝送され、そのサブネットワーク圧縮は有益であろう。任意のサブネットワーク圧縮アルゴリズムは、例えば、既に圧縮または暗号化されたデータを非圧縮データを拡張してはなりません。
We make a strong recommendation that subnetworks operating at low speed or with small MTUs compress IP and transport-level headers (TCP and UDP) using several header compression schemes developed within the IETF [RFC3150]. An uncompressed 40-byte TCP/IP header takes about 33 milliseconds to send at 9600 bps. "VJ" TCP/IP header compression [RFC1144] compresses most headers to 3-5 bytes, reducing transmission time to several milliseconds on dialup modem links. This is especially beneficial for small, latency-sensitive packets in interactive sessions.
我々は、低速で、または小さなMTUで動作するサブネットワーク強い推薦はIETF [RFC3150]で開発いくつかのヘッダ圧縮スキームを使用してIPおよびトランスポート・レベル・ヘッダ（TCPおよびUDP）を圧縮します。非圧縮の40バイトのTCP / IPヘッダは9600 bpsで送信するために約33ミリ秒かかります。 「VJ」TCP / IPヘッダー圧縮[RFC1144]は、ダイヤルアップモデムリンク上のいくつかのミリ秒の送信時間を減少、3-5バイトに最もヘッダを圧縮します。これは、対話型セッションでは小さな、遅延に敏感なパケットのために特に有益です。
Similarly, RTP compression schemes, such as CRTP [RFC2508] and ROHC [RFC3095], compress most IP/UDP/RTP headers to 1-4 bytes. The resulting savings are especially significant when audio packets are kept small to minimize store-and-forward latency.
同様に、CRTP [RFC2508]及びROHC [RFC3095]としてRTP圧縮方式、1-4バイトに最もIP / UDP / RTPヘッダを圧縮します。オーディオパケットは、ストアアンドフォワード遅延を最小限に抑えるために小さく維持されていると、得られる節約は特に重要です。
Designers should consider the effect of the subnetwork error rate on the performance of header compression. TCP ordinarily recovers from lost packets by retransmitting only those packets that were actually lost; packets arriving correctly after a packet loss are kept on a resequencing queue and do not need to be retransmitted. In VJ TCP/IP [RFC1144] header compression, however, the receiver cannot explicitly notify a sender of data corruption and subsequent loss of synchronization between compressor and decompressor. It relies instead on TCP retransmission to re-synchronize the decompressor. After a packet is lost, the decompressor must discard every subsequent packet, even if the subnetwork makes no further errors, until the sending TCP retransmits to re-synchronize the decompressor. This effect can substantially magnify the effect of subnetwork packet losses if the sending TCP window is large, as it will often be on a path with a large bandwidth*delay product [LRKOJ99].
設計者は、ヘッダー圧縮のパフォーマンス上のサブネットワークエラーレートの影響を考慮すべきです。 TCPは通常、実際に失われたパケットのみを再送することにより、失われたパケットから回復します。パケット損失の後に正常に到着するパケットは、再配列キューに保存され、再送信する必要はありません。 VJ TCP / IP [RFC1144]ヘッダ圧縮では、しかしながら、受信機は、明示的にデータの破損とコンプレッサとデコンプレッサとの間の同期の後続の損失の送信者に通知することができません。これは、デコンプレッサを再同期する代わりにTCP再送に依存しています。パケットが失われた後、送信側TCPは、デコンプレッサを再同期させるために再送信するまで、デコンプレッサは、サブネットワークがそれ以上のエラーをしない場合でも、後続のすべてのパケットを破棄しなければなりません。送信TCPウィンドウが大きい場合、それは多くの場合、大規模な帯域幅*遅れ製品[LRKOJ99]のパスになりますので、この効果は、実質的に、サブネットワークパケットロスの影響を拡大することができます。
Alternate header compression schemes, such as those described in [RFC2507], include an explicit request for retransmission of an uncompressed packet to allow decompressor resynchronization without waiting for a TCP retransmission. However, these schemes are not yet in widespread use.
このような[RFC2507]に記載されているような代替ヘッダ圧縮方式は、TCP再送を待つことなく、デコンプレッサの再同期を可能にするために圧縮されていないパケットの再送信のための明示的な要求を含みます。しかし、これらのスキームは、広く普及していません。
Both TCP header compression schemes do not compress widely-used TCP options such as selective acknowledgements (SACK). Both fail to compress TCP traffic that makes use of explicit congestion notification (ECN). Work is under way in the IETF ROHC WG to address these shortcomings in a ROHC header compression scheme for TCP [RFC3095] [RFC3096].
両方のTCPヘッダ圧縮方式は、そのような選択的肯定応答（SACK）として広く使用されているTCPオプションを圧縮しません。どちらも、明示的輻輳通知（ECN）を利用したTCPトラフィックを圧縮しません。作業はTCP [RFC3095]、[RFC3096]のためのROHCヘッダ圧縮方式でこれらの欠点に対処するためにIETF ROHC WGで進行中です。
The subnetwork error rate also is important for RTP header compression. CRTP uses delta encoding, so a packet loss on the link causes uncertainty about the subsequent packets, which often must be discarded until the decompressor has notified the compressor and the compressor has sent re-synchronizing information. This typically takes slightly more than the end-to-end path round-trip time. For links that combine significant error rates with latencies that require multiple packets to be in flight at a time, this leads to significant error propagation, i.e., subsequent losses caused by an initial loss.
サブネットワーク誤り率もRTPヘッダ圧縮のために重要です。 CRTPがデルタエンコーディングを使用するため、リンク上のパケット損失がデコンプレッサは、コンプレッサに通知したとコンプレッサーが再同期情報を送信したまで頻繁に廃棄しなければなら後続のパケットに関する不確実性の原因となります。これは通常、エンド・ツー・エンドのパス往復時間よりも少しかかります。一度に飛行にあるように、複数のパケットを必要と待機時間と有意な誤り率を組み合わせたリンクの場合、これは重大な誤り伝播、初期の損失によって引き起こされる、すなわち、その後の損失につながります。
For links that are both high-latency (multiple packets in flight from a typical RTP stream) and error-prone, RTP ROHC provides a more robust way of RTP header compression, at a cost of higher complexity at the compressor and decompressor. For example, within a talk spurt, only extended losses of (depending on the mode chosen) 12-64 packets typically cause error propagation.
高遅延（典型的なRTPストリームから飛行中の複数のパケット）とエラープローン共にリンクするために、RTP ROHCは、圧縮及び解凍器でのより高い複雑さを犠牲にし、RTPヘッダ圧縮のより堅牢な方法を提供します。例えば、トーク・スパート内、12-64パケット（選択されたモードに応じて）の唯一の拡張損失は、典型的には、誤り伝播を引き起こします。
The Internet architecture does not guarantee that packets will arrive in the same order in which they were originally transmitted; transport protocols like TCP must take this into account.
インターネットアーキテクチャは、パケットは、彼らが最初に送信されたのと同じ順序で到着することを保証するものではありません。 TCPのようなトランスポートプロトコルは、これを考慮に入れなければなりません。
However, reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP's sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers.
それが現在定義されているようしかし、並べ替えがTCPとコストで来るん。 TCPが到着した最後に次のセグメントを示す累積確認応答（ACK）を返すので、アウト・オブ・オーダのセグメントは、TCP受信機が重複確認応答を送信させます。 TCP送信者通知3つの重複確認応答が、それはセグメントがネットワークによって廃棄されたと仮定し、高速再送アルゴリズム[Jac90] [RFC2581]を使用する場合、セグメントを再送信します。また、輻輳ウィンドウを効果的にTCPの送信レートを半分にすること、半分に低減されます。サブネットワークが3つの重複ACKが生成されることを大幅にこのようなセグメントを並べ替えた場合、TCPの送信者は不輻輳ウィンドウを削減し、パフォーマンスが低下します。
Packet reordering frequently occurs in parts of the Internet, and it seems to be difficult or impossible to eliminate [BPS99]. For this reason, research on improving TCP's behavior in the face of packet reordering [LK00] [BA02] has begun.
パケット並べ替えが頻繁にインターネットの一部で発生し、[BPS99]排除することは困難または不可能であると思われます。このため、[LK00] [BA02]を並べ替え、パケットの顔にTCPの動作を改善する研究が始まっています。
[BPS99] cites reasons why it may even be undesirable to eliminate reordering. There are situations where average packet latency can be reduced, link efficiency can be increased, and/or reliability can be improved if reordering is permitted. Examples include certain high speed switches within the Internet backbone and the parallel links used over many Internet paths for load splitting and redundancy.
[BPS99]それも並べ替えを排除するために望ましくないかもしれない理由を挙げています。平均パケット遅延を低減することができる状況では、リンクの効率を高めることができ、および/または並べ替えが許可された場合、信頼性を向上させることが可能です。例としては、インターネットバックボーン内の特定の高速スイッチ及び負荷分割及び冗長性のため、多くのインターネットパス上で使用平行リンクを含みます。
This suggests that subnetwork implementers should try to avoid packet reordering whenever possible, but not if doing so compromises efficiency, impairs reliability, or increases average packet delay.
これは、サブネットワークの実装が可能な限り、パケットの並べ替えを回避しようとすべきであることを示唆しているが、やってはとても効率が損なわれていない場合、信頼性を損ない、または平均パケット遅延が増加します。
Note that every header compression scheme currently standardized for the Internet requires in-order packet delivery on the link between compressor and decompressor. PPP is frequently used to carry compressed TCP/IP packets; since it was originally designed for point-to-point and dialup links, it is assumed to provide in-order delivery. For this reason, subnetwork implementers who provide PPP interfaces to VPNs and other more complex subnetworks, must also maintain in-order delivery of PPP frames.
現在、インターネットのための標準毎のヘッダ圧縮方式は、コンプレッサとデコンプレッサとの間のリンク上での順序パケット配信を必要とすることに留意されたいです。 PPPは、頻繁に圧縮されたTCP / IPパケットを運ぶために使用されます。それは元々ポイントツーポイントおよびダイヤルアップリンクのために設計されたので、順序配信を提供するものとします。この理由のため、VPNおよび他のより複雑なサブネットワークへのPPPインタフェースを提供するサブネットワーク実装は、また、PPPフレームの順序配信を維持しなければなりません。
Internet users are increasingly mobile. Not only are many Internet nodes laptop computers, but pocket organizers and mobile embedded systems are also becoming nodes on the Internet. These nodes may connect to many different access points on the Internet over time, and they expect this to be largely transparent to their activities. Except when they are not connected to the Internet at all, and for performance differences when they are connected, they expect that everything will "just work" regardless of their current Internet attachment point or local subnetwork technology.
インターネットユーザーはますますモバイルです。多くのインターネットノードラップトップコンピュータですが、ポケットの主催者およびモバイル組み込みシステムだけでなく、また、インターネット上のノードになっています。これらのノードは、時間をかけて、インターネット上の多くの異なるアクセスポイントに接続することができ、そして、彼らはこれが彼らの活動に大部分が透明になるように期待しています。それらはすべてでインターネットに接続されていない場合を除き、そしてそれらが接続されているパフォーマンスの違いのために、彼らはすべてが関係なく、現在のインターネット接続点またはローカルサブネットワーク技術の「ただ働き」になることを期待しています。
Changing a host's Internet attachment point involves one or more of the following steps.
ホストのインターネット接続ポイントを変更すると、次のステップの一つ以上を含んでいます。
First, if use of the local subnetwork is restricted, the user's credentials must be verified and access granted. There are many ways to do this. A trivial example would be an "Internet cafe" that grants physical access to the subnetwork for a fee. Subnetworks may implement technical access controls of their own; one example is IEEE 802.11 Wireless Equivalent Privacy [IEEE80211]. It is common practice for both cellular telephone and Internet service providers (ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the standard method for ISPs to exchange authorization information.
ローカルサブネットワークの使用が制限されている場合、最初に、ユーザーの資格情報を検証しなければならず、アクセスが許可されました。これを行うには多くの方法があります。簡単な例は、有料でサブネットワークに物理的にアクセスを許可する「インターネットカフェ」になります。サブネットワークは、独自の技術的なアクセス制御を実装することができます。一つの例は、IEEE 802.11無線LAN同等のプライバシー[IEEE80211]です。これは、携帯電話やインターネットサービスプロバイダ（ISP）1 anothers'ユーザーにサービスを提供することに同意することの両方のために一般的です。 RADIUS [RFC2865]はISPが認証情報を交換するための標準的な方法です。
Second, the host may have to be reconfigured with IP parameters appropriate for the local subnetwork. This usually includes setting an IP address, default router, and domain name system (DNS) servers.
第二に、ホストは、ローカルサブネットワークに適したIPパラメータを再設定する必要があります。これは、通常、IPアドレス、デフォルトルータ、およびドメインネームシステム（DNS）サーバを設定することを含みます。
On multiple-access networks, the Dynamic Host Configuration Protocol (DHCP) [RFC2131] is almost universally used for this purpose. On PPP links, these functions are performed by the IP Control Protocol (IPCP) [RFC1332].
マルチアクセスネットワークでは、動的ホスト構成プロトコル（DHCP）[RFC2131]は、ほぼ普遍的に、この目的のために使用されます。 PPPリンク上で、これらの機能は、IP制御プロトコル（IPCP）[RFC1332]によって実行されます。
Third, traffic destined for the mobile host must be routed to its current location. This roaming function is the most common meaning of the term "Internet mobility".
第三に、モバイルホスト宛てのトラフィックは、現在の場所にルーティングする必要があります。このローミング機能は、用語「インターネットモビリティ」の最も一般的な意味です。
Internet mobility can be provided at any of several layers in the Internet protocol stack, and there is ongoing debate as to which is the most appropriate and efficient. Mobility is already a feature of certain application layer protocols; the Post Office Protocol (POP) [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501] were created specifically to provide mobility in the receipt of electronic mail.
インターネットモビリティは、インターネットプロトコルスタックのいくつかの層のいずれかに設けることができ、最も適切かつ効率的であるように、進行中の議論があります。モビリティは、すでに特定のアプリケーション層プロトコルの機能です。ポストオフィスプロトコル（POP）[RFC1939]とIMAP（Internet Message Access Protocol）[RFC3501]は、電子メールの受信にモビリティを提供するために特別に作成されました。
Mobility can also be provided at the IP layer [RFC3344]. This mechanism provides greater transparency, viz., IP addresses that remain fixed as the nodes move, but at the cost of potentially significant network overhead and increased delay because of the sub-optimal network routing and tunneling involved.
モビリティは、IP層[RFC3344]で提供することができます。このメカニズムが提供透明性、すなわち、ノードが移動するように固定されたが、オーバーヘッド潜在的に重要なネットワークのコストであるため関与する準最適ネットワークルーティング及びトンネリングの遅延を増加させたままIPアドレス。
Some subnetworks may provide internal mobility, transparent to IP, as a feature of their own internal routing mechanisms. To the extent that these simplify routing at the IP layer, reduce the need for mechanisms like Mobile IP, or exploit mechanisms unique to the subnetwork, this is generally desirable. This is especially true when the subnetwork covers a relatively small geographic area and the users move rapidly between the attachment points within that area. Examples of internal mobility schemes include Ethernet switching and intra-system handoff in cellular telephony.
いくつかのサブネットワークは、独自の内部ルーティングメカニズムの機能として、IPに対して透過内部モビリティを提供することができます。これらは、モバイルIPのようなメカニズムの必要性を減らす、IP層でルーティングを単純化する、またはサブネットワークに固有のメカニズムを利用する限り、これが一般的に望ましいです。サブネットワークは、比較的小さな地理的エリアをカバーし、ユーザーがその領域内での付着点との間に急速に移動するとき、これは特に真実です。内部モビリティスキームの例は、携帯電話内のイーサネット・スイッチングおよびシステム内ハンドオフを含みます。
However, if the subnetwork is physically large and connects to other parts of the Internet at multiple geographic points, care should be taken to optimize the wide-area routing of packets between nodes on the external Internet and nodes on the subnet. This is generally done with "nearest exit" routing strategies. Because a given subnetwork may be unaware of the actual physical location of a destination on another subnetwork, it simply routes packets bound for the other subnetwork to the nearest router between the two. This implies some awareness of IP addressing and routing within the subnetwork. The subnetwork may wish to use IP routing internally for wide area routing and restrict subnetwork-specific routing to constrained geographic areas where the effects of suboptimal routing are minimized.
サブネットワークは、物理的に大きく、複数の地理的ポイントでインターネットの他の部分に接続する場合は、注意がサブネット上の外部のインターネット上のノードと、ノード間でパケットの広域ルーティングを最適化するために取られるべきです。これは、一般に「最寄りの出口」ルーティング戦略で行われます。所与のサブネットワークが別のサブネットワーク上の宛先の実際の物理的な位置を知らないかもしれないので、それが単にルートパケットは、両者の間の最も近いルータに他のサブネットワークに向かいます。これは、IPアドレッシングおよびサブネットワーク内のルーティングのいくつかの意識を意味します。サブネットワークは、ワイドエリアルーティングのために内部IPルーティングを使用して、準最適ルーティングの効果が最小化される地理的エリアを拘束するためにサブネットワーク固有のルーティングを制限することを望むかもしれません。
Subnetworks connecting more than two systems must provide their own internal Layer-2 forwarding mechanisms, either implicitly (e.g., broadcast) or explicitly (e.g., switched). Since routing is the major function of the Internet layer, the question naturally arises as to the interaction between routing at the Internet layer and routing in the subnet, and proper division of function between the two.
以上の2つのシステムを接続するサブネットワーク（例えば、交換）独自の内部レイヤ2転送メカニズム、暗黙的（例えば、ブロードキャスト）、または明示的に提供しなければなりません。ルーティングは、インターネット層の主要な機能であるため、問題は当然、インターネット層でルーティングおよびサブネットにルーティングし、2つの間の機能の適切な分割の間の相互作用として生じます。
Layer-2 subnetworks can be point-to-point, connecting two systems, or multipoint. Multipoint subnetworks can be broadcast (e.g., shared media or emulated) or non-broadcast. Generally, IP considers multipoint subnetworks as broadcast, with shared-medium Ethernet as the canonical (and historical) example, and point-to-point subnetworks as a degenerate case. Non-broadcast subnetworks may require additional mechanisms, e.g., above IP at the routing layer [RFC2328].
レイヤ2サブネットワークは、ポイントツーポイント、2つのシステムを接続する、またはマルチすることができます。マルチポイントサブネットワークは、放送（例えば、メディアを共有またはエミュレートされた）または非ブロードキャストすることができます。一般に、IPは縮退ケースとして共有媒体カノニカル（及び過去）のようなイーサネット例えば、ポイント・ツー・ポイントサブネットワークに、ブロードキャストとしてサブネットワークをマルチ考慮する。非放送サブネットワークは、ルーティング層[RFC2328]で例えば、IP上の追加の機構を必要とし得ます。
IP is ignorant of the topology of the subnetwork layer. In particular, reconfiguration of subnetwork paths is not tracked by the IP layer. IP is only affected by whether it can send/receive packets sent to the remotely connected systems via the subnetwork interface (i.e., the reachability from one router to another). IP further considers that subnetworks are largely static -- that both their membership and existence are stable at routing timescales (tens of seconds); changes to these are considered re-provisioning, rather than routing.
IPはサブネットワークレイヤのトポロジの無知です。具体的には、サブネットワーク経路の再構成は、IP層によって追跡されません。 IPのみが送信できるかどうかによって影響される/サブネットワークインタフェースを介してリモート接続されたシステムに送信されたパケットを受信する（すなわち、別のルータから到達可能）。 IPは、さらにサブネットワークは、主に静的であることを考えて - 彼らの会員と存在の両方がルーティングの時間スケール（数十秒）で安定していること。これらの変更ではなく、ルーティングよりも、再プロビジョニングと考えられています。
Routing functionality in a subnetwork is related to addressing in that subnetwork. Resolution of addresses on subnetwork links is required for forwarding IP packets across links (e.g., ARP for IPv4, or ND for IPv6). There is unlikely to be direct interaction between subnetwork routing and IP routing. Where broadcast is provided or explicitly emulated, address resolution can be used directly; where not provided, the link layer routing may interface to a protocol for resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to provide context-dependent address resolution capabilities.
サブネットワーク内のルーティング機能は、そのサブネットワーク内のアドレス指定に関連しています。サブネットワークリンク上のアドレスの分解能がリンクを介してIPパケットを転送するために必要とされる（例えば、IPv4のARP IPv6の、又はND）。サブネットワークのルーティングとIPルーティングとの間の直接的な相互作用である可能性が低いがあります。放送が提供または明示的にエミュレートされている場合、アドレス解決を直接使用することができます。提供されない場合、リンク層ルーティングは、コンテキスト依存アドレス解決機能を提供するために、例えば、ネクストホップ解決プロトコル[RFC2322]に、解決のためのプロトコルにインタフェースすることができます。
Subnetwork routing can either complement or compete with IP routing. It complements IP when a subnetwork encapsulates its internal routing, and where the effects of that routing are not visible at the IP layer. However, if different paths in the subnetwork have characteristics that affect IP routing, it can affect or even inhibit the convergence of IP routing.
サブネットワークのルーティングは補完またはIPルーティングと競うことができます。サブネットワークは、その内部ルーティングをカプセル化する際には、IPを補完し、ここで、そのルーティングの効果は、IPレイヤで表示されません。サブネットワーク内の異なるパスがIPルーティングに影響を与える特性を有する場合は、それが影響し、さらにはIPルーティングの収束を阻害することができます。
Routing protocols generally consider Layer-2 subnetworks, i.e., with subnet masks and no intermediate IP hops, to have uniform routing metrics to all members. Routing can break when a link's characteristics do not match the routing metric, in this case, e.g., when some member pairs have different path characteristics. Consider a virtual Ethernet subnetwork that includes both nearby (sub-millisecond latency) and remote (100's of milliseconds away) systems. Presenting that group as a single subnetwork means that some routing protocols will assume that all pairs have the same delay, and that that delay is small. Because this is not the case, the routing tables constructed may be suboptimal or may even fail to converge.
ルーティングプロトコルは、一般的にレイヤ2サブネットワーク、すなわち、サブネットマスクと考えると、中間のIPは、すべてのメンバーに均一なルーティングメトリックを持つように、ホップません。いくつかのメンバーのペアが異なるパス特性を持っているときに、リンクの特性は、例えば、この場合には、ルーティングメトリックと一致しないとき、ルーティングが壊れることができます。両方の近く（サブミリ秒の遅延）とリモート（離れミリ秒の100年代）システムを含む仮想イーサネットサブネットワークを考えてみましょう。単一のサブネットワークとしてそのグループを提示することは、いくつかのルーティングプロトコルは、すべての対が同じ遅延を有すると仮定し、その遅延が小さいことすることを意味します。これが当てはまらないため、ルーティングテーブルが次善であってもよい構築あるいは収束に失敗することがあります。
When a subnetwork is used for transit between a set of routers, it conventionally provides the equivalent of a full mesh of point-to-point links. Simplicity of the internal subnet structure can be used (e.g., via NHRP [RFC2332]) to reduce the size of address resolution tables, but routing exchanges will continue to reflect the full mesh they emulate. In general, subnetworks should not be used as a transit among a set of routers where routing protocols would break if a full mesh of equivalent point-to-point links were used.
サブネットワークは、ルータの集合の間に通過するために使用される場合、それは、従来のポイントツーポイントリンクのフルメッシュと同等のものを提供します。内部サブネット構造の単純さは、アドレス解決テーブルのサイズを縮小するが、交流をルーティングすることは、それらがエミュレートフルメッシュを反映し続ける（例えば、NHRP [RFC2332]を介して）使用することができます。一般に、サブネットワークは、同等のポイントツーポイントリンクのフルメッシュが使用された場合、ルーティングプロトコルが壊れるルータの集合の中のトランジットとして使用すべきではありません。
Some subnetworks have special features that allow the use of more effective or responsive routing mechanisms that cannot be implemented in IP because of its need for generality. One example is the self-learning bridge algorithm widely used in Ethernet networks. Learning bridges perform Layer-2 subnetwork forwarding, avoiding the need for dynamic routing at each subnetwork hop. Another is the "handoff" mechanism in cellular telephone networks, particularly the "soft handoff" scheme in IS-95 CDMA.
いくつかのサブネットワークがあるため一般のためにその必要性のIPで実装することができない、より効果的なまたは応答性のルーティングメカニズムの使用を許可する特別な設備を備えています。一例としては、広くイーサネットネットワークで使用される自己学習ブリッジアルゴリズムです。学習ブリッジは、各サブネットワークホップでの動的ルーティングの必要性を回避し、レイヤ2サブ転送を行います。もう一つは、携帯電話網、IS-95 CDMAで、特に「ソフトハンドオフ」方式で「ハンドオフ」のメカニズムです。
Subnetworks that cover large geographic areas or include links of widely-varying capabilities should be avoided. IP routing generally considers all multipoint subnets equivalent to a local, shared-medium link with uniform metrics between any pair of systems, and ignores internal subnetwork topology. Where a subnetwork diverges from that assumption, it is the obligation of subnetwork designers to provide compensating mechanisms. Not doing so can affect the scalability and convergence of IP routing, as noted above.
大きな地理的領域をカバーするか、広く様々な機能のリンクを含めるサブネットワークは避けるべきです。 IPルーティングは、一般的にシステムの任意の対の間の均一なメトリックを持つローカル、共有媒体リンクと同等のすべてのマルチサブネットを考慮し、内部サブネットワークトポロジーを無視します。サブネットワークがその仮定から分岐する場合、それは補償メカニズムを提供するために、サブネットワークの設計者の義務です。上述のように、IPルーティングの拡張性と収束に影響を与えることができそうではありません。
The subnetwork designer who decides to implement internal routing should consider whether a custom routing algorithm is warranted, or if an existing Internet routing algorithm or protocol may suffice. The designer should consider whether this decision is to reduce the address resolution table size (possible, but with additional protocol support required), or is trying to reduce routing table complexity. The latter may be better achieved by partitioning the subnetwork, either physically or logically, and using network-layer protocols to support partitioning (e.g., AS's in BGP). Protocols and routing algorithms can be notoriously subtle, complex, and difficult to implement correctly. Much work can be avoided if existing protocols or implementations can be readily reused.
内部ルーティングを実装することを決定したサブネットワークの設計者は、カスタムルーティングアルゴリズムが保証されているかどうかを検討すべきである、または既存のインターネットルーティングアルゴリズムやプロトコルが十分である場合。設計者は、この決定は、アドレス解決テーブルサイズ（可能性が、必要な追加のプロトコルサポート付き）を低減することで、またはルーティングテーブルの複雑さを軽減しようとしているかどうかを検討すべきです。後者は、より良好な物理的または論理的サブネットワークを分割し、（BGPにだAS例えば、）パーティショニングをサポートするためにネットワーク層プロトコルを使用することによって達成することができます。プロトコルとルーティングアルゴリズムは悪名高く、微妙な複雑で、正しく実装するのが困難な場合があります。既存のプロトコルや実装が容易に再利用することができた場合に多くの作業を回避することができます。
Security has become a high priority in the design and operation of the Internet. The Internet is vast, and countless organizations and individuals own and operate its various components. A consensus has emerged for what might be called a "security placement principle": a security mechanism is most effective when it is placed as close as possible to, and under the direct control of the owner of the asset that it protects.
セキュリティは、インターネットの設計および動作に高い優先順位となっています。インターネットは広大であり、無数の団体や個人が所有し、そのさまざまなコンポーネントを動作させます。コンセンサスは、「セキュリティの配置原則」と呼ばれるかもしれないもののために浮上している：セキュリティメカニズムが最も効果的であることができるだけ近くに配置し、それが保護資産の所有者の直接の制御下にあるとき。
A corollary of this principle is that end-to-end security (e.g., confidentiality, authentication, integrity, and access control) cannot be ensured with subnetwork security mechanisms. Not only are end-to-end security mechanisms much more closely associated with the end-user assets they protect, they are also much more comprehensive. For example, end-to-end security mechanisms cover gaps that can appear when otherwise good subnetwork mechanisms are concatenated. This is an important application of the end-to-end principle [SRC81].
この原理の帰結は、エンドツーエンドのセキュリティ（例えば、機密性、認証、完全性、およびアクセス制御）サブネットワークセキュリティメカニズムを確保することができないことです。はるかに密接に彼らが守るエンドユーザーの資産に関連付けられているエンドツーエンドのセキュリティメカニズムだけでなく、彼らはまた、はるかに包括されています。例えば、エンドツーエンドのセキュリティメカニズムは、そうでなければ、良好なサブネットワーク機構が連結されているときに表示されるギャップを覆います。これは、エンド・ツー・エンド原理[SRC81]の重要なアプリケーションです。
Several security mechanisms that can be used end-to-end have already been deployed in the Internet and are enjoying increasing use. The most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and TLS [RFC2246] primarily used to protect web commerce, Pretty Good Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used to protect and authenticate email and software distributions, the Secure Shell (SSH), used for secure remote access and file transfer, and IPsec [RFC2401], a general purpose encryption and authentication mechanism that sits just above IP and can be used by any IP application. (IPsec can actually be used either on an end-to-end basis or between security gateways that do not include either or both end systems.)
エンドツーエンドで使用することができ、いくつかのセキュリティメカニズムは、すでにインターネットで展開されていると使用の増加を楽しんでいます。最も重要なのは、セキュア・ソケット・レイヤー（SSL）[SSL2] [SSL3]と、主にウェブコマース、プリティグッドプライバシー（PGP）[RFC1991]とS / MIME [RFCの-2630から2634]を保護するために使用するTLS [RFC2246]です主に、SSH（Secure Shell）を電子メールやソフトウェア配布を保護し、認証するために使用されるセキュアなリモートアクセスとファイル転送のために使用され、およびIPsec [RFC2401]、単にIPの上に座っている汎用の暗号化および認証メカニズムとで使用することができます任意のIPアプリケーション。 （IPsecは、実際にエンドツーエンドベースで、またはいずれか一方または両方のエンドシステムが含まれていないセキュリティゲートウェイとの間のいずれかで使用することができます。）
Nonetheless, end-to-end security mechanisms are not used as widely as might be desired. However, the group could not reach consensus on whether subnetwork designers should be actively encouraged to implement mechanisms to protect user data.
それにもかかわらず、エンドツーエンドのセキュリティメカニズムは、として広く望まれるかもしれないとして使用されません。しかし、グループは、サブネットワークの設計者が積極的にユーザーデータを保護するためのメカニズムを実装することが奨励されるべきかどうかについて合意に達することができませんでした。
The clear consensus of the working group held that subnetwork security mechanisms, especially when weak or incorrectly implemented [BGW01], may actually be counterproductive. The argument is that subnetwork security mechanisms can lull end users into a false sense of security, diminish the incentive to deploy effective end-to-end mechanisms, and encourage "risky" uses of the Internet that would not be made if users understood the inherent limits of subnetwork security mechanisms.
ワーキンググループの明確なコンセンサスが弱いまたは誤っ[BGW01]実施、実際には逆であってもよい場合は特に、そのサブネットワークのセキュリティメカニズムを開催しました。引数は、サブネットワークのセキュリティメカニズムは、誤った安心感にエンドユーザーが小康状態効果的なエンド・ツー・エンドの仕組みを導入するインセンティブを低下させ、そしてユーザーが固有に理解した場合に行われることはない、インターネットの「危険な」の使用を奨励することができるということですサブネットワークのセキュリティメカニズムの限界。
The other point of view encourages subnetwork security on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as consumers who have wireless home networks and/or shared media Internet access) often have control over at most one endpoint -- usually a client -- and therefore cannot enforce the use of end-to-end mechanisms. However, subnet security can be entirely adequate for protecting low-valued assets against the most likely threats. In any event, subnet mechanisms do not preclude the use of end-to-end mechanisms, which are typically used to protect highly-valued assets. This viewpoint recognizes that many security policies implicitly assume that the entire end-to-end path is composed of a series of concatenated links that are nominally physically secured. That is, these policies assume that all endpoints of all links are trusted, and that access to the physical medium by attackers is difficult. To meet the assumptions of such policies, explicit mechanisms are needed for links (especially shared medium links) that lack physical protection. This, for example, is the rationale that underlies Wired Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1] [DOCSIS2] data over cable television networks standards.
ビューの他のポイントは、それがあまりにも頻繁まったく保障されていないデフォルトの状況、より優れているという原則にサブネットワークのセキュリティを奨励しています。通常、クライアント - - （ワイヤレスホームネットワークおよび/または共有メディアのインターネットアクセスを持っている消費者など）特に脆弱サブネットのユーザは、多くの場合、最大1つのエンドポイントを管理しているため、エンド・ツー・エンドのメカニズムの使用を強制することはできません。しかし、サブネットのセキュリティは最も可能性の高い脅威に対して低値の資産を保護するための、完全に十分であることができます。いずれにせよ、サブネットメカニズムは、典型的には高度値の資産を保護するために使用され、エンドツーエンドのメカニズムの使用を排除するものではありません。この視点は、多くのセキュリティポリシーは、暗黙的に全体のエンドツーエンドのパスは、名目上、物理的に固定されている連結一連のリンクから構成されていることを前提としていることを認識しています。つまり、これらのポリシーは、すべてのリンクのすべてのエンドポイントが信頼されていることを想定し、攻撃者が物理的な媒体へのアクセスが困難です。そのような政策の仮定を満たすために、明示的なメカニズムは、物理的な保護が不足しているリンク（特に共有メディアリンク）のために必要とされます。これは、例えば、IEEE 802.11 [IEEE80211]無線LANの規格、およびケーブルテレビネットワーク規格を超えるDOCSIS [DOCSIS1] [DOCSIS2]データにおけるベースラインプライバシーインターフェイスにWEP（Wired Equivalent Privacy）を基礎となる根拠です。
We therefore recommend that subnetwork designers who choose to implement security mechanisms to protect user data be as candid as possible with the details of such security mechanisms and the inherent limits of even the most secure mechanisms when implemented in a subnetwork rather than on an end-to-end basis.
私たちは、ユーザデータを保護するためのセキュリティメカニズムを実装することを選択しているサブネットワークの設計者は、このようなセキュリティ機構やサブネットワークに実装しても最も安全なメカニズムの固有の制限の詳細というよりエンド・ツーにできるだけ率直なるのでをお勧めします末端の基礎。
In keeping with the "placement principle", a clear consensus exists for another subnetwork security role: the protection of the subnetwork itself. Possible threats to subnetwork assets include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks. In some cases, mechanisms that protect subnet assets can also improve (but cannot ensure) end-to-end security.
「配置の原則」に沿って、明確なコンセンサスは別のサブネットワークのセキュリティの役割のために存在する：サブネットワーク自体の保護を。サブネットワーク資産への脅威の可能性は、サービスとサービス拒否の盗難を含めます。共有されたメディアサブネットは、このような攻撃に対して特に脆弱になりがち。いくつかのケースでは、サブネットの資産を保護するメカニズムは、エンドツーエンドのセキュリティをさらに向上させることができます（ただし保証することはできません）。
One security service can be provided by the subnetwork that will aid in the solution of an overall Internet problem: subnetwork security should provide a mechanism to authenticate the source of a subnetwork frame. This function is missing in some current protocols, e.g., the use of ARP [RFC826] to associate an IPv4 address with a MAC address. The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar function.
一つのセキュリティサービスは、インターネット全体の問題の解決に役立ちますサブネットワークにより提供することができます：サブネットワークのセキュリティは、サブフレームの送信元を認証するためのメカニズムを提供する必要があります。この関数は、いくつかの現在のプロトコルでは欠落している、例えば、ARP [RFC826]の使用は、MACアドレスとIPv4アドレスを関連付けます。 IPv6の近隣探索（ND）[RFC2461]は、同様の機能を実行します。
There are well-known security flaws with this address resolution mechanism [Wilbur89]. However, the inclusion of subnetwork frame source authentication will permit a secure subnetwork address.
このアドレス解決メカニズム[Wilbur89]で、よく知られたセキュリティ上の欠陥があります。しかし、サブフレームの送信元認証を含めることは、安全なサブネットワークアドレスを許可します。
Another potential role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties and determining their communication patterns and volumes even when their actual contents are protected by strong end-to-end security mechanisms. Lower-layer security can be more effective against traffic analysis due to its inherent ability to aggregate the communications of multiple parties sharing the same physical facilities while obscuring higher-layer protocol information that indicates specific end points, such as IP addresses and TCP/UDP port numbers.
サブネットワークセキュリティのための別の潜在的な役割は、トラフィック分析に対してユーザを保護するために、すなわち、通信相手を特定し、その通信パターンと実際の内容が強いエンドツーエンドのセキュリティメカニズムによって保護されていてもボリュームを決定します。下位レイヤ・セキュリティは、IPアドレス及びTCP / UDPポートとして、原因特定のエンドポイントを示す上位層プロトコル情報を不明瞭にしながら、同一の物理的設備を共有する複数の当事者の通信を集約するその固有の能力にトラフィック解析に対してより効果的であり得ます数字。
However, traffic analysis is a notoriously subtle and difficult threat to understand and defeat, far more so than threats to confidentiality and integrity. We therefore urge extreme care in the design of subnetwork security mechanisms specifically intended to thwart traffic analysis.
しかし、トラフィック分析は、機密性と完全性への脅威よりもはるかに多くので、理解し、敗北する悪名高く微妙かつ困難な脅威です。そこで我々は、具体的なトラフィック分析を阻止することを目的とサブネットワークのセキュリティメカニズムの設計に細心の注意を促します。
Subnetwork designers must keep in mind that design and implementation for security is difficult [Schneier00]. [Schneier95] describes protocols and algorithms which are considered well-understood and believed to be sound.
サブネットワークの設計者は、セキュリティのための設計と実装は、[Schneier00]に困難であることを心に留めておく必要があります。 [Schneier95]よく理解考慮し、音であると考えられているプロトコルおよびアルゴリズムを記載しています。
Poor design process, subtle design errors and flawed implementation can result in gaping vulnerabilities. In recent years, a number of subnet standards have had problems exposed. The following are examples of mistakes that have been made:
悪い設計プロセス、微妙な設計ミスや欠陥のある実装では、脆弱性をぽっかりにつながることができます。近年では、サブネット基準の数が問題曝露がありました。以下の行われたミスの例は以下のとおりです。
1. Use of weak and untested algorithms [Crypto9912] [BGW01]. For a variety of reasons, algorithms were chosen which had subtle flaws, making them vulnerable to a variety of attacks.
弱いと未検証アルゴリズムの1. [Crypto9912] [BGW01]。様々な理由から、アルゴリズムは、さまざまな攻撃にそれらを脆弱になって、微妙な欠陥を持っていた選ばれました。
2. Use of "security by obscurity" [Schneier00] [Crypto9912]. One common mistake is to assume that keeping cryptographic algorithms secret makes them more secure. This is intuitive, but wrong. Full public disclosure early in the design process attracts peer review by knowledgeable cryptographers. Exposure of flaws by this review far outweighs any imagined benefit from forcing attackers to reverse engineer security algorithms.
"隠すことによるセキュリティ" の2. [Schneier00] [Crypto9912]。よくある間違いは、暗号化アルゴリズムの秘密を維持することは、それらをより安全になりと仮定することです。これは、直感的な、しかし間違っています。設計プロセスの初期段階での全公共の開示は、知識の豊富な暗号学者によるピアレビューを魅了しています。これまでエンジニアのセキュリティアルゴリズムを逆に攻撃を強制から任意の想像の利益を上回るこのレビューによる欠陥の暴露。
3. Inclusion of trapdoors [Schneier00] [Crypto9912]. Trapdoors are flaws surreptitiously left in an algorithm to allow it to be broken. This might be done to recover lost keys or to permit surreptitious access by governmental agencies. Trapdoors can be discovered and exploited by malicious attackers.
[Schneier00] [Crypto9912]トラップドアの3含めます。トラップドアはこっそりそれが破られることを可能にするアルゴリズムで左の欠陥です。これは、失われたキーを回復するために、または政府機関による内密のアクセスを可能にするために行われるかもしれません。トラップドアを発見し、悪意のある攻撃者によって悪用される可能性があります。
4. Sending passwords or other identifying information as clear text. For many years, analog cellular telephones could be cloned and used to steal service. The cloners merely eavesdropped on the registration protocols that exchanged everything in clear text.
4.クリアテキストとしてパスワードやその他の識別情報を送信します。長年にわたり、アナログ携帯電話をクローン化し、サービスを盗むために使用することができます。自分のクローンは単にクリアテキストですべてを交換し、登録プロトコルに盗聴しました。
6. Incorrect use of a sound mechanism. For example [BGW01], one subnet standard includes an initialization vector which is poorly designed and poorly specified. A determined attacker can easily recover multiple ciphertexts encrypted with the same key stream and perform statistical attacks to decipher them.
音機構の6.誤って使用します。例えば[BGW01】一のサブネット規格は、設計が不十分と不完全指定された初期化ベクトルを含みます。決定した攻撃者は簡単に同じキーストリームで暗号化された複数の暗号文を回復し、それらを解読するために統計的な攻撃を行うことができます。
7. Identifying information sent in clear text that can be resolved to an individual, identifiable device. This creates a vulnerability to attacks targeted to that device (or its owner).
7.個々の、識別可能なデバイスに解決することができるクリアテキストで送信された情報を識別。これは、そのデバイス（またはその所有者）への標的型攻撃への脆弱性を作成します。
10. Failure to address "man-in-the-middle" attacks, e.g., with mutual authentication.
対処するための10の失敗 "のman-in-the-middle" 相互認証と、例えば、攻撃。
11. Failure to provide a form of replay detection, e.g., to prevent a receiver from accepting packets from an attacker that simply resends previously captured network traffic.
単に以前にキャプチャネットワークトラフィックを再送信し、攻撃者からのパケットを受け入れるの受信を防止するために、例えば、リプレイ検出の形態を提供するために11失敗。
12. Failure to provide integrity mechanisms when providing confidentiality schemes [Bel98].
機密保持スキームを提供する際に整合性のメカニズムを提供するために、12の失敗[Bel98]。
This list is by no means comprehensive. Design problems are difficult to avoid, but expert review is generally invaluable in avoiding problems.
このリストは包括されるものではありません。設計上の問題は回避することは困難ですが、専門家レビューは、問題を回避する上で、一般的に非常に貴重です。
In addition, well-designed security protocols can be compromised by implementation defects. Examples of such defects include use of predictable pseudo-random numbers [RFC1750], vulnerability to buffer overflow attacks due to unsafe use of certain I/O system calls [WFBA2000], and inadvertent exposure of secret data.
また、適切に設計されたセキュリティプロトコルを実装欠陥によって損なわれることができます。このような欠陥の例としては、原因特定のI / Oシステムの安全でない使用[WFBA2000]呼び出し、秘密データの不注意な露出にオーバーフロー攻撃をバッファリングする予測可能な擬似乱数[RFC1750]、脆弱性の利用を含みます。
This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group.
この文書では、リンク特性のIETFパフォーマンスへの影響（PILC）ワーキンググループのメンバーのコンセンサスを表しています。
This document would not have been possible without the contributions of a great number of people in the Performance Implications of Link Characteristics Working Group. In particular, the following people provided major contributions of text, editing, and advice on this document: Mark Allman provided the final editing to complete this document. Carsten Bormann provided text on robust header compression. Gorry Fairhurst provided text on broadcast and multicast issues, routing, and many valuable comments on the entire document. Aaron Falk provided text on bandwidth on demand. Dan Grossman provided text on many facets of the document. Reiner Ludwig provided thorough document review and text on TCP vs. Link-Layer Retransmission. Jamshid Mahdavi provided text on TCP performance calculations. Saverio Mascolo provided feedback on the document. Gabriel Montenegro provided feedback on the document. Marie-Jose Montpetit provided text on bandwidth on demand. Joe Touch provided text on multicast, broadcast, and routing, and Lloyd Wood provided many valuable comments on versions of the document.
この文書では、リンク特性ワーキンググループの業績への影響の人々の多くの貢献なしには不可能でした。具体的には、以下の人々は、この文書には、テキスト、編集、およびアドバイスの主要な貢献を提供：マーク・オールマンは、この文書を完成するために、最終的な編集を提供します。カルステンボルマンは、堅牢なヘッダ圧縮にテキストを提供しました。 Gorry Fairhurstは、ブロードキャストおよびマルチキャストの問題、ルーティング、および文書全体に多くの貴重なコメントにテキストを提供しました。アーロンフォークは、オンデマンドの帯域幅にテキストを提供しました。ダン・グロスマンは、文書の多くの側面にテキストを提供しました。ライナールートヴィヒは、リンク層の再送対TCPに徹底した文書のレビューとテキストを提供しました。ジャムシードMahdaviは、TCPのパフォーマンスの計算上のテキストを提供しました。サヴェリオMascoloは、ドキュメントに関するフィードバックを提供します。ガブリエル・モンテネグロは、ドキュメントに関するフィードバックを提供します。マリー・ジョゼMontpetitは、オンデマンドの帯域幅にテキストを提供しました。ジョー・タッチは、マルチキャスト、ブロードキャスト、およびルーティングの上にテキストを提供し、ロイド・ウッドは、文書のバージョンに多くの貴重なコメントを提供しました。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org.
フォームRFCnnnnの参照はwww.rfc-editor.orgからオンラインで入手できますコメント（RFC）文書のためのインターネット要求されています。
[802.1D] Information Technology Telecommunications and information exchange between systems Local and metropolitan area networks, Common specifications Media access control (MAC) bridges, IEEE 802.1D, 1998. ISO 15802-3.
[802.1D]情報技術通信とローカルシステムとメトロポリタンエリアネットワーク間での情報交換、共通仕様のメディアアクセス制御（MAC）ブリッジ、IEEE 802.1D、1998年ISO 15802-3。
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area Networks - Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Multicast.
[802.1P] IEEE、802.1P、ローカルおよびメトロポリタンエリアネットワークの標準 - メディアアクセス制御（MAC）ブリッジへの補足：トラフィッククラス迅速化およびマルチキャスト。
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End Network Path Properties, In Proceedings of ACM SIGCOMM 99.
[AP99]オールマン、M.およびV.パクソン、ACM SIGCOMM 99の議事録で推定エンドツーエンドのネットワークパスの性質に。
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-Demand (WFBoD) for Geo-Stationary Satellite Networks with On-Board Processing, Computer Networks, 39(1), 2002.
オンボード処理、コンピュータネットワーク、39（1）、2002年とジオ静止衛星ネットワークのための[AR02] ACAR、G.とC.ローゼンバーグ、加重公平な帯域幅オンデマンド（WFBoD）。
[ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000. http://www.atmforum.com/
[ATMFTM] ATMフォーラム、 "トラフィック管理仕様、バージョン4.0"、1996年4月、文書のAF-TM-0056.000。 http://www.atmforum.com/
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.
パケットの並べ替えにTCPはよりロバスト作ることに[BA02]ブラントン、E.およびM.オールマン、。 ACMコンピュータコミュニケーションレビュー、32（1）、2002年1月。
[Bel98] Bellovin, S., "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1998. http://www.research.att.com/~smb/papers/inet-crypto.pdf
[Bel98] Bellovin氏、S.、CRYPTO '98、1998年8月の議事録では、 "暗号とインターネット"、http://www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11," In Proceedings of ACM MobiCom, July 2001.
ACMモビコム2001年7月の議事録において：[BGW01]ボリソフ、N.、ゴールドバーグ、I。およびD.ワグナー、「802.11の不安傍受モバイルコミュニケーションズ」。
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The Effects of Asymmetry on TCP Performance." ACM Mobile Networks and Applications (MONET), 1998.
【BPK98】バラクリシュナン、H.、Padmanabhan、V.、およびR.カッツ。 「TCPパフォーマンス上の非対称性の影響。」 ACMモバイルネットワークとアプリケーション（MONET）、1998。
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet Reordering is Not Pathological Network Behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999.
[BPS99]ベネット,, J.C.R.、ヤマウズラ、C.およびN. Shectman、 "パケットの順序変更は、病理学的ネットワークの動作ではありません"、ネットワーキング、巻上のIEEE / ACM取引。図7に示すように、第6号、1999年12月。
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group Management Protocol (CGMP)", 1996/1997. ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[CGMP]ファリナッチD.、Tweedly A.およびT.スピークマン、 "シスコグループ管理プロトコル（CGMP）"、1996/1997。 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms" Crypto-Gram, December 15, 1999. http://www.counterpane.com
[Crypto9912]シュナイアー、B.、 "欧州の携帯電話の暗号化アルゴリズム" 暗号-グラム、12月15日、1999年http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp, Ethernet Local Area Network Specification Version 2.0, November 1982.
[DIX82]ディジタルイクイップメント社、インテル社、ゼロックス社、イーサネットローカルエリアネットワーク仕様バージョン2.0、1982年11月。
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.0, SP-RFI-I05- 991105, November 1999, Cable Television Laboratories, Inc.
[DOCSIS1]データオーバーケーブルサービスインターフェース仕様、無線周波数インターフェース仕様1.0、SP-RFI-I05- 991105、1999年11月、ケーブルテレビラボラトリーズ社
[DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.1, SP-RFIv1.1-I05- 000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS2]データオーバーケーブルサービスインターフェース仕様、無線周波数インターフェース仕様1.1、SP-RFIv1.1-I05- 000714、2000年7月、ケーブルテレビラボラトリーズ社
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of Large Data Packets on Upstream Capacity", 14th ITC Specialists Seminar on Access Networks and Systems, Barcelona, Spain, April 25-27, 2001.
[DOCSIS3]ライ、W.S.、「DOCSISベースのケーブルネットワーク：上流容量の大きなデータパケットの影響」、アクセスネットワークとシステム、バルセロナ、スペイン、4月25-27、2001年第14回ITCスペシャリストセミナー。
[EN301192] ETSI, European Broadcasting Union, Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting, European Standard (Telecommunications Series) EN 301 192 v1.2.1(1999-06).
[EN301192] ETSI、欧州放送連合（EU）、デジタルビデオ放送（DVB）;データ放送用DVB規格、欧州規格（電気通信シリーズ）301 192 V1.2.1（1999年から1906年）EN。
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair (ELF) Scheduling for Wireless Networks, Proceedings of IEEE Infocom 2000.
ワイヤレスネットワーク、IEEEインフォコム2000手続のため[ES00]エックハルト、D.およびP. Steenkiste、「エフォート限定フェア（ELF）スケジューリング。
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue Management for Congestion Control" to appear in Infocom 2000.
[FB00] Firoiu V.とM.ボーデン、インフォコム2000年に登場する「輻輳制御のためのアクティブキュー管理の研究」。
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED to Improve Fairness in High-Speed Networks", Proceedings of the 7th International Workshop on Protocols for High-Speed Networks, April 2002.
[GM02] Grieco1、L.とS. Mascoloは、高速ネットワーク、2002年4月のためのプロトコルで、第7回国際ワークショップの議事録を「TCPウエストウッドと簡単REDは、高速ネットワークにおける公正性を向上させます」。
[IEEE8023] IEEE 802.3 CSMA/CD Access Method. http://standards.ieee.org/
[IEEE8023] IEEE 802.3 CSMA / CDアクセス方法。 http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard. http://standards.ieee.org/
[IEEE80211] IEEE 802.11無線LAN規格。 http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", International Organization For Standardization, Fourth edition 1991- 06-01.
[ISO3309] ISO / IEC 3309：1991（E）、「情報技術 - システム間のテレコミュニケーションと情報交換 - ハイレベルデータリンク制御（HDLC）手順を - フレーム構造」、国際標準化機構、第四版1991- 06- 01。
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information Technology - Generic coding of moving pictures and associated audio information: Systems, Second edition, 2000-12-01 International Organization for Standardization and International Electrotechnical Commission.
[ISO13818] ISO / IEC、ISO / IEC 13818-1：2000（E）情報技術 - 動画及び関連するオーディオ情報のジェネリックコーディング：システム、第2版、標準化と国際電気について2000-12-01国際。
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification Type AAL5, International Standards Organisation (ISO), 1996.
[ITU-I363] ITU-T I.363.5 B-ISDN ATMアダプテーションレイヤ仕様タイプAAL5、国際標準化機構（ISO）、1996。
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance Algorithm. Email to the end2end-interest mailing list, April 1990. ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[Jac90]ジェーコブソン、V.、変更されたTCPの輻輳回避アルゴリズム。 end2end金利メーリングリストへの電子メール、4月1990 ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000, Proceedings of IEEE ICC, 2002.
[KY02] Khafizov、F.およびM.ヤヴズは、TCPオーバーを実行すると、IEEE ICC、2002年の議事録-2000です。
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM Computer Communication Review, Vol. 30, No. 1, January 2000.
[LK00]ルートヴィヒ、R.とR. H.カッツ、「アイフェルアルゴリズム：スプリアス再送に対するTCPは堅牢にする」、ACMコンピュータコミュニケーションレビュー、巻。 30、第1号、2000年1月。
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", Kluwer/ACM Wireless Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299, March-May 2002.
[LKJK02]ルートヴィヒ、R.、コンラート、A.、ジョセフ、A. D.とR. H.カッツ、Kluwerの/ ACMワイヤレスネットワーク誌、巻「ワイヤレスリンク上で信頼性の高いフローのエンドツーエンドのパフォーマンスの最適化」。 8、番号2/3、頁289-299、月 - 2002年5月。
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A. Joseph, Multi-Layer Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings of ACM SIGMETRICS 99.
【LRKOJ99]ルートヴィヒ、R.、Rathonyi、B.、コンラッド、A.、おでん、K.およびA.ジョセフ、信頼性の高い無線リンクを介してTCPのマルチレイヤトレース、頁144から154、ACM SIGMETRICSの会報で99。
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission Timer, ACM Computer Communication Review, Vol. 30, No. 3, July 2000.
[LS00]ルートヴィヒ、R.とK. Sklower、アイフェル再送信タイマー、ACMコンピュータコミュニケーションレビュー、巻。 30、第3号、2000年7月。
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick, "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", Work in Progress.
[MAGMA-PROXY]フェナー、B.、彼、H.、ハーバーマン、B.及びH. Sandick、 "IGMP / MLDベースのマルチキャスト転送（" IGMP / MLDプロキシ "）"、ProgressのWork。
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", Work in Progress.
[MAGMAスヌープ]クリステンセン、M.、キンボール、K.およびF. Solensky、 "IGMPやMLDスヌーピングスイッチの考慮事項"、ProgressのWork。
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic Evaluation of RED Performance", INFOCOM 2000.
【MBB00]月、M.、ボナルド、T.およびJ-C。 Bolot、 "REDパフォーマンスの分析評価"、インフォコム2000。
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not to deploy RED", Proc. of 7th. International Workshop on Quality of Service (IWQoS'99), June 1999.
【MBDL99]月、M.、Bolot、J.、Diot、C.及びB. Lyles、PROC "REDを展開しない理由"。第七の。サービス品質に関する国際ワークショップ（IWQoS'99）、1999年6月。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, Vol. 27, number 3, July 1997.
[MSMO97]マシス、M.、Semke、J.、Mahdavi、J.およびT.オット、コンピュータコミュニケーションレビュー、集 "TCPの輻輳回避アルゴリズムの巨視的挙動"。 27、数3、1997年7月。
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A., Seitz, C., et al. MYRINET: A Gigabit per Second Local Area Network, IEEE-Micro, Vol. 15, No.1, February 1995, pp. 29-36.
【MYR95】ボーデン、N.、コーエン、D.、Felderman、R.、Kulawik、A.、サイツ、C.、ら。 Myrinetのセカンドローカルエリアネットワーク、IEEE-マイクロ、巻あたりギガビット。 15、No.1の、1995年2月、頁29-36。
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP Throughput: a Simple Model and its Empirical Validation", UMASS CMPSCI Tech Report TR98- 008, Feb. 1998.
[PFTK98] Padhye、J.、Firoiu、V.、Towsley、D.とJ.黒瀬、 "モデルTCPスループット：簡単なモデルとその実証的検証"、UMASS CMPSCIテックレポートTR98- 008、1998年2月。
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions in Networking, Vol. 1 No. 4, August 1993. http://www.aciri.org/floyd/papers/red/red.html
[RED93]フロイド、S.とV. Jacobson氏、 "輻輳回避のためのランダム早期検出・ゲートウェイ"、ネットワーキング、巻でIEEE / ACM取引。 1第4号、1993年8月http://www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over ATM Networks". IEEE Journal of Selected Areas in Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RF95] Romanow、A.とS.フロイド、 "ATMネットワーク上のTCPトラフィックのダイナミクス"。コミュニケーションにおける選択された領域のIEEEジャーナル、Vol.13第4号、1995年5月、P。 633から641まで。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48-bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]プラマー、D.C.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するための48ビットイーサネットアドレスにネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]ブレーデン、R.、ボーマン、D.およびC.ヤマウズラ、 "インターネットチェックサムの計算"、RFC 1071、1988年9月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1332] McGregor, C., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、C.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]ノウルズ、S.、 "パスMTUディスカバリの経験からIESGアドバイス"、RFC 1435、1993年3月。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]シンプソン、W.、エド。、 "PPP HDLCのようなフレーミングで"、STD 51、RFC 1662、1994年7月。
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]イーストレイク3日、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.とJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991]アトキンス、D.、ストーリングス、W.およびP.ツィンマーマン、 "PGPメッセージ交換フォーマット"、RFC 1991、1996年8月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、1997年9月。
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]マンキン、A.、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、O`Dell、M.、Romanow、A.、Weinrib、A.およびL.チャン、「リソース予約プロトコル（RSVP ） - バージョン1適用性に関する声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、 "制御負荷ネットワーク要素サービスの仕様"、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook, "Management of IP numbers by peg-dhcp", RFC 2322, 1 April 1998.
[RFC2322]ヴァンデンハウト、K.、Koopal、A.とR.バンムック、 "PEG-DHCPでIP番号の管理"、RFC 2322、1998年4月1日。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[RFC2332]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コール、B.およびN. Doraswamy、 "NBMAネクストホップ解決プロトコル（NHRP）"、RFC 2332、1998年4月。
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364]グロス、G.、Kaycee、MはLi、A.、Malis、A.およびJ.スティーブンス、 "PPPオーバーAAL5"、RFC 2364、1998年7月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394]ペレイラ、R.、 "DEFLATEを使用するIPペイロード圧縮"、RFC 2394、1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395]フレンド、R.とR. Monsour、 "IPペイロード圧縮使い方LZS"、RFC 2395、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2474] 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.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2632] Ramsdell、B.、エド。、 "S / MIMEバージョン3証明書の取り扱い"、RFC 2632、1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月。
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
"リアルタイム指向HDLCのようなフレーミングでPPP" [RFC2687]ボルマン、C.、RFC 2687、1999年9月。
[RFC2689] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[RFC2689]ボルマン、C.、 "低ビットレートリンク上で統合サービスの提供"、RFC 2689、1999年9月。
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
"IPv6のためのマルチキャストリスナー発見（MLD）" [RFC2710]デアリング、S.、フェナー、W.およびB.ハーバーマン、RFC 2710、1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.とW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、エド。、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K. 、劉、Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.及びH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、 UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096] Degermark、M.編、 "ロバストなIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年7月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]ドーキンス、S.、モンテネグロ、G.、古城、M.およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、BCP 48、RFC 3150、2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155]ドーキンス、S.、モンテネグロ、G.、古城、M.、Magret、V.およびN. Vaidya、 "エラーとリンクのエンドツーエンドのパフォーマンスへの影響"、BCP 50、RFC 3155、2001年8月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "IPに明示的輻輳通知（ECN）の追加"、RFC 3168、2001年9月。
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[RFC3173] Shacham、A.、Monsour、B.、ペレイラ、R。およびM.トーマス、 "IPペイロード圧縮プロトコル（のIPComp）"、RFC 3173、2001年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J., Halpern, J., Kumar, B. and J. Schnizlein, "A Delay Bound alternative revision of RFC 2598", RFC 3248, March 2002.
[RFC3248]アーミテージ、G.、大工、B.、カザーティ、A.、クロウクロフト、J.、アルペルン、J.、クマー、B.及びJ. Schnizlein、 "RFC 2598の遅延限界代替のリビジョン"、RFC 3248 、2002年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366] Fairhurst、G.とL.ウッド、BCP 62、RFC 3366、2002年8月 "リンク自動再送要求（ARQ）にデザイナーをリンクするためのアドバイス"。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.とA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]バラクリシュナン、H.、Padmanabhan、V.、Fairhurst、G.およびM. Sooriyabandara、 "ネットワークパス非対称のTCPパフォーマンスへの影響"、BCP 69、RFC 3449、2002年12月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.及びJ.クロウクロフト、RFC 3450 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、2002年12月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451、2002年12月。
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[RFC3452]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453、 2002年12月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]呉、I.およびT.エッカート、 "シスコシステムズルータポートグループ管理プロトコル（RGMP）"、RFC 3488、2003年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed. and G. Fairhurst, Ed., "The User Datagram Protocol (UDP)-Lite Protocol", RFC 3828, June 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、ピンク、S.、ジョンソン、L-E。、エド。そして、G. Fairhurst、エド。、 "ユーザーデータグラムプロトコル（UDP）-Liteプロトコル"、RFC 3828、2004年6月。
[Schneier95] Schneier, B., Applied Cryptography: Protocols, Algorithms and Source Code in C (John Wiley and Sons, October 1995).
[Schneier95]シュナイアー、B.、適用された暗号：プロトコル、アルゴリズムおよびCにおけるソースコード（ジョン・ワイリー・アンド・サンズ、1995年10月）。
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a Networked World (John Wiley and Sons, August 2000).
[Schneier00]シュナイアー、B.、秘密と嘘：ネットワークの世界ではデジタル・セキュリティー（ジョン・ワイリー・アンド・サンズ、2000年8月）。
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", ACM SIGCOMM, September 2000. http://www.acm.org/sigcomm/sigcomm2000/conf/ paper/sigcomm2000-9-1.pdf
[SP2000]ストーン、J.とC.ヤマウズラ、 "CRCとTCPチェックサムが同意しない"、ACM SIGCOMM、2000年9月http://www.acm.org/sigcomm/sigcomm2000/conf/紙/ sigcomm2000-9- 1.pdf
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End Arguments in System Design". Second International Conference on Distributed Computing Systems (April, 1981) pages 509-512. Published with minor changes in ACM Transactions in Computer Systems 2, 4, November, 1984, pages 277-288. Reprinted in Craig Partridge, editor Innovations in internetworking. Artech House, Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[SRC81] Saltzer、J.、リードD.とD.クラーク、「システム設計におけるエンド・ツー・エンドの引数」。分散コンピューティングシステム上の第二国際会議（4月、1981）頁509-512。コンピュータシステム2、4、11月、1984年、ページ277-288でACM取引の小さな変化で公開されました。クレイグ・パートリッジ、インターネットワーキングでは、エディタのイノベーションに復刻。アーテックハウス、ノーウッド、MA、1988、ページ195-206。 ISBN 0-89006-337-0。
[SSL2] Hickman, K., "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.
[SSL2]ヒックマン、K.、 "SSLプロトコル"、ネットスケープ・コミュニケーションズ社、1995年2月9日。
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[SSL3] Frier、A.、Karlton、P.およびP.コッヘル、 "SSL 3.0プロトコル"、ネットスケープ・コミュニケーションズ社、1996年11月18日。
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies: Analysis and Improvements", IEEE Infocom, March 1998. http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf
【TCPF98】リン、D.及びH.T.クン、「TCP高速リカバリ戦略：分析と改善」、IEEEインフォコム、1998年3月http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A First Step Toward Automated Detection of Buffer Overrun Vulnerabilities", Proceedings of NDSS2000. http://www.isoc.org/isoc/conferences/ndss/ 2000/proceedings/039.pdf
【WFBA2000】ワグナー、D.、フォスター、J.、ブリューワー、E.、およびA.エイケン、NDSS2000の会報「バッファオーバーランの脆弱性の自動検出の第一歩」。 http://www.isoc.org/isoc/conferences/ndss/ 2000 /手続き/ 039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama. "MAC layer Security Measures in Local Area Networks", Local Area Network Security, Workshop LANSEC '89 Proceedings, Springer-Verlag, April 1989, pp. 53-64.
[Wilbur89]ウィルバー、スティーブ・R.、ジョンクロウクロフト、および村山優子。 「ローカルエリアネットワークにおけるMAC層のセキュリティ対策」、ローカルエリアネットワークセキュリティ、ワークショップLANSEC '89予稿集、シュプリンガー・フェアラーク、1989年4月、頁53-64。
Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292
アーロンフォークUSC /情報科学研究所4676アドミラルティWayマリナデルレイ、CA 90292
Phone: 310-448-9327 EMail: falk@isi.edu
電話：310-448-9327 Eメール：falk@isi.edu
Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
電気電子工学のサヴェリオMascolo部門、工科バーリ経由Orabona 4、70125バリ、イタリア
Phone: +39 080 596 3621 EMail: mascolo@poliba.it URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
電話：+39 080 596 3621 Eメール：mascolo@poliba.it URL：http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit MJMontpetit.com
マリー・ジョゼMontpetit MJMontpetit.com
EMail: marie@mjmontpetit.com
メールアドレス：marie@mjmontpetit.com
Phil Karn, Editor Qualcomm 5775 Morehouse Drive San Diego CA 92121
フィル・カーン、エディタクアルコム5775モアハウスドライブサンディエゴCA 92121
Phone: 858 587 1121 EMail: karn@qualcomm.com
電話：858 587 1121 Eメール：karn@qualcomm.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
電話：+49 421 218 7024ファックス：+49 421 218 7000 Eメール：cabo@tzi.org
Godred (Gorry) Fairhurst Department of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, United Kingdom
Godred（Gorry）Fairhurst工学科、アバディーン大学、アバディーン、AB24 3UE、イギリス
EMail: gorry@erg.abdn.ac.uk URL: http://www.erg.abdn.ac.uk/users/gorry
メールアドレス：gorry@erg.abdn.ac.ukのURL：http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman Motorola, Inc. 111 Locke Drive Marlboro, MA 01752
ダン・グロスマンモトローラ社111ロックドライブマールボロ、MA 01752
EMail: Dan.Grossman@motorola.com
メールアドレス：Dan.Grossman@motorola.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
ライナールートヴィヒ・エリクソン研究エリクソンアリー1 52134 Herzogenrathの、ドイツ
Phone: +49 2407 575 719 EMail: Reiner.Ludwig@ericsson.com
電話：+49 2407 575 719 Eメール：Reiner.Ludwig@ericsson.com
Jamshid Mahdavi Novell, Inc.
ジャムシードMahdaviノベル株式会社
EMail: jmahdavi@earthlink.net
メールアドレス：jmahdavi@earthlink.net
Gabriel Montenegro Sun Microsystems Laboratories, Europe 180, Avenue de l'Europe 38334 Saint Ismier CEDEX France
ガブリエルモンテネグロSun Microsystemsの研究所、ヨーロッパ180、アベニュードゥヨーロッパ38334サンIsmierセデックスフランス
EMail: gab@sun.com
メールアドレス：gab@sun.com
Joe Touch USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey CA 90292
ジョー・タッチUSC /情報科学研究所4676アドミラルティWayマリナデルレイCA 90292
Phone: 310 448 9151 EMail: touch@isi.edu URL: http://www.isi.edu/touch
電話：310 448 9151 Eメール：touch@isi.edu URL：http://www.isi.edu/touch
Lloyd Wood Cisco Systems 9 New Square Park, Bedfont Lakes Feltham TW14 8HA United Kingdom
ロイド・ウッドシスコシステムズ9新スクエアパーク、Bedfont湖フェルサムTW14 8HAイギリス
Phone: +44 (0)20 8824 4236 EMail: lwood@cisco.com URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
電話：+44（0）20 8824 4236 Eメール：lwood@cisco.com URL：http://www.ee.surrey.ac.uk/Personal/L.Wood/
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。