Network Working Group B. Davie
Request for Comments: 3246 A. Charny
Obsoletes: 2598 Cisco Systems, Inc.
Category: Standards Track J.C.R. Bennett
Motorola
K. Benson
Tellabs
J.Y. Le Boudec
EPFL
W. Courtney
TRW
S. Davari
PMC-Sierra
V. Firoiu
Nortel Networks
D. Stiliadis
Lucent Technologies
March 2002
An Expedited Forwarding PHB (Per-Hop Behavior)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598.
この文書は、緊急転送（EF）と呼ばれるPHB（ホップ単位動作）を規定します。 PHBは、差別化サービスアーキテクチャの基本的なビルディングブロックです。 EFはEFの集合体は、ある設定されたレートで提供していることを保証することにより、低遅延、低ジッタ、低損失サービスのためのビルディングブロックを提供することを意図しています。この文書はRFC 2598を廃止します。
Table of Contents
目次
1 Introduction ........................................... 2
1.1 Relationship to RFC 2598 ............................... 3
2 Definition of EF PHB ................................... 3
2.1 Intuitive Description of EF ............................ 3
2.2 Formal Definition of the EF PHB ........................ 5
2.3 Figures of merit ....................................... 8
2.4 Delay and jitter ....................................... 8
2.5 Loss ................................................... 9
2.6 Microflow misordering .................................. 9
2.7 Recommended codepoint for this PHB ..................... 9
2.8 Mutability ............................................. 10
2.9 Tunneling .............................................. 10
2.10 Interaction with other PHBs ............................ 10
3 Security Considerations ................................ 10
4 IANA Considerations .................................... 11
5 Acknowledgments ........................................ 11
6 References ............................................. 11
Appendix: Implementation Examples .............................. 12
Authors' Addresses ............................................. 14
Full Copyright Statement ....................................... 16
Network nodes that implement the differentiated services enhancements to IP use a codepoint in the IP header to select a per-hop behavior (PHB) as the specific forwarding treatment for that packet [3, 4]. This memo describes a particular PHB called expedited forwarding (EF).
IPに差別化サービスの強化を実現するネットワーク・ノードは、そのパケットのための特定の転送処理としてホップ単位動作（PHB）を選択するためにIPヘッダーでコードポイントを使用する[3、4]。このメモは優先転送（EF）と呼ばれる特定のPHBを説明しています。
The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services. The details of exactly how to build such services are outside the scope of this specification.
EF PHBの目的は、低損失、低遅延、低ジッタのサービスのためのビルディングブロックを提供することです。このようなサービスを構築するため、正確に方法の詳細は、この仕様の範囲外です。
The dominant causes of delay in packet networks are fixed propagation delays (e.g. those arising from speed-of-light delays) on wide area links and queuing delays in switches and routers. Since propagation delays are a fixed property of the topology, delay and jitter are minimized when queuing delays are minimized. In this context, jitter is defined as the variation between maximum and minimum delay. The intent of the EF PHB is to provide a PHB in which suitably marked packets usually encounter short or empty queues. Furthermore, if queues remain short relative to the buffer space available, packet loss is also kept to a minimum.
パケットネットワークにおける遅延の支配的な原因は、伝播遅延を固定されている（例えば速度の光遅延に起因するもの）、ワイド・エリア・リンク上で、スイッチやルータの遅延キューイング。伝搬遅延は、キューイング遅延が最小化されるときに最小化されるトポロジ、遅延およびジッタの固定資産であるからです。この文脈では、ジッタは、最大と最小遅延との間の変化として定義されます。 EF PHBの目的は、適切にマークされたパケットは、通常は短いか、空のキューに遭遇したPHBを提供することです。キューが使用可能なバッファ空間に短い相対残っている場合また、パケット損失も最小限に抑えられます。
To ensure that queues encountered by EF packets are usually short, it is necessary to ensure that the service rate of EF packets on a given output interface exceeds their arrival rate at that interface over long and short time intervals, independent of the load of other (non-EF) traffic. This specification defines a PHB in which EF packets are guaranteed to receive service at or above a configured rate and provides a means to quantify the accuracy with which this service rate is delivered over any time interval. It also provides a means to quantify the maximum delay and jitter that a packet may experience under bounded operating conditions.
EFパケットが遭遇そのキューが通常短い確保するためには、与えられた出力インタフェース上のEFパケットのサービス率は（他の負荷とは無関係に、長い及び短い時間間隔にわたって、その界面での到着レートを超えることを保証する必要があります非EF）トラフィック。この仕様は、EFパケットが設定されたレートで、または上記のサービスを受けることが保証されたPHBを定義し、このサービスのレートは、任意の時間間隔にわたって配信される精度を定量化する手段を提供します。それはまた、パケットが有界動作条件下で発生する可能性が最大遅延およびジッタを定量化する手段を提供します。
Note that the EF PHB only defines the behavior of a single node. The specification of behavior of a collection of nodes is outside the scope of this document. A Per-Domain Behavior (PDB) specification [7] may provide such information.
EF PHBは、単一ノードの動作を定義することに留意されたいです。ノードの集合の挙動の仕様は、この文書の範囲外です。パードメイン行動（PDB）仕様[7]そのような情報を提供してもよいです。
When a DS-compliant node claims to implement the EF PHB, the implementation MUST conform to the specification given in this document. However, the EF PHB is not a mandatory part of the Differentiated Services architecture - a node is NOT REQUIRED to implement the EF PHB in order to be considered DS-compliant.
DS対応ノードがEFのPHBを実装するために主張する場合、実装は、この文書で与えられる仕様に準拠しなければなりません。しかし、EF PHBは、差別化サービスアーキテクチャの必須部分ではありません - ノードはDS準拠と見なされるためにEFのPHBを実装する必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
This document replaces RFC 2598 [1]. The main difference is that it adds mathematical formalism to give a more rigorous definition of the behavior described. The full rationale for this is given in [6].
この文書は、RFC 2598を置き換える[1]。主な違いは、それが説明した動作のより厳密な定義を与えるために、数学的形式主義を追加することです。このため、完全な理論的根拠は、[6]に記載されています。
Intuitively, the definition of EF is simple: the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface. Two difficulties arise when we try to formalize this intuition:
直感的に、EFの定義は単純である：EFトラフィックが所定の出力インタフェースで提供される速度は、そのインターフェイスに非EFトラフィックの提供負荷とは無関係に、適切に定義された間隔で、少なくとも設定されたレートRであるべきです。私たちは、この直観を形式化しようとすると、二つの問題が発生します：
- it is difficult to define the appropriate timescale at which to measure R. By measuring it at short timescales we may introduce sampling errors; at long timescales we may allow excessive jitter.
- 我々がサンプリング誤差を導入することができる短い時間スケールでそれを測定することによりRを測定するために、どので、適切なタイムスケールを定義することは困難です。長い時間スケールで、我々は過度のジッタを可能にすることができます。
- EF traffic clearly cannot be served at rate R if there are no EF packets waiting to be served, but it may be impossible to determine externally whether EF packets are actually waiting to be served by the output scheduler. For example, if an EF packet has entered the router and not exited, it may be awaiting service, or it may simply have encountered some processing or transmission delay within the router.
- 提供されるのを待って何のEFパケットが存在しない場合はEFトラフィックが明確にレートRで提供することはできませんが、EFパケットが実際に出力スケジューラによって提供されるのを待っているかどうかを外部から決定することは不可能かもしれません。 EFパケットがルータに入り、出ていない場合、例えば、それがサービスを待ってもよいし、またはそれは単にルータ内のいくつかの処理または伝送遅延に遭遇している可能性があります。
The formal definition below takes account of these issues. It assumes that EF packets should ideally be served at rate R or faster, and bounds the deviation of the actual departure time of each packet from the "ideal" departure time of that packet. We define the departure time of a packet as the time when the last bit of that packet leaves the node. The "ideal" departure time of each EF packet is computed iteratively.
以下の正式な定義は、これらの問題を考慮しました。これは、EFパケットは、理想的には、レートRまたはより高速で提供し、そのパケットの「理想的」出発時刻から、各パケットの実際の出発時刻のずれを境界とする必要があることを前提としています。私たちは、そのパケットの最後のビットは、ノードを去る時、パケットの出発時刻を定義します。各EFパケットの「理想」の出発時間が反復的に計算されます。
In the case when an EF packet arrives at a device when all the previous EF packets have already departed, the computation of the ideal departure time is simple. Service of the packet should (ideally) start as soon as it arrives, so the ideal departure time is simply the arrival time plus the ideal time to transmit the packet at rate R. For a packet of length L_j, that transmission time at the configured rate R is L_j/R. (Of course, a real packet will typically get transmitted at line rate once its transmission actually starts, but we are calculating the ideal target behavior here; the ideal service takes place at rate R.)
EFパケットは、以前のすべてのEFパケットがすでに出発しているデバイスに到着した場合には、理想的な出発時刻の計算は簡単です。それが到着すると、パケットのサービスは、（理想的には）とすぐに開始する必要がありますので、理想的な出発時刻は、単に到着時間を加えた長さL_j、構成されたその送信時間のパケットのレートR.でパケットを送信するのに理想的な時間です率RはL_j / Rです。 （;理想的なサービスは、料金R.で行われ、その送信が実際に開始しますが、我々はここで、理想的なターゲットの挙動を計算されればもちろん、実際のパケットは、通常、ラインレートで送信されます）
In the case when an EF packet arrives at a device that still contains EF packets awaiting service, the computation of the ideal departure time is more complicated. There are two cases to be considered. If the previous (j-1-th) departure occurred after its own ideal departure time, then the scheduler is running "late". In this case, the ideal time to start service of the new packet is the ideal departure time of the previous (j-1-th) packet, or the arrival time of the new packet, whichever is later, because we cannot expect a packet to begin service before it arrives. If the previous (j-1-th) departure occurred before its own ideal departure time, then the scheduler is running "early". In this case, service of the new packet should begin at the actual departure time of the previous packet.
EFパケットは、まだサービスを待っているEFパケットが含まれているデバイスに到着した場合には、理想的な出発時刻の計算はより複雑です。考慮すべき2つのケースがあります。前回（J-1番目）の出発は、自身の理想的な出発時刻の後に発生した場合は、スケジューラは「遅い」実行されています。私たちは、パケットを期待することはできませんので、この場合は、新しいパケットのサービスを開始するのに理想的な時間は、いずれか遅い前回（J-1番目）のパケット、または新しいパケットの到着時間の理想的な出発時刻でありますそれが到着する前にサービスを開始します。前回（J-1番目）の出発は、自身の理想的な出発時刻前に発生した場合、スケジューラは、「早期に」実行されています。この場合は、新しいパケットのサービスは、前のパケットの実際の出発時刻に開始すべきです。
Once we know the time at which service of the j-th packet should (ideally) begin, then the ideal departure time of the j-th packet is L_j/R seconds later. Thus we are able to express the ideal departure time of the j-th packet in terms of the arrival time of the j-th packet, the actual departure time of the j-1-th packet, and the ideal departure time of the j-1-th packet. Equations eq_1 and eq_2 in Section 2.2 capture this relationship.
我々はj番目のパケットのサービスは、（理想的に）開始する時刻を知ったら、その後、j番目のパケットの理想的な出発時刻は、後でL_j / R秒です。したがって、私たちは、j番目のパケットの到着時間の面でJ-1番目のパケットの実際の出発時刻をj番目のパケットの理想的な出発時刻を表現することができ、かつ、jの理想的な出発時刻-1番目のパケット。式はeq_1と2.2節でeq_2は、この関係を捉えます。
Whereas the original EF definition did not provide any means to guarantee the delay of an individual EF packet, this property may be desired. For this reason, the equations in Section 2.2 consist of two parts: an "aggregate behavior" set and a "packet-identity-aware" set of equations. The aggregate behavior equations (eq_1 and eq_2) simply describe the properties of the service delivered to the EF aggregate by the device. The "packet-identity-aware" equations (eq_3 and eq_4) enable the bound on delay of an individual packet to be calculated given a knowledge of the operating conditions of the device. The significance of these two sets of equations is discussed further in Section 2.2. Note that these two sets of equations provide two ways of characterizing the behavior of a single device, not two different modes of behavior.
オリジナルのEFの定義は、個々のEFパケットの遅延を保証するためにあらゆる手段を提供しなかったのに対し、このプロパティは、所望され得ます。 「凝集挙動」に設定し、方程式の「パケット識別認識」セット：この理由のために、2.2節での式は、2つの部分から成ります。凝集挙動式（eq_1とeq_2）単にデバイスによってEF集合に配信サービスのプロパティを記述する。 「パケット・アイデンティティ認識」式（eq_3とeq_4）は、デバイスの動作状態の知識を与えられた計算する個々のパケットの遅延に結合可能。方程式のこれら二組の重要性は、2.2節で詳しく説明されています。方程式のこれらの二つのセットが単一のデバイスではなく、行動の2つの異なるモードの挙動を特徴づけるの二つの方法を提供することに留意されたいです。
A node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
いくつかの構成比率Rの界面IにEFをサポートノードは、以下の式を満足しなければなりません。
d_j <= f_j + E_a for all j > 0 (eq_1)
d_j 0（eq_1）<= F_J + E_Aすべてのjについて>
where f_j is defined iteratively by
F_Jはで反復的に定義され、
f_0 = 0, d_0 = 0
F_0 = 0、D_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2)
全てのj> 0（eq_2）用F_J = MAX（a_j、分（d_j-1、F_J-1））+ l_j / R、
In this definition:
この定義には：
- d_j is the time that the last bit of the j-th EF packet to depart actually leaves the node from the interface I.
- d_jはj番目のEFパケットの最後のビットが出発すること時間は、実際にはインターフェースIからノードを残しています
- f_j is the target departure time for the j-th EF packet to depart from I, the "ideal" time at or before which the last bit of that packet should leave the node.
- F_JはI、そのパケットの最後のビットは、ノードを離れなければならないのか、前に「理想的な」時間から逸脱するj番目のEFパケットのターゲット出発時刻です。
- a_j is the time that the last bit of the j-th EF packet destined to the output I actually arrives at the node.
- a_jは、j番目のEFパケットの最後のビットは、私が実際にノードに到着出力に宛てている時間です。
- l_j is the size (bits) of the j-th EF packet to depart from I. l_j is measured on the IP datagram (IP header plus payload) and does not include any lower layer (e.g. MAC layer) overhead.
- l_j I.のl_j逸脱するj番目のEFパケットのサイズ（ビット）は、IPデータグラム（IPヘッダーとペイロード）で測定され、任意の下位層（例えばMAC層）オーバーヘッドを含みません。
- R is the EF configured rate at output I (in bits/second).
- Rは、I（ビット/秒）出力でEF設定されたレートです。
- E_a is the error term for the treatment of the EF aggregate. Note that E_a represents the worst case deviation between the actual departure time of an EF packet and the ideal departure time of the same packet, i.e. E_a provides an upper bound on (d_j - f_j) for all j.
- E_Aは、EF集合体の治療のための誤差項です。すべてのjについて - E_AがEFパケットの実際の出発時間と同じパケットの理想的な出発時刻との間の最悪の場合の偏差を表している、すなわちE_Aは（F_J d_j）の上限を提供します。
- d_0 and f_0 do not refer to a real packet departure but are used purely for the purposes of the recursion. The time origin should be chosen such that no EF packets are in the system at time 0.
- D_0とF_0は、実際のパケット出発を参照しませんが、再帰の目的のために純粋に使用されています。時間原点にはEFパケットが時間0でシステムにないように選択すべきです。
- for the definitions of a_j and d_j, the "last bit" of the packet includes the layer 2 trailer if present, because a packet cannot generally be considered available for forwarding until such a trailer has been received.
- 存在する場合、パケットは、一般に、トレーラが受信されるまで転送するために使用可能と考えることができないのでa_jとd_jの定義については、パケットの「最後のビットが」レイヤ2トレーラを含みます。
An EF-compliant node MUST be able to be characterized by the range of possible R values that it can support on each of its interfaces while conforming to these equations, and the value of E_a that can be met on each interface. R may be line rate or less. E_a MAY be specified as a worst-case value for all possible R values or MAY be expressed as a function of R.
EF準拠のノードは、これらの式に準拠しながら、そのインターフェースのそれぞれにサポートすることができる可能なR値の範囲、及び各インタフェース上で満たすことができるE_Aの値によって特徴付けることができなければなりません。 Rは、回線速度以下であってもよいです。 E_Aは、すべての可能なR値に対する最悪の場合の値として指定してもよく、またはRの関数として表すことができます
Note also that, since a node may have multiple inputs and complex internal scheduling, the j-th EF packet to arrive at the node destined for a certain interface may not be the j-th EF packet to depart from that interface. It is in this sense that eq_1 and eq_2 are unaware of packet identity.
ノードは、複数の入力と複雑な内部スケジューリングを有することができるので、また、その注意、j番目のEFパケットは、そのインターフェイスから逸脱するj番目のEFパケットではないかもしれない特定のインターフェイスに宛てノードに到達します。それはeq_1とeq_2は、パケットのIDを知らないこの意味です。
In addition, a node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
加えて、いくつかの設定されたレートRで、界面IでEFをサポートノードは、以下の式を満足しなければなりません。
D_j <= F_j + E_p for all j > 0 (eq_3)
D_j 0（eq_3）<= F_J + E_pすべてのjについて>
where F_j is defined iteratively by
F_Jはで反復的に定義され、
F_0 = 0, D_0 = 0
F_0 = 0、D_0 = 0
F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4)
F_J = MAX（A_j、分（D_j-1、F_J-1））+ L_j / R、全てのj> 0（eq_4）用
In this definition:
この定義には：
- D_j is the actual departure time of the individual EF packet that arrived at the node destined for interface I at time A_j, i.e., given a packet which was the j-th EF packet destined for I to arrive at the node via any input, D_j is the time at which the last bit of that individual packet actually leaves the node from the interface I.
- D_jは、私は、任意の入力を介してノードに到着する宛j番目のEFパケットたパケット与えられ、すなわちA_j時インターフェイスIを宛先ノードに到着した個々のEFパケットの実際の出発時間でありますD_jは、個々のパケットの最後のビットが実際に界面Iからノードを離れた時間であります
- F_j is the target departure time for the individual EF packet that arrived at the node destined for interface I at time A_j.
- F_Jは時間A_jでインタフェースI宛てのノードに到着した個々のEFパケットのターゲット出発時刻です。
- A_j is the time that the last bit of the j-th EF packet destined to the output I to arrive actually arrives at the node.
- A_jは私が到着する出力宛てのj番目のEFパケットの最後のビットが実際にノードに到着する時間です。
- L_j is the size (bits) of the j-th EF packet to arrive at the node that is destined to output I. L_j is measured on the IP datagram (IP header plus payload) and does not include any lower layer (e.g. MAC layer) overhead.
- L_j出力I. L_jを宛先とするノードに到達するj番目のEFパケットのサイズ（ビット）は、IPデータグラム（IPヘッダーとペイロード）で測定され、任意の下位層（例えばMACが含まれていません層）のオーバーヘッド。
- R is the EF configured rate at output I (in bits/second).
- Rは、I（ビット/秒）出力でEF設定されたレートです。
- E_p is the error term for the treatment of individual EF packets. Note that E_p represents the worst case deviation between the actual departure time of an EF packet and the ideal departure time of the same packet, i.e. E_p provides an upper bound on (D_j - F_j) for all j.
- E_pは、個々のEFパケットの処理のための誤差項です。すべてのjについて - E_p、すなわちE_p、EFパケットの実際の出発時間と同じパケットの理想的な出発時刻との間の最悪の場合の偏差を表す（F_J D_j）の上限を提供することに留意されたいです。
- D_0 and F_0 do not refer to a real packet departure but are used purely for the purposes of the recursion. The time origin should be chosen such that no EF packets are in the system at time 0.
- D_0とF_0は、実際のパケット出発を参照しませんが、再帰の目的のために純粋に使用されています。時間原点にはEFパケットが時間0でシステムにないように選択すべきです。
- for the definitions of A_j and D_j, the "last bit" of the packet includes the layer 2 trailer if present, because a packet cannot generally be considered available for forwarding until such a trailer has been received.
- 存在する場合、パケットは、一般に、トレーラが受信されるまで転送するために使用可能と考えることができないのでA_jとD_jの定義については、パケットの「最後のビットが」レイヤ2トレーラを含みます。
It is the fact that D_j and F_j refer to departure times for the j-th packet to arrive that makes eq_3 and eq_4 aware of packet identity. This is the critical distinction between the last two equations and the first two.
j番目のパケットはそれがeq_3を行い、パケットのアイデンティティを意識eq_4到着するためD_jとF_Jは、出発時刻を参照しているという事実です。これは、最後の二つの式と最初の二つの間の重要な違いです。
An EF-compliant node SHOULD be able to be characterized by the range of possible R values that it can support on each of its interfaces while conforming to these equations, and the value of E_p that can be met on each interface. E_p MAY be specified as a worst-case value for all possible R values or MAY be expressed as a function of R. An E_p value of "undefined" MAY be specified. For discussion of situations in which E_p may be undefined see the Appendix and [6].
EF準拠のノードは、これらの式に準拠しながら、そのインターフェースのそれぞれにサポートすることができる可能なR値の範囲、及び各インタフェース上で満たすことができるE_pの値によって特徴付け可能であるべきです。 E_pは、すべての可能なR値に対する最悪の場合の値として指定してもよく、または「未定義」のR.アンE_p値の関数を指定することができるように表すことができます。 E_pが未定義であってもよい状況の議論は、付録と参照[6]。
For the purposes of testing conformance to these equations, it may be necessary to deal with packet arrivals on different interfaces that are closely spaced in time. If two or more EF packets destined for the same output interface arrive (on different inputs) at almost the same time and the difference between their arrival times cannot be measured, then it is acceptable to use a random tie-breaking method to decide which packet arrived "first".
これらの式への適合性をテストする目的のために、密接に時間的に離間された異なるインタフェース上でのパケット到着に対処する必要があるかもしれません。同じ出力インタフェース宛二つ以上のEFパケットがほぼ同時に（異なる入力に）到着し、その到着時間の差を測定することができない場合、決定するランダムタイブレーク方式を使用する許容されたパケット「最初」に到着。
E_a and E_p may be thought of as "figures of merit" for a device. A smaller value of E_a means that the device serves the EF aggregate more smoothly at rate R over relatively short timescales, whereas a larger value of E_a implies a more bursty scheduler which serves the EF aggregate at rate R only when measured over longer intervals. A device with a larger E_a can "fall behind" the ideal service rate R by a greater amount than a device with a smaller E_a.
E_AとE_pは、デバイスの「性能指数」と考えることができます。 E_Aの値が小さいほどE_Aの大きな値はより長い間隔にわたって測定のみレートRでEF集合体を提供していますより多くのバーストスケジューラを意味し、一方、デバイスは、比較的短い時間スケール上レートRでより円滑EF集合体の役割を果たすことを意味します。大きなE_A有するデバイスは、より小さいE_A有するデバイスよりも大きな量だけ、理想的なサービスレートR「の後ろに落ちる」ことができます。
A lower value of E_p implies a tighter bound on the delay experienced by an individual packet. Factors that might lead to a higher E_p might include a large number of input interfaces (since an EF packet might arrive just behind a large number of EF packets that arrived on other interfaces), or might be due to internal scheduler details (e.g. per-flow scheduling within the EF aggregate).
E_pの低い値は、個々のパケットが経験する遅延に緊密結合したことを意味します。より高いE_pにつながる可能性がある要因は（（EFパケットがちょうど他のインターフェースに到着EFパケットの多数の後ろに到着する可能性があるので）入力インターフェイスの多数が含まれる場合があり、又は内部スケジューラ詳細に起因するかもしれない例えばパー）EFの集計内のスケジューリングを流れます。
We observe that factors that increase E_a such as those noted above will also increase E_p, and that E_p is thus typically greater than or equal to E_a. In summary, E_a is a measure of deviation from ideal service of the EF aggregate at rate R, while E_p measures both non-ideal service and non-FIFO treatment of packets within the aggregate.
我々は、上述のもののようなE_Aを増やす要因もE_pを増加させ、E_pは、このように一般的により大きいかまたはE_Aに等しくなるであろうことを観察します。 E_p措置の両方集約内のパケットの非理想的なサービスと非FIFO治療しながら要約すると、E_Aは、レートRでEF集合体の理想的なサービスからの偏差の尺度です。
For more discussion of these issues see the Appendix and [6].
これらの問題の多くの議論については、付録を参照してくださいし、[6]。
Given a known value of E_p and a knowledge of the bounds on the EF traffic offered to a given output interface, summed over all input interfaces, it is possible to bound the delay and jitter that will be experienced by EF traffic leaving the node via that interface. The delay bound is
全ての入力インターフェイス上で合計、E_pの既知の値と所定の出力インタフェースに提供EFトラフィック上の境界の知識を与えられ、その介してノードを残しEFトラフィックによって経験される遅延およびジッタを結合することが可能ですインタフェース。遅延限界があります
D = B/R + E_p (eq_5)
D = B / R + E_p（eq_5）
where
どこ
- R is the configured EF service rate on the output interface
- Rは、出力インターフェイスに構成されたEFサービスレートであります
- the total offered load of EF traffic destined to the output interface, summed over all input interfaces, is bounded by a token bucket of rate r <= R and depth B
- 出力インタフェース宛EFトラフィックの総提供負荷は、レートr <= R及び深さBのトークンバケットによって制限され、全ての入力インターフェイス上で合計します
Since the minimum delay through the device is clearly at least zero, D also provides a bound on jitter. To provide a tighter bound on jitter, the value of E_p for a device MAY be specified as two separate components such that
装置を通る最小遅延が少なくともゼロ明らかであるので、Dはまた、ジッタ上の結合を提供します。ジッタに結合タイトを提供するために、デバイスのためのE_pの値は、そのような2つの別個の構成要素として指定することができます
E_p = E_fixed + E_variable
E_p = E_fixed + E_variable
where E_fixed represents the minimum delay that can be experienced by an EF packet through the node.
E_fixedノードを通じてEFパケットが経験することができる最小の遅延を表します。
The EF PHB is intended to be a building block for low loss services. However, under sufficiently high load of EF traffic (including unexpectedly large bursts from many inputs at once), any device with finite buffers may need to discard packets. Thus, it must be possible to establish whether a device conforms to the EF definition even when some packets are lost. This is done by performing an "off-line" test of conformance to equations 1 through 4. After observing a sequence of packets entering and leaving the node, the packets which did not leave are assumed lost and are notionally removed from the input stream. The remaining packets now constitute the arrival stream (the a_j's) and the packets which left the node constitute the departure stream (the d_j's). Conformance to the equations can thus be verified by considering only those packets that successfully passed through the node.
EF PHBは、低損失のサービスのためのビルディングブロックであることを意図しています。しかし、EFトラフィックの十分に高い負荷の下で（一度に多くの入力から予想外に大バーストを含む）、有限バッファを持つ任意のデバイスは、パケットを廃棄する必要があるかもしれません。したがって、デバイスはいくつかのパケットが失われた場合でも、EF定義に準拠しているかどうかを確立することが可能でなければなりません。これは4を介して1ノードに入り、出るパケットのシーケンスを観察した後、残さなかったパケットが失われたと仮定され、概念的に入力ストリームから除去される式への適合の「オフライン」テストを実行することによって行われます。残りのパケットは、現在到着ストリーム（a_j年代）を構成し、ノードを左パケットが出発ストリーム（d_j年代）を構成します。式への適合は、このように正常にノードを通過したパケットのみを考慮することによって確認することができます。
In addition, to assist in meeting the low loss objective of EF, a node MAY be characterized by the operating region in which loss of EF due to congestion will not occur. This MAY be specified, using a token bucket of rate r <= R and burstsize B, as the sum of traffic across all inputs to a given output interface that can be tolerated without loss.
加えて、EFの低損失目的を満たすのを助けるために、ノードは、輻輳のEFの損失が発生しないれる運転領域によって特徴づけることができます。これは、損失なしに許容できる所定の出力インターフェイスへのすべての入力間のトラフィックの合計として率r <= Rとburstsize Bのトークンバケットを使用して、指定されてもよいです。
In the event that loss does occur, the specification of which packets are lost is beyond the scope of this document. However it is a requirement that those packets not lost MUST conform to the equations of Section 2.2.
損失が発生した場合には、パケットが失われているの仕様は、このドキュメントの範囲を超えています。しかし、それが失われていない、これらのパケットは、セクション2.2の方程式に従わなければならないという要件です。
Packets belonging to a single microflow within the EF aggregate passing through a device SHOULD NOT experience re-ordering in normal operation of the device.
デバイスを通過するEFの集約内の単一マイクロフローに属するパケットは、デバイスの正常な動作に並べ替えを経験するべきではありません。
Codepoint 101110 is RECOMMENDED for the EF PHB.
コードポイント101110は、EF PHBをお勧めします。
Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
EF PHBのためにマークされたパケットは、唯一のEF PHBを満たす他のコードポイントにDSドメイン境界で述べられるかもしれません。 EFのPHBのためにマークされたパケットは、降格またはDSドメインで別のPHBに昇格されるべきではありません。
When EF packets are tunneled, the tunneling packets SHOULD be marked as EF. A full discussion of tunneling issues is presented in [5].
EFパケットがトンネリングされている場合、トンネリングパケットはEFとしてマークする必要があります。トンネリングの問題の完全な議論は[5]に提示されています。
Other PHBs and PHB groups may be deployed in the same DS node or domain with the EF PHB. The equations of Section 2.2 MUST hold for a node independent of the amount of non-EF traffic offered to it.
他のPHBおよびPHBグループは、EF PHBと同じDSノードまたはドメインに配備されてもよいです。セクション2.2の式は、それに提供される非EFトラフィックの量の、ノード独立のために保持しなければなりません。
If the EF 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 EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).
EF PHBは、他のトラフィック（例えば、プライオリティキュー）の無制限のプリエンプションを可能にするメカニズムによって実装されている場合、実装は、他のトラフィックに与える可能性が損傷EFトラフィックを制限するためにいくつかの手段を含まなければならない（例えば、トークンバケットレートリミッタ） 。この制限を超えるトラフィックは捨てなければなりません。この最大EFレート、バーストサイズ適切な場合には、（ノードは、不揮発性コンフィギュレーションのためのサポート何らかのメカニズムを使用して）ネットワーク管理者によって設定可能でなければなりません。
To protect itself against denial of service attacks, the edge of a DS domain SHOULD strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. Packets in excess of the negotiated rate SHOULD be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain SHOULD use 0 as the rate (i.e., drop all EF marked packets).
サービス拒否攻撃から自身を保護するために、DSドメインのエッジは、厳密に警察のすべてのEFは、隣接する上流のドメインと交渉レートにパケットをマークすべきです。交渉さ率を超えたパケットは廃棄されるべきです。隣接する二つのドメインがEF率を交渉していない場合、下流のドメイン（すなわち、すべてのEFマーキングされたパケットをドロップ）率として0を使用すべきです。
In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. Such behavior is as required by the Differentiated Services architecture [4]. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any Traffic Conditioning Specification provisioned at an ingress interface, but which map to EF inside the DS-domain.
また、DS-ドメインに入口におけるトラフィック調整は、それらがDSドメインを入力したときにEF PHBに対応するのDSCPを持つパケットだけがDSドメインの内部EFに対応するDSCPでマークされていることを確認しなければなりません。そのような挙動は、差別化サービスアーキテクチャによって必要とされる[4]。これは、サービス拒否（DoS）から保護し、任意のトラフィックコンディショニング仕様で識別されていないのDSCPを利用するサービスの窃盗攻撃は、入力インターフェイスでプロビジョニングが、DSドメイン内のEFにマッピングされました。
This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [3].
この文書では、[3]で定義されたコード空間のプール1において、1つのコードポイント、101110を割り当てます。
This document was the result of collaboration and discussion among a large number of people. In particular, Fred Baker, Angela Chiu, Chuck Kalmanek, and K. K. Ramakrishnan made significant contributions to the new EF definition. John Wroclawski provided many helpful comments to the authors. This document draws heavily on the original EF PHB definition of Jacobson, Nichols, and Poduri. It was also greatly influenced by the work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, Kumar, and Schnizlein.
この文書では、多くの人々の間でのコラボレーションや議論の結果でした。具体的には、フレッド・ベイカー、アンジェラ・チウ、チャックKalmanek、およびK. K.ラマクリシュナンは、新たなEF定義に重要な貢献をしました。ジョンWroclawskiは作者に多くの有益なコメントを提供しました。この文書では、ヤコブソン、ニコルズ、およびPoduriの元EF PHBの定義に大きく描画します。それはまた大幅アーミテージ、カザーティ、クロウクロフト、ハルパーン、クマー、およびSchnizleinのEFRESOLVEチームの作業に影響を受けました。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] 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.
[3]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[4]ブラック、D.、ブレイク、S.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[5]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[6] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[6] Charny、A.、ベイカー、F.、デイビー、B.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V 。、Kalmanek、C.、ラマクリシュナン、KKそして、D. Stiliadis、「EFのPHBの新しい定義（優先転送ホップ単位動作）のための補足情報」、RFC 3247、2002年3月。
[7] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[7]ニコルズK.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
Appendix: Implementation Examples
付録：実装例
This appendix is not part of the normative specification of EF. However, it is included here as a possible source of useful information for implementors.
この付録では、EFの規範的な仕様の一部ではありません。しかし、実装のための有用な情報源の可能性として、ここに含まれています。
A variety of factors in the implementation of a node supporting EF will influence the values of E_a and E_p. These factors are discussed in more detail in [6], and include both output schedulers and the internal design of a device.
EFをサポートするノードの実装に様々な要因がE_AとE_pの値に影響を与えます。これらの要因は、[6]で詳しく説明し、出力スケジューラと装置の内部設計の両方が含まれます。
A priority queue is widely considered as the canonical example of an implementation of EF. A "perfect" output buffered device (i.e. one which delivers packets immediately to the appropriate output queue) with a priority queue for EF traffic will provide both a low E_a and a low E_p. We note that the main factor influencing E_a will be the inability to pre-empt an MTU-sized non-EF packet that has just begun transmission at the time when an EF packet arrives at the output interface, plus any additional delay that might be caused by non-pre-emptable queues between the priority queue and the physical interface. E_p will be influenced primarily by the number of interfaces.
プライオリティキューが広くEFの実装の標準的な例として考えられます。 EFトラフィックのプライオリティキューと「完全な」出力緩衝装置（適切な出力キューに直ちにパケットを配信すなわち、1種）は、低E_A及び低E_pの両方を提供するであろう。私たちは、E_Aに影響を与える主な要因は、EFパケットが出力インターフェイスに到着する時間だけで送信を開始しているMTUサイズの非EFパケットを横取りすることができない、プラス生じる可能性のある追加の遅延になることに注意してくださいプライオリティキューと物理インターフェイス間の非事前emptableキューによります。 E_pは、主インターフェースの数によって影響されるであろう。
Another example of an implementation of EF is a weighted round robin scheduler. Such an implementation will typically not be able to support values of R as high as the link speeds, because the maximum rate at which EF traffic can be served in the presence of competing traffic will be affected by the number of other queues and the weights given to them. Furthermore, such an implementation is likely to have a value of E_a that is higher than a priority queue implementation, all else being equal, as a result of the time spent serving non-EF queues by the round robin scheduler.
EFの実施のもう一つの例は、重み付けラウンドロビンスケジューラです。 EFトラフィックが競合トラフィックの存在下で提供することができる最大レートは、他のキューの数と所定の重みによって影響されるので、このような実装は、典型的には、リンク速度と高いRの値をサポートすることができません彼らへ。さらに、このような実装では、プライオリティキューの実装よりも高くなっているE_Aの価値を持っている可能性があるすべての時間の結果は、ラウンドロビンスケジューラによって非EFキューにサービスを提供費やしたとして他、等しいです。
Finally, it is possible to implement hierarchical scheduling algorithms, such that some non-FIFO scheduling algorithm is run on sub-flows within the EF aggregate, while the EF aggregate as a whole could be served at high priority or with a large weight by the top-level scheduler. Such an algorithm might perform per-input scheduling or per-microflow scheduling within the EF aggregate, for example. Because such algorithms lead to non-FIFO service within the EF aggregate, the value of E_p for such algorithms may be higher than for other implementations. For some schedulers of this type it may be difficult to provide a meaningful bound on E_p that would hold for any pattern of traffic arrival, and thus a value of "undefined" may be most appropriate.
最後に、全体としてのEF集合体により高い優先度で、または大重量で配信することができるが、いくつかの非FIFOスケジューリングアルゴリズムは、EF集合内のサブフローで実行されるように、階層的なスケジューリング・アルゴリズムを実装することが可能ですトップレベルのスケジューラ。そのようなアルゴリズムは、例えば、EF集合内の単位の入力スケジューリング又はごとマイクロスケジューリングを行う可能性があります。そのようなアルゴリズムは、EF集合内の非FIFOサービスにつながるので、このようなアルゴリズムのE_pの値は、他の実装よりも高くてもよいです。このタイプのいくつかのスケジューラのためには、トラフィック到着のいずれかのパターンのために開催するものE_pに意味のあるバウンドを提供することは困難であるため、「未定義」の値が最も適切であるかもしれません。
It should be noted that it is quite acceptable for a Diffserv domain to provide multiple instances of EF. Each instance should be characterizable by the equations in Section 2.2 of this specification. The effect of having multiple instances of EF on the E_a and E_p values of each instance will depend considerably on how the multiple instances are implemented. For example, in a multi-level priority scheduler, an instance of EF that is not at the highest priority may experience relatively long periods when it receives no service while higher priority instances of EF are served. This would result in relatively large values of E_a and E_p. By contrast, in a WFQ-like scheduler, each instance of EF would be represented by a queue served at some configured rate and the values of E_a and E_p could be similar to those for a single EF instance.
DiffservのドメインがEFの複数のインスタンスを提供することは非常に許容可能であることに留意すべきです。各インスタンスは、本明細書の2.2節での式によって特徴付けなければなりません。各インスタンスのE_AとE_p値にEFの複数のインスタンスを有することの効果は、複数のインスタンスが実装されている方法にかなり依存します。 EFの優先度の高いインスタンスが配信されている間、それがサービスを受信しない場合、例えば、マルチレベル優先スケジューラで、最高の優先順位ではないEFのインスタンスは、比較的長い期間を経験するかもしれません。これはE_AとE_pの比較的大きな値になるでしょう。対照的に、WFQ状スケジューラにおいて、EFの各インスタンスは、キューは、いくつかの構成割合で提供することによって表現されるとE_AとE_pの値は、単一EFインスタンスのものと同様であってもよいです。
Authors' Addresses
著者のアドレス
Bruce Davie Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA, 01824
ブルース・デイビーシスコシステムズ社300アポロドライブチェルムズフォード、MA、01824
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
アンナCharnyシスコシステムズ300アポロドライブチェルムズフォード、MA 01824
EMail: acharny@cisco.com
メールアドレス：acharny@cisco.com
Jon Bennett Motorola 3 Highwood Drive East Tewksbury, MA 01876
ジョン・ベネットモトローラ3ハイウッドドライブ東テュークスベリー、MA 01876
EMail: jcrb@motorola.com
メールアドレス：jcrb@motorola.com
Kent Benson Tellabs Research Center 3740 Edison Lake Parkway #101 Mishawaka, IN 46545
46545ケント・ベンソンテラブス研究センター3740エジソン湖パークウェイ＃101ミシャウォーカ、
EMail: Kent.Benson@tellabs.com
メールアドレス：Kent.Benson@tellabs.com
Jean-Yves Le Boudec ICA-EPFL, INN Ecublens, CH-1015 Lausanne-EPFL, Switzerland
ジャン=イヴ・ルICA-EPFL Boudec、INN Ecublens、CH-1015ローザンヌ、ローザンヌ連邦工科大学、スイス
EMail: jean-yves.leboudec@epfl.ch
メールアドレス：jean-yves.leboudec@epfl.ch
Bill Courtney TRW Bldg. 201/3702 One Space Park Redondo Beach, CA 90278
ビル・コートニーTRWビル。 201/3702一つのスペースパークレドンドビーチ、CA 90278
EMail: bill.courtney@trw.com
メールアドレス：bill.courtney@trw.com
Shahram Davari PMC-Sierra Inc 411 Legget Drive Ottawa, ON K2K 3C9, Canada
K2K 3C9、カナダON Shahram Davari PMC-Sierraの社411 Leggetドライブオタワ、
EMail: shahram_davari@pmc-sierra.com
メールアドレス：shahram_davari@pmc-sierra.com
Victor Firoiu Nortel Networks 600 Tech Park Billerica, MA 01821
ビクターFiroiu Nortel Networksの600ハイテクパークビレリカ、MA 01821
EMail: vfiroiu@nortelnetworks.com
メールアドレス：vfiroiu@nortelnetworks.com
Dimitrios Stiliadis Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
ディミトリオスStiliadisルーセント・テクノロジーズ101 Crawfordsコーナー道路ホルムデル、NJ 07733
EMail: stiliadi@bell-labs.com
メールアドレス：stiliadi@bell-labs.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機能のための基金は現在、インターネット協会によって提供されます。