[要約] RFC 3248は、RFC 2598の遅延バウンドの代替改訂案であり、遅延の制限と品質の向上を目的としています。
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 RFC 2598
RFC 2598の遅延バウンドの代替改訂
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.
Copyright（c）The Internet Society（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の元の著者が好むが、2000年12月にワーキンググループには採用されていないEFデザインチームの提案されたソリューションをキャプチャします。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を実験することを選択した場合、キーワードは「必須」、「必須」、「必須」、「しなければ」、「そうしない」、「はそうではありません」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [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]。DiffServワーキンググループのEF PHBの継続的な改良の一環として、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の新しい表現を提案しました。この情報文書の残りの部分は、2000年12月にサンディエゴIETFのDiffservワーキンググループへのフィードバックを捉えています。私たちのソリューションは、RFC 2598の元の著者の目標を達成したRFC 2598の遅延境界（DB）ベースの再発現に焦点を当てました。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の動作自体の説明的な定義を提供し、DB定義に準拠することの意味を議論し、実験的なDB PHBコードポイントを割り当てます。
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-Domainへのイングレス）で形作られなければなりません。ただし、特定のポリシングおよび/または形成ルールは、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.
デバイス（ホップ）は、1つ以上のインターフェイスで受信された適切にマークされたトラフィックにDBの動作を提供します（マーキングはセクション2.4で指定されています）。デバイスは、DBのマーク付きトラフィックミーティング（つまり、等しくない）に特定の到着レート制限RにDBの描写を提供するものとします。
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トラフィックの元のソースは形成されますが、集約と上流のジッターは、特定のホップに到着するトラフィックがそのように形成されると想定できないことを保証します。したがって、DBの実装には、爆発性に対する寛容がある必要があります - 到着率がレート制限Rを超えている場合でも、EFの動作を提供する能力。
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パケットの許容可能な（到着率RIMIT 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は、すべての私にとって、それを保証する動作として定義されます。
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は、この定義されたバウンドを満たすために、レートのデバイスの特性です。このスコアは、できれば小さな定数であり、デバイスのスケジューリングメカニズムと構成に依存します。
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、およびスコアを指定する必要があります。実装では、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.
このドキュメントでは、DB実装のR、S、または許容可能なバーストの値に関する要件を指定していません。これらのパラメーターは、設計されている実際のネットワークや目的のPDBなどの実際の考慮事項に制限されます。
One or more DiffServ codepoint (DSCP) value may be used to indicate a requirement for DB behavior [4].
DB行動の要件を示すために、1つ以上のDiffServ CodePoint（DSCP）値を使用することができます[4]。
By default we suggest an 'experimental' DSCP of 101111 be used to indicate that DB PHB is required.
デフォルトでは、DB PHBが必要であることを示すために、101111の「実験的」DSCPを使用することをお勧めします。
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.
セクション2の要件が満たされている限り、他のPHBおよびPHBグループは、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.
セクション2で与えられたDBの挙動の定義は、入力レートrと出力遅延変動D（I）-E（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動作の境界パラメーターではありません。ジッターは、たとえば、パケット間間隔から次の間隔までのパケット間時間の変動など、さまざまな方法で理解できます。ただし、DBの動作は、関連するが異なるパラメーターをバインドすることを目的としています。競合するトラフィックがない場合、および競合するトラフィックの存在下で出発する場合、時間パケット間の遅延の変動は出発します。）。
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トラフィックが複数の入力ポートから単一の出力ポートに収束しているより一般的なケースの両方をカバーしています。DBデバイスが1つのポートに到着するトラフィックに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ホップを通過するときに断片化される可能性があります。ただし、断片化の予測不可能性は、制御可能なQOを提供するという目標に大きく反しています。したがって、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つの実験的なコードポイント、101111を提案しています。DSCPは実験コード空間から取得されるため、他の実験的または情報的違い提案によって再利用される可能性があります。
5. Conclusion.
5. 結論。
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の動作を定義しています。2つのパラメーター - キャップ到着率（r）と「スコア」が定義され、ターゲット遅延変動結合に関連しています。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以下の値）。交渉レートを超えるパケットを削除する必要があります。2つの隣接するドメインがDBレートとDBレートを交渉していない場合、下流ドメインは0をレートとして使用する必要があります（つまり、すべてのDBマークされたパケットをドロップします）。
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。Jacobson、K。Nichols、K。Poduri[1]の仕事に基づいて、ボランティアの「EF Resolve」デザインチームの製品であり、Diffserv Working Groupのメンバー（特に著者の著者との議論を通じて明確になりました。[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
http://www.ietf.org/ipr.html
References
参考文献
[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[1] Jacobson、V.、Nichols、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] 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。および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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「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] Black、D.、Blake、S.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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 Rueschlikon Switzerland電子メール：brian@hursley.ibm.com
Alessio Casati Lucent Technologies Swindon, WI SN5 7DJ United Kingdom EMail: acasati@lucent.com
Alessio Casati Lucent Technologies Swindon、Wi SN5 7DJ United Kingdom Email：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電子メール：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
Joel M. Halpern P. O. Box 6049 Leesburg、VA 20178電話：1-703-371-3043メール：jmh@joelhalpern.com
Brijesh Kumar Corona Networks Inc., 630 Alder Drive, Milpitas, CA 95035 EMail: brijesh@coronanetworks.com
Brijesh Kumar Corona Networks Inc.、630 Alder Drive、Milpitas、CA 95035メール：brijesh@coronanetworks.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 EMail: john.schnizlein@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington、MD 20744メール：john.schnizlein@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。