RFC3819 日本語訳
3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C.Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G.Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT=152174 bytes) (Also BCP0089) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループP.Karn、エドをネットワークでつないでください。コメントのために以下を要求してください。 3819クアルコムBCP: 89C.ボルマンカテゴリ: 最も良い現在の習慣のJ.MahdaviノベルG.モンテネグロサン・マイクロシステムズUniversitaetブレーメンTZI G.FairhurstアバディーンD.グロースマンモトローラR.ラドウィグエリクソン大学研究研究所、ヨーロッパJ.接触USC/ISI L.は2004年7月にシスコシステムズを植林します。
Advice for Internet Subnetwork Designers
インターネットサブネットワークデザイナーのためのアドバイス
Status of this Memo
この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).
Copyright(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.
このドキュメントは、インターネットプロトコルをサポートしたがっているディジタル通信設備のデザイナー、リンク層プロトコル、およびパケットで切り換えられた企業内情報通信網(サブネットワークとまとめて呼ばれる)にアドバイスを提供しますが、性能の彼らのデザイン選択とインターネットの効率のインターネット構造と含意になじみがないかもしれません。
Karn, et al. Best Current Practice [Page 1] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[1ページ]RFC3819アドバイス
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
1. 序論と概観。 . . . . . . . . . . . . . . . . . . 2 2. マキシマム・トランスミッション・ユニット(MTUs)とIP断片化. . . . 4 2.1。 遅いネットワークでMTUを選びます。 . . . . . . . . . . . 6 3. 接続指向のサブネットワーク. . . . . . . . . . 7 4の上で縁どっています。 接続指向のサブネットワーク。 . . . . . . . . . . . . . . . 9 5. 放送と発見. . . . . . . . . . . . . . . . . . 10 6。 マルチキャスティング. . . . . . . . . . . . . . . . . . . . . . . . . 11 7。 帯域幅のオンデマンドの(体)サブネット。 . . . . . . . . . . . . . . 13 8. 信頼性と誤り制御。 . . . . . . . . . . . . . . . . 14 8.1. TCP対リンクレイヤRetransmission. . . . . . . . . . . . 14 8.2 サブネットワーク供給停止. . . . . . . . . . . . 17 8.3からの回復。 CRCs、チェックサム、および誤り検出。 . . . . . . . . . . 18 8.4. TCPはどう働いているか。 . . . . . . . . . . . . . . . . . . . . . 20 8.5. TCPパフォーマンスの特性。 . . . . . . . . . . . . 22 8.5.1. 公式. . . . . . . . . . . . . . . . . . 22 8.5.2。 仮定。 . . . . . . . . . . . . . . . . . . 23 8.5.3. TCPパフォーマンスのリンクレイヤ効果の分析。 . . . . . . . . . . . . . . . . . . 24 9. サービスの質(QoS)問題。 . . . . . . . . . . . 26 10. 公正対パフォーマンス . . . . . . . . . . . . . . . . . . . 29 11. 特性を遅らせてください。 . . . . . . . . . . . . . . . . . . . . 30 12. 帯域幅ひずみ。 . . . . . . . . . . . . . . . . . . . . 31 13. バッファリング、流れ、および混雑は.31 14を制御します。 圧縮。 . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. パケットReordering。 . . . . . . . . . . . . . . . . . . . . . . 36 16. 移動性. . . . . . . . . . . . . . . . . . . . . . . . . . . 37 17。 ルート設定。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 41 19. 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 44 20。 有益な参照. . . . . . . . . . . . . . . . . . . . 45 21。 貢献者のアドレス。 . . . . . . . . . . . . . . . . . . . 57 22. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 58 23。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 60
1. Introduction and Overview
1. 序論と概観
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(すなわち、終わりのホストかルータ)を使用することで2台以上のシステムを接続するためにIP層のすぐ下で作動するどんなネットワークも示します。 最も簡単なフォームでは、これはIPシステム(例えば、ケーブルの長さか無線の媒体を使用する)の間のダイレクト接続であるかもしれません。
Karn, et al. Best Current Practice [Page 2] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[2ページ]RFC3819アドバイス
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.
このドキュメントは2がネットワークでつなぐ層とサブネットワークを定義します。(それは、サブネットワークの部分の間にパケットを送るためにIPルータのサービスを当てにされないネットワークです)。 しかしながら、IPルータはサブネットワークの部分の間にLayer2にフレームに橋を架けるかもしれません。 時々、単一の論理的なサブネットワークへのそのようなサブネットワークのグループに集めるのは便利です。 IPルーティング・プロトコル、(例えば、OSPF、-、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つの補足的な問題がかかわります:
1. Providing functionality sufficient to carry IP.
1. IPを運ぶことができるくらいの機能性を提供します。
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。
Karn, et al. Best Current Practice [Page 3] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[3ページ]RFC3819アドバイス
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.
どんな層にされた通信ネットワークの効率的なデザインにおける主要な考慮も与えられた機能を実行する適切な層です。 この問題は精液の紙に記述された1番目、「システム設計における終わりから終わりへの議論」[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サポートに関連していると考える様々なサブネットワークデザイン問題について議論します。
2. Maximum Transmission Units (MTUs) and IP Fragmentation
2. マキシマム・トランスミッション・ユニット(MTUs)と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パケットとして与えられたサブネットワークには、断片に大き過ぎるパケットを壊す計画にその旅行を提供するとき(64KB)の最大サイズのIPパケットを支持する必要はなくて、目的地で組み立て直されます。 サブネットワークによって支持された最大のパケットサイズはMaximum Transmission Unit(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
必要でなく、それらが運ぶそれぞれのパケットの長さを示して、サブネットワークはそうするかもしれません。 1つの例が広く使用されたDIX[DIX82](IEEE802.3でない[IEEE8023])ヘッダーがあるイーサネットです。(ヘッダーは長さを欠いています)。
Karn, et al. Best Current Practice [Page 4] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[4ページ]RFC3819アドバイス
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メッセージはひどく制限しているファイアウォールによって妨げられます。 結果は[RFC2923][RFC1435]「経路MTUブラックホール」であることができます。
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.
Path MTUディスカバリー手順、経路MTUブラックホールの固執、およびIPv6でのルータ断片化の削除はルータ断片化を最も良い避けるというインターネット技術団体のコンセンサスを反映します。 これは、サブネットワークが「合理的に」大きいMTUsを支持するのを必要とします。 すべての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パケットを内部のデータ要素に細かく分けて、サブネットワークのもう一方の端でそれらを組み立て直すべきです。
Karn, et al. Best Current Practice [Page 5] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[5ページ]RFC3819アドバイス
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と100Mb/s)には1500バイトのMTUがあります、そして、イーサネットの偏在のために、わずかなインターネット経路でしかMTUsは現在、この値より大きくなりません。 これは厳しく他のサブネットワークによって提供されたより大きいMTUsに関するユーティリティを制限します。 implementersはその間、より大きいMTUsがますますホストコンピュータで1パケットあたりの処理オーバヘッドを下げる高速サブネットワークで望ましく、イーサネットが経路にもあるとき、彼らが使用可能でないかもしれませんが、彼らを提供するよう奨励されます。
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.
トンネルモード[RFC2406]によるGRE[RFC2784]かIP Securityなどの様々な「トンネリング」計画はIPのためにサブネットワークとしてIPを扱います。 トンネリングがヘッダーオーバーヘッドを加えるので、断片化の引き金となることができます、同じ物理的なサブネットワーク(例えば、イーサネット)がIPsecカプセル化を実行しているホストの両側で使用さえされるとき。 トンネリングは、ルータ断片化を避けるのをより難しくして、経路MTUブラックホール[RFC2401][RFC2923]の発生を増加させました。 より大きいサブネットワークMTUsは、この問題を軽減するのを助けるかもしれません。
2.1. Choosing the MTU in Slow Networks
2.1. 遅いネットワークで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.
遅いネットワークでは、可能な限り大きいパケットは、発信するにはかなりの時かかるかもしれません。 これはチャネル化か連載遅れとして知られています。 原稿Thisがすべてのソースを含む総終わりによる対話的な応答時間が周知の人間の要素限界を超えるべきでない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.536Mb/s)リンクを転送するためにおよそ8ミリセカンドと同じくらい取るでしょう。 しかし、リンク速度が19.2kb/sであるなら、トランスミッション時間はかなり私たちの100-200ms限界を超えて625msになります。 256バイトのMTUは100余り原稿余りHoweverにこの遅れを下ろして、MTUを過度に下ろさないように注意するべきです、これがヘッダーオーバーヘッドを上げて、頻繁なルータ断片化の引き金となるとき(Path MTU発見が使用中でないなら)。 これはマルチキャストがあるケースである傾向があります。そこでは、Path 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)
小さいMTUを課すことのない対話的な通信への遅れがこの交通を最優先させて、先取りすることになっている限界に、一方通行です。(アボート)
Karn, et al. Best Current Practice [Page 6] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[6ページ]RFC3819アドバイス
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.
より高い優先権パケットであるときに、低優先度パケットのトランスミッションは待ち行列に到達します。 しかしながら、中止になっているパケットを送るのに使用されるリンクリソースは無くなります、そして、総合的なスループットは減少するでしょう。
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パケットのセグメントがトランスミッション優先で。 Pointからポイントへのプロトコル(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.
ATM(非同期通信モード)はSNDUsが、より小さい53バイトのATMセルの向こう側に断片化されて、はさみ込まれるところのこのテクニックに関する別の例です。 しかしながら、一般に、ATMは店とフォワード遅れが既に最小限であり、それがそれぞれの48バイトのATMセルへの5バイトのセルオーバーヘッドの添加によるオーバーヘッドのかなり(~9%)の増加を導入する高速リンクの上に使用されます。
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.56Mb/sか5.12Mb/sの典型的な上流の帯域幅があるData過剰Cable Service Interface Specification(DOCSIS)です。 DOCSIS1.0[DOCSIS1]の1500年のバイトのMTUの衝撃を減少させるために、データ・リンク層断片化メカニズムはDOCSIS1.1[DOCSIS2]で指定されます。 インストールされたベースを収容するために、DOCSIS1.1は1.0が一般に、断片化を支持しないモデムに電報を打つDOCSISと互換性があった状態で後方でなければなりません。 DOCSIS1.0とDOCSIS1.1の共存の下では、DOCSIS1.1から影響するかもしれないDOCSIS1.0からのパケットが音声パケットのためのサービスの質にモデムに電報を打つ非断片化している大きいデータはモデムに電報を打ちます。この場合、[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.
まとめるために覚えておく、効率と潜在の間には、サブネットワークのデザインに基本的な見返りがあって、デザイナーはこの見返りを覚えておくべきです。
3. Framing on Connection-Oriented Subnetworks
3. 接続指向のサブネットワークの上で縁どっています。
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パケットの首尾をマークするのを必要とします。 本質的な特徴としてこれを提供しないリンクとサブネットワークに関するいくつかの例は:
1. leased lines carrying a synchronous bit stream;
1. シンクロナスビットを運ぶ専用線が流れます。
2. ISDN B-channels carrying a synchronous octet stream;
2. 同期八重奏を運ぶISDN Bチャネルが流れます。
3. dialup telephone modems carrying an asynchronous octet stream;
3. 非同期な八重奏を運ぶダイアルアップ電話モデムが流れます。
Karn, et al. Best Current Practice [Page 7] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[7ページ]RFC3819アドバイス
and
そして
4. Asynchronous Transfer Mode (ATM) networks carrying an
asynchronous stream of fixed-sized "cells".
4. 修理サイズの「セル」の非同期な流れを運ぶ非同期なTransfer Mode(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].
インターネットコミュニティはこれらのすべてのサブネットワークのためにパケット縁どり方法を定義しました。 Pointからポイントへのプロトコル(PPP)[RFC1661]は噛み付いている同時の、そして、八重奏同時の、そして、八重奏非同期なリンク(すなわち、1-3 上記の例)に適切です。(それは、HDLCの異形を使用します)。 多くのシステムがPPPと共に共同利用するので、PPPは1つのIPに、都合のよい縁どり方法です。 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を区切るサブネットワークの既存の性能を当てにすることです。 好例はイーサネットです。 しかしながら、いくつかのサブネットワークで、1以上のSNDUsにサイズを固定しています、切り換え、前進型誤信号訂正、そして/または、問題をはさみ込むことによって書き取られるように。 そして、そのようなサブネットワークに関する例はATMを含んでいます、48の八重奏の単細胞ペイロードサイズと5八重奏ヘッダーと共に-95である、それぞれ20ミリセカンドの境界で選択されるかもしれない2「レートセット」の4つの固定フレーム・サイズがあるデジタル携帯電話。
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パケットの間の境界をマークしている間、IPパケットをSNDUsに変換するのに必要です。
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
この問題へのいくつかのアプローチがあります。 1番目は、SNDUが1つ以上のIPパケットの断片を含まないでそれぞれのIPパケットを1SNDUsにコード化して、必要に応じてパケットの最後のSNDUを広げることです。 各SNDUに加えられたコントロールヘッダーのビットは、IPパケットにはデータ・セグメントがどこにあるかを示します。 サブネットワークが整然とした状態で提供されるなら大部分、一度、配送、ヘッダーはSNDUがIPパケットの1番目、そして/または、最終であるかどうかを示す1組のビットと同じくらい簡単であることができます。 あるいはまた、SNDUの断片を追加注文でないのにするサブネットワークに関してパケットの最後のSNDUしかマークできませんでした、これがそれとなくそうするように
Karn, et al. Best Current Practice [Page 8] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[8ページ]RFC3819アドバイス
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.
新しいIPパケットにおける1番目として次のSNDUを示してください。 ATMと共に使用されるAAL5(ATM Adaptation Layer5)計画はこのアプローチに関する例です、他の特徴を加えますが、ペイロード長分野を含んでいてペイロードは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 User-ユーザIndication(ATMセルの有効搭載量Type分野でコード化される)はパケットの最後のセルを示します。 パケットトレーラは、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).
別の縁どりのテクニックはセグメントオプションの存在を示すために1セグメントあたりのオーバーヘッドを挿入することです。 存在しているとき、オプションはパケットの端までポインタを運びます。 これは別のパケットが同じセグメントの中で続くことを許可するという点においてAAL5と異なっています。 MPEG-2Transport Streams[EN301192][ISO13818]が、このスタイルの断片化を支持して、詰め物(1つのIPパケットの一部だけを運ぶためにそれぞれのMPEG輸送流れのパケットを制限する)を使用するか、または2番目のIPパケットが同じTransport Streamパケット(水増ししない)で始まるのを許容するかもしれません。
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.
3番目のアプローチは、それぞれのIPパケットの間のデータ・ストリームの中に特別なフラグ・シーケンスを挿入して、SNDU境界への尊敬なしで結果として起こるデータ・ストリームにSNDUsに詰め込むことです。 これには、フレームが無くなるとき、意味があるかもしれません。 また、フラグ・シーケンスはSNDUの端で未使用のスペースを水増しできます。 特別な旗が利用者データに現れるなら、それ、旗として誤解されるのを避けるために代替順序(通常旗より大きい)に逃げられます。 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つの適合計画がオーバーヘッドを導入します。 どれくらい多くかがIPパケットサイズ、SNDUs、およびHDLCのようなアプローチ(IPパケット(以来、パケットの系列発生(それらを広げる)から逃げなければならないように弛む)の内容)におけるサイズの分配によります。 また、デザイナーは適合層の選択とデザインにおける実現の複雑さと性能を熟慮しなければなりません。
4. Connection-Oriented Subnetworks
4. 接続指向のサブネットワーク
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には、「接続」の考えが全くありません。 それは純粋にコネクションレスなプロトコルです。 接続がアプリケーションで必要であるときに、通常、それはTCP[RFC793]によって提供されます、通信制御プロトコル、終わりから終わりへのベースのIPの上を走って。
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
接続指向のサブネットワークがIPを運ぶのに使用されますが(そして広くである)、しばしばかなりの複雑さと共にあることができます。 わずかなノードから成るサブネットワークは単にそれぞれの組のノードの間の永久接続を開くことができます。 ATMと共にこれを頻繁にします。 しかしながら、ポートの数はノードの数の二乗として増加して、そうはこれです。
Karn, et al. Best Current Practice [Page 9] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[9ページ]RFC3819アドバイス
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とサブネットワークの間の「詰め物」層が、接続を管理するのに必要です。 これはIPとサブネットワークの間のSubnetwork Dependent Convergence Function(SNDCF)副層の最も一般的な機能の1つです。
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).
SNDCFsはIPパケットがトランスミッションのために列に並ばせられるとき、必要に応じてサブネットワーク接続を通常開いて、アイドルタイムアウトの後に彼らを閉じます。 より高い層(例えば、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.
インターネットトラフィックが適応する通常burstyとトランザクションであるので、最適のアイドルタイムアウトを選ぶのはしばしば難しいです。 タイムアウトが短過ぎるなら、サブネットワーク接続は、急速に開かれて、閉店します、ことによるとサブネットワーク接続マネージメントシステムを過度に強調して(特にそれが音声トラヒック呼び出し把持回数のために設計されたなら)。 タイムアウトが長過ぎるなら、サブネットワーク接続はよく無駄です、サブネットワークによってそれらに捧げられたどんなリソースも浪費して。
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やFrame Relayなどの)はそれほど最適ではありません、ベストエフォート型IPが状態を創設して、維持するオーバーヘッドの利益を得ないので。(パケット網は、状態を持って、ダイナミックにリソースを共有します)。 接続指向の回路交換ネットワーク(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をサポートするのに使用されるなら、サブネットにおける接続処理が比較的短い把持時間について行くことができるのを確実にするために注意するべきです。
5. Broadcasting and Discovery
5. 放送と発見
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つのカテゴリになります: 二地点間で共有されています。 二地点間サブネットには、まさに2つの終点コンポーネント(ホストかルータ)があります。 共有されたリンクには、2つ以上の終点コンポーネントがあります、本来放送された媒体(例えば、イーサネット、ラジオ)かネットワーク層隠された切り換え層(例えば、イーサネット、Myrinet[MYR95]、ATMを切り換える)のどちらかを使用して。 切り換えられたサブネットワークは放送パケットをコピーすることによって、放送を扱います、1つをサポートする各インタフェース、または以上(それぞれのパケットのコピーがあるシステム(ホストかルータ))を提供して
Karn, et al. Best Current Practice [Page 10] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[10ページ]RFC3819アドバイス
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プロトコルはマルチキャスティングを使用します(次のセクションを見ます)。
6. Multicasting
6. マルチキャスティング
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の標準装備です。 いくつかのマルチメディア、電子会議、ゲーミング、およびファイル分配(ウェブ、ピアツーピア共有)アプリケーション、主要なネットワーク、およびホストプロトコル(例えば、RIPv2、OSPF、NTP)によってIPv4マルチキャストは現在、使用されます。 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ルータは、それぞれのマルチキャストグループをスパニングツリーへまとめて、それぞれのマルチキャストパケットと推進のコピーをマルチキャストグループの少なくとも1人の川下のメンバーを含んでいるそれぞれの出力インタフェースへのコピーにすることによって、ルートマルチキャストパケットをまとめます。
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部だけを送らなければなりません、マルチキャストグループの何人のメンバーがセグメントに接続されても。 ネイティブのマルチキャストサポートがなければ、共有されたリンクの上のルータとスイッチは、ソフトウェアフィルタによる放送を使用する必要があって、あらゆるマルチキャストパケットが発信したようなものはサブネットワークの上のあらゆるノードのためにソフトウェアオーバーヘッドを被ります、ノードがマルチキャストグループのメンバーでなくても。 交互に、ルータはそのままなセグメントに関するマルチキャストグループのすべてのメンバーに別々のコピーをマルチキャスト不可能な切り換えられたサブネットでしていた状態で伝えるでしょう。
Karn, et al. Best Current Practice [Page 11] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[11ページ]RFC3819アドバイス
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、Ethernets)を使用するサブネットワークはネイティブのマルチキャスティングに特に適しています、そして、彼らのデザイナーはそれをサポートするためにあらゆる努力するべきです。 これは、マルチキャスティングのためにサブネットワークの自己のアドレス空間のセクションを指定することを伴います。 これらのネットワークでは、マルチキャストは媒体の上でLayer-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層が関連ホストが申し込むマルチキャスト(そして、ユニキャスト)トラフィックのすべて、およびホストが申し込まないマルチキャストトラフィックのあるわずかな部分を受ける「論じ尽くす」機能を実装します。 そして、ホスト/ルータソフトウェアはLayer-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.
そこでは、Layer-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つのオプションは放送されるように同じ方法でマルチキャストパケットをあふれさせる」ことです。 これがいくつかのサブネットワークリンクにおける不要なトランスミッションに通じることができる、(著しさ、非マルチキャスト意識する、イーサネットスイッチ) したがって、いくつかのサブネットワークで、マルチキャストフィルタテーブルは、どのリンクが特定のグループのものパケットを受けるかを制御できます。 自動的にこれを構成するのはLayer-3グループ会員資格情報(例えば、IGMP[RFC3376]、またはMLD[RFC2710])へのアクセスを必要とします。 様々な実装オプションは、現在、ポート/インタフェースへのマルチキャストアドレスに関するマッピングのリストをサブネットノードに提供するために存在します。 これらはさまざまなアプローチを使います、終わりのホスト(例えば、IEEE802ガープ/GMRP[802.1p])から合図するのを含んでいて、IPグループ会員資格パケット(例えば、IGMP/MLD Proxy[MAGMA-PROXY])と、Layer-2を有効にするスイッチ(例えば、CGMP[CGMP]とRGMP[RFC3488])、妨害、およびプロキシから進められたLayer-3プロトコルヘッダーへの/覗き見を詮索するか、または点検するようにデバイスに合図して(例えば。
Karn, et al. Best Current Practice [Page 12] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[12ページ]RFC3819アドバイス
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) 彼らがLayer-3マルチキャストを推論できるように、会員資格[MAGMA-スヌープ]を分類してください。 これらのアプローチはそれらの複雑さ、柔軟性、および新しいプロトコルをサポートする能力において異なります。
7. Bandwidth on Demand (BoD) Subnets
7. 帯域幅のオンデマンドの(体)サブネット
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つ以上のパケット(または、パケット断片)を送るのを許容できるくらいのトランスミッションの機会の計画をして、与えます。 私たちは、Demand(BoD)サブネットにこれらのサブネットをBandwidthと呼びます。 BoDサブネットに関する例はIEEE802.11ポイントコーディネート機能(PCF)のDemand Assignment Multiple Access(DAMA)衛星、地球のワイヤレス・ネットワーク、モード、およびDOCSISを含んでいます。 接続指向のネットワーク(PSTN、ATMまたはFrame Relayなどの)は、はるかに長いスケールでリソースを予約して、したがって、私たちの分類学の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.
実装はかなり異なったかもしれませんが、BoDが接続においてそれらと同様であるので、デザインパラメタはサブネットワークを適応させました。 BoDでは、ユーザは何らかの持続時間のために共有されたチャンネルへのアクセスを通常要求します。 しばらくある数のパケットの特定の速度で割り当てるか、またはユーザがチャンネルを釈放するまで、アクセスはそうです。 アクセスは中央の経営体か分配されたアルゴリズムがユーザの中のひとりで調整されるかもしれません。 共有されるかもしれないリソースに関する例は陸生のワイヤレスのホップ、ケーブルテレビシステムの上流のチャンネル、衛星中継、および終わりからエンドへの衛星チャンネルを含んでいます。
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サブネットはトラフィックを予期するのにおいて接続指向のサブネットと同様の問題を引き起こします。 新しいデータが到着すると予想しながら接続指向のサブネットが使用されていないチャンネルを開けておいている間、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
利用可能なさまざまなBoDプロトコルがあります。 しかしながら、BoDメカニズムとインターネットプロトコル性能との相互作用の比較的少ない幅広い研究がありました。 いくつかの特定のメカニズムの研究は利用可能です(例えば[AR02])。 研究された1つの項目がTCPの再送信タイマー[KY02]です。 体
Karn, et al. Best Current Practice [Page 13] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[13ページ]RFC3819アドバイス
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送付者は早まってセグメントを再送することの傾向があります。
8. Reliability and Error Control
8. 信頼性と誤り制御
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が支配的なプロトコルでないかもしれないインターネットの部分にさえ。
8.1. TCP vs Link-Layer Retransmission
8.1. TCP対リンクレイヤRetransmission
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.
エラー回復は利用者データから計算された余分な情報の世代と伝達にかかわります。 どのくらいの余分な情報を送るか、そして、それがどのように発生しているかによって、受信機は伝送エラーを確かに検出するのにそれを使用できます、何らかの最大数の伝送エラー、または両方まで正しいです。 一般的方法はError Control Coding、または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
十分なECC情報が受信機が「再-トランスミッション」なしでいくつかの伝送エラーを修正することを許可するために利用可能であるときに、アプローチはForward Error Correction(FEC)として知られています。 必要なECCの、より大きい複雑さと特定のモデムとチャンネルの特性、FECにデザインを合わせる必要性のため
Karn, et al. Best Current Practice [Page 14] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[14ページ]RFC3819アドバイス
has traditionally been implemented in special-purpose hardware integral to a modem. This effectively makes it part of the physical layer.
モデムに不可欠の専用ハードウェアで伝統的に実装されました。 これは事実上それを物理的な層の一部にします。
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ダイアルアップモデム(上流の方向への)は1つの例です。 ほとんどの誤りが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.
仕事は現在物理的な層の上のFECを適用するために進行中です、主として従来のARQメカニズムが効率が悪いか、または実装するのが難しい信頼できるマルチキャスティング[RFC3048][RFC3450-RFC3453]に関して。 しかしながら、この議論では、私たちは、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、および信頼できるリンクレイヤはIEEE802.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バイト)と比較的高いフレーム損失率があります。 唯一当てにして、終わらせる終わりのエラー回復は明確に性能退行をもたらすことができます、終わりから端への経路中の「再-トランスミッション」が受け取るにははるかに長い間リンクレイヤ「再-トランスミッション」が使用されている時よりかかるとき。 したがって、リンクレイヤエラー回復はしばしば終わりから終わりへの性能を増強できます。 その結果、リンクレイヤと終わりへの終わりの回復はしばしば共存しています。 これは2つの層のARQプロトコルの間の効率の悪い相互作用の可能性に通じることができます。
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
この相互層の「競争」は以下の無駄な状況に通じるかもしれません。 リンクレイヤが再送される、(離れている、)、パケットであり、リンク潜在はしばらく増加します。 TCPベース、それ
Karn, et al. Best Current Practice [Page 15] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[15ページ]RFC3819アドバイス
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は、終わりから終わりへの信頼できる配送をそのようなリンクの上に供給し続けています。
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").
しかしながら、リンクレイヤが個々の流れを特定して、選択的[LKJK02]にARQを適用できるとき、次に、リンクARQ契約の継続は、流れに信頼できるユニキャストトランスポート・プロトコル(例えば、TCP)を使用することで高いはずであり、他のすべての流れには、低くなければなりません。 最も大きいリンク供給停止がTCPを許容するより大きいリンクARQ契約の継続に急速に「再-トランスミッション」タイムアウトを待つ必要はなくてトランスミッションを復元するように設定します。 一般に、これは一時的な供給停止に直面してTCP性能を向上させます。 しかしながら、過度に高い固執は不利であるかもしれません。 30-60秒の実用的な上限は望ましいかもしれません。 そのような体系の実装は研究課題のままで残っています。 (また、「サブネットワーク供給停止からの回復」という以下のセクションを見ます。)
Karn, et al. Best Current Practice [Page 16] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[16ページ]RFC3819アドバイス
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性能が減少している損失に応じて向上しますが、終わりから終わりへの増加する遅れで悪化するので、分析とシミュレーションで適性バランスを見つけるのは重要です。
8.2. Recovery from Subnetwork Outages
8.2. サブネットワーク供給停止からの回復
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)と、インタフェースを定義するはずです。 供給停止が終わって、これができないなら、サブネットワークは、少なくともそれが供給停止の間に受け入れるパケットのいくつかを握って、それらを提供するのを試みるはずです。 パケットが捨てられるとき、IPは、適切なICMPメッセージを送ることができるように通知されるべきです。
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.
それが*ではなく、供給停止の間、パケットを下げるのを完全に避けるのに必要な*であることに注意してください。 供給停止か、サブネットワークかIP層においてパケットを握る目的は、最後の配送が、サブネットワークが再び操作上であるようにそれとなくTCPに通知するためのそうです。 これは信頼性を確実にするのではなく、性能を高めるためのものです--終わりから終わりへのベースで以前に検討したことであるが信頼性を確実にすることができるだけです。
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].
ほんのいくつかのACKsを含むTCP接続あたりのパケットが流れがいったん再開するとTCP送付者が追加損失から回復することを引き起こすこのよう[RFC3366]に保持されなければなりません。
Karn, et al. Best Current Practice [Page 17] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[17ページ]RFC3819アドバイス
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.
それはIPかサブネットワーク層がTCPヘッダー(IPsec暗号化[RFC2401]が使用中であるなら、とにかく不可能である)を見るためにはレイヤリング違反(そして、ことによると性能ヒット)でしょう、したがって、IPかサブネットワーク層が選ばれるのが、妥当でしょう、デザインパラメタとして、供給停止の間に保有される何らかの少ない数のパケット。
8.3. CRCs, Checksums and Error Detection
8.3. CRCs、チェックサム、および誤り検出
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]を使用します。 IPv4ヘッダーチェックサムはIPv4ヘッダーだけを保護します、TCP、ICMP、およびUDPチェックサムは疑似ヘッダー(ネットワークとトランスポート層情報を含んでいる)と輸送ペイロードデータを両方の輸送のための終わりから終わりへの誤り検出に提供しますが。 データの保護が、アプリケーションに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ヘッダー(IPv4で既に実行された習慣)でのチェックサムの計算にIPソースと送付先アドレス(疑似ヘッダー)を含んでいることによって、これをします。 他の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.
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.
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
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
Karn, et al. Best Current Practice [Page 18] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 18] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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).
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).
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].
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].
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].
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].
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.
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.
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
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
Karn, et al. Best Current Practice [Page 19] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 19] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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].
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].
8.4. How TCP Works
8.4. How TCP Works
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.
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 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 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 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 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.
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.
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 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 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.
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
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
Karn, et al. Best Current Practice [Page 20] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 20] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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].
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].
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
Karn, et al. Best Current Practice [Page 21] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 21] RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5. TCP Performance Characteristics
8.5. TCP Performance Characteristics
Caveat
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.
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.
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.
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.
8.5.1. The Formulae
8.5.1. The Formulae
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:
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:
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
MSS BW = -------------------------------------------------------- RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
where
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)
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.
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.
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.
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.
Karn, et al. Best Current Practice [Page 22] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 22] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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 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].
MSS 1
BW = C --- -------
RTT sqrt(p)
MSS 1 BW = C --- ------- RTT sqrt(p)
where C is 0.93.
where C is 0.93.
8.5.2. Assumptions
8.5.2. Assumptions
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.
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.
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).
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).
The RTT used is the arithmetic average, including queuing delays.
The RTT used is the arithmetic average, including queuing delays.
The formulae are for a single TCP connection. If a path carries many TCP connections, each will follow the formulae above independently.
The formulae are for a single TCP connection. If a path carries many TCP connections, each will follow the formulae above independently.
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.
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.
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).
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).
Note that these formulae break down as p approaches 100%.
Note that these formulae break down as p approaches 100%.
Karn, et al. Best Current Practice [Page 23] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 23] RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5.3. Analysis of Link-Layer Effects on TCP Performance
8.5.3. Analysis of Link-Layer Effects on TCP Performance
Consider the following example:
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.
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.
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:
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:
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and TCP headers.
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and TCP headers.
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec each way for the new wireless link).
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec each way for the new wireless link).
For p, use .01. For C, assume 1.
For p, use .01. For C, assume 1.
The simple formula gives:
The simple formula gives:
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
The more complex formula gives:
The more complex formula gives:
BW = 402.9 kbit/sec
BW = 402.9 kbit/sec
If this were a 2 Mb/s wireless LAN, the designers might be somewhat disappointed.
If this were a 2 Mb/s wireless LAN, the designers might be somewhat disappointed.
Some observations on performance:
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. 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.
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. 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:
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
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
Karn, et al. Best Current Practice [Page 24] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 24] RFC 3819 Advice for Internet Subnetwork Designers July 2004
subnetwork does not perform ARQ or transparent fragmentation
[RFC3366].) If the inequality
subnetwork does not perform ARQ or transparent fragmentation [RFC3366].) If the inequality
BER * [FRAME_SIZE*8] << 1
BER * [FRAME_SIZE*8] << 1
holds, the packet loss probability p can be approximated by:
holds, the packet loss probability p can be approximated by:
p = BER * [FRAME_SIZE*8]
p = BER * [FRAME_SIZE*8]
These equations can be used to apply BER to the performance
equations above.
These equations can be used to apply BER to the performance equations above.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Karn, et al. Best Current Practice [Page 25] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 25] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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. 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.
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.
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.
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.
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.
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.
9. Quality-of-Service (QoS) considerations
9. Quality-of-Service (QoS) considerations
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.
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.
There are presently two architectural approaches to providing mechanisms for QoS support in the Internet.
There are presently two architectural approaches to providing mechanisms for QoS support in the Internet.
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 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.
Karn, et al. Best Current Practice [Page 26] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 26] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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.
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.
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. 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.
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].
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].
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 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.
1. The class selector PHB [RFC2474] replaces the IP precedence field
of the former ToS byte. It offers relative forwarding
priorities.
1. The class selector PHB [RFC2474] replaces the IP precedence field of the former ToS byte. It offers relative forwarding priorities.
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. 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.
Karn, et al. Best Current Practice [Page 27] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn, et al. Best Current Practice [Page 27] RFC 3819 Advice for Internet Subnetwork Designers July 2004
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. 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.
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.
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.
The QoS guarantees that can be offered by the IP layer are a product of two factors:
The QoS guarantees that can be offered by the IP layer are a product of two factors:
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
1. 流れの経路に沿ったサブネットによって提供されたQoS保証の連結。 サブネットはこれが複数のサービスをIP層に提供したがっているつもりであるかもしれません(異なったQoS保証で)。(次に、それは、どの流れがどのサブネットサービスを利用するかを決定できます)。 そして言い換えれば、サブネットにおける推進の振舞いが、推進の振舞い(サービスかPHB)でIP層で「手掛かりを与えられている」必要がある。
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. 1セットの協力メカニズムの操作、帯域幅の予約と入場コントロールとしてあれほどです、政策管理(交通分類)は調節(印、取り締まり、そして/または、形成)、選択している破棄、列を作り、およびスケジューリングを取引します。 サブネットにおけるQoSのサポートが同様のメカニズムを必要とするかもしれないことに注意してください、特に、これらのサブネットが一般的なトポロジーサブネット(例えば、ATM、フレームリレー、またはMPLS)か共有されたメディアサブネットであるときに。
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. 帯域幅の予約は1か2象徴しているバケツモデルに基づくべきです、サービスが一定のレートかbursty交通を支持することを意図するかどうかによって。
Karn, et al. Best Current Practice [Page 28] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[28ページ]RFC3819アドバイス
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.
7. Diffservクラスセレクタ[RFC2474]のサポートは、サブネットがプライオリティを支持するメカニズムを考えるかもしれないのを示します。
10. Fairness vs Performance
10. 公正対パフォーマンス
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].
その都度、スケジューリングアルゴリズムデザイナーは競争している目的のバランスをとらなければなりません: ネットワークの総容積を最大にしている間、それぞれのサブネットノードに容量の正当な分け前を提供します。 性能と公正のバランスをとるための1つのアプローチが[ES00]に概説されています。
Karn, et al. Best Current Practice [Page 29] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[29ページ]RFC3819アドバイス
11. Delay Characteristics
11. 遅れの特性
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]で説明されます。 [AP99]と[LS00]でTCPの再送信タイマーの評価を見つけることができます。
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
多くのサブネットワークでは、これらのパラメタは本来闘争中です。 例えば、移動無線チャンネルの上では、サブネットワークデザイナーは、TCP性能を向上させるための努力における遅れ、遅れ変化、およびパケット損失を交換するのに、「再-トランスミッション」(ARQ)、そして/または、前進型誤信号訂正(FEC)を使用できます。 FEC、ARQは遅れ変化を増加させますが
Karn, et al. Best Current Practice [Page 30] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[30ページ]RFC3819アドバイス
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.
. しかしながら、FEC(特にインターリービングに結合されると)は意地悪な遅れをしばしば増加させます、ARQ retransmissionsが必要でなく、また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とのそれらの相互作用の中の見返りは、かなり複雑である場合があり、多くの継続中の研究の対象です。 私たちは、したがって、サブネットワークデザイナーがこれらのメカニズムの実現でできるだけ多くの柔軟性を提供することを勧めて、上でServiceのQualityの上のセクションで議論するようにそれらへのアクセスを前提とします。
12. Bandwidth Asymmetries
12. 帯域幅ひずみ
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データ・セグメントが戻っている承認による外で「時間を計られる」ので、ACKsを返すことができるレート[BPK98]によってTCP送付者は制限されます。 したがって、インターネット経路の有効な容量がデータを運ぶ対承認のリターンパスの帯域幅の比率が大き過ぎるときに、ACKsの遅い復帰は直接性能に影響を与えます。 ACKsがデータ・セグメントより一般に小さいので、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].
いくつかの戦略が、2人のTCP終わりのホスト例えば、[RFC3449]の間のネットワーク経路の非対称の影響を減少させるために特定されました。 これらのテクニックは、終わりのホストの変化、サブネットワークパケット推進の変更でリターンパス(低い帯域幅チャンネル)の上に送られたACKsの数を減少させるのを試みます。 これらの解決策が非対称のサブネットワークによって引き起こされた性能問題を緩和しているかもしれない間、それらは、関連費用を持っていて、他の意味を持っているかもしれません。 戦略とそれらの含意の、よりふくよかな議論を[RFC3449]に提供します。
13. Buffering, flow and congestion control
13. バッファリング、流れ、および輻輳制御
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.
多くのサブネットが異なった交通需要とことによると異なった伝送速度との複数のリンクを含んでいます。 各リンクに、バッファリング、スケジューリング、および余分なサブネットパケットを捨てる能力を含んでいて、列を作りシステムがあるに違いありません。 また、これらの待ち行列はサブネットフロー制御か輻輳制御計画の一部であるかもしれません。
Karn, et al. Best Current Practice [Page 31] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[31ページ]RFC3819アドバイス
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.
いくつかのサブネットには、パケット低下に加えて流れか混雑制御機構があるかもしれません。 そのようなメカニズムは、サブネット層のスケジューラ、整形器、または「不-梳毛機」などの部品を作動させることができて、サブネットの縁でIP混載業者の操作に影響できます。 しかしながら、Explicit Congestion Notification[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交通)はburstyです。 結果、深層が名目上は安定したネットワークでさえ変えることができる瞬時に起こっている待ち行列として。 バッファ領域が入手できないだけではないときに、最適の性能において、パケットは管理された方法で落とされるべきです。 それでも、どのくらいのバッファ領域を供給するべきであるかは、論争の的ですが、原則として、親指では、各ノードは、1個のリンク_帯域幅*リンク_遅れ生成物のリンクを共有しているそれぞれのTCP接続へのデータの価値を保持にバッファリングしながら、堪能するはずです。
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:
1つの形式の活発な待ち行列管理はRandom Early Detection(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.
最大の敷居の間には、この平均した待ち行列の深さがあるときには_に最大限にしてください、a最小の敷居分第_、落とされるパケットの確率は量に平均した待ち行列の深さが分_を超えている第比例しています。
Karn, et al. Best Current Practice [Page 32] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[32ページ]RFC3819アドバイス
When this average queue depth is equal to max_th, the drop
probability is equal to a configurable parameter max_p.
この平均した待ち行列の深さが_に最大限にするために等しい、低下確率は構成可能なパラメタ最大_pと第等しいです。
When this average queue depth is greater than max_th, packets are
always dropped.
この平均した待ち行列の深さが最大_より大きい、パケットはいつも第落とされます。
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.
アクティブな待ち行列管理アルゴリズムで、低下しているパケットは終わりのホストのTCPsによる、より適切な混雑の振舞いの引き金となるフィードバック信号になります。 低下の無作為化は、関連低下で連動するようになるためには異なったTCP接続のものであるTCPの窓の観測された傾向を終える傾向があります、そして、また、それは適切にTCP輻輳回避を実行するそれらの接続に1段階の公正を課します。 アクティブな待ち行列管理アルゴリズムの別の重要な特性は大きい短期的な炸裂を収容している間、平均した待ち行列が深層であることを急に保つのを試みるということです。
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接続の大きい集合が同じ待ち行列を共有しそうであるなら、これは特に本当です。 しかしながら、活発な待ち行列管理はTCP接続の、より小さい集合を運ぶ多くの待ち行列の場合でそれほど効果的でないかもしれません、例えば、1VCあたりの列を作りを実行するATMスイッチで。
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]を著しく下げることができるサブネットで非生産的な負荷になります。 したがって、サブネットワークは、それらの1つを捨てなければならないときはいつも、これらの余分な断片を捨てるのを試みるはずです。 既にIPパケットにいつを部分的に送ったかなら、捨てることは必要になります、次に、また、IPパケットの端を示すもの以外のあらゆる残っている断片が捨てられるべきです。 ATMサブネットのために、これは、Early Packet DiscardとPartial Packet Discard[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
いくつかのサブネットが事実上、交通の流れのレートがエントリーのときにサブネットに形成されるのを必要とするフロー制御メカニズムを含んでいます。 そのようなサブネットメカニズムに関する1つの例がATM Available Bitにあります。
Karn, et al. Best Current Practice [Page 33] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[33ページ]RFC3819アドバイス
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.
(ABR)サービスがカテゴリ[ATMFTM]であると評定してください。 そのようなフロー制御メカニズムには、サブネットの縁でIPルータに混雑を押し込むことによってサブネットをほとんどlosslessにするという効果があります。 そのような場合、適切なバッファリング、および破棄では、方針が、異なった帯域幅を持っているように見えるサブネットに対処するのにこれらのルータで必要です。 この種類のフロー制御には利益があるかは、論議を呼んでいます。 頻繁なシミュレーションと続く分析的研究があります。両方の道。 そのような異なった結果につながる問題のいくつかがABRパラメタ、1VCあたりの列を作りの明白なレート帰還、使用よりむしろバイナリー(or not)の使用、およびアルゴリズムが研究に選択した特定のATMスイッチに感度を含めるように見えます。 Anecdotallyに、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 Explicit Congestion Notification(電子証券取引ネットワーク)意味論[RFC3168]でサブネットフレームで明白な混雑インディケータを利用することで働くだろうことです。 サブネットの縁のルータは形成よりむしろ電子証券取引ネットワークの指示を持っているサブネットフレームに受け取られるそれらのIPパケットに明白な混雑ビットをはめ込むでしょう。 サブネットにおけるノードは、それらを落とすことの代わりにサブネットがフレームであるとマークするアクティブな待ち行列管理プロトコルを実行する必要があるでしょう。
ECN is currently a proposed standard, but it is not yet widely deployed.
現在、電子証券取引ネットワークは提案された標準ですが、それはまだ広く配備されていません。
14. Compression
14. 圧縮
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.
サブネットワーク層に提示されたデータは、応用層(HTTP/1.1[RFC2616]における例えば、任意の"gzip"、「湿布」、および「空気を抜いてください」圧縮)に圧縮された圧縮形式(例えば、JPEGファイル)には既にあるか、またはIP層に圧縮されているかもしれません(IP有効搭載量Compressionプロトコル[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]).
また、サブネットワークがTCP(SSL、TLS[RFC2246])の上、または、IPのすぐすぐ上でアプリケーション(OpenPGP[RFC2440]かS/MIME[RFC2633])でコード化されたデータを処理するかもしれない、(IPsec、超能力[RFC2406)。
Karn, et al. Best Current Practice [Page 34] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[34ページ]RFC3819アドバイス
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.
しかしながら、多くのデータがまだインターネットの上で解凍されていた状態で送られているので、サブネットワーク圧縮は有益であるかもしれません。 どんなサブネットワーク圧縮アルゴリズムもuncompressibleデータ、例えば既に圧縮されるか、またはコード化されたデータを広くしてはいけません。
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.
私たちは、IETF[RFC3150]の中で開発されたいくつかのヘッダー圧縮技術を使用することで低速において、または、小さいMTUsと共に作動するサブネットワークがIPを圧縮するという強い推薦と輸送レベルヘッダーを(TCPとUDP)に作ります。 解凍された40バイトのTCP/IPヘッダーは、9600年のビーピーエスで発信するためにおよそ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などのRTP圧縮技術[RFC3095]はほとんどのIP/UDP/RTPヘッダーを1-4バイトに圧縮します。 オーディオパケットが店とフォワード潜在を最小にするために小さく保たれるとき、結果として起こる貯蓄は特に重要です。
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 retransmissionを当てにします。 パケットが無くなった後に、減圧装置はあらゆるその後のパケットを捨てなければなりません、サブネットワークがさらなる誤りを全くしないでも、発信している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 retransmissionを待たないで減圧装置再同期を許容するという明白な要求を含んでいます。 しかしながら、これらの計画はまだ普及使用中ではありません。
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
両方のTCPヘッダー圧縮技術は選択している承認(SACK)などの広く使用されたTCPオプションを圧縮しません。 両方が明白な混雑を利用するTCP交通を圧縮しません。
Karn, et al. Best Current Practice [Page 35] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[35ページ]RFC3819アドバイス
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[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 (選ばれたモードに依存します)パケットの拡張損失だけが誤り伝播を通常引き起こします。
15. Packet Reordering
15. パケットReordering
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送付者通知threeが承認をコピーするとき、それは、セグメントがネットワークによって落とされたと仮定します、そして、速さがアルゴリズム[Jac90][RFC2581]を再送する用途はセグメントを再送します。 さらに、事実上、TCPの送付レートを半分にして、混雑ウィンドウは半減します。 サブネットワーク追加注文セグメントであるなら、かなり、3写しACKsが発生して、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の振舞いを改良する研究は始まりました。
Karn, et al. Best Current Practice [Page 36] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[36ページ]RFC3819アドバイス
[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.
これは、サブネットワークimplementersがそう妥協に効率をしないなら可能であるときはいつも、再命令されるパケットを避けようとするべきであるか、信頼性を損なうか、または平均したパケット遅れを増加させるのを示します。
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パケットを運ぶのに頻繁に使用されます。 それが元々ポイントツーポイントとダイアルアップリンクに設計されて以来、オーダーにおける配送を提供すると思われます。 この理由、提供するサブネットワークimplementersに関しては、PPPはVPNsと他の、より複雑なサブネットワークに連結して、また、オーダーにおける、PPPフレームの配送を維持しなければなりません。
16. Mobility
16. 移動性
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.
ホストのインターネット付着点を変えると、以下のステップの1つ以上は伴われます。
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.
地方のサブネットワークの使用は制限されていて、ユーザの資格証明書について確かめなければならないということであるかどうか、そして、最初に、承諾されたアクセス。 これをする多くの方法があります。 些細な例は有料でサブネットワークへの物理的なアクセスを承諾する「インターネットカフェ」でしょう。 サブネットワークは、技術的なアクセスがそれら自身のコントロールであると実装するかもしれません。 1つの例がIEEE802.11Wireless Equivalent Privacy[IEEE80211]です。 携帯電話とインターネット接続サービス業者の両方(ISP)が、お代わりの1つのもののユーザに役立つのに同意するのは、一般的な習慣です。 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.
2番目に、ホストは地方のサブネットワークに、適切なIPパラメタで再構成されなければならないかもしれません。 通常、これは、IPアドレス、デフォルトルータ、およびドメイン名システム(DNS)サーバを設定するのを含んでいます。
Karn, et al. Best Current Practice [Page 37] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[37ページ]RFC3819アドバイス
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].
複数のアクセスネットワークでは、Dynamic Host Configuration Protocol(DHCP)[RFC2131]はほとんど一般にこのために使用されます。 PPPリンクに、IP Controlプロトコル(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".
3番目に、モバイルホストのために運命づけられたトラフィックを現在の位置に発送しなければなりません。 このローミング機能は「インターネットの移動性」という用語の最も一般的な意味です。
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]とインターネットMessage Accessプロトコル(IMAP)[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.
しかしながら、サブネットワークが物理的に大きく、複数の地理的なポイントでインターネットの他の地域に接続するなら、サブネットの外部のインターネットとノードの上のノードの間のパケットの広い領域ルーティングを最適化するために注意するべきです。 一般に、「最も近い出口」ルーティング戦略でこれをします。 与えられたサブネットワークが別のサブネットワークで目的地の実際の物理的な位置に気づかないかもしれないので、それは単にもう片方のサブネットワークに最も近いルーターに向かっているパケットを2つの間に発送します。 これはサブネットワークの中でIPアドレシングとルーティングの何らかの認識を含意します。 サブネットワークは、準最適のルーティングの効果が最小にされる強制的な地理上の区域に広い領域ルーティングに内部的にIPルーティングを使用して、サブネットワーク特有のルーティングを制限したがっているかもしれません。
Karn, et al. Best Current Practice [Page 38] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[38ページ]RFC3819アドバイス
17. Routing
17. ルート設定
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台のシステムがそれとなくメカニズムを進めながらそれら自身の内部のLayer-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層によって追跡されません。 それがサブネットワークインタフェース(すなわち、1つのルータから別のルータまでの可到達性)を通してほんの少し接続されたシステムに送られたパケットを送るか、または受けることができるかどうかによって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のためのノースダコタ)の向こう側に必要です。 サブネットワークルーティングとIPルーティングの間には、直接的な相互作用がありそうにはありません。 放送を提供するか、または明らかに見習うところでは、直接アドレス解決を使用できます。 提供されないところでは、リンクレイヤルーティングは、文脈依存するアドレス解決能力を提供するために例えば、解決のためのプロトコル、Next-ホップResolutionプロトコル[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ルーティングの集合を影響するか、または抑制さえできます。
Karn, et al. Best Current Practice [Page 39] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[39ページ]RFC3819アドバイス
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.
一般に、プロトコルがすなわち、サブネットマスクでLayer-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.
サブネットワークが1セットのルータの間のトランジットに使用されるとき、それは慣習上ポイントからポイントへのリンクの完全なメッシュの同等物を提供します。 アドレス解決テーブルのサイズを減少させるのに内部サブネット構造の簡単さを使用できますが(例えば、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で実装することができない有効であるか敏感なルーティングメカニズムの使用を許す特徴があります。 1つの例がイーサネットネットワークに広く使用される自己ラーニングブリッジアルゴリズムです。 それぞれのサブネットワークホップのダイナミックルーティングの必要性を避けて、ラーニングブリッジはLayer-2サブネットワーク推進を実行します。 別のものが携帯電話ネットワークで「移管」メカニズムであり、特に「柔らかい移管」体系がコネである、-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
内部のルーティングを実装すると決めるサブネットワークデザイナーは、カスタムルーティング・アルゴリズムが保証されるかどうか、または既存のインターネットルーティング・アルゴリズムかプロトコルが十分であるかもしれないかどうか考えるべきです。 デザイナーが、この決定がアドレス解決テーブルサイズを減少させるかどうかことであると考えるべきである、(可能である、追加議定書サポートで必要である、)、減少しようとするのは、経路指定テーブルの複雑さです。 後者は、サブネットワークを仕切ることによって物理的か論理的に達成されて、仕切りが(例えば、BGPのASのもの)であるとサポートするのにネットワーク層プロトコルを使用することで、より良いかもしれません。 プロトコルとルーティング
Karn, et al. Best Current Practice [Page 40] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[40ページ]RFC3819アドバイス
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.
アルゴリズムは、悪名高く微妙で、複雑で、正しく実装するのは難しい場合があります。 容易に既存のプロトコルか実装を再利用できるなら、多くの仕事を避けることができます。
18. Security Considerations
18. セキュリティ問題
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]であり、ウェブ商業を保護するのに主として使用されるTLS[RFC2246](プリティ・グッド・プライバシ(PGP)[RFC1991]とS/MIME[RFCs-2630-2634])は主としてIPのすぐ上に座っていて、どんなIPアプリケーションでも使用できるメール、ソフトウェア配、安全な遠隔アクセスとファイル転送に使用されるSecureシェル(SSH)、IPsec[RFC2401]、汎用の暗号化、および認証機構を、保護して、以前はよく認証していました。 (実際に終わりから終わりへのベースの上、または、どちらも含んでいないセキュリティゲートウェイかエンドシステムの両方の間で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
ワーキンググループの明確なコンセンサスは、特に、弱いか不当に実装されると[BGW01]サブネットワークセキュリティー対策が実際に反生産的であるかもしれないと主張しました。 議論はサブネットワークセキュリティー対策がエンドユーザを大丈夫だという誤った感覚に和らげることができるということであり、終わるために終わった状態で有効な状態で展開する誘因を減少させてください。
Karn, et al. Best Current Practice [Page 41] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[41ページ]RFC3819アドバイス
mechanisms, and encourage "risky" uses of the Internet that would not be made if users understood the inherent limits of subnetwork security mechanisms.
メカニズム、および「危険」が使用するユーザがサブネットワークセキュリティー対策の固有の限界を理解しているなら作られないインターネットの督励。
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つの終点(通常クライアント)をしばしば高々管理して、したがって、終わりまでの終わりのメカニズムの使用を実施できません。しかしながら、最もありそうな脅威に対して低く評価された資産を保護するのに、サブネットセキュリティは完全に適切である場合があります。 とにかく、サブネットメカニズムは終わりから終わりへのメカニズムの使用を排除しません。(メカニズムは、高く評価された資産を保護するのに通常使用されます)。 この観点は、多くの安全保障政策が、終わりから端への全体の経路が名目上は物理的に固定されている一連の連結されたリンクで構成されるとそれとなく仮定すると認めます。 すなわち、これらの方針はすべてのリンクのすべての終点が信じられて、攻撃者による物理的な媒体へのアクセスが難しいと仮定します。 そのような方針の仮定を満たすために、明白なメカニズムが物理的防護を欠いているリンク(特に共有された中型のリンク)に必要です。 例えば、これはIEEE802.11[IEEE80211]無線LAN規格においてWEPの基礎となる原理(WEP)です、そして、ケーブルテレビの上のDOCSIS[DOCSIS1][DOCSIS2]データのBaseline Privacy Interfaceは規格をネットワークでつなぎます。
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.
総合的なインターネット問題の解決で支援されるサブネットワークは1つのセキュリティー・サービスを提供できます: サブネットワークセキュリティは、サブネットワークフレームの源を認証するためにメカニズムを提供するべきです。 この機能は、IPv4アドレスをMACアドレスに関連づけるためにいくつかの現在のプロトコル、例えば、ARPの使用[RFC826]で消えています。 IPv6 Neighborディスカバリー(ノースダコタ)[RFC2461]は同様の機能を実行します。
Karn, et al. Best Current Practice [Page 42] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[42ページ]RFC3819アドバイス
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]の使用。 1つの一般的な誤りは暗号アルゴリズムを秘密にするのにより安全になると仮定することです。 これは、直感的ですが、間違っています。 早くデザイン過程でパブリックディスクロージャを洗い張りしてください。博識な暗号使用者はピア・レビューを引き付けます。 これによる欠点の暴露は遠くに論評します。攻撃者にセキュリティアルゴリズムをリバースエンジニアさせるのからの利益であると想像されたいずれも重いです。
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.
3. 跳ね上げ戸[Schneier00][Crypto9912]の包含。 跳ね上げ戸が欠点であることはそれが壊れているのを許容するのをアルゴリズムでこっそりと残らせています。 無くなっているキーを回収するか、または政府機関による秘密のアクセスを可能にするためにこれをするかもしれません。 悪意がある攻撃者は、跳ね上げ戸を発見して、利用できます。
Karn, et al. Best Current Practice [Page 43] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[43ページ]RFC3819アドバイス
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. 何らかのパスワードに情報がクリアテキストであると認識させます。 何年間も、サービスを横取りするのにアナログの携帯電話をクローンを作って、使用できました。 互換機ユーザは単にクリアテキストのすべてを交換した登録プロトコルを立ち聞きしました。
5. Keys which are common to all systems on a subnet [BGW01].
5. サブネット[BGW01]のすべてのシステムに共通のキー。
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]、1つのサブネット規格が不十分に設計されて、不十分に指定された初期化ベクトルを含んでいます。 断固とした攻撃者は、容易に同じ主要なストリームで暗号化された複数の暗号文を回復して、それらを解読するために統計的な攻撃を実行できます。
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. 身元確認のための情報は個々の、そして、身元保証可能なデバイスに決議できるクリアテキストを送りました。 これはそのデバイス(または、所有者)に狙う攻撃に脆弱性を作成します。
8. Inability to renew and revoke shared secret information.
8. 更新できないことと取消しは秘密の情報を共有しました。
9. Insufficient key length.
9. 不十分なキー長。
10. Failure to address "man-in-the-middle" attacks, e.g., with mutual
authentication.
10. 「中央の男性」を扱わない場合、例えば、互いの認証で、攻撃します。
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.
さらに、実装欠陥でよく設計されたセキュリティプロトコルに感染することができます。 そのような欠陥に関する例は予測できる擬似乱数[RFC1750](ある入出力システムコール[WFBA2000]の危険な使用、および機密データの不注意な暴露によるオーバーフロー攻撃をバッファリングする脆弱性)の使用を含んでいます。
19. Contributors
19. 貢献者
This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group.
このドキュメントはLink Characteristics(PILC)ワーキンググループのIETFパフォーマンスImplicationsのメンバーのコンセンサスを表します。
Karn, et al. Best Current Practice [Page 44] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[44ページ]RFC3819アドバイス
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.
このドキュメントはLink Characteristics作業部会のパフォーマンスImplicationsにおける、たくさんの人の貢献なしで可能でなかったでしょう。 特に、以下の人々はこのドキュメントに関するテキスト、編集、およびアドバイスの主要な貢献を提供しました: マーク・オールマンは、このドキュメントを完成するために最終的な編集を提供しました。 カルステン・ボルマンは体力を要しているヘッダー圧縮に関するテキストを提供しました。 ゴーリーFairhurstは全体のドキュメントの放送に関するテキスト、マルチキャスト問題、ルーティング、および多くの貴重なコメントを提供しました。 アーロン・フォークはオンデマンドの帯域幅に関するテキストを提供しました。 ダン・グロースマンはドキュメントの多くの一面に関するテキストを提供しました。 ライナー・ラドウィグはTCPに関する徹底的なドキュメントレビューとテキスト対Link-層のRetransmissionを提供しました。 Jamshid MahdaviはTCP性能計算に関するテキストを提供しました。 Saverio Mascoloはドキュメントのフィードバックを提供しました。 ガブリエル・モンテネグロはドキュメントのフィードバックを提供しました。 マリー=ジョゼMontpetitはオンデマンドの帯域幅に関するテキストを提供しました。 ジョーTouchは放送されたマルチキャストに関するテキストとルーティングを提供しました、そして、ロイドWoodはドキュメントのバージョンの多くの貴重なコメントを提供しました。
20. Informative References
20. 有益な参照
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org.
フォームRFCnnnnの参照はオンラインで利用可能なComments(RFC)ドキュメントのためのwww.rfc-editor.orgのインターネットRequestです。
[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]情報Technology TelecommunicationsとシステムLocalとメトロポリタンエリアネットワークの間の情報交換、Common仕様メディアはコントロール(MAC)ブリッジ、IEEE 802.1D、1998にアクセスします。 ISO15802-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 SIGCOMM99の議事で経路の特性をネットワークでつなぎます。
[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.
[AR02]Acar(G.とC.ローゼンバーグ)は車載処理、コンピュータネットワーク、39(1)、2002で静止衛星ネットワークの公正な帯域幅進行中の要求(WFBoD)に重みを加えました。
[ATMFTM] The ATM Forum, "Traffic Management Specification,
Version 4.0", April 1996, document af-tm-0056.000.
http://www.atmforum.com/
[ATMFTM] ATM Forum、「ドキュメントaf-tm-0056.000輸送管理仕様、バージョン4インチ、1996年4月、 http://www.atmforum.com/ 」
Karn, et al. Best Current Practice [Page 45] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[45ページ]RFC3819アドバイス
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to
Packet Reordering. ACM Computer Communication Review,
32(1), January 2002.
TCPをパケットReorderingにより強健にするときの[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
暗号98年、1998年8月の http://www.research.att.com/~smb/papers/inet-crypto.pdf の議事における[Bel98]Bellovinと、S.と、「暗号とインターネット」
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
Mobile Communications: The Insecurity of 802.11," In
Proceedings of ACM MobiCom, July 2001.
[BGW01] ボリーソフ、N.、ゴールドバーグ、I.、およびD.ワグナー、「移動通信を傍受します:」 2001年7月のACM MobiComの議事における「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] Balakrishnan、H.、Padmanabhan、V.、およびR.キャッツ。 「TCPパフォーマンスへの非対称の効果。」 ACMモバイルネットワークとアプリケーション(モネ)、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.、Partridge、C.、およびN.Shectman、「パケットReorderingはNot Pathological Network Behaviorです」、Networkingの上のIEEE/ACM Transactions、Vol.7、No.6、12月1999
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[CGMP] 1996/1997 ファリナッチD.、Tweedly A.とT.Speakman、「コクチマスグループ管理プロトコル(CGMP)」、 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.、「ヨーロッパのセル暗号化アルゴリズム」暗号、1999年12月15日 http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp,
Ethernet Local Area Network Specification Version 2.0,
November 1982.
[DIX82] デジタル機器Corp、インテルCorp、ゼロックスCorp、イーサネットローカル・エリア・ネットワーク仕様バージョン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月、ケーブルテレビ研究所Inc.
[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月、ケーブルテレビ研究所Inc.
[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]レイ、南西、「DOCSISを拠点とするケーブルネットワーク:」 「上流の容量への大きいデータ・パケットの影響」とアクセスネットワークにおける第14ITC専門家セミナーとシステム(バルセロナ(スペイン)2001年4月25日〜27日)。
Karn, et al. Best Current Practice [Page 46] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[46ページ]RFC3819アドバイス
[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、欧州放送連合、(DVB)を放送するデジタルビデオ。 Data BroadcastingのためのDVB Specification、ヨーロッパのStandard(テレコミュニケーションSeries)EN301 192v1.2.1(1999-06)。
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
(ELF) Scheduling for Wireless Networks, Proceedings of
IEEE Infocom 2000.
[ES00]エッカード(D.とP.Steenkiste)は、「ワイヤレス・ネットワーク、IEEE Infocom2000の議事のための公正な(小妖精)スケジューリングを努力して制限しました」。
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue
Management for Congestion Control" to appear in Infocom
2000.
[FB00] Firoiu V.とM.ボーデン、Infocom2000で見える「輻輳制御のための活発な待ち行列管理の研究。」
[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、および「高速ネットワークで公正を改良しやすいTCPウエストウッドと赤」、高速ネットワーク(2002年4月)のためのプロトコルにおける第7国際ワークショップの議事
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE8023]IEEE802.3CSMA/CDアクセス法 http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[IEEE80211]IEEE802.11Wireless 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/IEC3309: 1991(E)、「情報Technology--システムの間のテレコミュニケーションと情報交換--ハイレベル・データ・リンク制御手順(HDLC)手順--、枠組構造、」、国際標準化機構(Fourth版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/IEC13818-1: 2000(E)情報Technology--映画と関連オーディオ情報の一般的なコード化: システム、Second版、2000年12月1日の国際標準化機構、および国際電気標準化会議。
[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.5B-ISDN気圧適合層の仕様タイプ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-関心メーリングリスト、1990年4月の ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt にメールしてください。
Karn, et al. Best Current Practice [Page 47] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[47ページ]RFC3819アドバイス
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
Proceedings of IEEE ICC, 2002.
TCPをひく[KY02]Khafizov、F.、およびM.Yavuz、-2000である、IEEE ICC、2002年の議事
[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.キャッツ、「アイフェル高原アルゴリズム:」 「偽物のRetransmissionsに対して強健な作成TCP」、ACMコンピュータコミュニケーションレビュー、Vol.30、No.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 Wireless Networks Journal、Vol.8、No.2/3、ページ 289-299と、2002年3月-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.
Reliable Wireless Link、ページの上のTCPの[LRKOJ99]ラドウィグとR.とRathonyiとB.とコンラッドとA.とオーデンとK.とA.ジョゼフ、Multi-層のTracing 144-154 ACM SIGMETRICS99の議事で。
[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コンピュータコミュニケーションはVol.30、2000年7月No.日3に再検討されます。
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
Proxying")", Work in Progress.
「IGMP/MLDベースのマルチキャスト推進("IGMP/MLD Proxying")」という[マグマプロキシ]フェナー、B.、彼、H.、ハーバーマン、B.、およびH.Sandickは進行中で働いています。
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches",
Work in Progress.
[MAGMAスヌープ] 「スイッチについて詮索するIGMPとMLDのための問題」というクリステンセン、M.、キンボール、K.、およびF.Solenskyは進行中で働いています。
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic
Evaluation of RED Performance", INFOCOM 2000.
[MBB00] 5月、M.、ボナルド、T.、およびJ-C。 Bolot、「赤いパフォーマンスの解析的評価」、INFOCOM2000。
[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]5月、M.とBolotとJ.、DiotとC.とB.ライルス、「REDを配備しない理由」Proc7番目について。 1999'年6月のサービスの質(IWQoS'99)に関する国際ワークショップ。
[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輻輳回避アルゴリズムの巨視的行動」、コンピュータCommunication Review、Vol.27、No.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: Secondローカル・エリア・ネットワークあたり1Gigabit、IEEE-ミクロ、Vol.15、No.1、1995年2月、ページ 29-36.
Karn, et al. Best Current Practice [Page 48] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[48ページ]RFC3819アドバイス
[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スループット:」 「Simple ModelとそのEmpirical Validation」、UMASS CMPSCI Tech Report TR98 008、2月1998日
[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.ジェーコブソン、「Congestion Avoidanceのための無作為のEarly Detectionゲートウェイ」、Networking、Vol.1No.4(1993年8月) http://www.aciri.org/floyd/papers/red/red.html のIEEE/ACM Transactions
[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.フロイド、「気圧ネットワークの上のTCP交通の力学。」 CommunicationのSelected AreasのIEEE Journal、Vol.13No.4、1995年5月、p。 633-641.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、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ビットのイーサネットへのアドレスはトランスミッションのためにイーサネットにハードウェアを記述する」STD37、RFC826、1982年11月。
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC1071] ブレーデンとR.とボーマンとD.とC.Partridge、「インターネットチェックサムを計算します」、RFC1071、1988年9月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC1332] McGregor, C., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー(C.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
Karn, et al. Best Current Practice [Page 49] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[49ページ]RFC3819アドバイス
[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、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[RFC1662] エドシンプソン、W.、STD51、RFC1662、「HDLCのようのpppは縁どっている」7月1994日
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1750] イーストレーク3番目とD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC1939] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、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.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC1991] アトキンスとD.とストーリングズとW.とP.Zimmermann、「PGP交換処理形式」、RFC1991、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の選択している承認オプション」、RFC2018、1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、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の機能的な仕様」、RFC2205、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.、オデル、M.、Romanow、A.、Weinrib、A.、およびL.チャン、「資源予約プロトコル(RSVP)--、バージョン1つの適用性証明、展開に関するいくつかのガイドライン、」、RFC2208(1997年9月)
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
Karn, et al. Best Current Practice [Page 50] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[50ページ]RFC3819アドバイス
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[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.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(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]は穴のHoutとK.とKoopalとA.とR.バンモーク、「釘-dhcpによるIP管理番号」をバンに積みます、RFC2322、1998年4月1日。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、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.と李とA.とMalisとA.とJ.スティーブンズ、「AAL5"、RFC2364、1998年7月の間のppp。」
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE",
RFC 2394, December 1998.
[RFC2394] ペレイラ、R.、「IP有効搭載量圧縮使用は空気を抜く」RFC2394、1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression
Using LZS", RFC 2395, December 1998.
[RFC2395] 友人とR.とR.Monsour、「LZSを使用するIP有効搭載量圧縮」、RFC2395、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、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メッセージ・フォーマット」、RFC2440、1998年11月。
Karn, et al. Best Current Practice [Page 51] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[51ページ]RFC3819アドバイス
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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)のための隣人発見」、RFC2461、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分野)の定義」RFC2474(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.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、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変更」、RFC2582、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は分類する」RFC2597、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC2630] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC2631] レスコラ、E.、「ディフィー-ヘルマンの主要な協定方法」、RFC2631、1999年6月。
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
[RFC2632] エドRamsdell、B.、RFC2632、「S/MIMEバージョン3証明書は扱う」6月1999日
Karn, et al. Best Current Practice [Page 52] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[52ページ]RFC3819アドバイス
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC2633] Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[RFC2634] ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation over ATM Adaptation Layer 5", RFC 2684,
September 1999.
[RFC2684] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
PPP", RFC 2686, September 1999.
[RFC2686] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」、RFC2686、1999年9月。
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like
Framing", RFC 2687, September 1999.
[RFC2687] ボルマン、C.、「リアルタイムの指向のHDLCのような縁どりにおけるppp」、RFC2687、1999年9月。
[RFC2689] Bormann, C., "Providing Integrated Services over Low-
bitrate Links", RFC 2689, September 1999.
[RFC2689] ボルマン、C.、「Low- bitrateリンクスの上にIntegrated Servicesを提供します」、RFC2689、1999年9月。
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2710] デアリングとS.とフェナーとW.とB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[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.と2000年のP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC2784行進。
[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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC2990] ヒューストン、G.、「IP QoS構造のための次のステップ」、RFC2990、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.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。
Karn, et al. Best Current Practice [Page 53] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[53ページ]RFC3819アドバイス
[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.(エド)、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
header compression", RFC 3096, July 2001.
[RFC3096] デーゲルマルク、M.、エド、「強健なIP/UDP/RTPヘッダー圧縮のための要件」、RFC3096、7月2001日
[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.、Kojo、M.、および「終わりから終わりへの遅いリンクのパフォーマンス含意」、BCP48、RFC3150(2001年7月)対Magret
[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.とKojoとM.、MagretとV.とN.Vaidya、「終わりから終わりへの誤りとのリンクのパフォーマンス含意」BCP50、RFC3155(2001年8月)。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3168]RamakrishnanとK.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、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)」、RFC3173 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.とシャルニーとA.とアメリカダイコンソウとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とコートニーとW.とDavariとS.とFiroiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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.、Carpenter、B.、カサーティ、A.、クロウクロフト、J.、アルペルン、J.、クマー、B.、およびJ.Schnizlein、「RFC2598インチ、RFC3248(2002年3月)のDelay Boundの代替の改正
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[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.Wood、「リンクAutomatic Repeat reQuest(ARQ)にデザイナーをリンクするというアドバイス」BCP62、RFC3366(2002年8月)。
Karn, et al. Best Current Practice [Page 54] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[54ページ]RFC3819アドバイス
[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インチ、RFC3376、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]BalakrishnanとH.とPadmanabhanとV.、FairhurstとG.とM.Sooriyabandara、「ネットワーク経路非対称のTCPパフォーマンス含意」BCP69、RFC3449(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] Luby、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、「非同期な層にされたコード化(ALC)は具体化について議定書の中で述べます」、RFC3450、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]Luby(M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「コード化輸送(LCT)ブロックを層にしました」、RFC3451、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]Luby(M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「エラー修正(FEC)ブロックを進めます」、RFC3452、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] LubyとM.とVicisanoとL.とGemmellとJ.とリゾーとL.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、2002年12月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488] ウーとI.とT.エッケルト、「シスコシステムズルータポートグループ管理プロトコル(RGMP)」、RFC3488、2003年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、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.、デーゲルマルク、M.は突かれます、S.、イェンソン、L-E.、G.Fairhurst、エド、「ユーザー・データグラム・プロトコル(UDP)-Liteは議定書を作ります」、RFC3828、6月2004
[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.Partridge、「CRCとTCPチェックサムであるときには、意見を異にしてください」、ACM SIGCOMM、9月2000 http://www.acm.org/sigcomm/sigcomm2000/conf/ 紙/sigcomm2000-9-1.pdf
Karn, et al. Best Current Practice [Page 55] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[55ページ]RFC3819アドバイス
[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.クラーク、「システム設計における終わりから終わりへの議論」をアシで飾ります。 Distributed Computing Systems(1981年4月)509-512ページの第2国際コンファレンス。 マイナーチェンジがコンピュータシステムズ2、4、1984年11月、277-288ページのACM Transactionsにある状態で、発行されます。 クレイグPartridge、インターネットワーキングにおけるエディタInnovationsでは、翻刻しました。 Artech家、ノーウッド、1988、195-206ページのMA。 ISBN0-89006-337-0。
[SSL2] Hickman, K., "The SSL Protocol", Netscape
Communications Corp., Feb 9, 1995.
[SSL2] 1995年2月9日のヒックマン、K.、「SSLプロトコル」ネットスケープ・コミュニケーションズ。
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
1996年11月18日の[SSL3]フライ料理人とA.、KarltonとP.とP.コッハー、「SSL3.0プロトコル」、ネットスケープ・コミュニケーションズ。
[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の速い回復戦略:」 「分析とImprovements」、IEEE Infocom、3月1998日の http://www.eecs.harvard.edu/networking/papers/infocom- のtcpの最終的な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.、ジョン・クロウクロフト、およびYuko村山。 「ローカル・エリア・ネットワークにおけるMAC層のSecurity Measures」、ローカル・エリア・ネットワークSecurity、Workshop LANSEC89年Proceedings、Springer-Verlag、1989年4月、ページ 53-64.
Karn, et al. Best Current Practice [Page 56] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[56ページ]RFC3819アドバイス
21. Contributors' Addresses
21. 貢献者のアドレス
Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292
アーロンフォークUSC/情報科学研究所4676海軍省道マリナデル・レイ(カリフォルニア)90292
Phone: 310-448-9327 EMail: falk@isi.edu
以下に電話をしてください。 310-448-9327 メールしてください: falk@isi.edu
Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
Saverio Mascolo DipartimentoディElettrotecnica教育Elettronica、PolitecnicoディバリVia Orabona4、70125バリ(イタリア)
Phone: +39 080 596 3621 EMail: mascolo@poliba.it URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
以下に電話をしてください。 +39 3621年の080 596メール: 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
Karn, et al. Best Current Practice [Page 57] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[57ページ]RFC3819アドバイス
22. Authors' Addresses
22. 作者のアドレス
Phil Karn, Editor Qualcomm 5775 Morehouse Drive San Diego CA 92121
フィルKarn、エディタクアルコム5775モアハウス・Driveサンディエゴカリフォルニア 92121
Phone: 858 587 1121 EMail: karn@qualcomm.com
以下に電話をしてください。 1121年の858 587メール: karn@qualcomm.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
以下に電話をしてください。 +49 421 218、7024Fax: +49 7000年の421 218メール: cabo@tzi.org
Godred (Gorry) Fairhurst Department of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, United Kingdom
(ゴーリー)Fairhurst工学部、アバディーン、アバディーンAB24 3UE、イギリスの大学をGodredしました。
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
52134Herzogenrath、ライナーラドウィグエリクソン研究エリクソンAllee1ドイツ
Phone: +49 2407 575 719 EMail: Reiner.Ludwig@ericsson.com
以下に電話をしてください。 +49 2407 575 719はメールされます: Reiner.Ludwig@ericsson.com
Karn, et al. Best Current Practice [Page 58] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[58ページ]RFC3819アドバイス
Jamshid Mahdavi Novell, Inc.
Jamshid MahdaviノベルInc.
EMail: jmahdavi@earthlink.net
メール: jmahdavi@earthlink.net
Gabriel Montenegro Sun Microsystems Laboratories, Europe 180, Avenue de l'Europe 38334 Saint Ismier CEDEX France
ガブリエルモンテネグロサン・マイクロシステムズ研究所、ヨーロッパ180、アベニューde l'Europe38334セイント・Ismier CEDEXフランス
EMail: gab@sun.com
メール: gab@sun.com
Joe Touch USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey CA 90292
ジョーTouch USC/Information Sciences Institute4676海軍本部Wayマリナデルレイカリフォルニア 90292
Phone: 310 448 9151 EMail: touch@isi.edu URL: http://www.isi.edu/touch
以下に電話をしてください。 9151年の310 448メール: 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の新しい正方形のPark、Bedfont湖Feltham 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はメールされます: lwood@cisco.com URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Karn, et al. Best Current Practice [Page 59] RFC 3819 Advice for Internet Subnetwork Designers July 2004
Karn、他 インターネットサブネットワークデザイナー2004年7月のための最も良い現在の習慣[59ページ]RFC3819アドバイス
23. Full Copyright Statement
23. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Karn, et al. Best Current Practice [Page 60]
Karn、他 最も良い現在の習慣[60ページ]
一覧
スポンサーリンク
