RFC1349 日本語訳
1349 Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. (Format: TXT=68949 bytes) (Obsoleted by RFC2474) (Updates RFC1248, RFC1247, RFC1195, RFC1123, RFC1122, RFC1060, RFC0791) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Almquist
Request for Comments: 1349 Consultant
Updates: RFCs 1248, 1247, 1195, July 1992
1123, 1122, 1060, 791
Almquistがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1349のコンサルタントアップデート: RFCs1248、1247、1195、7月1992 1123、1122、1060、791
Type of Service in the Internet Protocol Suite
インターネットプロトコル群のサービスのタイプ
Status of This Memo
このメモの状態
This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、IAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Summary
概要
This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. The handling of IP Type of Service by both hosts and routers is specified in some detail.
このメモは、インターネットプロトコル(IP)ヘッダーでService八重奏のTypeの意味論のいくつかの局面を変えて、はっきりさせます。 ホストとルータの両方によるServiceのIP Typeの取り扱いは何らかの詳細に指定されます。
This memo defines a new TOS value for requesting that the network minimize the monetary cost of transmitting a datagram. A number of additional new TOS values are reserved for future experimentation and standardization. The ability to request that transmission be optimized along multiple axes (previously accomplished by setting multiple TOS bits simultaneously) is removed. Thus, for example, a single datagram can no longer request that the network simultaneously minimize delay and maximize throughput.
このメモは、ネットワークがデータグラムを送る貨幣原価を最小にするよう要求するために新しいTOS値を定義します。 多くの追加新しいTOS値が今後の実験と標準化のために予約されます。 トランスミッションが複数の軸(以前に、同時に複数のTOSビットを設定することによって、達成される)に沿って最適化されるよう要求する能力を取り除きます。 このようにして、例えば、単一のデータグラムは、もうネットワークが同時に、遅れを最小にして、スループットを最大にするよう要求できません。
In addition, there is a minor conflict between the Host Requirements (RFC-1122 and RFC-1123) and a number of other standards concerning the sizes of the fields in the Type of Service octet. This memo resolves that conflict.
さらに、Service八重奏のTypeの分野のサイズに関してHost Requirements(RFC-1122とRFC-1123)と他の多くの規格との小さい方の衝突があります。 このメモはその闘争を解決します。
Table of Contents
目次
1. Introduction ............................................... 3
1. 序論… 3
2. Goals and Philosophy ....................................... 3
2. 目標と哲学… 3
3. Specification of the Type of Service Octet ................. 4
3. サービス八重奏のタイプの仕様… 4
4. Specification of the TOS Field ............................. 5
4. TOS分野の仕様… 5
Almquist [Page 1]
Almquist[1ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
5. Use of the TOS Field in the Internet Protocols ............. 6
5.1 Internet Control Message Protocol (ICMP) ............... 6
5.2 Transport Protocols .................................... 7
5.3 Application Protocols .................................. 7
5. TOSの使用はインターネットでプロトコルをさばきます… 6 5.1 インターネット・コントロール・メッセージ・プロトコル(ICMP)… 6 5.2 プロトコルを輸送してください… 7 5.3 アプリケーションプロトコル… 7
6. ICMP and the TOS Facility .................................. 8
6.1 Destination Unreachable ................................ 8
6.2 Redirect ............................................... 9
6. ICMPとTOS施設… 8 6.1 目的地手の届かない… 8 6.2 向け直します。 9
7. Use of the TOS Field in Routing ............................ 9
7.1 Host Routing ........................................... 10
7.2 Forwarding ............................................. 12
7. ルート設定におけるTOS分野の使用… 9 7.1 ルート設定を主催してください… 10 7.2 進めます。 12
8. Other consequences of TOS .................................. 13
8. TOSの他の結果… 13
APPENDIX A. Updates to Other Specifications ................... 14
A.1 RFC-792 (ICMP) ......................................... 14
A.2 RFC-1060 (Assigned Numbers) ............................ 14
A.3 RFC-1122 and RFC-1123 (Host Requirements) .............. 16
A.4 RFC-1195 (Integrated IS-IS) ............................ 16
A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB) ................ 17
他の仕様への付録A.最新版… 14 A.1 RFC-792(ICMP)… 14 A.2 RFC-1060(規定番号)… 14のA.3 RFC-1122とRFC-1123(ホスト要件)… 16A.4 RFC-1195、(統合、-、)、… 16 A.5 RFC-1247(OSPF)とRFC-1248(OSPF MIB)… 17
APPENDIX B. Rationale ......................................... 18
B.1 The Minimize Monetary Cost TOS Value ................... 18
B.2 The Specification of the TOS Field ..................... 19
B.3 The Choice of Weak TOS Routing ......................... 21
B.4 The Retention of Longest Match Routing ................. 22
B.5 The Use of Destination Unreachable ..................... 23
付録B.原理… 18B.1、貨幣原価TOS価値を最小にしてください… 18 TOS分野のB.2仕様… 19 弱いTOSルート設定のB.3選択… 21 最も長いマッチルート設定のB.4保有… 22 目的地手の届かないことのB.5使用… 23
APPENDIX C. Limitations of the TOS Mechanism .................. 24
C.1 Inherent Limitations ................................... 24
C.2 Limitations of this Specification ...................... 25
TOSメカニズムの付録C.限界… 24 C.1の固有の制限… 24 このSpecificationのC.2限界… 25
References ..................................................... 27
参照… 27
Acknowledgements ............................................... 28
承認… 28
Security Considerations ........................................ 28
セキュリティ問題… 28
Author's Address ............................................... 28
作者のアドレス… 28
Almquist [Page 2]
Almquist[2ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
1. Introduction
1. 序論
Paths through the Internet vary widely in the quality of service they provide. Some paths are more reliable than others. Some impose high call setup or per-packet charges, while others do not do usage-based charging. Throughput and delay also vary widely. Often there are tradeoffs: the path that provides the highest throughput may well not be the one that provides the lowest delay or the lowest monetary cost. Therefore, the "optimal" path for a packet to follow through the Internet may depend on the needs of the application and its user.
インターネットを通した経路はそれらが提供するサービスの質でばらつきが大きいです。 いくつかの経路が他のものより信頼できます。 或るものは高い呼び出しセットアップか1パケットあたりの充電を課しますが、他のものは用法ベースの充電をしません。 また、スループットと遅れはばらつきが大きいです。 見返りがしばしばあります: 最も高いスループットを提供する経路はたぶん最も低い遅れか最も低い貨幣原価を提供するものでないでしょう。 したがって、パケットがインターネットを通して続く「最適」の経路はアプリケーションとそのユーザの必要性によるかもしれません。
Because the Internet itself has no direct knowledge of how to optimize the path for a particular application or user, the IP protocol [11] provides a (rather limited) facility for upper layer protocols to convey hints to the Internet Layer about how the tradeoffs should be made for the particular packet. This facility is the "Type of Service" facility, abbreviated as the "TOS facility" in this memo.
インターネット自体には特定用途かユーザのためにどう経路を最適化するかに関するどんなダイレクト知識もないので、見返りが特定のパケットのためにどう作られているべきであるかに関して上側の層のプロトコルがインターネットLayerにヒントを伝えるように、IPプロトコル[11]は(かなり制限される)の施設を提供します。 この施設はこのメモで「TOS施設」が簡略化された「サービスのタイプ」施設です。
Although the TOS facility has been a part of the IP specification since the beginning, it has been little used in the past. However, the Internet host specification [1,2] now mandates that hosts use the TOS facility. Additionally, routing protocols (including OSPF [10] and Integrated IS-IS [7]) have been developed which can compute routes separately for each type of service. These new routing protocols make it practical for routers to consider the requested type of service when making routing decisions.
TOS施設は始め以来のIP仕様の一部ですが、それは過去に少ししか使用されていません。 しかしながら、インターネット・ホスト仕様[1、2]は、現在、ホストがTOS施設を使用するのを強制します。 さらに、ルーティング・プロトコル、(OSPF[10]とIntegratedを含んでいる、-、それぞれのタイプのサービスのために別々にルートを計算できる[7])が開発されました。 これらの新しいルーティング・プロトコルで、ルーティングを決定にするとき要求されたタイプのサービスを考えるのはルータに実用的になります。
This specification defines in detail how hosts and routers use the TOS facility. Section 2 introduces the primary considerations that motivated the design choices in this specification. Sections 3 and 4 describe the Type of Service octet in the IP header and the values which the TOS field of that octet may contain. Section 5 describes how a host (or router) chooses appropriate values to insert into the TOS fields of the IP datagrams it originates. Sections 6 and 7 describe the ICMP Destination Unreachable and Redirect messages and how TOS affects path choice by both hosts and routers. Section 8 describes some additional ways in which TOS may optionally affect packet processing. Appendix A describes how this specification updates a number of existing specifications. Appendices B and C expand on the discussion in Section 2.
この仕様は詳細にホストとルータがどうTOS施設を使用するかを定義します。 セクション2はこの仕様でデザイン選択を動機づけたプライマリ問題を紹介します。 セクション3と4はその八重奏のTOS分野が含むかもしれないIPヘッダーと値におけるService八重奏のTypeについて説明します。 セクション5はホスト(または、ルータ)がどうそれが溯源するIPデータグラムのTOS分野に挿入するのが適切である値を選ぶかを説明します。 セクション6と7はICMP Destination Unreachableと、RedirectメッセージとTOSがホストとルータの両方でどう経路選択に影響するかを説明します。 セクション8はTOSがパケット処理に任意に影響するかもしれないいくつかの追加方法を述べます。 付録Aはこの仕様がどう多くの既存の仕様をアップデートするかを説明します。 付録BとCはセクション2で議論について詳述します。
2. Goals and Philosophy
2. 目標と哲学
The fundamental rule that guided this specification is that a host should never be penalized for using the TOS facility. If a host makes appropriate use of the TOS facility, its network service should be at least as good as (and hopefully better than) it would have been
この仕様を誘導した原理はホストがTOS施設を使用するために決して罰せられるべきでないということです。 ホストがTOS施設の適切な使用をするなら、ネットワーク・サービスが少なくとも同じくらい良いはずである、(願わくはより良い、)、それはあったでしょう。
Almquist [Page 3]
Almquist[3ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
if the host had not used the facility. This goal was considered particularly important because it is unlikely that any specification which did not meet this goal, no matter how good it might be in other respects, would ever become widely deployed and used. A particular consequence of this goal is that if a network cannot provide the TOS requested in a packet, the network does not discard the packet but instead delivers it the same way it would have been delivered had none of the TOS bits been set.
ホストが施設を使用していなかったなら。 この目標は、それが他の点でどんなに良いかもしれなくてもこの目標を達成しなかったどんな仕様も広く配布されるようになるのが、ありそうもないので特に重要であると考えられて、使用されました。 この目標の特定の結果はネットワークがパケットで要求されたTOSを提供できないなら、ネットワークがパケットを捨てませんが、代わりにTOSビットのいずれも設定されなかったならそれが提供された同じ方法にそれを提供するということです。
Even though the TOS facility has not been widely used in the past, it is a goal of this memo to be as compatible as possible with existing practice. Primarily this means that existing host implementations should not interact badly with hosts and routers which implement the specifications of this memo, since TOS support is almost non-existent in routers which predate this specification. However, this memo does attempt to be compatible with the treatment of IP TOS in OSPF and Integrated IS-IS.
TOS施設は過去に広く使用されていませんが、それはできるだけ既存の習慣と互換性があるこのメモの目標です。 主として、これは、既存のホスト導入がひどくこのメモの仕様を履行するホストとルータと対話するべきでないことを意味します、TOSサポートがこの仕様より前に起こるルータでほとんど実在しないので。 しかしながら、このメモが、OSPFとIntegratedでのIP TOSの処理と互換性があるのを試みる、-
Because the Internet community does not have much experience with TOS, it is important that this specification allow easy definition and deployment of new and experimental types of service. This goal has had a significant impact on this specification. In particular, it led to the decision to fix permanently the size of the TOS field and to the decision that hosts and routers should be able to handle a new type of service correctly without having to understand its semantics.
インターネットコミュニティにはTOSの多くの経験がないので、この仕様が新しくて実験しているタイプのサービスの簡単な定義と展開を許すのは、重要です。 この目標はこの仕様で重要な影響を与えました。 特に、それは永久に、TOS分野のサイズを固定して、ホストとルータが正しくそうする必要はなくて新しいタイプのサービスを扱うことができるべきであるという決定に意味論を理解しているという決定に通じました。
Appendix B of this memo provides a more detailed explanation of the rationale behind particular aspects of this specification.
このメモの付録Bはこの仕様の特定の局面の後ろに原理の、より詳細な説明を提供します。
3. Specification of the Type of Service Octet
3. サービス八重奏のタイプの仕様
The TOS facility is one of the features of the Type of Service octet in the IP datagram header. The Type of Service octet consists of three fields:
TOS施設はIPデータグラムヘッダーのService八重奏のTypeの特徴の1つです。 Service八重奏のTypeは3つの分野から成ります:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TOS | MBZ |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | 先行| TOS| MBZ| | | | | +-----+-----+-----+-----+-----+-----+-----+-----+
The first field, labeled "PRECEDENCE" above, is intended to denote the importance or priority of the datagram. This field is not discussed in detail in this memo.
上を「先行」とラベルされた最初の分野がデータグラムの重要性か優先権を指示することを意図します。 このメモで詳細にこの分野について議論しません。
The second field, labeled "TOS" above, denotes how the network should
上を「TOS」とラベルされた分野がどのようにを指示する秒に、ネットワークはそうするべきであるか。
Almquist [Page 4]
Almquist[4ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
make tradeoffs between throughput, delay, reliability, and cost. The TOS field is the primary topic of this memo.
スループットと、遅れと、信頼性と、費用の間で見返りを作ってください。 TOS分野はこのメモのプライマリ話題です。
The last field, labeled "MBZ" (for "must be zero") above, is currently unused. The originator of a datagram sets this field to zero (unless participating in an Internet protocol experiment which makes use of that bit). Routers and recipients of datagrams ignore the value of this field. This field is copied on fragmentation.
"MBZ"とラベルされた最後の分野、(「ゼロでなければならない」、)、上は現在、未使用です。 データグラムの創始者はこの分野をゼロに設定します(そのビットを利用するインターネットプロトコル実験に参加しない場合)。 データグラムのルータと受取人はこの分野の値を無視します。 この分野は断片化のときにコピーされます。
In the past there has been some confusion about the size of the TOS field. RFC-791 defined it as a three bit field, including bits 3-5 in the figure above. It included bit 6 in the MBZ field. RFC-1122 added bits 6 and 7 to the TOS field, eliminating the MBZ field. This memo redefines the TOS field to be the four bits shown in the figure above. The reasons for choosing to make the TOS field four bits wide can be found in Appendix B.2.
そこの過去に、TOS分野のサイズに関する何らかの混乱がありました。 RFC-791は上の図形にビット3-5を含む3ビットの分野とそれを定義しました。 それはMBZ分野にビット6を含んでいました。 MBZ分野を排除して、RFC-1122はビット6と7をTOS分野に加えました。 このメモは、上の図形に示された4ビットになるようにTOS分野を再定義します。 Appendix B.2でTOS分野を幅4ビットであるのにするのを選ぶ理由を見つけることができます。
4. Specification of the TOS Field
4. TOS分野の仕様
As was stated just above, this memo redefines the TOS field as a four bit field. Also contrary to RFC-791, this memo defines the TOS field as a single enumerated value rather than as a set of bits (where each bit has its own meaning). This memo defines the semantics of the following TOS field values (expressed as binary numbers):
すぐ上に述べられたように、このメモは、TOS分野を4ビットの分野と再定義します。 RFC-791とは逆にも、このメモは1セットのビット(各ビットがそれ自身の意味を持っているところ)としてというよりむしろただ一つの列挙された値とTOS分野を定義します。 このメモは以下のTOS分野値(2進の数として、言い表される)の意味論を定義します:
1000 -- minimize delay
0100 -- maximize throughput
0010 -- maximize reliability
0001 -- minimize monetary cost
0000 -- normal service
1000--遅れ0100を最小にしてください--スループット0010を最大にしてください--信頼性0001を最大にしてください--貨幣原価0000を最小にしてください--、通常のサービス
The values used in the TOS field are referred to in this memo as "TOS values", and the value of the TOS field of an IP packet is referred to in this memo as the "requested TOS". The TOS field value 0000 is referred to in this memo as the "default TOS."
TOS分野で使用される値はこのメモに「TOS値」と呼ばれます、そして、IPパケットのTOS分野の値はこのメモに「要求されたTOS」と呼ばれます。 TOS分野価値0000はこのメモに「デフォルトTOS」と呼ばれます。
Because this specification redefines TOS values to be integers rather than sets of bits, computing the logical OR of two TOS values is no longer meaningful. For example, it would be a serious error for a router to choose a low delay path for a packet whose requested TOS was 1110 simply because the router noted that the former "delay bit" was set.
この仕様がビットのセットよりむしろ整数になるようにTOS値を再定義するので、2つのTOS値の論理的なORを計算するのはもう重要ではありません。 例えば、単にルータが、前の「遅れビット」が設定されたことに注意したのでTOSが1110であるよう要求したのは、ルータがパケットのための低い遅れ経路を選ぶ重大な誤りでしょう。
Although the semantics of values other than the five listed above are not defined by this memo, they are perfectly legal TOS values, and hosts and routers must not preclude their use in any way. As will become clear after reading the remainder of this memo, only the default TOS is in any way special. A host or router need not (and
上に記載された5以外の値の意味論はこのメモで定義されませんが、それらは完全に法的なTOS値です、そして、ホストとルータは何らかの方法で彼らの使用を排除してはいけません。 このメモ、デフォルトだけTOSの残りを読んだ後に、特別番組がどんな方法でもあるのが明確になるので。 そしてホストかルータがそうする必要はない、(。
Almquist [Page 5]
Almquist[5ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
except as described in Section 8 should not) make any distinction between TOS values whose semantics are defined by this memo and those that are not.
セクション8がそうするべきでない説明されたコネ) TOSのどんな区別も評価する意味論がこのメモで定義される造とそうしないそれらを除いて。
It is important to note the use of the words "minimize" and "maximize" in the definitions of values for the TOS field. For example, setting the TOS field to 1000 (minimize delay) does not guarantee that the path taken by the datagram will have a delay that the user considers "low". The network will attempt to choose the lowest delay path available, based on its (often imperfect) information about path delay. The network will not discard the datagram simply because it believes that the delay of the available paths is "too high" (actually, the network manager can override this behavior through creative use of routing metrics, but this is strongly discouraged: setting the TOS field is intended to give better service when it is available, rather than to deny service when it is not).
それは、単語の使用が値の定義でTOS分野に「最小にし」て、「最大にする」と述べるために重要です。 例えば、1000(遅れを最小にする)にTOS分野を設定するのは、データグラムによって取られた経路がユーザが「低く」考える遅れを持つのを保証しません。 ネットワークは、経路遅れの(しばしば不完全)の情報に基づいて利用可能な最も低い遅れ経路を選ぶのを試みるでしょう。 単に利用可能な経路の遅れが「高過ぎること」が(これは強くがっかりしています: それが意図しないとき、実際に、ネットワークマネージャはルーティング測定基準の創造的な使用でこの振舞いをくつがえすことができますが、サービスを否定するというよりむしろそれが利用可能であるときに、TOS分野を設定すると、より良いサービスが与えられることを意図します)信じているので、ネットワークはデータグラムを捨てないでしょう。
5. Use of the TOS Field in the Internet Protocols
5. インターネットプロトコルにおけるTOS分野の使用
For the TOS facility to be useful, the TOS fields in IP packets must be filled in with reasonable values. This section discusses how protocols above IP choose appropriate values.
TOS施設が役に立つように、適正価値でIPパケットのTOS分野に記入しなければなりません。 このセクションはIPの上のプロトコルがどう適切な値を選ぶかを論じます。
5.1 Internet Control Message Protocol (ICMP)
5.1 インターネット・コントロール・メッセージ・プロトコル(ICMP)
ICMP [8,9,12] defines a number of messages for performing error
reporting and diagnostic functions for the Internet Layer. This
section describes how a host or router chooses appropriate TOS
values for ICMP messages it originates. The TOS facility also
affects the origination and processing of ICMP Redirects and ICMP
Destination Unreachables, but that is the topic of Section 6.
ICMP[8、9、12]は誤り報告と診断機能をインターネットLayerに実行することへの多くのメッセージを定義します。 このセクションはそれが溯源するICMPメッセージのためにホストかルータがどう適切なTOS値を選ぶかを説明します。 また、TOS施設はICMP RedirectsとICMP Destination Unreachablesの創作と処理に影響しますが、それはセクション6の話題です。
For purposes of this discussion, it is useful to divide ICMP
messages into three classes:
この議論の目的に、ICMPメッセージを3つのクラスに分割するのは役に立ちます:
o ICMP error messages include ICMP message types 3 (Destination
Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time
Exceeded), and 12 (Parameter Problem).
o ICMPエラーメッセージはメッセージがタイプするICMPを含んでいます。3 (目的地Unreachable)、(ソースQuench)、5(向け直す)、11(時間Exceeded)、および12(パラメタProblem)の4。
o ICMP request messages include ICMP message types 8 (Echo), 10
(Router Solicitation), 13 (Timestamp), 15 (Information
Request -- now obsolete), and 17 (Address Mask Request).
o ICMP要求メッセージが15歳のICMPメッセージタイプ8(反響する)、10(ルータSolicitation)、13(タイムスタンプ)を含んでいる、(情報Request--、現在時代遅れにする、)、そして、17(アドレスMask Request)。
o ICMP reply messages include ICMP message types 0 (Echo
Reply), 9 (Router Advertisement), 14 (Timestamp Reply), 16
(Information Reply -- also obsolete), and 18 (Address Mask
Reply).
o ICMP応答メッセージが9歳のICMPメッセージタイプ0(エコーReply)(ルータAdvertisement)を含んでいる、14(タイムスタンプReply)、16、(情報Reply--、また、時代遅れにする、)、そして、18(アドレスMask Reply)。
Almquist [Page 6]
Almquist[6ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
An ICMP error message is always sent with the default TOS (0000).
デフォルトTOS(0000)と共にICMPエラーメッセージをいつも送ります。
An ICMP request message may be sent with any value in the TOS
field. A mechanism to allow the user to specify the TOS value to
be used would be a useful feature in many applications that
generate ICMP request messages.
どんな値もTOS分野にある状態で、ICMP要求メッセージを送るかもしれません。 ユーザが使用されるためにTOS値を指定するのを許容するメカニズムはICMPに要求メッセージを生成する多くのアプリケーションで役に立つ特徴でしょう。
An ICMP reply message is sent with the same value in the TOS field
as was used in the corresponding ICMP request message.
同じ値が対応するICMP要求メッセージで使用されたTOS分野にある状態で、ICMP応答メッセージを送ります。
5.2 Transport Protocols
5.2 輸送プロトコル
When sending a datagram, a transport protocol uses the TOS
requested by the application. There is no requirement that both
ends of a transport connection use the same TOS. For example, the
sending side of a bulk data transfer application should request
that throughput be maximized, whereas the receiving side might
request that delay be minimized (assuming that it is primarily
sending small acknowledgement packets). It may be useful for a
transport protocol to provide applications with a mechanism for
learning the value of the TOS field that accompanied the most
recently received data.
データグラムを送るとき、トランスポート・プロトコルはアプリケーションで要求されたTOSを使用します。 輸送接続の両端が同じTOSを使用するという要件が全くありません。 例えば、バルク・データ転送アプリケーションの送付側は、スループットが最大にされるよう要求するはずですが、受信側は、遅れが最小にされるよう要求するかもしれません(主として小さい確認応答パケットを送ると仮定して)。 トランスポート・プロトコルが最も最近伴走したTOS分野の値がデータを受け取ったことを学ぶためにメカニズムをアプリケーションに提供するのは、役に立つかもしれません。
It is quite permissible to switch to a different TOS in the middle
of a connection if the nature of the traffic being generated
changes. An example of this would be SMTP, which spends part of
its time doing bulk data transfer and part of its time exchanging
short command messages and responses.
生成されるトラフィックの本質が変化するなら、接続の途中の異なったTOSに切り替わるのはかなり許されています。 この例はSMTPでしょう。(そのSMTPは、短いコマンドメッセージと応答を交換しながら、時間のバルク・データ転送と一部をするのに時間の一部を費やします)。
TCP [13] should use the same TOS for datagrams containing only TCP
control information as it does for datagrams which contain user
data. Although it might seem intuitively correct to always
request that the network minimize delay for segments containing
acknowledgements but no data, doing so could corrupt TCP's round
trip time estimates.
TCP[13]はそれとしてTCP制御情報だけを含んでいると利用者データを含むデータグラムのためにするデータグラムに同じTOSを使用するはずです。 いつもネットワークが承認を含んでいますが、どんなデータも含まないセグメントのために遅れを最小にするよう要求するのが直観的に正しく思えるかもしれませんが、そうするのはTCPの周遊旅行時間見積りを崩壊させるかもしれません。
5.3 Application Protocols
5.3 アプリケーションプロトコル
Applications are responsible for choosing appropriate TOS values
for any traffic they originate. The Assigned Numbers document
[15] lists the TOS values to be used by a number of common network
applications. For other applications, it is the responsibility of
the application's designer or programmer to make a suitable
choice, based on the nature of the traffic to be originated by the
application.
それらが溯源するどんなトラフィックにおいても、アプリケーションは適切なTOS値を選ぶのに原因となります。 Assigned民数記ドキュメント[15]は、多くの一般的なネットワーク応用で使用されるためにTOS値を記載します。 他のアプリケーションのために、適当な選択をするのは、アプリケーションのデザイナーかプログラマの責任です、アプリケーションで溯源されるべきトラフィックの本質に基づいて。
It is essential for many sorts of network diagnostic applications,
and desirable for other applications, that the user of the
アプリケーションの、そして、他のアプリケーションに、望ましいネットワーク病気の特徴の多くの種類に、それは不可欠であり、それはユーザです。
Almquist [Page 7]
Almquist[7ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
application be able to override the TOS value(s) which the
application would otherwise choose.
アプリケーション、アプリケーションが別の方法で選ぶTOS値をくつがえすことができてください。
The Assigned Numbers document is revised and reissued
periodically. Until RFC-1060, the edition current as this is
being written, has been superceded, readers should consult
Appendix A.2 of this memo.
Assigned民数記ドキュメントは、定期的に改訂されて、再発行されます。 RFC-1060がスーパー割譲されるまで、これとしての版の電流が書かれている読者はこのメモのAppendix A.2に相談するべきです。
6. ICMP and the TOS Facility
6. ICMPとTOS施設
Routers communicate routing information to hosts using the ICMP protocol [12]. This section describes how support for the TOS facility affects the origination and interpretation of ICMP Redirect messages and certain types of ICMP Destination Unreachable messages. This memo does not define any new extensions to the ICMP protocol.
ルータは、ICMPプロトコル[12]を使用することでルーティング情報をホストに伝えます。 このセクションはTOS施設のサポートがどうICMP Redirectメッセージの創作と解釈とあるタイプに関するICMP Destination Unreachableメッセージに影響するかを説明します。 このメモは少しの新しい拡大もICMPプロトコルと定義しません。
6.1 Destination Unreachable
6.1の目的地手が届きません。
The ICMP Destination Unreachable message contains a code which
describes the reason that the destination is unreachable. There
are four codes [1,12] which are particularly relevant to the topic
of this memo:
ICMP Destination Unreachableメッセージは目的地が手が届かない理由について説明するコードを含んでいます。 特にこのメモの話題に関連している4つのコード[1、12]があります:
0 -- network unreachable
1 -- host unreachable
11 -- network unreachable for type of service
12 -- host unreachable for type of service
0--手の届かない1をネットワークでつないでください--手の届かない11--サービス12のタイプに、手の届かないネットワーク--サービスのタイプに、手の届かないホストを接待してください。
A router generates a code 11 or code 12 Destination Unreachable
when an unreachable destination (network or host) would have been
reachable had a different TOS value been specified. A router
generates a code 0 or code 1 Destination Unreachable in other
cases.
異なったTOS値が指定されたなら手の届かない目的地(ネットワークでつなぐか、または接待する)が届いていたとき、ルータは、コード11かコードが12Destination Unreachableであると生成します。 ルータは、他の場合でコード0かコードが1Destination Unreachableであると生成します。
A host receiving a Destination Unreachable message containing any
of these codes should recognize that it may result from a routing
transient. The host should therefore interpret the message as
only a hint, not proof, that the specified destination is
unreachable.
これらのコードのいずれも含むDestination Unreachableメッセージを受け取るホストは、一時的な状態でルーティングから生じるかもしれないと認めるべきです。 したがって、ホストは証拠ではなく、指定された目的地が手が届かないというヒントだけとしてメッセージを解釈するべきです。
The use of codes 11 and 12 may seem contrary to the statement in
Section 2 that packets should not be discarded simply because the
requested TOS cannot be provided. The rationale for having these
codes and the limited cases in which they are expected to be used
are described in Appendix B.5.
コード11と12の使用は、声明とは逆にセクション2でパケットが単に要求されたTOSを提供できないので捨てられるべきでないように思えるかもしれません。 これらのコードを持つための原理とそれらが使用されると予想される限られた場合はAppendix B.5で説明されます。
Almquist [Page 8]
Almquist[8ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
6.2 Redirect
6.2は向け直します。
The ICMP Redirect message also includes a code, which specifies
the class of datagrams to which the Redirect applies. There are
currently four codes defined:
また、ICMP Redirectメッセージはコードを含んでいます。(それは、Redirectが適用するデータグラムのクラスを指定します)。 現在、定義された4つのコードがあります:
0 -- redirect datagrams for the network
1 -- redirect datagrams for the host
2 -- redirect datagrams for the type of service and network
3 -- redirect datagrams for the type of service and host
0(ネットワーク1のための再直接のデータグラム)はホスト2のためにデータグラムを向け直します--サービスとネットワーク3のタイプのためにデータグラムを向け直してください--サービスとホストのタイプのためにデータグラムを向け直してください。
A router generates a code 3 Redirect when the Redirect applies
only to IP packets which request a particular TOS value. A router
generates a code 1 Redirect instead when the the optimal next hop
on the path to the destination would be the same for any TOS
value. In order to minimize the potential for host confusion,
routers should refrain from using codes 0 and 2 in Redirects
[3,6].
Redirectが特定のTOS値を要求するIPパケットだけに適用するとき、ルータは、コードが3Redirectであると生成します。 どんなTOS値にも、目的地への経路の次の最適のホップが同じであるだろうというときに、ルータは、代わりにコードが1Redirectであると生成します。 ホスト混乱の可能性を最小にするために、ルータは、Redirects[3、6]でコード0と2を使用するのを控えるべきです。
Although the current Internet Host specification [1] only requires
hosts to correctly handle code 0 and code 1 Redirects, a host
should also correctly handle code 2 and code 3 Redirects, as
described in Section 7.1 of this memo. If a host does not, it is
better for the host to treat code 2 as equivalent to code 0 and
code 3 as equivalent to code 1 than for the host to simply ignore
code 2 and code 3 Redirects.
現在のインターネットHost仕様[1]は、ホストが正しくコード0を扱って、1Redirectsをコード化するのを必要とするだけですが、ホストは、また、正しくコード2を扱って、3Redirectsをコード化するべきです、このメモのセクション7.1で説明されるように。 ホストがそうしないなら、ホストが1をコード化するために同等な同じくらい0と同じくらいコード3をコード化するために同等な同じくらいコード2を扱うのは、ホストが単にコード2を無視して、3Redirectsをコード化するより良いです。
7. Use of the TOS Field in Routing
7. ルート設定におけるTOS分野の使用
Both hosts and routers should consider the value of the TOS field of a datagram when choosing an appropriate path to get the datagram to its destination. The mechanisms for doing so are discussed in this section.
目的地にデータグラムを届けるために適切な経路を選ぶとき、ホストとルータの両方がデータグラムのTOS分野の値を考えるべきです。 このセクションでそうするためのメカニズムについて議論します。
Whether a packet's TOS value actually affects the path it takes inside of a particular routing domain is a choice made by the routing domain's network manager. In many routing domains the paths are sufficiently homogeneous in nature that there is no reason for routers to choose different paths based up the TOS field in a datagram. Inside such a routing domain, the network manager may choose to limit the size of the routing database and of routing protocol updates by only defining routes for the default (0000) TOS. Neither hosts nor routers should need to have any explicit knowledge of whether TOS affects routing in the local routing domain.
パケットのTOS値が実際に、それが中で取る特定の経路ドメインの経路に影響するかどうかが、経路ドメインのネットワークマネージャによってされた選択です。 多くの経路ドメインでは、経路がルータがTOS分野に基づく異なった経路を選ぶ理由が全くデータグラムにない自然で十分均質です。 そのような経路ドメインの中では、ネットワークマネージャは、デフォルト(0000)TOSのためにルートを定義するだけでルーティングデータベースとルーティング・プロトコルアップデートのサイズを制限するのを選ぶかもしれません。 ホストもルータもTOSが地方の経路ドメインでルーティングに影響するかどうかに関する少しの形式知も必要とするべきではありません。
Almquist [Page 9]
Almquist[9ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
7.1 Host Routing
7.1 ホストルート設定
When a host (which is not also a router) wishes to send an IP
packet to a destination on another network or subnet, it needs to
choose an appropriate router to send the packet to. According to
the IP Architecture, it does so by maintaining a route cache and a
list of default routers. Each entry in the route cache lists a
destination (IP address) and the appropriate router to use to
reach that destination. The host learns the information stored in
its route cache through the ICMP Redirect mechanism. The host
learns the list of default routers either from static
configuration information or by using the ICMP Router Discovery
mechanism [8]. When the host wishes to send an IP packet, it
searches its route cache for a route matching the destination
address in the packet. If one is found it is used; if not, the
packet is sent to one of the default routers. All of this is
described in greater detail in section 3.3.1 of RFC-1122 [1].
ホスト(また、ルータでない)が別のネットワークかサブネットでIPパケットを目的地に送りたがっているとき、それは、パケットを送るのが適切であるルータを選ぶ必要があります。 IP Architectureによると、それは、そう経路キャッシュとデフォルトルータのリストを維持することによって、します。 経路キャッシュにおける各エントリーは目的地(IPアドレス)とその目的地に達するのに使用するのが適切であるルータを記載します。 ホストはICMP Redirectメカニズムを通して経路キャッシュで保存された情報を学びます。 ホストは、静的な設定情報かICMP Routerディスカバリーメカニズム[8]を使用することによって、デフォルトルータのリストを学びます。 ホストがIPパケットを送りたがっているとき、それはパケットで送付先アドレスに合っているルートとして経路キャッシュを捜します。 1つが見つけられるなら、使用されています。 そうでなければ、デフォルトルータの1つにパケットを送ります。 このすべてが.1セクション3.3RFC-1122[1]で詳細によりすばらしい説明されます。
Adding support for the TOS facility changes the host routing
procedure only slightly. In the following, it is assumed that (in
accordance with the current Internet Host specification [1]) the
host treats code 0 (redirect datagrams for the network) Redirects
as if they were code 1 (redirect datagrams for the host)
Redirects. Similarly, it is assumed that the host treats code 2
(redirect datagrams for the network and type of service) Redirects
as if they were code 3 (redirect datagrams for the host and type
of service) Redirects. Readers considering violating these
assumptions should be aware that long and careful consideration of
the way in which Redirects are treated is necessary to avoid
situations where every packet sent to some destination provokes a
Redirect. Because these assumptions match the recommendations of
Internet Host specification, that careful consideration is beyond
the scope of this memo.
TOS施設のサポートを加えると、ホストルーティング手順はわずかにだけ変化します。 以下では、それが想定される、それ、(現在のインターネットHost仕様[1])に従ったコード0(ネットワークのためにデータグラムを向け直します)がまるでそれらが1(ホストのためにデータグラムを向け直す)が向け直すコードであるかのように向け直すホストの御馳走。 同様に、まるでそれらがあるかのようにコード2(サービスのネットワークとタイプのためにデータグラムを向け直します)が向け直すホストの御馳走が(サービスのホストとタイプのための再直接のデータグラム)が向け直す3をコード化すると思われます。 これらの仮定に違反すると考える読者はRedirectsが扱われる方法の長くて慎重な熟考がいくつかの目的地に送られたあらゆるパケットがRedirectを引き起こす状況を避けるのに必要であることを意識しているべきです。 これらの仮定がインターネットHost仕様の推薦に合うのが、このメモの範囲を超えたその熟慮の理由です。
As was described in Section 6.2, some ICMP Redirects apply only to
IP packets which request a particular TOS. Thus, a host (at least
conceptually) needs to store two types of entries in its route
cache:
セクション6.2で説明されたように、いくつかのICMP Redirectsが特定のTOSを要求するIPパケットだけに適用します。 したがって、ホスト(少なくとも概念的である)は、経路キャッシュにおける、2つのタイプのエントリーを保存する必要があります:
type 1: { destination, TOS, router }
タイプ1: 目的地、TOS、ルータ
type 2: { destination, *, router }
2はタイプします: 目的地、*、ルータ
where type 1 entries result from the receipt of code 3 (or code 1)
Redirects and type 2 entries result from the receipt of code 2 (or
code 0) Redirects.
タイプ1エントリーがコードの領収書から生じるところでは、3(または、コード1)は、コード2(または、コード0)の領収書からの結果が向け直す2つのエントリーを向け直して、タイプします。
Almquist [Page 10]
Almquist[10ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
When a host wants to send a packet, it first searches the route
cache for a type 1 entry whose destination matches the destination
address of the packet and whose TOS matches the requested TOS in
the packet. If it doesn't find one, the host searches its route
cache again, this time looking for a type 2 entry whose
destination matches the destination address of the packet. If
either of these searches finds a matching entry, the packet is
sent to the router listed in the matching entry. Otherwise, the
packet is sent to one of the routers on the list of default
routers.
ホストはパケットを送りたがっていて、最初に目的地がパケットの送付先アドレスに合っているタイプ1エントリーとして経路キャッシュを捜します、そして、TOSはパケットで要求されたTOSに合っています。 1つを見つけないなら、ホストは、再び、今回、目的地がパケットの送付先アドレスに合っているタイプ2エントリーを探しながら、経路キャッシュを捜します。 これらの検索のどちらかが合っているエントリーを見つけるなら、合っているエントリーに記載されたルータにパケットを送ります。 さもなければ、デフォルトルータのリストの上のルータの1つにパケットを送ります。
When a host creates (or updates) a type 2 entry, it must flush
from its route cache any type 1 entries which have the same
destination. This is necessary for correctness, since the type 1
entry may be obsolete but would continue to be used if it weren't
flushed because type 1 entries are always preferred over type 2
entries.
ホストがタイプ2エントリーを作成するとき(または、アップデート)、それは経路キャッシュから同じ目的地を持っているどんなタイプ1エントリーも洗い流さなければなりません。 これが正当性に必要です、タイプ1エントリーが、時代遅れであるかもしれませんが、タイプ1エントリーがタイプ2エントリーよりいつも好まれるのでそれが洗い流されないなら使用され続けているので。
However, the converse is not true: when a host creates a type 1
entry, it should not flush a type 2 entry that has the same
destination. In this case, the type 1 entry will properly
override the type 2 entry for packets whose destination address
and requested TOS match the type 1 entry. Because the type 2
entry may well specify the correct router for some TOS values
other than the one specified in the type 1 entry, saving the type
2 entry will likely cut down on the number of Redirects which the
host would otherwise receive. This savings can potentially be
substantial if one of the Redirects which was avoided would have
created a new type 2 entry (thereby causing the new type 1 entry
to be flushed). That can happen, for example, if only some of the
routers on the local net are part of a routing domain that
computes separate routes for each TOS.
しかしながら、逆は本当ではありません: ホストがタイプ1エントリーを作成するとき、それは同じ目的地を持っているタイプ2エントリーを洗い流すべきではありません。 この場合、タイプ1エントリーは適切に送付先アドレスと要求されたTOSがタイプ1エントリーに合っているパケットのためのタイプ2エントリーをくつがえすでしょう。 タイプ2エントリーはたぶんタイプ1エントリーで指定されたもの以外のいくつかのTOS値に正しいルータを指定するでしょう、したがって、そうでなければホストが受け取るRedirectsの数で削られて、2エントリーがおそらくそうするタイプを救うこと。 避けられたRedirectsの1つが新しいタイプ2エントリー(その結果、1つの洗い流されるべきエントリーを新しいタイプに引き起こす)を作成したなら、この貯蓄は潜在的に実質的である場合があります。 例えば、それはローカルのネットのルータの唯一のいくつかが各TOSのために別々のルートを計算する経路ドメインの一部であるなら起こることができます。
As an alternative, a host may treat all Redirects as if they were
code 3 (redirect datagrams for hosts and type of service)
Redirects. This alternative allows the host to have only type 1
route cache entries, thereby simplifying route lookup and
eliminating the need for the rules in the previous two paragraphs.
The disadvantage of this approach is that it increases the size of
the route cache and the amount of Redirect traffic if the host
sends packets with a variety of requested TOS's to a destination
for which the host should use the same router regardless of the
requested TOS. There is not yet sufficient experience with the
TOS facility to know whether that disadvantage would be serious
enough in practice to outweigh the simplicity of this approach.
代替手段として、ホストはまるで彼らが3(サービスのホストとタイプのためにデータグラムを向け直す)が向け直すコードであるかのようにすべてのRedirectsを扱うかもしれません。 ホストはこの代替手段でタイプ1経路キャッシュエントリーしか持つことができません、前の2つのパラグラフでその結果、ルートルックアップを簡素化して、規則の必要性を排除して。 このアプローチの不都合はホストがホストが要求されたTOSにかかわらず同じルータを使用するべきである目的地に要求されたTOSのさまざまなものがあるパケットを送るなら経路キャッシュのサイズとRedirectトラフィックの量を増強するということです。 まだ、TOS施設にはその不都合が実際にはこのアプローチの簡単さを重いことができるくらい重大であるかどうかを知ることができるくらいの経験がありません。
Despite RFC-1122, some hosts acquire their routing information by
"wiretapping" a routing protocol instead of by using the
RFC-1122にもかかわらず、使用することの代わりにルーティング・プロトコルが「盗聴」であることによって彼らのルーティング情報を取得するホストもいます。
Almquist [Page 11]
Almquist[11ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
mechanisms described above. Such hosts will need to follow the
procedures described in Section 7.2 (except of course that hosts
will not send ICMP Destination Unreachables or ICMP Redirects).
上で説明されたメカニズム。 そのようなホストは、セクション7.2で説明された手順に従う必要があるでしょう(もちろんそれ以外に、ホストはICMP Destination UnreachablesかICMP Redirectsを送らないでしょう)。
7.2 Forwarding
7.2 推進
A router in the Internet should be able to consider the value of
the TOS field when choosing an appropriate path over which to
forward an IP packet. How a router does this is a part of the
more general issue of how a router picks appropriate paths. This
larger issue can be extremely complex [4], and is beyond the scope
of this memo. This discussion should therefore be considered only
an overview. Implementors should consult the Router Requirements
specification [3] and the the specifications of the routing
protocols they implement for details.
IPパケットを送るのが適切である経路を選ぶとき、インターネットのルータはTOS分野の値を考えることができるべきです。 ルータがどうこれをするかは、ルータがどう適切な経路を選ぶかに関する、より一般的な問題の一部です。 このより大きい問題は、非常に複雑な[4]であることができ、このメモの範囲を超えています。 したがって、この議論は概要だけであると考えられるべきです。 作成者はそれらが詳細のために実装するルーティング・プロトコルのRouter Requirements仕様[3]と仕様に相談するべきです。
A router associates a TOS value with each route in its forwarding
table. The value can be any of the possible values of the TOS
field in an IP datagram (including those values whose semantics
are yet to be defined). Any routes learned using routing
protocols which support TOS are assigned appropriate TOS value by
those protocols. Routes learned using other routing protocols are
always assigned the default TOS value (0000). Static routes have
their TOS values assigned by the network manager.
ルータは推進テーブルの各ルートにTOS値を関連づけます。 値はIPデータグラムのTOS分野の可能な値のいずれであることができます(まだ定義されていない意味論がことであるそれらの値を含んでいて)も。 適切なTOS値はそれらのプロトコルによってTOSをサポートするルーティング・プロトコルを使用することで学習されたどんなルートにも割り当てられます。 デフォルトTOS価値(0000)はいつも他のルーティング・プロトコルを使用することで学習されたルートに割り当てられます。 スタティックルートで、ネットワークマネージャはそれらのTOS値を割り当てます。
When a router wants to forward a packet, it first looks up the
destination address in its forwarding table. This yields a set of
candidate routes. The set may be empty (if the destination is
unreachable), or it may contain one or more routes to the
destination. If the set is not empty, the TOS values of the
routes in the set are examined. If the set contains a route whose
TOS exactly matches the TOS field of the packet being forwarded
then that route is chosen. If not but the set contains a route
with the default TOS then that route is chosen.
ルータであるときに、パケットを進める必需品であり、それは最初に、推進テーブルで送付先アドレスを調べます。 これは1セットの候補ルートをもたらします。 セットが空であるかもしれませんか(目的地が手が届かないなら)、またはそれは1つ以上のルートを目的地に含むかもしれません。 セットが空でないなら、セットにおける、ルートのTOS値は調べられます。 セットがTOSがまさに進められるパケットのTOS分野に合っているルートを含んでいるなら、そのルートは選ばれています。 セットだけがデフォルトTOSがあるルートを含んでいないなら、そのルートは選ばれています。
If no route is found, or if the the chosen route has an infinite
metric, the destination is considered to be unreachable. The
packet is discarded and an ICMP Destination Unreachable is
returned to the source. Normally, the Unreachable uses code 0
(Network unreachable) or 1 (Host unreachable). If, however, a
route to the destination exists which has a different TOS value
and a non-infinite metric then code 11 (Network unreachable for
type of service) or code 12 (Host unreachable for type of service)
must be used instead.
ルートが全く当たられないか、または無限が選ばれたルートでメートル法になるなら、目的地が手が届かないと考えられます。 パケットは捨てます、そして、ICMP Destination Unreachableをソースに返します。 通常、Unreachableはコード0(ネットワーク手の届かない)か1(ホスト手の届かない)を使用します。 しかしながら、目的地への異なったTOS値と非無限をメートル法にするルートが存在しているなら、代わりに、コード11(サービスのタイプに、手の届かないネットワーク)かコード12(サービスのタイプに、手の届かないホスト)を使用しなければなりません。
Almquist [Page 12]
Almquist[12ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
8. Other consequences of TOS
8. TOSの他の結果
The TOS field in a datagram primarily affects the path chosen through the network, but an implementor may choose to have TOS also affect other aspects of how the datagram is handled. For example, a host or router might choose to give preferential queuing on network output queues to datagrams which have requested that delay be minimized. Similarly, a router forced by overload to discard packets might attempt to avoid discarding packets that have requested that reliability be maximized. At least one paper [14] has explored these ideas in some detail, but little is known about how well such special handling would work in practice.
データグラムのTOS分野は主としてネットワークを通して選ばれた経路に影響しますが、作成者は、また、TOSをデータグラムがどう扱われるかに関する他の局面に影響させるのを選ぶかもしれません。 例えば、ホストかルータが、ネットワーク出力キューの優先の列を作りを遅れが最小にされるよう要求したデータグラムに与えるのを選ぶかもしれません。 同様に、オーバーロードでやむを得ずパケットを捨てたルータは、信頼性が最大にされるよう要求したパケットを捨てるのを避けるのを試みるかもしれません。 少なくとも紙[14]がこれらの考えを探った或るものが詳しく述べる1、そのような特別な取り扱いが実際にはどれくらいよく働くだろうかに関して少ししかだけ知られていません。
Additionally, some Link Layer protocols have their own quality of service mechanisms. When a router or host transmits an IP packet, it might request from the Link Layer a quality of service as close as possible to the one requested in the TOS field in the IP header. Long ago an attempt (RFC-795) was made to codify how this might be done, but that document describes Link Layer protocols which have since become obsolete and no more recent document on the subject has been written.
さらに、いくつかのLink Layerプロトコルには、それら自身のサービスの質メカニズムがあります。ルータかホストがIPパケットを伝えるとき、それはできるだけIPヘッダーのTOS分野で要求されたものの近くでLink Layerからサービスの質を要求するかもしれません。 昔に、これが完了しているかもしれませんが、そのドキュメントがどう以来時代遅れになっているLink Layerプロトコルについて説明するかを成文化するのを試み(RFC-795)をしました、そして、話題の上のそれ以上の最近のドキュメントを書いていません。
Almquist [Page 13]
Almquist[13ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
APPENDIX A. Updates to Other Specifications
他の仕様への付録A.最新版
While this memo is primarily an update to the IP protocol specification [11], it also peripherally affects a number of other specifications. This appendix describes those peripheral effects. This information is included in an appendix rather than in the main body of the document because most if not all of these other specifications will be updated in the future. As that happens, the information included in this appendix will become obsolete.
このメモは主としてIPプロトコル仕様[11]への最新版ですが、また、それは周囲に他の多くの仕様に影響します。 この付録はそれらの周囲の効果について説明します。 この情報は、将来これらの他の仕様の大部分かすべてをアップデートするので、ドキュメントの本体でというよりむしろ付録に含まれています。 それが起こるのに従って、この付録に情報を含んでいるのは時代遅れになるでしょう。
A.1 RFC-792 (ICMP)
A.1 RFC-792(ICMP)
RFC-792 [12] defines a set of codes indicating reasons why a
destination is unreachable. This memo describes the use of two
additional codes:
RFC-792[12]は目的地が手が届かない理由を示す1セットのコードを定義します。 このメモは2つの追加コードの使用について説明します:
11 -- network unreachable for type of service
12 -- host unreachable for type of service
11--サービス12のタイプに、手の届かないネットワーク--サービスのタイプに、手の届かないホスト
These codes were defined in RFC-1122 [1] but were not included in
RFC-792.
これらのコードは、RFC-1122[1]で定義されましたが、RFC-792に含まれていませんでした。
A.2 RFC-1060 (Assigned Numbers)
A.2 RFC-1060(規定番号)
RFC-1060 [15] describes the old interpretation of the TOS field
(as three independent bits, with no way to specify that monetary
cost should be minimized). Although it is likely obvious how the
values in RFC-1060 ought to be interpreted in light of this memo,
the information from that RFC is reproduced here. The only actual
changes are for ICMP (to conform to Section 5.1 of this memo) and
NNTP:
RFC-1060[15]はTOS分野(貨幣原価が最小にされるべきであると指定する方法のない独立している3ビットとしての)の古い解釈について説明します。 RFC-1060の値がこのメモの観点からどのように解釈されるべきであるかが、おそらく明白ですが、そのRFCからの情報はここで再生します。 唯一の実際の変化がICMP(このメモのセクション5.1に従う)とNNTPのためのものです:
----- Type-of-Service Value -----
----- サービスのタイプ値-----
Protocol TOS Value
プロトコルTOS価値
TELNET (1) 1000 (minimize delay)
telnet(1)1000(遅れを最小にします)
FTP
Control 1000 (minimize delay)
Data (2) 0100 (maximize throughput)
FTP Control1000(遅れを最小にします)データ(2)0100(スループットを最大にします)
TFTP 1000 (minimize delay)
TFTP1000(遅れを最小にします)
SMTP (3)
Command phase 1000 (minimize delay)
DATA phase 0100 (maximize throughput)
SMTP(3)コマンドフェーズ1000(遅れを最小にする)DATAは0100の位相を合わせます。(スループットを最大にします)
Almquist [Page 14]
Almquist[14ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
----- Type-of-Service Value -----
----- サービスのタイプ値-----
Protocol TOS Value
プロトコルTOS価値
Domain Name Service
UDP Query 1000 (minimize delay)
TCP Query 0000
Zone Transfer 0100 (maximize throughput)
ドメインName Service UDP Query1000(遅れを最小にする)TCP Query0000Zone Transfer0100(スループットを最大にします)
NNTP 0001 (minimize monetary cost)
NNTP0001(貨幣原価を最小にします)
ICMP
Errors 0000
Requests 0000 (4)
Responses <same as request> (4)
要求>と同じICMP Errors0000Requests0000(4)応答<。(4)
Any IGP 0010 (maximize reliability)
どんなIGP0010(信頼性を最大にします)
EGP 0000
EGP0000
SNMP 0010 (maximize reliability)
SNMP0010(信頼性を最大にします)
BOOTP 0000
BOOTP0000
Notes:
注意:
(1) Includes all interactive user protocols (e.g., rlogin).
(1)はすべての対話的なユーザプロトコル(例えば、rlogin)を含んでいます。
(2) Includes all bulk data transfer protocols (e.g., rcp).
(2)はすべてのバルク・データ転送プロトコル(例えば、rcp)を含んでいます。
(3) If the implementation does not support changing the TOS
during the lifetime of the connection, then the
recommended TOS on opening the connection is the default
TOS (0000).
(3) 実装が、接続の生涯変化がTOSであるとサポートしないなら、接続を開くときのお勧めのTOSはデフォルトTOS(0000)です。
(4) Although ICMP request messages are normally sent with the
default TOS, there are sometimes good reasons why they
would be sent with some other TOS value. An ICMP response
always uses the same TOS value as was used in the
corresponding ICMP request message. See Section 5.1 of
this memo.
(4) デフォルトTOSで通常ICMP要求メッセージを送りますが、それらがある他のTOS値と共に送られる十分な理由が時々あります。 ICMP応答はいつもTOSが対応するICMP要求メッセージで使用されたように評価する同じくらいを使用します。 このメモのセクション5.1を見てください。
An application may (at the request of the user) substitute 0001
(minimize monetary cost) for any of the above values.
アプリケーションは0001(貨幣原価を最小にする)を上の値のいずれも代わりに用いるかもしれません(ユーザの依頼で)。
This appendix is expected to be obsoleted by the next revision
of the Assigned Numbers document.
Assigned民数記ドキュメントの次の改正でこの付録が時代遅れにされると予想されます。
Almquist [Page 15]
Almquist[15ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
A.3 RFC-1122 and RFC-1123 (Host Requirements)
A.3 RFC-1122とRFC-1123(ホスト要件)
The use of the TOS field by hosts is described in detail in
RFC-1122 [1] and RFC-1123 [2]. The information provided there is
still correct, except that:
ホストによるTOS分野の使用はRFC-1122[1]とRFC-1123[2]で詳細に説明されます。 それを除いて、そこに提供された情報はまだ正しいです:
(1) The TOS field is four bits wide rather than five bits wide.
The requirements that refer to the TOS field should refer
only to the four bits that make up the TOS field.
(1) TOS分野は幅5ビットよりむしろ幅4ビットです。 TOS野原について言及する要件はTOS分野を作る4ビットだけについて言及するべきです。
(2) An application may set bit 6 of the TOS octet to a non-zero
value (but still must not set bit 7 to a non-zero value).
(2) アプリケーションは非ゼロ値(しかし、まだ、非ゼロ値にビット7を設定してはいけない)にTOS八重奏のビット6を設定するかもしれません。
These details will presumably be corrected in the next revision of
the Host Requirements specification, at which time this appendix
can be considered obsolete.
おそらく、どの時に時代遅れであるとこの付録を考えることができるかとき、これらの詳細はHost Requirements仕様の次の改正で直るでしょう。
A.4 RFC-1195 (Integrated IS-IS)
A.4 RFC-1195(統合、-、)
Integrated IS-IS (sometimes known as Dual IS-IS) has multiple
metrics for each route. Which of the metrics is used to route a
particular IP packet is determined by the TOS field in the packet.
This is described in detail in section 3.5 of RFC-1195 [7].
統合、-、(Dualとして時々知られている、-、)、各ルートへの複数の測定基準を持っています。 測定基準のどれが特定のIPパケットを発送するのに使用されるかは、パケットのTOS分野のそばで決定しています。 これはRFC-1195[7]のセクション3.5で詳細に説明されます。
The mapping from the value of the TOS field to an appropriate
Integrated IS-IS metric is described by a table in that section.
Although the specification in this memo is intended to be
substantially compatible with Integrated IS-IS, the extension of
the TOS field to four bits and the addition of a TOS value
requesting "minimize monetary cost" require minor modifications to
that table, as shown here:
TOS分野の値からのマッピング、適切なIntegrated、-、メートル法、テーブルで、そのセクションで、説明されます。 このメモによる仕様は実質的にIntegratedと互換性があることを意図する、-、4ビットへのTOS分野の拡大と「貨幣原価を最小にしてください」がそれへの小さい方の変更を必要とするよう要求するa TOS価値の追加はここで示されるとして以下をテーブルの上に置きます。
The IP TOS octet is mapped onto the four available metrics as
follows:
IP TOS八重奏は以下の4つの利用可能な測定基準に写像されます:
Bits 0-2 (Precedence): (unchanged from RFC-1195)
ビット0-2(先行): (RFC-1195から変わりのない)です。
Bits 3-6 (TOS):
ビット3-6(TOS):
0000 (all normal) Use default metric
1000 (minimize delay) Use delay metric
0100 (maximize throughput) Use default metric
0010 (maximize reliability) Use reliability metric
0001 (minimize monetary cost) Use cost metric
other Use default metric
デフォルトメートル法の1000(遅れを最小にする)が使用する0000(すべての標準)使用は他の費用メートル法のUseデフォルトメートル法でデフォルトメートル法の0010(信頼性を最大にする)使用信頼性のメートル法の0001(貨幣原価を最小にします)が使用するメートル法の0100(スループットを最大にする)使用を遅らせます。
Bit 7 (MBZ): This bit is ignored by Integrated IS-IS.
ビット7(MBZ): このビットがIntegratedによって無視される、-
Almquist [Page 16]
Almquist[16ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
It is expected that the next revision of the Integrated IS-IS
specification will include this corrected table, at which time
this appendix can be considered obsolete.
それが予想される、それ、Integratedの次の改正、-、仕様はこの直っているテーブルを含むでしょう。その時に時代遅れであるとこの付録を考えることができます。
A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB)
A.5 RFC-1247(OSPF)とRFC-1248(OSPF MIB)
Although the specification in this memo is intended to be
substantially compatible with OSPF, the extension of the TOS field
to four bits requires minor modifications to the section that
describes the encoding of TOS values in Link State Advertisements,
described in section 12.3 of RFC-1247 [10]. The encoding is
summarized in Table 17 of that memo; what follows is an updated
version of table 17. The numbers in the first column are decimal
integers, and the numbers in the second column are binary TOS
values:
このメモによる仕様は実質的にOSPFと互換性があることを意図しますが、4ビットへのTOS分野の拡張子はRFC-1247[10]のセクション12.3で説明されたLink州AdvertisementsでのTOS値のコード化について説明するセクションへの小さい方の変更を必要とします。 コード化はそのメモのTable17にまとめられます。 続くことはテーブル17のアップデートされたバージョンです。 最初の桁の数は10進整数です、そして、第2桁の数は2進のTOS値です:
OSPF encoding TOS
_____________________________________________
TOSをコード化するOSPF_____________________________________________
0 0000 normal service
2 0001 minimize monetary cost
4 0010 maximize reliability
6 0011
8 0100 maximize throughput
10 0101
12 0110
14 0111
16 1000 minimize delay
18 1001
20 1010
22 1011
24 1100
26 1101
28 1110
30 1111
0000年の0の通常のサービス、2、0001、貨幣原価を最小にしてください、4、0010、信頼性6の0011を最大にしてください、0100が最大にする8、スループット10 0101 12 0110 14 0111 16 1000は遅れ18 1001 20 1010 22 1011 24 1100 26 1101 28 1110 30 1111を最小にします。
The OSPF MIB, described in RFC-1248 [5], is entirely consistent
with this memo except for the textual comment which describes the
mapping of the old TOS flag bits into TOSType values. TOSType
values use the same encoding of TOS values as OSPF's Link State
Advertisements do, so the above table also describes the mapping
between TOSType values (the first column) and TOS field values
(the second column).
RFC-1248[5]で説明されたOSPF MIBは古いTOSフラグビットのマッピングについてTOSType値に説明する原文のコメント以外のこのメモと完全に一致しています。 また、上のテーブルがTOSType値(最初のコラム)の間のマッピングについて説明して、Advertisementsがして、TOSがさばくOSPFのLink州が(第2コラム)を評価するとき、TOSType値はTOS値の同じコード化を使用します。
If RFC-1247 and RFC-1248 are revised in the future, it is expected
that this information will be incorporated into the revised
versions. At that time, this appendix may be considered obsolete.
RFC-1247とRFC-1248が将来改訂されるなら、この情報が改訂版に組み入れられると予想されます。 その時、この付録は時代遅れであると考えられるかもしれません。
Almquist [Page 17]
Almquist[17ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
APPENDIX B. Rationale
付録B.原理
The main body of this memo has described the details of how TOS facility works. This appendix is for those who wonder why it works that way.
このメモの本体はTOS施設がどう働くかに関する詳細について説明しました。 この付録はそれがなぜそのように働くかと思う人のためのものです。
Much of what is in this document can be explained by the simple fact that the goal of this document is to provide a clear and complete specification of the existing TOS facility rather than to design from scratch a new quality of service mechanism for IP. While this memo does amend the facility in some small and carefully considered ways discussed below, the desirability of compatibility with existing specifications and uses of the TOS facility [1,2,7,10,11] was never in doubt. This goal of backwards compatibility determined the broad outlines and many of the details of this specification.
このドキュメントの目標が最初からIPのために新しいサービスの質メカニズムを設計するというよりむしろ既存のTOS施設の明確で完全な仕様を提供することであるという簡単な事実でこのドキュメントにあるものの多くについて説明できます。 このメモは以下で議論したいくつかの小さくて慎重に考えられた方法で施設を修正しますが、TOS施設[1、2、7、10、11]の既存の仕様と用途との互換性の願わしさが決してどんな疑問でもありませんでした。 遅れている互換性のこの目標は広いアウトラインとこの仕様の細目の多くを決定しました。
Much of the rest of this specification was determined by two additional goals, which were described more fully in Section 2. The first was that hosts should never be penalized for using the TOS facility, since that would likely ensure that it would never be widely deployed. The second was that the specification should make it easy, or at least possible, to define and deploy new types of service in the future.
この仕様の残りの多くが2つの追加目標のそばで決定していました。(目標はセクション2で、より完全に説明されました)。 1番目はホストがTOS施設を使用するために決して罰せられるべきでないということでした、それが、それが広く決して配布されないのをおそらく確実にするでしょう、したがって。 2番目は仕様で将来新しいタイプのサービスを定義して、配布するために簡単であるか、または少なくとも可能になるべきであるということでした。
The three goals above did not eliminate all need for engineering choices, however, and in a few cases the goals proved to be in conflict with each other. The remainder of this appendix discusses the rationale behind some of these engineering choices.
しかしながら、上の3つの目標が工学選択のすべての必要性を排除したというわけではありません、そして、いくつかの場合では、目標は互いとの闘争にはあると判明しました。 この付録の残りはこれらの工学選択のいくつか後ろで原理について議論します。
B.1 The Minimize Monetary Cost TOS Value
B.1、貨幣原価TOS価値を最小にしてください。
Because the Internet is becoming increasingly commercialized, a
number of participants in the IETF's Router Requirements Working
Group felt it would be important to have a TOS value which would
allow a user to declare that monetary cost was more important than
other qualities of the service.
インターネットがますます商業化されるようになっているので、IETFのRouter Requirements作業部会の多くの関係者が、ユーザが貨幣原価が他のサービスの品質より重要であったと宣言できるTOS値を持っているのが重要であると感じました。
There was considerable debate over what exactly this value should
mean. Some felt, for example, that the TOS value should mean
"must not cost money". This was rejected for several reasons.
Because it would request a particular level of service (cost = 0)
rather than merely requesting that some service attribute be
minimized or maximized, it would not only philosophically at odds
with the other TOS values but would require special code in both
hosts and routers. Also, it would not be helpful to users who
want their packets to travel via the least-cost path but can
accept some level of cost when necessary. Finally, since whether
any particular routing domain considers the TOS field when routing
この値が意味するべきであるいったい何に関するかなりの討論があったか。 例えば、或るものは、値が意味するべきであるTOSが「金がかかってはいけない」と感じました。 これはいくつかの理由で拒絶されました。 何らかのサービス属性が最小にされるか、または最大にされるよう単に要求するよりむしろ特定のレベルのサービスを要求するでしょう(=0かかってください)、それは他のTOS値と不和で哲学的だけに必要でないでしょうが、したがって、ホストとルータの両方で特別なコードを必要とするでしょう。 また、それは、彼らのパケットが最小費用経路を通って移動して欲しいユーザにとって役立っていないでしょうが、必要であるときに、何らかのレベルの費用を受け入れることができます。 最終的に、ドメインを発送するどんな事項も考えるか否かに関係なく、TOSは、掘りながら、いつをさばくか。
Almquist [Page 18]
Almquist[18ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
is a choice made by the network manager, a user requiring a free
path might not get one if the packet has to pass through a routing
domain that does not consider TOS in its routing decisions.
ネットワークマネージャ(パケットがルーティング決定でTOSを考えない経路ドメインを通り抜けなければならないなら自由な経路を必要とするのが1つを届けないかもしれないユーザ)は選択をしますか?
Some proposed a slight variant: a TOS value which would mean "I am
willing to pay money to have this packet delivered". This
proposal suffers most of the same shortcomings as the previous one
and turns out to have an additional interesting quirk: because of
the algorithms specified in Section 7.2, any packet which used
this TOS value would prefer links that cost money over equally
good free links. Thus, such a TOS value would almost be
equivalent to a "maximize monetary cost" value!
或るものはわずかな異形を提案しました: 「私はこのパケットを届けさせるために金を出します」と意味するTOS値。 この提案は、前のものと同じ短所の大部分を我慢して、追加おもしろい気まぐれを持つために判明します: セクション7.2で指定されたアルゴリズムのために、このTOS値を使用したどんなパケットも等しく良い無料のリンクの上に金がかかるリンクを好むでしょう。 したがって、そのようなTOS値は「貨幣原価を最大にしてください」という値にほとんど同等です!
It seems likely that in the future users may need some mechanism
to express the maximum amount they are willing to pay to have a
packet delivered. However, an IP option would be a more
appropriate mechanism, since there are precedents for having IP
options that all routers are required to honor, and an IP option
could include parameters such as the maximum amount the user was
willing to pay. Thus, the TOS value defined in this memo merely
requests that the network "minimize monetary cost".
彼らが支払っても構わないとパケットを届けさせると思っている最大の額を表すのは将来のユーザのそれが何らかのメカニズムを必要とするかもしれないのがありそうに思えます。 しかしながら、IPオプションは、より適切なメカニズムでしょう、すべてのルータが光栄に思うのに必要であるIPオプションを持つための先例があって、IPオプションがユーザが支払っても構わないと思っていた最大の額などのパラメタを含むかもしれないので。 したがって、TOS値はこのメモでネットワークが「貨幣原価を最小にする」という単に要求を定義しました。
B.2 The Specification of the TOS Field
TOS分野のB.2仕様
There were four goals that guided the decision to have a four bit
TOS field and the specification of that field's values:
4ビットのTOS分野を持っているという決定とそのフィールドの値の仕様を誘導した4つの目標がありました:
(1) To define a new type of service requesting that the network
"minimize monetary cost"
(1) ネットワークが「貨幣原価を最小にする」よう要求する新しいタイプのサービスを定義するために
(2) To remain as compatible as possible with existing
specifications and uses of the TOS facility
(2) できるだけTOS施設の既存の仕様と用途と互換性があったままで残るために
(3) To allow for the definition and deployment of new types of
service in the future
(3) 将来新しいタイプのサービスの定義と展開を考慮するために
(4) To permanently fix the size of the TOS field
(4) 永久にTOS分野のサイズを固定するために
The last goal may seem surprising, but turns out to be necessary
for routing to work correctly when new types of service are
deployed. If routers have different ideas about the size of the
TOS field they make inconsistent decisions that may lead to
routing loops.
最後の目標は、新しいサービスのタイプが配備されるとき、ルーティングが正しく利くように驚くべきものに見えるかもしれませんが、必要であると判明します。 ルータにTOS分野のサイズに関する異なった考えがあるなら、彼らは輪を発送するのに通じるかもしれない無節操な決定をします。
At first glance goals (3) and (4) seem to be pretty much mutually
exclusive. The IP header currently has only three unused bits, so
at most three new type of service bits could be defined without
resorting to the impractical step of changing the IP header
一見したところでは目標(3)と(4)はほとんど互いに排他的であるように思えます。 現在、IPヘッダーには未使用の3ビットしかないので、IPヘッダーを変える非実用的なステップに頼らないで、高々3の新しいタイプのサービス・ビットを定義できました。
Almquist [Page 19]
Almquist[19ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
format. Since one of them would need to be allocated to meet goal
(1), at most two bits could be reserved for new or experimental
types of service. Not only is it questionable whether two would
be enough, but it is improbable that the IETF and IAB would allow
all of the currently unused bits to be permanently reserved for
types of service which might or might or might not ever be
defined.
形式。 彼らのひとりは、目標(1)を達成するために割り当てられる必要があるでしょう、したがって、新しいか実験しているタイプのサービスのために高々2ビットしか予約できませんでした。 それが2が十分であるかどうか疑わしいだけではなく、IETFとIABが定義されるかもしれないか、優に現在未使用のビットが永久にサービスのそうするかもしれないタイプのために予約されるのを許容するだろうか、またはかつて定義されないのが、ありそうもないです。
However, some (if not most of) the possible combinations of the
individual bits would not be useful. Clearly, setting all of the
bits would be equivalent to setting none of the bits, since
setting all of the bits would indicate that none of the types of
optimization was any more important than any of the others.
Although one could perhaps assign reasonable semantics to most
pairs of bits, it is unclear that the range of network service
provided by various paths could usefully be subdivided in so fine
a manner. If some of these non-useful combinations of bits could
be assigned to new types of service then it would be possible to
meet goal (3) and goal (4) without having to use up all of the
remaining reserved bits in the IP header. The obvious way to do
that was to change the interpretation of TOS values so that they
were integers rather than independently settable bits.
しかしながらと、いくつか、(だいたいならでない) 個々のビットの可能な組み合わせは役に立たないでしょう。 明確に、優にビットを設定するのはビットのいずれも設定しないのに同等でしょう、優にビットを設定するのは、最適化のタイプのだれ一人もう他のもののだれよりも重要でなかったのを示すでしょう、したがって。 1つは恐らくほとんどの組のビットに妥当な意味論を割り当てるかもしれませんが、とてもよい方法で有効に様々な経路によって提供されたネットワーク・サービスの範囲を分筆できるだろうというのは不明瞭です。 ビットのこれらの非役に立つ組み合わせのいくつかを新しいタイプのサービスに割り当てることができるなら目標(3)を達成するのが可能であり、目標(4)は残りのすべてを使いきる必要はなくてIPヘッダーでビットを予約しました。 それをする当たり前の方法がTOS値の解釈を変えることであったので、それらは独自に「舗装用敷石-可能」なビットよりむしろ整数でした。
The integers were chosen to be compatible with the bit definitions
found in RFC-791. Thus, for example, setting the TOS field to
1000 (minimize delay) sets bit 3 of the Type of Service octet; bit
3 is defined as the Low Delay bit in RFC-791. This memo only
defines values which correspond to setting a single one of the
RFC-791 bits, since setting multiple TOS bits does not seem to be
a common practice. According to [15], none of the common TCP/IP
applications currently set multiple TOS bits. However, TOS values
corresponding to particular combinations of the RFC-791 bits could
be defined if and when they are determined to be useful.
整数は、定義がRFC-791で当たったビットと互換性があるように選ばれました。 このようにして、例えば、1000(遅れを最小にする)にTOS分野を設定すると、Service八重奏のTypeのビット3は設定されます。 ビット3はRFC-791でLow Delayビットと定義されます。 このメモはRFC-791ビットの単一の1つを設定すると対応する値を定義するだけです、複数のTOSビットを設定するのが一般的な習慣であるように思えないので。 [15]によると、一般的なTCP/IPアプリケーションのいずれも現在、複数のTOSビットを設定しません。 しかしながら、彼らが役に立つと決心しているなら、RFC-791ビットの特定の組み合わせに対応するTOS値は定義されるかもしれません。
The new TOS value for "minimize monetary cost" needed to be one
which would not be too terribly misconstrued by preexisting
implementations. This seemed to imply that the value should be
one which left all of the RFC-791 bits clear. That would require
expanding the TOS field, but would allow old implementations to
treat packets which request minimization of monetary cost (TOS
0001) as if they had requested the default TOS. This is not a
perfect solution since (as described above) changing the size of
the TOS field could cause routing loops if some routers were to
route based on a three bit TOS field and others were to route
based on a four bit TOS field. Fortunately, this should not be
much of a problem in practice because routers which route based on
a three bit TOS field are very rare as this is being written and
will only become more so once this specification is published.
「貨幣原価を最小にしてください」のための新しいTOS値は、実現を先在させることによってあまりものすごく誤解されないものである必要がありました。 これは値が優にRFC-791ビットを明確なままにしたものであるべきであることを含意するように思えました。 それで、TOS分野を広げるのが必要でしょうが、古い実現はまるで彼らがデフォルトTOSを要求したかのように貨幣原価(TOS0001)の最小化を要求するパケットを扱うでしょう。 TOSがさばいて、他のものが発送することになっていた4ビットのTOS分野に基づく3ビットに基づくルートにいくつかのルータがあったなら輪を発送するTOS分野のサイズが引き起こす場合があった(上で説明されるように)変化以来これは完全な解決ではありません。 幸い、ルートが3ビットのTOSフィールドに基礎づけたルータがこれが書かれているとき非常にまれであり、この仕様がいったん発表されると、よりそうになるだけであるので、これは実際には大した問題であるべきではありません。
Almquist [Page 20]
Almquist[20ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
Because of those considerations, and also in order to allow a
reasonable number of TOS values for future definition, it seemed
desirable to expand the TOS field. That left the question of how
much to expand it. Expanding it to five bits would allow
considerable future expansion (27 new TOS values) and would be
consistent with Host Requirements, but would reduce to one the
number of reserved bits in the IP header. Expanding the TOS field
to four bits would restrict future expansion to more modest levels
(11 new TOS values), but would leave an additional IP header bit
free. The IETF's Router Requirements Working Group concluded that
a four bits wide TOS field allow enough values for future use and
that consistency with Host Requirements was inadequate
justification for unnecessarily increasing the size of the TOS
field.
それらの問題であり、また、TOS分野を広げるのは、今後の定義のための相当な数のTOS値を許容するために望ましく思えました。 それはどのようにたくさんそれを広げるかに関する質問を残しました。 5ビットにそれを広げるのは、かなりの今後の拡大(27の新しいTOS値)を許容して、Host Requirementsと一致しているでしょうが、IPヘッダーの予約されたビットの数を1まで減少させるでしょう。 TOS分野を4ビットに広げると、今後の拡大が、より穏やかなレベル(11の新しいTOS値)に制限されるでしょうが、追加IPヘッダーはビットから無料でままにされるでしょう。 IETFのRouter Requirements作業部会は幅4ビットのTOS分野が今後の使用のための十分な値を許容して、Host Requirementsがある一貫性がTOS分野のサイズを不必要に増加させるための不十分な正当化であると結論を下しました。
B.3 The Choice of Weak TOS Routing
弱いTOSルート設定のB.3選択
"Ruminations on the Next Hop" [4] describes three alternative ways
of routing based on the TOS field. Briefly, they are:
「Next Hopにおける反芻」[4]はTOS分野に基づくルーティングの3つの代替の方法を述べます。 簡潔に、それらは以下の通りです。
(1) Strong TOS --
a route may be used only if its TOS exactly matches the TOS
in the datagram being routed. If there is no route with the
requested TOS, the packet is discarded.
(1)の強いTOS--TOSがまさに発送されるデータグラムでTOSに合っている場合にだけ、ルートは使用されるかもしれません。 要求されたTOSがあるルートが全くなければ、パケットは捨てられます。
(2) Weak TOS --
like Strong TOS, except that a route with the default TOS
(0000) is used if there is no route that has the requested
TOS. If there is no route with either the requested TOS or
the default TOS, the packet is discarded.
(2)の弱いTOS--Strong TOSのように、ルートが全くなければデフォルトTOS(0000)があるルートが使用されているのを除いて、それには要求されたTOSがあります。 要求されたTOSかデフォルトTOSのどちらかがあるルートが全くなければ、パケットは捨てられます。
(3) Very Weak TOS --
like Weak TOS, except that a route with the numerically
smallest TOS is used if there is no route that has either the
requested TOS or the default TOS.
(3)のまさしくそのWeak TOS--Weak TOSのように、ルートが全くなければ数の上で最も小さいTOSがあるルートが使用されているのを除いて、それには要求されたTOSかデフォルトTOSのどちらかがあります。
This specification has adopted Weak TOS.
この仕様はWeak TOSを採用しました。
Strong TOS was quickly rejected. Because it requires that each
router a packet traverses have a route with the requested TOS,
packets which requested non-zero TOS values would have (at least
until the TOS facility becomes widely used) a high probability of
being discarded as undeliverable. This violates the principle
(described in Section 2) that hosts should not be penalized for
choosing non-zero TOS values.
強いTOSはすぐに拒絶されました。 それが、パケットが横断する各ルータが要求されたTOSがあるルートを持っているのを必要とするので、非ゼロTOS値を要求したパケットが「非-提出物」として捨てられるという高い確率を持っているでしょう(TOS施設が少なくとも広く使用されるようになるまで)。 これは非ゼロTOS値を選ぶためにホストを罰するべきでないという原則(セクション2では、説明される)に違反します。
The choice between Weak TOS and Very Weak TOS was not as
straightforward. Weak TOS was chosen because it is slightly
Weak TOSとVery Weak TOSの選択は簡単ではありませんでした。 それがわずかに選ばれたので、弱いTOSは選ばれました。
Almquist [Page 21]
Almquist[21ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
simpler to implement and because it is consistent with the OSPF
and Integrated IS-IS specifications. In addition, many dislike
Very Weak TOS because its algorithm for choosing a route when none
of the available routes have either the requested or the default
TOS cannot be justified by intuition (there is no reason to
believe that having a numerically smaller TOS makes a route
better). Since a router would need to understand the semantics of
all of the TOS values to make a more intelligent choice, there
seems to be no reasonable way to fix this particular deficiency of
Very Weak TOS.
道具、それがOSPFとIntegratedと一致しているのでより簡単である、-、仕様。 さらに、多くが、直観で利用可能なルートのいずれにも要求かデフォルトのどちらかTOSがないときルートを選ぶためのアルゴリズムを正当化できないので(数の上でより小さいTOSを持っているのにルートが、より良くなると信じる理由が全くありません)、Very Weak TOSが嫌です。 ルータは、TOS値のすべての意味論が、より知的な選択をするのを理解する必要があるでしょう、したがって、Very Weak TOSのこの特定の欠乏を修正するどんな合理的な方法もあるように思えません。
In practice it is expected that the choice between Weak TOS and
Very Weak TOS will make little practical difference, since (except
where the network manager has intentionally set things up
otherwise) there will be a route with the default TOS to any
destination for which there is a route with any other TOS.
実際には、Weak TOSとVery Weak TOSの選択がほとんど実用的な違いを作らないと予想されます、いかなる他のTOSがあるルートもあるどんな目的地へのデフォルトTOSがあるルートもあるので(そうでなければネットワークマネージャが故意に事態をセットアップしたところを除いて)。
B.4 The Retention of Longest Match Routing
最も長いマッチルート設定のB.4保有
An interesting issue is how early in the route choice process TOS
should be considered. There seem to be two obvious possibilities:
おもしろい問題はルート選択過程TOSがどれくらい中で早く考えられるべきであるかということです。 2つの明白な可能性があるように思えます:
(1) Find the set of routes that best match the destination
address of the packet. From among those, choose the route
which best matches the requested TOS.
(1) パケットの送付先アドレスに最もよく合っているルートのセットを見つけてください。 それらから、要求されたTOSに最もよく合っているルートを選んでください。
(2) Find the set of routes that best match the requested TOS.
From among those, choose the route which best matches the
destination address of the packet.
(2) 要求されたTOSに最もよく合っているルートのセットを見つけてください。 それらから、パケットの送付先アドレスに最もよく合っているルートを選んでください。
The two approaches are believed to support an identical set of
routing policies. Which of the two allows the simpler
configuration and minimizes the amount of routing information that
needs to be passed around seems to depend on the topology, though
some believe that the second option has a slight edge in this
regard.
2つのアプローチが同じセットのルーティング方針を支持すると信じられています。 或るものは、2番目のオプションにはわずかな強味がこの点であると信じていますが、2つのもののどれが、より簡単な構成を許して、回される必要があるルーティング情報の量を最小にするかはトポロジーによるように思えます。
Under the first option, if the network manager neglects some
pieces of the configuration the likely consequence is that some
packets which would benefit from TOS-specific routes will be
routed as if they had requested the default TOS. Under the second
option, however, a network manager can easily (accidently)
configure things in such a way that packets which request a
certain TOS and should be delivered locally will instead follow a
default route for that TOS and be dumped into the Internet. Thus,
the first option would seem to have a slight edge with regard to
robustness in the face of errors by the network manager.
第1の選択で、ネットワークマネージャが構成のいくつかの断片を無視するなら、起こりそうな結果はまるでデフォルトTOSを要求したかのようにTOS特有のルートの利益を得るいくつかのパケットが発送されるということです。 2番目のオプションで、しかしながら、ネットワークマネージャは、そのTOSのために容易に(事故に)あるTOSを要求して、局所的に届けられるべきであるパケットが代わりにデフォルトルートに従うような方法でものを構成して、インターネットにどさっと落とすことができます。 したがって、第1の選択はネットワークマネージャによる誤りに直面して丈夫さに関してわずかな強味を持っているように思えるでしょう。
Almquist [Page 22]
Almquist[22ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
It has been also been suggested that the first option provides the
additional benefit of allowing loop-free routing in routing
domains which contain both routers that consider TOS in their
routing decisions and routers that do not. Whether that is true
in all cases is unknown. It is certainly the case, however, that
under the second option it would not work to mix routers that
consider TOS and routers which do not in the same routing domain.
また、それがそう、示されて、第1の選択が両方のルータを含む中に掘っている無輪の掘っているドメインにそれを許容する追加利益を提供するのが彼らのルーティング決定とそうしないルータでTOSを考えます。 それがすべての場合に当てはまるかどうかが、未知です。 しかしながら、確かに、2番目のオプションで、TOSを考えるルータと同じ経路ドメインでそうしないルータを混ぜるために働いていないのは、事実です。
All in all, there were no truly compelling arguments for choosing
one way or the other, but it was nontheless necessary to make a
choice: if different routers were to make the choice differently,
chaos (in the form of routing loops) would result. The mechanisms
specified in this memo reflect the first option because that will
probably be more intuitive to most network managers. Internet
routing has traditionally chosen the route which best matches the
destination address, with other mechanisms serving merely as tie-
breakers. The first option is consistent with that tradition.
結局、どちらかの方向に選ぶためのどんな本当に無視できない議論もありませんでしたが、それは選択をするのに必要なnonthelessでした: 異なったルータが異なって選択をすることであるなら、カオス(ルーティング輪の形の)は結果として生じます。 それがたぶんほとんどのネットワークマネージャにより直感的になるので、このメモで指定されたメカニズムは第1の選択を反映します。 インターネット・ルーティングは送付先アドレスに最もよく合っているルートを伝統的に選びました、他のメカニズムが単に繋がりのブレーカーとして機能して。 第1の選択はその伝統と一致しています。
B.5 The Use of Destination Unreachable
目的地手の届かないことのB.5使用
Perhaps the most contentious and least defensible part of this
specification is that a packet can be discarded because the
destination is considered to be unreachable even though a packet
to the same destination but requesting a different TOS would have
been deliverable. This would seem to fall perilously close to
violating the principle that hosts should never be penalized for
requesting non-default TOS values in packets they originate.
この仕様の最も議論好きで最も防御可能でない部分は同じ目的地にもかかわらず、異なったTOSを要求することへのパケットが提出物だったでしょうが、目的地が手が届かないと考えられるのでパケットを捨てることができるということです。 これはホストがそれらが溯源するパケットで非デフォルトTOS値を要求するために決して罰せられるべきでないという原則に違反する近くで冒険的に低下するように思えるでしょう。
This can happen in only three, somewhat unusual, cases:
これは、3だけでいくらか珍しい状態で起こることができて、以下をケースに入れます。
(1) There is a route to the packet's destination which has the
TOS value requested in the packet, but the route has an
infinite metric.
(1) パケットでTOS値を要求するパケットの目的地へのルートがありますが、ルートで、無限はメートル法になります。
(2) The only routes to the packet's destination have TOS values
other than the one requested in the packet. One of them has
the default TOS, but it has an infinite metric.
(2) パケットの目的地への唯一のルートには、パケットで要求されたもの以外のTOS値があります。 彼らのひとりに、デフォルトTOSがありますが、それで、無限はメートル法になります。
(3) The only routes to the packet's destination have TOS values
other than the one requested in the packet. None of them
have the default TOS.
(3) パケットの目的地への唯一のルートには、パケットで要求されたもの以外のTOS値があります。 それらのいずれにはも、デフォルトTOSがありません。
It is commonly accepted that a router which has a default route
should nonetheless discard a packet if the router has a more
specific route to the destination in its forwarding table but that
route has an infinite metric. The first two cases seem to be
analogous to that rule.
一般的に、ルータが推進テーブルにより特定のルートを目的地に持っていますが、無限がそのルートでメートル法になるならデフォルトルートを持っているルータがそれにもかかわらず、パケットを捨てるべきであると受け入れます。 最初の2つのケースがその規則に類似しているように思えます。
Almquist [Page 23]
Almquist[23ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
In addition, it is worth noting that, except perhaps during brief
transients resulting from topology changes, routes with infinite
metrics occur only as the result of deliberate action (or serious
error) on the part of the network manager. Thus, packets are
unlikely to be discarded unless the network manager has taken
deliberate action to cause them to be. Some people believe that
this is an important feature of the specification, allowing the
network to (for example) keep packets which have requested that
cost be minimized off of a link that is so expensive that the
network manager feels confident that the users would want their
packets to be dropped. Others (including the author of this memo)
believe that this "feature" will prove not to be useful, and that
other mechanisms may be required for access controls on links, but
couldn't justify changing this specification in the ways necessary
to eliminate the "feature".
さらに、恐らくトポロジー変化から生じる簡潔な過渡現象を除いて、無限の測定基準があるルートがネットワークマネージャ側の単に慎重な行為(または、重大な誤り)の結果として現れることに注意する価値があります。 したがって、ネットワークマネージャがそれらは引き起こす慎重な行動を取っていない場合、パケットは捨てられそうにはありません。 何人かの人々が、これが仕様の重要な特徴であると信じています、(例えば) ネットワークが費用がユーザが彼らのパケットを下げて欲しいと確信しているとネットワークマネージャが感じられるほど高価なリンクから最小にされるよう要求したパケットを保つのを許容して。 他のもの(このメモの作者を含んでいます)は、他のメカニズムが、この「特徴」が役に立たないと判明して、アクセス制御にリンクの上に必要であったかもしれませんが、この仕様を変えるのを「特徴」を排除するのに必要な方法で正当化できなかったと信じています。
Case (3) above is more problematic. It could have been avoided by
using Very Weak TOS, but that idea was rejected for the reasons
discussed in Appendix B.3. Some suggested that case (3) could be
fixed by relaxing longest match routing (described in Appendix
B.4), but that idea was rejected because it would add complexity
to routers without necessarily making their routing choices
particularly more intuitive. It is also worth noting that this is
another case that a network manager has to try rather hard to
create: since OSPF and Integrated IS-IS both enforce the
constraint that there must be a route with the default TOS to any
destination for which there is a route with a non-zero TOS, a
network manager would have to await the development of a new
routing protocol or create the problem with static routes. The
eventual conclusion was that any fix to case (3) was worse than
the problem.
上のケース(3)は、より問題が多いです。 それはVery Weak TOSを使用することによって、避けられたかもしれませんでしたが、その考えはAppendix B.3で議論した理由で拒絶されました。 必ず彼らのルーティング選択を特により直感的にするというわけではなくて、ルータに複雑さを加えるでしょう、或るものは、最も長いマッチルーティング(Appendix B.4では、説明される)を弛緩することによってケース(3)を修理できるだろうというのを示しましたが、したがって、その考えは拒絶されました。 また、これがネットワークマネージャがかなり一生懸命引き起こそうとしなければならない別のそうであることに注意する価値があります: OSPFとIntegrated、-、両方が非ゼロTOSがあるルートがあるどんな目的地にもデフォルトTOSがあるルートがあるに違いないという規制を実施して、ネットワークマネージャは、新しいルーティング・プロトコルの開発を待たなければならないか、またはスタティックルートに関する問題を生じさせなければならないでしょう。 最後の結論は(3)をケースに入れるどんなフィックスも問題より悪かったということでした。
APPENDIX C. Limitations of the TOS Mechanism
TOSメカニズムの付録C.限界
It is important to note that the TOS facility has some limitations. Some are consequences of engineering choices made in this specification. Others, referred to as "inherent limitations" below, could probably not have been avoided without either replacing the TOS facility defined in RFC-791 or accepting that things wouldn't work right until all routers in the Internet supported the TOS facility.
TOS施設にはいくつかの制限があることに注意するのが重要です。 何かがこの仕様でされた工学選択の結果です。 まさしくインターネットのすべてのルータがTOS施設をサポートするまで、RFC-791で定義されたTOS施設を取り替えるか、またはいろいろなことが働かないと受け入れない、たぶん以下に「固有の制限」と呼ばれた他のものは避けることができませんでした。
C.1 Inherent Limitations
C.1の固有の制限
The most important of the inherent limitations is that the TOS
facility is strictly an advisory mechanism. It is not an
appropriate mechanism for requesting service guarantees. There
are two reasons why this is so:
固有の制限で最も重要であるのは、TOS施設が厳密にそうであるということです。顧問メカニズム。 それは、サービス保証を要求するための適切な手段ではありません。 したがって、2つの理由があります:
Almquist [Page 24]
Almquist[24ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
(1) Not all networks will consider the value of the TOS field
when deciding how to handle and route packets. Partly this
is a transition issue: there will be a (probably lengthy)
period when some networks will use equipment that predates
this specification. Even long term, however, many networks
will not be able to provide better service by considering the
value of the TOS field. For example, the best path through a
network composed of a homogeneous collection of
interconnected LANs is probably the same for any possible TOS
value. Inside such a network, it would make little sense to
require routers and routing protocols to do the extra work
needed to consider the value of the TOS field when forwarding
packets.
(1) どのようにパケットを扱って、発送するかを決めるとき、すべてのネットワークがTOS分野の値を考えるというわけではないでしょう。 これは一部、変遷問題です: いくつかのネットワークがこの仕様より前に起こる設備を使用する(たぶん長い)の期間があるでしょう。 しかしながら、長い期間さえ、多くのネットワークは、TOS分野の値を考えることによって、より良いサービスを提供できないでしょう。 例えば、どんな可能なTOS値にも、インタコネクトされたLANの均質の収集で構成されたネットワークを通した最も良い経路はたぶん同じです。 そのようなネットワークの中では、それは、パケットを進めるとき、TOS分野の値を考えるのに必要である時間外労働をするためにほとんどルータとルーティングを必要とする意味をプロトコルにしないでしょう。
(2) The TOS mechanism is not powerful enough to allow an
application to quantify the level of service it desires. For
example, an application may use the TOS field to request that
the network choose a path which maximizes throughput, but
cannot use that mechanism to say that it needs or wants a
particular number of kilobytes or megabytes per second.
Because the network cannot know what the application
requires, it would be inappropriate for the network to decide
to discard a packet which requested maximal throughput
because no "high throughput" path was available.
(2) TOSメカニズムはアプリケーションがそれが望んでいるサービスのレベルを定量化するのを許容するくらいには強力ではありません。 例えば、アプリケーションは、ネットワークがスループットを最大にする経路を選ぶよう要求するのにTOS分野を使用するかもしれませんが、特定の数の1秒あたりのキロバイトかメガバイトが必要である、または欲しいと言うのにそのメカニズムは使用できません。 ネットワークが、アプリケーションが何を必要とするかを知ることができないので、ネットワークが、どんな「高生産性」経路も利用可能でなかったので最大限度のスループットを要求したパケットを捨てると決めるのは、不適当でしょう。
The inability to provide resource guarantees is a serious drawback
for certain kinds of network applications. For example, a system
using packetized voice simply creates network congestion when the
available bandwidth is inadequate to deliver intelligible speech.
Likewise, the network oughtn't even bother to deliver a voice
packet that has suffered more delay in the network than the
application can tolerate. Unfortunately, resource guarantees are
problematic in connectionless networks. Internet researchers are
actively studying this problem, and are optimistic that they will
be able to invent ways in which the Internet Architecture can
evolve to support resource guarantees while preserving the
advantages of connectionless networking.
リソース保証を提供できないことはある種類のネットワーク応用のための重大な欠点です。 利用可能な帯域幅が明瞭なスピーチを提供するために不十分であるときに、例えば、単にpacketized声を使用するシステムはネットワークの混雑を作成します。 同様に、それを音声パケットに提供する面倒ではなくさえ、ネットワークoughtnがネットワークのアプリケーションが許容できるより多くの遅れを受けました。 残念ながら、リソース保証はコネクションレスなネットワークで問題が多いです。 インターネット情報検索専門家は、積極的にこの問題を研究していて、彼らがインターネットArchitectureがコネクションレスなネットワークの利点を保存している間、リソース保証をサポートするために発展できる方法を発明できると楽観的です。
C.2 Limitations of this Specification
このSpecificationのC.2限界
There are a couple of additional limitations of the TOS facility
which are not inherent limitations but instead are consequences of
engineering choices made in this specification:
固有の制限ではありませんが、代わりにこの仕様でされた工学選択の結果であるTOS施設の2、3の追加制限があります:
(1) Routing is not really optimal for some TOS values. This is
because optimal routing for those TOS values would require
that routing protocols be cognizant of the semantics of the
TOS values and use special algorithms to compute routes for
(1) いくつかのTOS値には、ルート設定は本当に最適ではありません。 それらのTOS値のための最適ルーティングは、ルーティング・プロトコルがTOS値の意味論を認識しているのが必要であり、ルートを計算する特別なアルゴリズムを使用するでしょう、したがって、これはそうです。
Almquist [Page 25]
Almquist[25ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
them. For example, routing protocols traditionally compute
the metric for a path by summing the costs of the individual
links that make up the path. However, to maximize
reliability, a routing protocol would instead have to compute
a metric which was the product of the probabilities of
successful delivery over each of the individual links in the
path. While this limitation is in some sense a limitation of
current routing protocols rather than of this specification,
this specification contributes to the problem by specifying
that there are a number of legal TOS values that have no
currently defined semantics.
それら。 例えば、ルーティング・プロトコルは、経路を作る個々のリンクのコストをまとめることによって、経路へのメートル法を伝統的に計算します。 しかしながら、信頼性を最大にするために、ルーティング・プロトコルは代わりにメートル法でaを計算しなければならないでしょう(経路のそれぞれの個々のリンクの上のうまくいっている配送の確率の製品でした)。 何らかの意味で、この制限はこの仕様についてというよりむしろ現在のルーティング・プロトコルの制限ですが、多くの現在定義された意味論を全く持っていない法的なTOS値があると指定することによって、この仕様は問題に貢献します。
(2) This specification assumes that network managers will do "the
right thing". If a routing domain uses TOS, the network
manager must configure the routers in such a way that a
reasonable path is chosen for each TOS. While this ought not
to be terribly difficult, a network manager could accidently
or intentionally violate our rule that using the TOS facility
should provide service at least as good as not using it.
(2) この仕様は、ネットワークマネージャが「正しいもの」をすると仮定します。 経路ドメインがTOSを使用するなら、ネットワークマネージャは妥当な経路が各TOSに選ばれているような方法でルータを構成しなければなりません。 これがものすごく難しいべきでない間、ネットワークマネージャは、事故である、または故意に、TOS施設を使用するとサービスがそれを使用しないのと少なくとも同じくらい良い状態で提供されるべきであるという私たちのやり方に違反するかもしれません。
Almquist [Page 26]
Almquist[26ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
References
参照
[1] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Communication Layers", RFC
1122, USC/Information Sciences Institute, October 1989.
[1] インターネット・エンジニアリング・タスク・フォース(R.ブレーデン、エディタ)、「インターネットホストのための要件--コミュニケーションは層にします」、RFC1122、科学が設けるUSC/情報、1989年10月。
[2] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Application and Support",
RFC 1123, USC/Information Sciences Institute, October 1989.
[2] インターネット・エンジニアリング・タスク・フォース(R.ブレーデン、エディタ)、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123(科学が1989年10月に設けるUSC/情報)
[3] Almquist, P., "Requirements for IP Routers", Work in progress.
[3]Almquist、P.、「IPルータのための要件」、進行中のWork。
[4] Almquist, P., "Ruminations on the Next Hop", Work in progress.
[4]Almquist、P.、「次のホップにおける反芻」、進行中のWork。
[5] Baker, F. and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1248, ACC, Computer Science Center, August 1991.
[5] ベイカーとF.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1248、ACC、Computerサイエンス・センター1991年8月。
[6] Braden, R. and J. Postel, "Requirements for Internet Gateways",
RFC 1009, USC/Information Sciences Institute, June 1987.
ブレーデンとR.とJ.ポステル、「インターネットゲートウェイのための要件」、RFC1009、USC/情報科学が1987年6月に設ける[6]。
[7] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC 1195, Digital Equipment Corporation, December
1990.
[7]Callon、R.、「OSIの使用、-、TCP/IPにおけるルート設定と二元的な環境、」、RFC1195、ディジタルイクイップメント社(1990年12月)
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[8] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、ゼロックスPARC、1991年9月。
[9] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", RFC 950, USC/Information Sciences Institute, August
1985.
ムガール人とJ.とJ.ポステル、「インターネットの標準のサブネッティング手順」、RFC950、USC/情報科学が1985年8月に設ける[9]。
[10] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
[10]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon Inc.、1991インチ年7月。
[11] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[11] ポステル、J.、「インターネットプロトコル」、RFC791、DARPA、1981年9月。
[12] Postel, J., "Internet Control Message Protocol", RFC 792, DARPA,
September 1981.
[12] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、RFC792、DARPA、1981年9月。
[13] Postel, J., "Transmission Control Protocol", RFC 793, DARPA,
September 1981.
[13] ポステル、J.、「通信制御プロトコル」、RFC793、DARPA、1981年9月。
[14] Prue, W. and J. Postel, "A Queuing Algorithm to Provide Type-
of-Service for IP Links", RFC 1046, USC/Information Sciences
Institute, February 1988.
[14] Prue、W.、およびJ.ポステル、「サービスのタイプをIPに提供する待ち行列アルゴリズムはリンクします」、RFC1046、科学が設けるUSC/情報、1988年2月。
[15] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
レイノルズとJ.とJ.ポステル、「規定番号」、RFC1060、USC/情報科学が1990年3月に設ける[15]。
Almquist [Page 27]
Almquist[27ページ]
RFC 1349 Type of Service July 1992
サービス1992年7月のRFC1349タイプ
Acknowledgements
承認
Some of the ideas presented in this memo are based on discussions held by the IETF's Router Requirements Working Group. Much of the specification of the treatment of Type of Service by hosts is merely a restatement of the ideas of the IETF's former Host Requirements Working Group, as captured in RFC-1122 and RFC-1123. The author is indebted to John Moy and Ross Callon for their assistance and cooperation in achieving consistency among the OSPF specification, the Integrated IS-IS specification, and this memo.
このメモに提示された考えのいくつかがIETFのRouter Requirements作業部会によって行われた議論に基づいています。 ホストによるServiceのTypeの処理の仕様の多くが単にIETFの前のHost Requirements作業部会の考えの再声明です、RFC-1122とRFC-1123でキャプチャされるように。 作者がOSPF仕様の中で一貫性を獲得することへの彼らの支援と協力にジョンMoyとロスCallonの世話になっている、Integrated、-、仕様、そして、このメモ。
This memo has been substantially improved as the result of thoughtful comments from a number of reviewers, including Dave Borman, Bob Braden, Ross Callon, Vint Cerf, Noel Chiappa, Deborah Estrin, Phill Gross, Bob Hinden, Steve Huston, Jon Postel, Greg Vaudreuil, John Wobus, and the Router Requirements Working Group.
このメモは考え深いコメントの結果として多くの評論家から実質的に改良されました、デーヴ・ボーマン、ボブ・ブレーデン、ロスCallon、Vintサーフ、クリスマスChiappa、デボラEstrin、フィルGross、ボブHinden、スティーブ・ヒューストン、ジョン・ポステル、グレッグ・ボードルイ、ジョンWobus、およびRouter Requirements作業部会を含んでいて。
The initial work on this memo was done while its author was an employee of BARRNet. Their support is gratefully acknowledged.
作者がBARRNetの従業員であった間、このメモへの初期の作業をしました。 彼らのサポートは感謝して承諾されます。
Security Considerations
セキュリティ問題
This memo does not explicitly discuss security issues. The author does not believe that the specifications in this memo either weaken or enhance the security of the IP Protocol or of the other protocols mentioned herein.
このメモは明らかに安全保障問題について議論しません。 作者は、このメモによる仕様がIPプロトコルかここに言及された他のプロトコルのセキュリティを弱めるか、または高めると信じていません。
Author's Address
作者のアドレス
Philip Almquist 214 Cole Street, Suite 2 San Francisco, CA 94117-1916
フィリップAlmquist214コール通り、Suite2サンフランシスコ、カリフォルニア94117-1916
Phone: 415-752-2427
以下に電話をしてください。 415-752-2427
Email: almquist@Jessica.Stanford.EDU
メール: almquist@Jessica.Stanford.EDU
Almquist [Page 28]
Almquist[28ページ]
一覧
スポンサーリンク
