Network Working Group G. Armitage
Request for Comments: 3248 Swinburne University of Technology
Category: Informational B. Carpenter
IBM
A. Casati
Lucent Technologies
J. Crowcroft
University of Cambridge
J. Halpern
Consultant
B. Kumar
Corona Networks Inc.
J. Schnizlein
Cisco Systems
March 2002
A Delay Bound alternative revision of
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB.
歴史的な関心のために、この文書は、RFC 2598の原作者で好ましいが、EFの本来の定義はアンロードされたネットワーク上の転送の比較に基づいた2000年12月にワーキンググループによって採用されていない、EFデザインチームの提案したソリューションをキャプチャします。この実験的な遅延限界（DB）PHBは、ネットワーク内の他のトラフィックへのパケットの遅延のバウンドが必要です。 2000年8月のピッツバーグIETF会議で、差別化サービスワーキンググループは、RFC 2598に関する深刻な問題に直面した - グループの基準は緊急転送（EF）毎のホップの挙動（PHB）の定義を追跡します。 「EF設計チームは、」心の中のDiffServグループで提起された問題を担持し、RFC 2598の再発現を開発するために志願しました。 2000年12月、サンディエゴIETFミーティングでのDiffServワーキンググループが再発現EF PHBの代替を追求することを決めました。
Specification of Requirements
要件の仕様
This document is for Informational purposes only. If implementors choose to experiment with the DB PHB, key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [3].
この文書は情報提供のみを目的としています。実装者は、DB PHBで実験することを選択した場合、キーワードは "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL NOT"、 "SHOULD" "ものと"、 "SHOULD NOT"、 "推奨"、 "MAY" RFC 2119に記載されているように、及び "OPTIONAL" が解釈される[3]。
1 Introduction
1はじめに
RFC 2598 was the Differentiated Services (DiffServ) working group's first standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) [1]. As part of the DiffServ working group's ongoing refinement of the EF PHB, various issues were raised with the text in RFC 2598 [2].
RFC 2598は、差別化サービス（DiffServの）ワーキンググループの最初の基準はホップの挙動（PHB）毎の緊急転送（EF）の定義を追跡した[1]。 EF PHBのDiffServのワーキンググループの継続的な改善の一環として、様々な問題は、RFC 2598でテキストで育った[2]。
After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF design team' was formed (the authors of this document) to propose a new expression of the EF PHB. The remainder of this Informational document captures our feedback to the DiffServ working group at the San Diego IETF in December 2000. Our solution focussed on a Delay Bound (DB) based re-expression of RFC 2598 which met the goals of RFC 2598's original authors. The DiffServ working group ultimately chose an alternative re-expression of the EF PHB text, developed by the authors of [2] and revised to additionally encompass our model described here.
2000年8月のピッツバーグIETFミーティングの後、ボランティア「EFのデザインチームは、」EF PHBの新しい表現を提案する（この文書の著者）を形成しました。この情報文書の残りの部分では、当社のソリューションは、（DB）遅延限界に焦点を当てた2000年12月にサンディエゴIETFでのDiffServワーキンググループに私たちのフィードバックを取り込み、RFC 2598のオリジナルの作者の目標を達成し、RFC 2598のベースの再発現。 DiffServのワーキンググループは、最終的には[2]の著者によって開発され、さらにここで説明する我々のモデルを包含するように改訂され、EF PHBのテキストの代わりの再発現を選びました。
Our proposed Delay Bound solution is archived for historical interest. Section 2 covers the minimum, necessary and sufficient description of what we believed qualifies as 'DB' behavior from a single node. Section 3 then discusses a number of issues and assumptions made to support the definition in section 2.
私たちの提案遅延限界溶液は歴史的な関心のためにアーカイブされます。第2節では、我々は、単一のノードから「DBの行動としての資格を信じて何の最低限、必要かつ十分な説明をカバーしています。第3節では、セクション2で定義をサポートするために作られた問題や多くの仮定を説明します。
For a traffic stream not exceeding a particular configured rate, the goal of the DB PHB is a strict bound on the delay variation of packets through a hop.
特定の設定されたレートを超えないトラフィックストリームのために、DB PHBの目的は、ホップを介してパケットの遅延変動に関する厳しい結合されます。
This section will begin with the goals and necessary boundary conditions for DB behavior, then provide a descriptive definition of DB behavior itself, discuss what it means to conform to the DB definition, and assign the experimental DB PHB code point.
このセクションでは、DBの定義に準拠し、かつ実験的なDBのPHBコードポイントを割り当てることが何を意味するのかについて議論し、DBの挙動自体の記述的な定義を提供し、目標とDBの動作に必要な境界条件で始まります。
For a traffic stream not exceeding a configured rate the goal of the DB PHB is a strict bound on the delay variation of packets through a hop.
設定されたレートを超えないトラフィックストリームのためにDB PHBの目的は、ホップを介してパケットの遅延変動に関する厳しい結合されます。
Traffic MUST be policed and/or shaped at the source edge (for example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in order to get such a bound. However, specific policing and/or shaping rules are outside the scope of the DB PHB definition. Such rules MUST be defined in any per-domain behaviors (PDBs) composed from the DB PHB.
（RFC 2475で説明されているように[5]例えば、DS-ドメインへ入口に）トラフィックは、このようなバウンドを得るためにポリシング及び/又はソース端に成形されなければなりません。しかし、特定のポリシング及び/又は整形ルールはDB PHB定義の範囲外です。そのようなルールは、DB PHBからなる任意あたりドメイン行動（のPDB）で定義されなければなりません。
A device (hop) delivers DB behavior to appropriately marked traffic received on one or more interfaces (marking is specified in section 2.4). A device SHALL deliver the DB behavior on an interface to DB marked traffic meeting (i.e. less than or equal) a certain arrival rate limit R.
デバイス（ホップ）を適切トラフィック（マーキングは、セクション2.4で指定されている）1つまたは複数のインターフェイス上で受信されたとマークするDBの動作を提供します。 DBへのインターフェース上でDBの動作を交付しなければならない装置（以下、すなわち）特定の到着レート制限R.トラフィック会議をマーク
If more DB traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the DB behavior. However, although the original source of DB traffic will be shaped, aggregation and upstream jitter ensure that the traffic arriving at any given hop cannot be assumed to be so shaped. Thus a DB implementation SHOULD have some tolerance for burstiness - the ability to provide EF behavior even when the arrival rate exceeds the rate limit R.
より多くのDBトラフィックが許容可能であるよりも、到着した場合、デバイスは、DBの振る舞いを提供する必要はありません。 DBトラフィックの元のソースが整形されるものの、凝集および上流のジッタは、任意の所与のホップで到達するトラフィックがそれほど形状であると仮定することができないことを確認してください。到着レートがレート制限Rを超えてもEF動作を提供する能力 - こうしてDBの実装では、バーストのためのいくつかの耐性を有するべきです
Different DB implementations are free to exhibit different tolerance to burstiness. (Burstiness MAY be characterized in terms of the number of back-to-back wire-rate packets to which the hop can deliver DB behavior. However, since the goal of characterizing burstiness is to allow useful comparison of DB implementations, vendors and users of DB implementations MAY choose to utilize other burstiness metrics.)
異なるDBの実装では、バースト性の異なる耐性を示すことは自由です。 （バースト性は、ホップはDBの動作を実現することができたバックツーバックワイヤレートパケットの数の点で特徴付けることができる。しかし、バースト性を特徴付けるの目標は、DBの実装、ベンダーとユーザの有用な比較を可能にすることであるのでDBの実装は、他のバースト性の指標を利用することを選ぶかもしれません。）
The DB PHB definition does NOT mandate or recommend any particular method for achieving DB behavior. Rather, the DB PHB definition identifies parameters that bound the operating range(s) over which an implementation can deliver DB behavior. Implementors characterize their implementations using these parameters, while network designers and testers use these parameters to assess the utility of different DB implementations.
DBのPHBの定義は、DBの振る舞いを達成するための任意の特定の方法を強制あるいは推奨していません。むしろ、DB PHB定義は、実装がDBの動作を実現することができ、その上、動作範囲（複数可）に結合したパラメータを識別する。ネットワーク設計者とテスターは異なるDBの実装の有用性を評価するためにこれらのパラメータを使用しながら、実装者は、これらのパラメータを使用して実装を特徴付けます。
For simplicity the definition will be explained using an example where traffic arrives on only one interface and is destined for another (single) interface.
簡単にするために定義は、トラフィックが1つのインタフェースだけに到着し、別の（単一の）インターフェイスを宛先とする例を用いて説明します。
The crux of this definition is that the difference in time between when a packet might have been delivered, and when it is delivered, will never exceed a specifiable bound.
この定義の核心は、パケットが配信されている可能性がある場合、それが配信されたときの間の時間の差は、指定可能なバウンドを超えることはありませんということです。
Given an acceptable (not exceeding arrival rate limit R) stream of DB packets arriving on an interface:
インターフェースに到着DBパケットの許容される（到着レート制限Rを超えない）ストリーム所与。
There is a time sequence E(i) when these packets would be delivered at the output interface in the absence of competing traffic. That is, E(i) are the earliest times that the packets could be delivered by the device.
これらのパケットは、トラフィックの競合が存在しない場合に出力インタフェースに配信されるだろう時系列E（i）があります。つまり、E（i）は、パケットがデバイスによって送達され得るという太古の時代です。
In the presence of competing traffic, the packets will be delayed to some later time D(i).
トラフィック競合の存在下では、パケットは、いくつかの後の時点D（I）に遅延されます。
Competing traffic includes all DB traffic arriving at the device on other ports, and all non-DB traffic arriving at the device on any port.
他のポート上のデバイスに到着するすべてのDBのトラフィック、および任意のポート上のデバイスに到着するすべての非DBトラフィックはトラフィックを含む競合します。
DB is defined as the behavior which ensures, for all i, that:
DBは、全てのi、そのため、確実に行動のように定義されます。
D(i) - E(i) <= S * MTU/R.
D（I） - E（I）<= S * MTU / R.
MTU is the maximum transmission unit (packet size) of the output. R is the arrival rate that the DB device is prepared to accept on this interface.
MTUは、出力の最大伝送単位（パケットサイズ）です。 Rは、DB装置は、このインターフェイス上で受け入れるように準備される到着率です。
Note that D(i) and E(i) simply refer to the times of what can be thought of as "the same packet" under the two treatments (with and without competing traffic).
D（i）とE（i）は、単純に（と、トラフィックを競合せずに）2つの治療の下で「同じパケット」と考えることができるかの回を参照していることに注意してください。
The score, S, is a characteristic of the device at the rate, R, in order to meet this defined bound. This score, preferably a small constant, depends on the scheduling mechanism and configuration of the device.
スコアSは、これが結合した定義された満たすために、R、速度でデバイスの特性です。このスコアは、好ましくは小定数は、デバイスのスケジューリング機構および構成に依存します。
An implementation need not conform to the DB specification over an arbitrary range of parameter values. Instead, implementations MUST specify the rates, R, and scores S, for which they claim conformance with the DB definition in section 2.2, and the implementation-specific configuration parameters needed to deliver conformant behavior. An implementation SHOULD document the traffic burstiness it can tolerate while still providing DB behavior.
実装は、パラメータ値の任意の範囲にわたってDB仕様に準拠する必要はありません。その代わりに、実装は、それらがセクション2.2でDB定義の適合を主張いるレート、R、及びスコアS、および準拠動作を実現するために必要な実装固有の設定パラメータを指定する必要があります。実装は、トラフィックをドキュメント化する必要がありますバーストまだDBの動作を提供しながら、それを容認することができます。
The score, S, and configuration parameters depend on the implementation error from an ideal scheduler. Discussion of the ability of any particular scheduler to provide DB behavior, and the conditions under which it might do so, is outside the scope of this document.
スコア、S、および構成パラメータは、理想的なスケジューラから実装誤差に依存します。 DBの振る舞いを提供するために、いずれかの特定のスケジューラの能力、そしてそれはそうかもしれない条件の議論は、この文書の範囲外です。
The implementor MAY define additional constraints on the range of configurations in which DB behavior is delivered. These constraints MAY include limits on the total DB traffic across the device, or total DB traffic targeted at a given interface from all inputs.
実装は、DBの動作が配信された構成の範囲に追加の制約を定義することができます。これらの制約は、すべての入力から所定のインターフェースを対象デバイス、又は全DBのトラフィックを横切る総DBトラフィックの制限を含むかもしれません。
This document does not specify any requirements on DB implementation's values for R, S, or tolerable burstiness. These parameters will be bounded by real-world considerations such as the actual network being designed and the desired PDB.
この文書では、R、S、または許容バーストのためのDB実装の値の任意の要件を指定していません。これらのパラメータは、そのように設計されている実際のネットワークと希望PDBのような実世界の配慮によって制限されます。
One or more DiffServ codepoint (DSCP) value may be used to indicate a requirement for DB behavior [4].
一つ以上のDiffServコードポイント（DSCP）値は、[4] DBの動作のための要件を示すために使用されてもよいです。
By default we suggest an 'experimental' DSCP of 101111 be used to indicate that DB PHB is required.
デフォルトでは、我々は101111の「実験」DSCPは、DB PHBが必要であることを示すために使用されることが示唆されました。
This section discusses some issues that might not be immediately obvious from the definition in section 2.
このセクションでは、セクション2で定義からすぐに明らかにならないかもしれないいくつかの問題について説明します。
Packets marked for DB PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the DB PHB. Packets marked for DB PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
DB PHBのためにマークされたパケットは、唯一のDB PHBを満たす他のコードポイントにDSドメイン境界で述べられるかもしれません。 DBのPHBのためにマークされたパケットは、DSドメインで別のPHBに昇格または降格されるべきではありません。
When DB packets are tunneled, the tunneling packets must be marked as DB.
DBパケットがトンネリングされている場合、トンネリングパケットは、DBとしてマークする必要があります。
Other PHBs and PHB groups may be deployed in the same DS node or domain with the DB PHB as long as the requirement of section 2 is met.
他のPHBおよびPHBグループがあれば区間2の要件が満たされるようにDB PHBと同じDSノードまたはドメインに配備されてもよいです。
The definition of DB behavior given in section 2 is quite explicitly given in terms of input rate R and output delay variation D(i) - E(i). A scheduler's output rate does not need to be specified, since (by design) it will be whatever is needed to achieve the target delay variation bounds.
E（I） - セクション2で与えられたDBの動作の定義は非常に明示的に入力レートRと出力遅延変動D（i）の点で与えられます。 （デザインによって）それが目標遅延変動の範囲を達成するために必要とされているものになりますので、スケジューラの出力レートは、指定する必要はありません。
Jitter is not the bounded parameter in DB behavior. Jitter can be understood in a number of ways, for example the variability in inter-packet times from one inter-packet interval to the next. However, DB behavior aims to bound a related but different parameter - the variation in delay between the time packets would depart in the absence of competing traffic, E(i), and when they would depart in the presence of competing traffic, D(i).
ジッタは、DB行動の有界パラメータではありません。ジッタは、次の1つのパケット間間隔から、例えば、いくつかの方法でパケット間の時間の変動を理解することができます。しかし、DBの動作が関連するが異なるパラメータをバインドすることを目指して - パケットは、競合するトラフィックが存在しない状態で出発E（I）、そして彼らは、競合するトラフィックの存在下で出発だろうというときでしょう時間との間の遅延の変動、D（I ）。
The definition of 'competing traffic' in section 2.2 covers both the single input/single output case and the more general case where DB traffic is converging on a single output port from multiple input ports. When evaluating the ability of an DB device to offer DB behavior to traffic arriving on one port, DB traffic arriving on other ports is factored in as competing traffic.
セクション2.2カバー単一入力/単一出力の場合とDBトラフィックが複数の入力ポートからの単一の出力ポートに収束されるより一般的な場合の両方において、「競合するトラフィック」の定義。 1ポートに着信したトラフィックにDBの振る舞いを提供するDBデバイスの能力を評価する場合、他のポートに到着DBトラフィックはトラフィックを競合として織り込まれています。
When considering DB traffic from a single input that is leaving via multiple ports, it is clear that the behavior is no worse than if all of the traffic could be leaving through each one of those ports individually (subject to limits on how much is permitted).
複数のポートを介して離脱された単一の入力からDBトラフィックを考慮した場合、動作トラフィックのすべてが個々にそれらのポートの各々を通って出ることができる場合よりも悪くないこと（許可されているどのくらいの制限を受ける）は明らかです。
Where an ingress link has an MTU higher than that of an egress link, it is conceivable packets may be fragmented as they pass through a Diffserv hop. However, the unpredictability of fragmentation is significantly counter to the goal of providing controllable QoS. Therefore we assume that fragmentation of DB packets is being avoided (either through some form of Path MTU discovery, or configuration), and does not need to be specifically considered in the DB behavior definition.
入口リンクがより高い出力リンクよりもMTUを有する場合、それはDiffservのホップを通過するように考えられるパケットが断片化されてもよいです。しかし、断片化の予測不可能性は、制御可能なQoSを提供することを目標に大きくカウンターです。そこで我々は、DBパケットの断片化が（どちらかのパスMTUディスカバリ、または構成のいくつかのフォームを）回避され、具体的には、DBの振る舞いの定義で考慮される必要がないことを前提としています。
If the DB PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage DB traffic could inflict on other traffic. This will be reflected in the DB device's burst tolerance described in section 2.1.
DB PHBは、他のトラフィック（例えば、プライオリティキュー）の無制限のプリエンプションを可能にするメカニズムによって実装されている場合、実装は、DBのトラフィックが他のトラフィックに与える可能性損傷を制限するための何らかの手段を含まなければなりません。これはセクション2.1で説明したDB装置のバースト許容範囲に反映されます。
Some DB implementations may choose to provide queuing and scheduling at a finer granularity, (for example, per micro flow), than is indicated solely by the packet's DSCP. Such behavior is NOT precluded by the DB PHB definition. However, such behavior is also NOT part of the DB PHB definition. Implementors are free to characterize and publicize the additional per micro flow capabilities of their DB implementations as they see fit.
いくつかのDBの実装は、単にパケットのDSCPによって示されるよりも、（例えば、マイクロフロー当たり）、より細かい粒度でのキューイングおよびスケジューリングを提供するように選択することができます。このような行動は、DB PHBの定義によって排除されません。しかし、そのような行動はまた、DB PHBの定義の一部ではありません。実装者は、特徴づけると、彼らが合うように自分のDB実装のマイクロ流機能ごとの追加を公表するのは自由です。
In the absence of additional information, R is assumed to be limited by the slowest interface on the device.
付加情報の非存在下で、Rは、デバイス上の最も遅いインターフェイスによって制限されているものとします。
In addition, an DB device may be characterized by different values of R for different traffic flow scenarios (for example, for traffic aimed at different ports, total incoming R, and possibly total per output port incoming R across all incoming interfaces).
また、DB装置は、（例えば、異なるポートに向けたトラフィックのために、総着信R、およびすべての着信インターフェイスを横切って出力ポートの着信R当たりおそらく合計）は、異なるトラフィックフローのシナリオのためのRの異なる値によって特徴付けられてもよいです。
This document suggests one experimental codepoint, 101111. Because the DSCP is taken from the experimental code space, it may be re-used by other experimental or informational DiffServ proposals.
この文書では、1つの実験コードポイント、DSCPは、実験的なコード空間から取られているので、それは他の実験または情報のDiffServの提案によって再使用することができる101111.を示唆しています。
This document defines DB behavior in terms of a bound on delay variation for traffic streams that are rate shaped on ingress to a DS domain. Two parameters - capped arrival rate (R) and a 'score' (S), are defined and related to the target delay variation bound. All claims of DB 'conformance' for specific implementations of DB behavior are made with respect to particular values for R, S, and the implementation's ability to tolerate small amounts of burstiness in the arriving DB traffic stream.
この文書では、DSドメインへの進入に形率あるトラフィックストリームのための遅延変動にバインドされたという点でDBの振る舞いを定義します。二つのパラメータ - キャップされた到着レート（R）と「スコア」（S）は、定義され、結合した標的の遅延変動に関連しています。 DBの行動の具体的な実装のためのDB「適合」の全てのクレームはR、S、及び到着DBトラフィックストリームにバースト性の少量を許容する実装の能力のために特定の値に関して作られています。
Security Considerations
セキュリティの考慮事項
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all DB marked packets to a rate negotiated with the adjacent upstream domain (for example, some value less than or equal to the capped arrival rate R). Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an DB rate, the downstream domain MUST use 0 as the rate (i.e., drop all DB marked packets).
サービス拒否攻撃からそれ自体を保護するために、DSドメインのエッジは、厳密警察すべてのDBは、隣接する上流のドメイン（以下キャップされた到着レートRに等しく、例えば、いくつかの値）と交渉レートにパケットをマークしなければなりません。交渉さ率を超えたパケットは廃棄されなければなりません。隣接する二つのドメインがDB速度をネゴシエートしていない場合、下流のドメイン（すなわち、すべてのDBがパケットをマークドロップ）率として0を使用しなければなりません。
Since PDBs constructed from the DB PHB will require that the upstream domain police and shape DB marked traffic to meet the rate negotiated with the downstream domain, the downstream domain's policer should never have to drop packets. Thus these drops (or a summary of these drops) SHOULD be noted (e.g., via rate-limited SNMP traps) as possible security violations or serious misconfiguration.
DB PHBから構築のPDBは、上流のドメイン警察や形状DBは、下流のドメインと交渉率を満たすために、トラフィックをマークされている必要がありますので、下流のドメインのポリサーは、パケットを廃棄する必要はありません。したがって潜在的なセキュリティ違反または重大な設定ミスなど（例えば、レート制限されたSNMPトラップを介して）に注目すべきであるこれらの液滴（またはこれらの液滴の要約）。
Overflow events on an DB queue MAY also be logged as indicating possible denial of service attacks or serious network misconfiguration.
DBキューのオーバーフローイベントは、サービスの攻撃や重大なネットワークの設定ミスの可能性否定を示すものとして記録されることがあります。
Acknowledgments
謝辞
This document is the product of the volunteer 'EF Resolve' design team, building on the work of V. Jacobson, K. Nichols, K. Poduri [1] and clarified through discussions with members of the DiffServ working group (particularly the authors of [2]). Non-contentious text (such as the use of DB with tunnels, the security considerations, etc.) were drawn directly from equivalent text in RFC 2598.
この文書では、ボランティアV.ヤコブソン、K.ニコルズ、K. Poduriの仕事に構築する「EFの解決」デザインチーム、の積である[1]とのDiffServワーキンググループのメンバー（特に著者との議論を通じて明らかにし[2]）。 （等トンネル、セキュリティ問題とDBの使用など）、非競合のテキストは、RFC 2598の等価テキストから直接採取しました。
Intellectual Properties Considerations
知的財産に関する注意事項
To establish whether any considerations apply to the idea expressed in this document, readers are encouraged to review notices filed with the IETF and stored at:
いずれかの考察はこの文書で表現アイデアに適用されるかどうかを確立するために、読者はIETFに提出通知を確認することを奨励し、で保存されています。
http://www.ietf.org/ipr.html
ｈっｔｐ：／／ｗっｗ。いえｔｆ。おｒｇ／いｐｒ。ｈｔｍｌ
References
リファレンス
[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[1]ジェーコブソン、V.、ニコルズ、K.及びK. Poduri、 "緊急転送PHB"、RFC 2598、1999年6月。
[2] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[2]デイビー、B.、Charny、A.、ベイカー、F.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V 。、Kalmanek、C.、ラマクリシュナン、K.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）"、RFC 3246、2002年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] 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.
[4]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[5] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[5]ブラック、D.、ブレイク、S.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
Authors (volunteer EF Design Team members)
著者（ボランティアEF設計チームのメンバー）
Grenville Armitage Center for Advanced Internet Architectures Swinburne University of Technology, Melbourne, Australia EMail: garmitage@swin.edu.au
テクノロジー、メルボルン、オーストラリアの電子メールの高度なインターネットアーキテクチャスウィンバーン大学グレンヴィルアーミテージセンター：garmitage@swin.edu.au
Brian E. Carpenter (team observer, WG co-chair) IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland EMail: brian@hursley.ibm.com
ブライアンE.カーペンター（チームのオブザーバー、WG共同議長）IBMチューリッヒ研究所Saeumerstrasse 4 8803リュシュリコンスイスEメール：brian@hursley.ibm.com
Alessio Casati Lucent Technologies Swindon, WI SN5 7DJ United Kingdom EMail: acasati@lucent.com
アレッシオカザーティルーセント・テクノロジーズスウィンドン、WI SN5 7DJイギリスメールアドレス：acasati@lucent.com
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD Phone: +44 (0)1223 763633 EMail: Jon.Crowcroft@cl.cam.ac.uk
ケンブリッジの通信システム大学のジョン・クロークロフトマルコーニ教授コンピュータ研究所のウィリアム・ゲイツビルJ JトムソンアベニューケンブリッジCB3 0FD電話：+44（0）1223 763633 Eメール：Jon.Crowcroft@cl.cam.ac.uk
Joel M. Halpern P. O. Box 6049 Leesburg, VA 20178 Phone: 1-703-371-3043 EMail: jmh@joelhalpern.com
ジョエルM.ハルパーンP. O.ボックス6049リーズバーグ、VA 20178電話：1-703-371-3043 Eメール：jmh@joelhalpern.com
Brijesh Kumar Corona Networks Inc., 630 Alder Drive, Milpitas, CA 95035 EMail: brijesh@coronanetworks.com
Brijeshクマーコロナネットワークス、630アルダードライブ、ミルピタス、CA 95035 Eメール：brijesh@coronanetworks.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 EMail: john.schnizlein@cisco.com
ジョンSchnizleinシスコシステムズ9123ローラン・ロードフォートワシントン、MD 20744 Eメール：john.schnizlein@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。