[要約] RFC 3662は、異なるサービスに対するドメインごとの低い努力の振る舞い（PDB）に関するものであり、異なるドメイン間でのトラフィックの優先度を制御するためのガイドラインを提供しています。目的は、ネットワークのリソースを効果的に管理し、異なるサービスの要件に応じたトラフィックの品質を確保することです。
Network Working Group R. Bless
Request for Comments: 3662 Univ. of Karlsruhe
Category: Informational K. Nichols
Consultant
K. Wehrle
Univ. of Tuebingen/ICSI
December 2003
A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
差別化されたサービスのドメインごとの行動（PDB）の低い
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.
このドキュメントでは、適切に機能するネットワークでトラフィックが「飢え」（厳密には必要ありませんが）（ただし飢starが飢えている」可能性がある、ドメインごとの差別化されたサービス（PDB）を提案しています。これは、インターネットの「ベストエフォート」または「通常のインターネットトラフィック」モデルとは対照的であり、長期にわたる飢vがネットワークの問題を示しています。この意味で、提案されているPDBのトラフィックは、通常の「ベストエフォート」インターネットトラフィックよりも「低い」優先度で転送されます。したがって、PDBは「低い努力」（LE）と呼ばれます。このPDBの使用により、ネットワークオペレーターは、「Best-Effort」/「通常」または他のすべてのインターネットトラフィックに対するトラフィックの影響を厳密に制限できます。このドキュメントは、いくつかの例を使用していますが、PDBの使用を特定のタイプのトラフィックに制約することを提案していません。
This document proposes a differentiated services per-domain behavior [RFC3086] called "Lower Effort" (LE) which is intended for traffic of sufficiently low value (where "value" may be interpreted in any useful way by the network operator), in which all other traffic takes precedence over LE traffic in consumption of network link bandwidth. One possible interpretation of "low value" traffic is its low priority in time, which does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be considered as a network equivalent to a background priority for processes in an operating system. There may or may not be memory (buffer) resources allocated for this type of traffic.
このドキュメントは、ドメインごとの差別化されたサービス[RFC3086]を提案します[低努力]（LE）は、十分に低い値のトラフィックを目的としています（ネットワークオペレーターによって「値」が有用な方法で解釈される場合があります）。他のすべてのトラフィックは、ネットワークリンク帯域幅の消費におけるLEトラフィックよりも優先されます。「価値の低い」トラフィックの1つの可能な解釈は、時間の優先度が低いことです。これは、それが一般的に重要であることを必ずしも意味するものではありません。この観点からは、オペレーティングシステムのプロセスのバックグラウンドの優先度に相当するネットワークと見なすことができます。このタイプのトラフィックに割り当てられたメモリ（バッファー）リソースがある場合とない場合があります。
Some networks carry traffic for which delivery is considered optional; that is, packets of this type of traffic ought to consume network resources only when no other traffic is present. Alternatively, the effect of this type of traffic on all other network traffic is strictly limited. This is distinct from "best-effort" (BE) traffic since the network makes no commitment to deliver LE packets. In contrast, BE traffic receives an implied "good faith" commitment of at least some available network resources. This document proposes a Lower Effort Differentiated Services per-domain behavior (LE PDB) [RFC3086] for handling this "optional" traffic in a differentiated services domain.
一部のネットワークには、配信がオプションと見なされるトラフィックがあります。つまり、このタイプのトラフィックのパケットは、他のトラフィックが存在しない場合にのみ、ネットワークリソースを消費する必要があります。あるいは、他のすべてのネットワークトラフィックに対するこのタイプのトラフィックの影響は厳密に制限されています。これは、ネットワークがLEパケットを配信することをコミットしていないため、「ベストエフォルト」（BE）トラフィックとは異なります。対照的に、BEトラフィックは、少なくともいくつかの利用可能なネットワークリソースの暗黙の「誠実な」コミットメントを受け取ります。このドキュメントでは、差別化されたサービスドメインでこの「オプションの」トラフィックを処理するためのドメインごとの行動（LE PDB）[RFC3086] [RFC3086]の低い努力を提案しています。
There is no intrinsic reason to limit the applicability of the LE PDB to any particular application or type of traffic. It is intended as an additional tool for administrators in engineering networks.
LE PDBの適用性を特定のアプリケーションまたはトラフィックの種類に制限する本質的な理由はありません。エンジニアリングネットワークの管理者向けの追加ツールとして意図されています。
Note: where not otherwise defined, terminology used in this document is defined as in [RFC2474].
注：それ以外の場合は定義されていない場合、このドキュメントで使用される用語は[RFC2474]のように定義されます。
A Lower Effort (LE) PDB is for sending extremely non-critical traffic across a DS domain or DS region. There should be an expectation that packets of the LE PDB may be delayed or dropped when other traffic is present. Use of the LE PDB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Alternatively, or in addition, packets can be designated for the LE PDB when the goal is to protect all other packet traffic from competition with the LE aggregate, while not completely banning LE traffic from the network. An LE PDB should not be used for a customer's "normal internet" traffic, nor should packets be "downgraded" to the LE PDB for use as a substitute for dropping packets that ought to simply be dropped as unauthorized. The LE PDB is expected to be applicable to networks that have some unused capacity at some times of day.
低い努力（LE）PDBは、DSドメインまたはDS領域に非常に非批判的なトラフィックを送信するためのものです。他のトラフィックが存在するときに、LE PDBのパケットが遅延または削除される可能性があるという期待があるはずです。LE PDBの使用は、ネットワークオペレーターが特定の種類のトラフィックまたはユーザーをオフピーク時間に移動するのに役立つ場合があります。あるいは、または、ネットワークからのLEトラフィックを完全に禁止しているわけではなく、LE集合体との競合から他のすべてのパケットトラフィックを保護することを目標とする場合、LE PDBにパケットを指定することができます。LE PDBは、顧客の「通常のインターネット」トラフィックに使用しないでください。また、不正として単純にドロップするべきパケットを落とす代わりに使用するために、パケットをLE PDBに「ダウングレード」する必要もありません。LE PDBは、1日の時期に何らかの未使用容量を持つネットワークに適用できると予想されます。
This is a PDB that allows networks to protect themselves from selected types of traffic rather than giving a selected traffic aggregate preferential treatment. Moreover, it may also exploit all unused resources from other PDBs.
これは、選択されたトラフィックの総優先治療を提供するのではなく、ネットワークが選択されたタイプのトラフィックから自分自身を保護できるようにするPDBです。さらに、他のPDBからすべての未使用のリソースを活用することもあります。
There are no required traffic profiles governing the rate and bursts of packets beyond the limits imposed by the ingress link. It is not necessary to limit the LE aggregate using edge techniques since its PHB is configured such that packets of the aggregate will be dropped in the network if no forwarding resources are available. The differentiated services architecture [RFC2475] allows packets to be marked upstream of the DS domain or at the DS domain's edge. When packets arrive pre-marked with the DSCP used by the LE PDB, it should not be necessary for the DS domain boundary to police that marking; further (MF) classification for such packets would only be required if there was some reason for the packets to be marked with a different DSCP.
イングレスリンクによって課される制限を超えて、パケットのレートとバーストを管理する必要なトラフィックプロファイルはありません。転送リソースが利用できない場合、そのPHBがネットワークで削除されるようにPHBが構成されているため、Edge技術を使用してLEアグリゲートを制限する必要はありません。差別化されたサービスアーキテクチャ[RFC2475]により、パケットをDSドメインの上流またはDSドメインのエッジでマークすることができます。LE PDBが使用したDSCPを事前にマークしてパケットが到着した場合、DSドメイン境界がそのマーキングに警察する必要はありません。パケットが別のDSCPでマークされる理由がある場合にのみ、そのようなパケットの追加（MF）分類が必要です。
If there is not an agreement on a DSCP marking with the upstream domain for a DS domain using the LE PDB, the boundary must include a classifier that selects the appropriate LE target group of packets out of all arriving packets and steers them to a marker that sets the appropriate DSCP. No other traffic conditioning is required.
LE PDBを使用してDSドメインの上流ドメインとのDSCPマーキングに合意がない場合、境界には、到着するすべてのパケットから適切なLEターゲットグループを選択し、それらをマーカーに導く分類器を含める必要があります。適切なDSCPを設定します。他のトラフィックコンディショニングは必要ありません。
Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] may be used as the PHB for the LE traffic aggregate. This document does not specify the exact DSCP to use inside a domain, but instead specifies the necessary properties of the PHB selected by the DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
クラスセレクター（CS）PHB [RFC2474]、実験/ローカル使用（EXP/LU）PHB [RFC2474]、またはLEトラフィックアグリゲートのPHBとして使用される可能性があります。このドキュメントは、ドメイン内で使用する正確なDSCPを指定するのではなく、DSCPによって選択されたPHBの必要なプロパティを指定します。CS PHBを使用する場合、クラスセレクター1（DSCP = 001000）が推奨されます。
The PHB used by the LE aggregate inside a DS domain should be configured so that its packets are forwarded onto the node output link when the link would otherwise be idle; conceptually, this is the behavior of a weighted round-robin scheduler with a weight of zero.
DSドメイン内でLEアグリゲートで使用されるPHBは、リンクがアイドル状態になるときにパケットがノード出力リンクに転送されるように構成する必要があります。概念的には、これはゼロの重量の加重ラウンドロビンスケジューラの動作です。
An operator might choose to configure a very small link share for the LE aggregate and still achieve the desired goals. That is, if the output link scheduler permits, a small fixed rate might be assigned to the PHB, but the behavior beyond that configured rate should be that packets are forwarded only when the link would otherwise be idle. This behavior could be obtained, for example, by using a CBQ [CBQ] scheduler with a small share and with borrowing permitted. A PHB that allows packets of the LE aggregate to send more than the configured rate when packets of other traffic aggregates are waiting for the link is not recommended.
オペレーターは、LEアグリゲートに対して非常に小さなリンク共有を構成し、目的の目標を達成することを選択する場合があります。つまり、出力リンクスケジューラが許可されている場合、少量の固定レートがPHBに割り当てられる可能性がありますが、その構成レートを超える動作は、リンクがアイドル状態になる場合にのみパケットが転送されることです。この動作は、たとえば、CBQ [CBQ]スケジューラを少数の共有で使用し、借入を許可することで得ることができます。他のトラフィック集合体のパケットがリンクを待っている場合、LEアグリゲートのパケットが構成されたレート以上の送信を許可するPHBは推奨されません。
If a CS PHB is used, note that this configuration will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have a less timely forwarding than CS0. An operator's goal of providing an LE PDB is sufficient cause for violating the SHOULD. If an AF PHB is used, it must be configured and a DSCP assigned such that it does not violate the "MUST" of paragraph three of section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount of forwarding resources".
CS PHBを使用している場合、CS1はCS0よりもタイムリーな転送がないため、この構成はRFC 2474 [RFC2474]のセクション4.2.2.2 [RFC2474]に違反することに注意してください。LE PDBを提供するというオペレーターの目標は、違反するのに十分な理由です。AF PHBを使用する場合は、「最小限のフォワーディングリソース」を提供するRFC 2597 [RFC2597]のセクション2の3つのパラグラフ3の「必須」に違反しないように、設定され、DSCPを割り当てなければなりません。
The ingress and egress flow of the LE aggregate can be measured but there are no absolute or statistical attributes that arise from the PDB definition. A particular network operator may configure the DS domain in such a way that a statistical metric can be associated with that DS domain. When the DS domain is known to be heavily congested with traffic of other PDBs, a network operator should expect to see no (or very few) packets of the LE PDB egress from the domain. When there is no other traffic present, the proportion of the LE aggregate that successfully crosses the domain should be limited only by the capacity of the network relative to the ingress LE traffic aggregate.
LE骨材の侵入と出口の流れは測定できますが、PDB定義から生じる絶対的または統計的属性はありません。特定のネットワーク演算子は、統計メトリックがそのDSドメインに関連付けられるようにDSドメインを構成する場合があります。DSドメインが他のPDBのトラフィックと非常に混雑していることが知られている場合、ネットワークオペレーターは、ドメインからのLE PDB出口のNO（または非常に少ない）パケットが表示されることを期待する必要があります。他のトラフィックが存在しない場合、ドメインをうまく通過するLE骨材の割合は、イングレスLEトラフィックの集合体に対するネットワークの容量によってのみ制限される必要があります。
None required.
必要ありません。
A properly functioning network.
適切に機能するネットワーク。
o Multimedia applications [this example edited from Yoram Bernet]:
o マルチメディアアプリケーション[Yoram Bernetから編集されたこの例]：
Many network managers want to protect their networks from certain applications, in particular, from multimedia applications that typically use such non-adaptive protocols as UDP.
多くのネットワークマネージャーは、特に特定のアプリケーションからネットワークを保護したいと考えています。特に、このような適応プロトコルをUDPとして使用するマルチメディアアプリケーションから。
Most of the focus in quality-of-service is on achieving attributes that are better than Best Effort. These approaches can provide network managers with the ability to control the amount of multimedia traffic that is given this improved performance with excess relegated to Best Effort. This excess traffic can wreak havoc with network resources even when it is relegated to Best Effort because it is non-adaptive and because it can be significant in volume and duration. These characteristics permit it to seize network resources, thereby compromising the performance of other, more important applications that are included in the Best Effort traffic aggregate but that use adaptive protocols (e.g., TCP). As a result, network managers often simply refuse to allow multimedia applications to be deployed in resource constrained parts of their network.
サービスの質の焦点のほとんどは、最善の努力よりも優れた属性を達成することです。これらのアプローチは、ネットワークマネージャーに、この改善されたパフォーマンスが最善の努力に追いやられたこの改善されたパフォーマンスを与えられるマルチメディアトラフィックの量を制御する機能を提供できます。この過剰なトラフィックは、ネットワークリソースが最善の努力に追いやられていても、それが不適応であり、量と期間が重要である可能性があるため、最善の努力に追いやられた場合でも、大混乱をもたらす可能性があります。これらの特性により、ネットワークリソースを押収することができ、それにより、最良のトラフィックの集計に含まれるが、適応プロトコル（TCPなど）を使用する他のより重要なアプリケーションのパフォーマンスが損なわれます。その結果、ネットワークマネージャーは、マルチメディアアプリケーションをネットワークのリソース制約部分に展開できるようにすることを単に拒否することがよくあります。
The LE PDB enables a network manager to allow the deployment of multimedia applications without losing control of network resources. A limited amount of multimedia traffic may (or may not) be assigned to PDBs with attributes that are better than Best Effort. Excess multimedia traffic can be prevented from wreaking havoc with network resources by forcing it to the LE PDB.
LE PDBにより、ネットワークマネージャーは、ネットワークリソースの制御を失うことなく、マルチメディアアプリケーションの展開を許可できます。限られた量のマルチメディアトラフィックは、最善の努力よりも優れた属性を持つPDBに割り当てることができます（またはそうでない場合があります）。過剰なマルチメディアトラフィックは、LE PDBに強制することにより、ネットワークリソースで大混乱をもたらすことができなくなります。
o For Netnews and other "bulk mail" of the Internet.
o インターネットのNetNewsおよびその他の「バルクメール」の場合。
o For "downgraded" traffic from some other PDB when this does not violate the operational objectives of the other PDB or the overall network. As noted in section 2, LE should not be used for the general case of downgraded traffic, but may be used by design, e.g., when multicast is used with a value-added DS-service and consequently the Neglected Reservation Subtree problem [NRS] arises.
o 他のPDBまたはネットワーク全体の運用目標に違反しない場合、他のPDBからの「ダウングレード」トラフィックの場合。セクション2に記載されているように、LEは格下げのトラフィックの一般的なケースには使用すべきではありませんが、たとえば、マルチキャストが付加価値のあるDSサービスで使用され、その結果、無視された予約サブツリー問題[NRS]で使用される場合、設計によって使用される場合があります。発生します。
o For content distribution, peer-to-peer file sharing traffic, and the like.
o コンテンツの配布、ピアツーピアファイル共有トラフィックなど。
o For traffic caused by world-wide web search engines while they gather information from web servers.
o Webサーバーから情報を収集しながら、世界中のWeb検索エンジンによって引き起こされるトラフィックの場合。
The authors solicit further experiences for this section. Results from simulations are presented and discussed in Appendix A.
著者は、このセクションのさらなる経験を求めています。シミュレーションの結果については、付録Aで説明し、説明します。
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
このPDBの特定のセキュリティエクスポージャーはありません。[RFC2474]および[RFC2475]の一般的なセキュリティ上の考慮事項を参照してください。
The previous name of this PDB, "bulk handling", was loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate: it denotes a lower-cost delivery where the items are not handled with the same care or delivered with the same timeliness as items with first-class postage. Finally, the name was changed to "lower effort", because the authors and other DiffServ Working Group members believe that the name should be more generic in order to not imply constraints on the PDB's use to a particular type of traffic (namely that of bulk data).
このPDBの以前の名前である「バルクハンドリング」は、非常に低い優先順位メールの米国の郵便サービス期間に大まかに基づいており、削減されたレートで送信されます。同じケアまたは、一流の郵便料金のあるアイテムと同じ適時性で配信されます。最後に、著者や他のdiffservワーキンググループのメンバーは、特定のタイプのトラフィックに対するPDBの使用に対する制約を暗示しないために名前がより一般的であるべきだと考えているため、名前は「より低い努力」に変更されました。データ）。
The notion of having something "lower than Best Effort" was raised in the Diffserv Working Group, most notably by Roland Bless and Klaus Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for enterprise multimedia applications. One of its first applications was to re-mark packets within multicast groups [NRS]. Therefore, previous discussions centered on the creation of a new PHB. However, the original authors (Brian Carpenter and Kathleen Nichols) believe this is not required and this document was written to specifically explain how to get less than Best Effort without a new PHB.
「ベスト努力よりも低い」何かを持つという概念は、Diffserv Working Groupで提起されました。最も顕著なのは、Roland BlessとKlaus Wehrleによって、インターネットドラフト[LBE]と[LE]、およびエンタープライズマルチメディアアプリケーションのYoram Bernetによって提起されました。最初のアプリケーションの1つは、マルチキャストグループ[NRS]内でパケットを再マークすることでした。したがって、以前の議論は、新しいPHBの作成を中心としています。しかし、元の著者（ブライアン・カーペンターとキャスリーン・ニコルズ）は、これは必須ではないと考えており、この文書は新しいPHBなしで最善の努力を得る方法を具体的に説明するために書かれています。
Yoram Bernet contributed significant amounts of text for the "Examples" section of this document and provided other useful comments that helped in editing. Other Diffserv WG members suggested that the LE PDB is needed for Napster traffic, particularly at universities. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations that are described in Appendix A.
Yoram Bernetは、このドキュメントの「例」セクションにかなりの量のテキストを提供し、編集に役立つ他の有用なコメントを提供しました。他のDiffserv WGメンバーは、特に大学でのNapsterトラフィックにLE PDBが必要であることを示唆しました。付録Aで説明されているシミュレーションを実行する際の広範な努力について、ミレナノイマンに感謝します。
The intention of this appendix is to show that a Lower Effort PDB with a behavior as described in this document can be realized with different implementations and PHBs respectively. Overall, each of these variants show the desired behavior but also show minor differences in certain traffic load situations. This comparison could make the choice of a realization variant interesting for a network operator.
この付録の意図は、このドキュメントに記載されている動作を持つより低い努力PDBが、それぞれ異なる実装とPHBで実現できることを示すことです。全体として、これらのバリアントはそれぞれ望ましい動作を示していますが、特定のトラフィック負荷の状況にわずかな違いを示します。この比較により、ネットワークオペレーターにとって実現バリアントの選択が面白くなる可能性があります。
The small DiffServ domain shown in Figure 1 was used to simulate the LE PDB. There are three main sources of traffic (S1-S3) depicted on the left side of the figure. Source S1 sends five aggregated TCP flows (A1-A5) to the receivers R1-R5 respectively. Each aggregated flow Ax consists of 20 TCP connections, where each aggregate experiences a different round trip time between 10ms and 250ms. There are two sources of bulk traffic. B1 consists of 100 TCP connections sending as much data as possible to R6 and B2 is a single UDP flow also sending as much as possible to R7.
図1に示す小さなDiffServドメインを使用して、LE PDBをシミュレートしました。図の左側に描かれている3つの主要なトラフィックソース（S1-S3）があります。ソースS1は、それぞれ5つの凝集したTCPフロー（A1-A5）をレシーバーR1-R5に送信します。各集約されたフローxは20のTCP接続で構成され、各集合体は10msから250msの間の異なる往復時間を経験します。バルクトラフィックには2つのソースがあります。B1は、R6にできるだけ多くのデータを送信する100のTCP接続で構成され、B2はR7にできるだけ多くのUDPフローを送信します。
...................
. . R1
. . /
. . /-R2
. . /
S1==**=>[BR1] [BR4]==**==>---R3
. \\ // . \
. \\ // . \-R4
. ** ** . \
. \\ // . R5
. \\ // .
S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .
(Bulk) . // \\ .
. // :: .
. :: \\ .
. // ++ .
.// \\.
S3==::==>[BR3] [BR5]==++==>R6
(UDP) . . ||
. . ||
. . ::
.................... ||
VV
R7
Figure 1: A DiffServ domain with different flows
図1：異なるフローを持つDiffservドメイン
In order to show the benefit of using the LE PDB instead of the normal Best Effort (BE) PDB [RFC3086], different scenarios are used:
通常の最善の努力（BE）PDB [RFC3086]の代わりにLE PDBを使用する利点を示すために、さまざまなシナリオが使用されます。
A) B1 and B2 are not present, i.e., the "normal" situation without bulk data present. A1-A5 use the BE PDB.
A）B1とB2は存在しません。つまり、バルクデータが存在しない「通常の」状況。a1-a5はbe pdbを使用します。
B) B1 and B2 use the BE PDB for their traffic, too.
b）B1とB2は、トラフィックにもBE PDBを使用します。
C) B1 and B2 use LE PDB for their traffic with different PHB implementations:
c）B1とB2は、異なるPHB実装でトラフィックにLE PDBを使用します。
1) PHB with Priority Queueing (PQ) 2) PHB with Weighted Fair Queueing (WFQ) 3) PHB with Weighted RED (WRED) 4) PHB with WFQ and RED
1) 優先QUEUING（PQ）2）のPHB（PQ）のPHB重み付き公正キューイング（WFQ）3）WFQおよび赤の重み付き赤（WRED）4）PHB
C1) represents the case where there are no allocated resources for the LE PDB, i.e., LE traffic is only forwarded if there are unused resources. In scenarios C2)-C4), a bandwidth share of 10% has been allocated for the LE PDB. RED parameters were set to w_q=0.1 and max_p=0.2. In scenario C2), two tail drop queues were used for BE and LE and WFQ scheduling was set up with a weight of 9:1 for the ratio of BE:LE. In scenario C3), a total queue length of 200000 bytes was used with the following thresholds: min_th_BE=19000, max_th_BE=63333, min_th_LE=2346, max_th=7037. WRED allows to mark packets with BE or LE within the same microflow (e.g., letting applications pre-mark packets according to their importance) without causing a reordering of packets within the microflow. In scenario C4), each queue had a length of 50000 bytes with the same thresholds of min_th=18000 and max_th=48000 bytes. WFQ parameters were the same as in C2).
C1）は、LE PDBに割り当てられたリソースがない場合を表します。つまり、LEトラフィックは、未使用のリソースがある場合にのみ転送されます。シナリオc2）-c4）では、10％の帯域幅シェアがLE PDBに割り当てられています。赤いパラメーターはW_Q = 0.1およびMAX_P = 0.2に設定されました。シナリオc2）では、2つのテールドロップキューがBeに使用され、LEおよびWFQスケジューリングは、Be：LEの比率で9：1の重量で設定されました。シナリオc3）では、次のしきい値で200000バイトの合計キュー長を使用しました：min_th_be = 19000、max_th_be = 63333、min_th_le = 2346、max_th = 7037。Wredは、マイクロフロー内でパケットを並べ替えることなく、同じマイクロフロー内でBeまたはLEでパケットをマークすることができます（たとえば、その重要性に応じてアプリケーションを事前にマークパケットにさせる）。シナリオc4）では、各キューの長さは50000バイトの長さで、min_th = 18000とmax_th = 48000バイトと同じしきい値がありました。WFQパラメーターはC2と同じでした）。
The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, thus creating the bottleneck in the network for the following situations. In all situations, the 20 TCP connections within each aggregated flow Ax (flowing from S1 to Rx) used the Best Effort PDB. Sender S2 transmitted bulk flow B1 (consisting of 100 TCP connections to R6) with an aggregated rate of 550 kbit/s, whereas the UDP sender S3 transmitted with a rate of 50 kbit/s.
IR1とIR2の間のリンク帯域幅は1200 Kbit/sに制限されているため、次の状況でネットワーク内のボトルネックを作成します。すべての状況で、各集約されたフローx（S1からRXに流れる）内の20のTCP接続が最適なPDBを使用しました。Sender S2は、550 Kbit/sの集計レートで、バルクフローB1（R6への100 TCP接続で構成される）を送信しましたが、UDP Sender S3は50 KBIT/sのレートで送信されました。
The following four different situations with varying traffic load for the Ax flows (at application level) were simulated.
（アプリケーションレベルで）axフローにさまざまなトラフィック負荷を備えた次の4つの異なる状況がシミュレートされました。
Situation | I | II | III | IV |
----------------------------+------+------+------+------|
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 |
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 |
Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 |
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 |
Best Effort Load (S1) | 100% | 90% | 150% | 67% |
Total load for link IR1->IR2| 150% | 140% | 200% | 117% |
In situation I, there are no unused resources left for the B1 and B2 flows. In situation II, there is a residual bandwidth of 10% of the bottleneck link between IR1 and IR2. In situation III, the traffic load of A1-A5 is 50% higher than the bottleneck link capacity. In situation IV, A1-A5 consume only 2/3 of the bottleneck link capacity. B1 and B2 require together 50% of the bottleneck link capacity.
状況Iでは、B1およびB2の流れには未使用のリソースが残っていません。状況IIでは、IR1とIR2の間にボトルネックリンクの10％の残留帯域幅があります。状況IIIでは、A1-A5のトラフィック負荷は、ボトルネックリンク容量よりも50％高くなっています。状況IVでは、A1-A5はボトルネックリンク容量の2/3のみを消費します。B1とB2には、ボトルネックリンク容量の50％が必要です。
The simulations were performed with the freely available discrete event simulation tool OMNeT++ and a suitable set of QoS mechanisms [SimKIDS]. Results from the different simulation scenarios are discussed in the next section.
シミュレーションは、自由に利用可能な離散イベントシミュレーションツールオムネットとQoSメカニズムの適切なセット[Simkids]で実行されました。さまざまなシミュレーションシナリオの結果については、次のセクションで説明します。
QoS parameters listed in the following tables are averaged over the first 160s of the transmission. Results of situation I are shown in Figure 2. When the BE PDB is used for transmission of bulk flows B1 and B2 in case B), one can see that flows A1-A5 throttle their sending rate to allow transmission of bulk flows B1 and B2. In case C1), not a single packet is transmitted to the receiver because all packets get dropped within IR1, thereby protecting Ax flows from Bx flows. In case C2), B1 and B2 consume all resources up to the configured limit of 10% of the link bandwidth, but not more. C3) also limits the share of B1 and B2 flows, but not as precisely as with WFQ. C4) shows slightly higher packet losses for Ax flows due to the active queue management.
次のテーブルにリストされているQoSパラメーターは、伝送の最初の160年代にわたって平均されています。状況の結果Iを図2に示します。BEPDBがバルクフローB1およびB2のケースB）の送信に使用される場合、A1-A5が送信速度をスロットルして、バルクフローB1およびB2の伝達を可能にすることがわかります。。ケースC1）では、すべてのパケットがIR1内にドロップされるため、単一のパケットが受信機に送信されるため、BXフローからのaxフローを保護します。ケースC2）では、B1とB2は、リンク帯域幅の10％の構成制限まですべてのリソースを消費しますが、それ以上ではありません。C3）もB1およびB2フローのシェアを制限しますが、WFQと同じくらい正確には制限されません。c4）アクティブキュー管理により、axフローのパケット損失がわずかに高いことを示します。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |
| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |
| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |
| Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 |
| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |
| | B1 | - | 491 | 0 | 82 | 85 | 84 |
| | B2 | - | 40 | 0 | 39 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |
| [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 |
| | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 |
| | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 |
| Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 |
| [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 |
| | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 |
| | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 |
| Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 2: Situation I - Best Effort traffic uses 100% of the available bandwidth
図2：状況I-最良の努力トラフィックでは、利用可能な帯域幅の100％を使用しています
Results of situation II are shown in Figure 3. In case C1), LE traffic gets exactly the 10% residual bandwidth that is not used by the Ax flows. Cases C2) and C4) show similar results compared to C1), whereas case C3) also drops packets from flows A1-A5 due to active queue management.
状況IIの結果を図3に示します。ケースC1）、LEトラフィックは、axの流れで使用されない10％の残留帯域幅を正確に取得します。ケースC2）およびC4）は、C1）と比較して同様の結果を示しますが、ケースC3）は、アクティブキュー管理によりフローA1-A5からパケットをドロップします。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |
| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |
| Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 |
| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |
| | B1 | - | 488 | 83 | 83 | 114 | 84 |
| | B2 | - | 39 | 39 | 39 | 33 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 |
+----------------+--------+--------+------+------+------+----+-+-------+
| | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 |
| | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 |
| | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 |
| Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 |
| [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 |
| | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 |
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 |
| Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 3: Situation II - Best Effort traffic uses 90% of the available bandwidth
図3：状況II-最適な努力トラフィックでは、利用可能な帯域幅の90％を使用しています
Results of simulations for situation III are depicted in Figure 4. Due to overload caused by flows A1-A5, packets get dropped in all cases. Bulk flows B1 and B2 nearly get their maximum throughput in case B). As one would expect, in case C1) all packets from B1 and B2 are dropped, in cases C2) and C4) resource consumption of bulk data is limited to the configured share of 10%. Again the WRED implementation in C3) is not as accurate as the WFQ variants and lets more BE traffic pass through IR1.
状況IIIのシミュレーションの結果を図4に示します。フローA1-A5によって引き起こされる過負荷により、すべての場合にパケットが削除されます。バルクフローB1とB2は、ケースb）で最大スループットをほぼ取得します。予想されるように、C1）B1とB2のすべてのパケットが削除され、c2）およびc4）バルクデータのリソース消費は、構成された10％の構成された共有に制限されています。繰り返しますが、C3）のWRED実装は、WFQバリアントほど正確ではなく、IR1を通過するトラフィックをより多くすることができます。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |
| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |
| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |
| Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 |
| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |
| | B1 | - | 483 | 0 | 83 | 73 | 83 |
| | B2 | - | 41 | 0 | 38 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |
| [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 |
| | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 |
| | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 |
| Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 |
| [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 |
| | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 |
| | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 |
| Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 4: Situation III - Best Effort traffic load is 150%
図4：状況III-最良のトラフィック負荷は150％です
In situation IV, 33% or 400 kbit/s are not used by Ax flows and the results are listed in Figure 5. In case B) where bulk data flows B1 and B2 use the BE PDB, packets of Ax flows are dropped, whereas in cases C1)-C4) flows Ax are protected from bulk flows B1 and B2. Therefore, by using the LE PDB for Bx flows, the latter get only the residual bandwidth of 400 kbit/s but not more. Packets of Ax flows are not affected by Bx traffic in these cases.
状況IVでは、33％または400 kbit/sはaxフローでは使用されず、結果を図5に示します。ケースC1）-C4）フロー軸は、バルクフローB1およびB2から保護されています。したがって、BXフローにLE PDBを使用することにより、後者は400 kbit/sの残留帯域幅のみを取得しますが、それ以上になります。これらの場合、axフローのパケットはBXトラフィックの影響を受けません。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |
| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |
| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |
| Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 |
| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |
| | B1 | - | 509 | 361 | 362 | 364 | 362 |
| | B2 | - | 43 | 40 | 39 | 38 | 40 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 |
| [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 |
| | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 |
| | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 |
| Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 |
| [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 |
| | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 |
| | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 |
| Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 5: Situation IV - Best Effort traffic load is 67%
図5：状況IV-最良の努力トラフィック負荷は67％です
In summary, all the different scenarios show that the "normal" BE traffic can be protected from traffic in the LE PDB effectively. Either no packets get through if no residual bandwidth is left (LE traffic is starved), or traffic of the LE PDB can only consume resources up to a configurable limit.
要約すると、すべての異なるシナリオは、「通常の」BEトラフィックがLE PDBのトラフィックから効果的に保護できることを示しています。残留帯域幅が残っていない場合（LEトラフィックが飢えている）、またはLE PDBのトラフィックは、構成可能な制限までのみリソースを消費することができます。
Furthermore, the results substantiate that mass data transfer can adversely affect "normal" BE traffic (e.g., 14.9% packet loss in situations I and II, even 10.2% in situation IV) in situations without using the LE PDB.
さらに、結果は、質量データ転送が「通常の」BEトラフィックに悪影響を与える可能性があることを実証しています（例えば、LE PDBを使用せずに状況では、状況IおよびIIで14.9％のパケット損失、状況IVでも10.2％）。
Thus, while all presented variants of realizing the LE PDB meet the desired behavior of protecting BE traffic, they also show small differences in detail. A network operator has the opportunity to choose a realization method to fit the desired behavior (showing this is - after the proof of LE's efficacy - the second designation of this appendix). For instance, if operators want to starve LE traffic completely in times of congestion, they could choose PQ. This causes LE traffic to be completely starved and not a single packet would get through in case of full load or overload.
したがって、LE PDBが保護するという望ましい動作を満たすことを実現するすべての提示されたバリアントは、交通を保護することですが、それらは詳細に小さな違いを示します。ネットワークオペレーターには、目的の動作に適合する実現方法を選択する機会があります（これは、LEの有効性の証明の後、この付録の2番目の指定です）。たとえば、オペレーターが混雑の時にLEの交通を完全に飢えさせたい場合、PQを選択できます。これにより、LEトラフィックが完全に飢えています。また、全負荷や過負荷の場合に1つのパケットが通過することはありません。
On the other hand, for network operators who want to permit some small amount of throughput in the LE PDB, one of the other variants would be a better choice.
一方、LE PDBで少量のスループットを許可したいネットワークオペレーターにとって、他のバリアントの1つがより良い選択です。
Referring to this, the WFQ implementation showed a slightly more robust behavior with PQ, but had problems with synchronized TCP flows. WRED behavior is highly dependent on the actual traffic characteristics and packet loss rates are often higher compared to other implementations, while the fairness between TCP connections is better. The combined solution of WFQ with RED showed the overall best behavior, when an operator's intent is to keep a small but noticeable throughput in the LE PDB.
これを参照すると、WFQの実装はPQでわずかに堅牢な動作を示しましたが、同期されたTCPフローの問題がありました。WREDの動作は実際のトラフィック特性に大きく依存しており、パケット損失率は他の実装と比較して高いことが多く、TCP接続間の公平性は優れています。WFQとREDの組み合わせ溶液は、オペレーターの意図がLE PDBで小さくても顕著なスループットを維持することである場合、全体的な最高の動作を示しました。
Normative References
引用文献
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、RFC 3086、2001年4月。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
Informative References
参考引用
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[CBQ] Floyd, S. and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3, No. 4, pp. 365-386, August 1995.
[CBQ] Floyd、S。およびV. Jacobson、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE/ACMトランザクションオンネットワーク、Vol。3、No。4、pp。365-386、1995年8月。
[LBE] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", Work in Progress, September 1999.
[Lbe] Bless、R。およびK. Wehrle、「最高のエフォルトあたりの行動よりも低い」、1999年9月、進行中の作業。
[LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop Behavior", Work in Progress, February 2001.
[Le] Bless、R。およびK. Wehrle、「限られた努力あたりの行動」、2001年2月、進行中の作業。
[SimKIDS] Wehrle, K., Reber, J. and V. Kahmann, "A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior", in Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), USA, pp. 115-122, January 2001.
[Simkids] Wehrle、K.、Reber、J。and V. Kahmann、「任意のサービス品質行動を統合する機能を備えたインターネットノードのシミュレーションスイート」、通信ネットワークおよび分散システムモデリングおよびシミュレーション会議（CNDS2001）、フェニックス（AZ）、米国、pp。115-122、2001年1月。
[NRS] Bless, R. and K. Wehrle, "Group Communication in Differentiated Services Networks", in Proceedings of IEEE International Workshop on "Internet QoS", Brisbane, Australia, IEEE Press, pp. 618-625, May 2001.
[NRS] Bless、R。およびK. Wehrle、「差別化されたサービスネットワークにおけるグループコミュニケーション」、「インターネットQos」に関するIEEE国際ワークショップの議事録、オーストラリア、ブリスベン、IEEEプレス、pp。618-625、2001年5月。
Authors' Addresses
著者のアドレス
Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany
Roland Bless Telematics Institute、Universitaet karlsruhe（th）Zirkel 2 76128 Karlsruheドイツ
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
Kathleen Nichols 325M Sharon Park Drive #214 Menlo Park, CA 94025
キャスリーンニコルズ325mシャロンパークドライブ＃214メンロパーク、カリフォルニア94025
EMail: knichols@ieee.org
Klaus Wehrle University of Tuebingen, Computer Networks and Internet Morgenstelle 10c, 72076 Tuebingen, Germany & International Computer Science Institute (ICSI) 1947 Center Street, Berkeley, CA, 94704, USA
Klaus Wehrle Tuebingen大学、コンピューターネットワーク、インターネットMorgenstelle 10C、72076 Tuebingen、Germany＆International Computer Science Institute（ICSI）1947 Center Street、Berkeley、CA、94704、米国
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。