[要約] RFC 3246は、Expedited Forwarding PHB（Per-Hop Behavior）に関する標準化されたガイドラインです。このRFCの目的は、ネットワーク上での優先的な転送を実現するためのPHBを定義することです。
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)
迅速な転送PHB（ホップごとの動作）
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、Expedited Forwarding（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に差別化されたサービス強化を実装するネットワークノードIPヘッダーのコードポイントを使用して、そのパケットの特定の転送処理としてホップごとの動作（PHB）を選択します[3、4]。このメモは、Expedited Forwarding（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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でなければなりません。。この直感を正式化しようとすると、2つの困難が生じます。
- 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パケットがデバイスに到着する場合、理想的な出発時間の計算は簡単です。パケットのサービスは（理想的には）到着したらすぐに開始する必要があるため、理想的な出発時間は、到着時間とレートRでパケットを送信する理想的な時間です。rate 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-Th）出発が独自の理想的な出発時間の後に発生した場合、スケジューラは「遅く」実行されます。この場合、新しいパケットのサービスを開始する理想的な時間は、前の（j-1-th）パケットの理想的な出発時間、または新しいパケットの到着時間です。到着する前にサービスを開始します。以前の（J-1-Th）出発が独自の理想的な出発時間の前に発生した場合、スケジューラは「早期」に実行されます。この場合、新しいパケットのサービスは、前のパケットの実際の出発時刻に開始する必要があります。
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-Thパケットのサービスが（理想的に）開始する時間がわかったら、J-Thパケットの理想的な出発時間は秒後になります。したがって、j-thパケットの到着時間、j-1-thパケットの実際の出発時間、およびjの理想的な出発時間に関して、J-thパケットの理想的な出発時間を表現できます。-1-thパケット。セクション2.2の方程式EQ_1および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でさらに説明します。これらの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)
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)
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-Th 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は、J-Th EFパケットがIから出発するターゲット出発時間であり、そのパケットの最後のビットがノードを離れる「理想的な」時間です。
- 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から出発するJ-Th EFパケットのサイズ（ビット）です。L_Jは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凝集体の治療のエラー項です。E_Aは、EFパケットの実際の出発時間と同じパケットの理想的な出発時間との間の最悪のケース偏差を表していることに注意してください。
- 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は、実際のパケットの出発を指すのではなく、再帰の目的で純粋に使用されます。時間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-Th EFパケットは、そのインターフェイスから出発するJ-Th EFパケットではない場合があります。この意味で、EQ_1とEQ_2がパケットのアイデンティティを知らないことです。
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)
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)
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は、インターフェイスIに到達したノードに到達した個々のEFパケットの実際の出発時間です。その個々のパケットの最後のビットが実際にインターフェイス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は、到着する出力Iに運命づけられたJ-Th 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は、J-Th EFパケットのサイズ（ビット）であり、出力I. L_Jが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パケットの処理のエラー用語です。E_Pは、EFパケットの実際の出発時間と同じパケットの理想的な出発時間との間の最悪のケース偏差を表していることに注意してください。
- 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は、実際のパケットの出発を指すのではなく、再帰の目的で純粋に使用されます。時間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.
d_jとf_jは、eq_3とeq_4がパケットのアイデンティティを認識させるJ-thパケットの出発時間を指すという事実です。これは、最後の2つの方程式と最初の2つの方程式の重要な区別です。
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".
これらの方程式への適合性をテストする目的のために、時間内に密接に間隔を空けているさまざまなインターフェイスでのパケットの到着に対処する必要がある場合があります。同じ出力インターフェイスに向けられた2つ以上の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の値が少ないということは、デバイスが比較的短いタイムスケールでレートrでEF凝集体をよりスムーズに提供することを意味しますが、E_Aの値が大きいほど、より長い間隔で測定された場合にのみ、レート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_AはレートrでのEF凝集体の理想的なサービスからの偏差の尺度であり、E_Pは総合的なサービスと非FIFO治療の両方を総合的に測定します。
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定義に適合するかどうかを確立することが可能である必要があります。これは、方程式1から4への適合の「オフライン」テストを実行することによって行われます。ノードを入力して出発するパケットのシーケンスを観察した後、残っていないパケットは失われ、入力ストリームから概念的に削除されます。残りのパケットは、到着ストリーム（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とバーストサイズ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.
CodePoint 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マークされたパケットを隣接する上流ドメインと交渉したレートに厳密に警察する必要があります。交渉レートを超えるパケットを削除する必要があります。2つの隣接するドメインがEFレートをネゴシエートしていない場合、ダウンストリームドメインは0をレートとして使用する必要があります（つまり、すべてのEFマークされたパケットをドロップします）。
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]で必要とされています。IngressインターフェイスでプロビジョニングされているがDSドメイン内のEFにマッピングされたトラフィックコンディショニング仕様で識別されないDSCPを活用するサービス拒否およびサービス拒否攻撃から保護します。
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.
この文書は、多くの人々の間でのコラボレーションと議論の結果でした。特に、フレッド・ベイカー、アンジェラ・チウ、チャック・カルマネク、およびK. K.ラマクリシュナンは、新しいEF定義に多大な貢献をしました。John Wroclawskiは、著者に多くの有益なコメントを提供しました。この文書は、ジェイコブソン、ニコルズ、ポドゥリの元のEF PHB定義に大きく描かれています。また、アーミテージ、カサティ、クロウクロフト、ハルパーン、クマール、シニズレインのエフレゾルブチームの仕事に大きな影響を受けました。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「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] Black、D.、Blake、S.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[5] Black、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.、Baker、F.、Davie、B.、Bennett、J.C.R.、Benson、K.、Le Boudec、J.Y.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、ラマクリシュナン、K.K。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] Nichols K.およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、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トラフィックの優先キューを備えた「完璧な」出力バッファーデバイス（つまり、適切な出力キューにパケットをすぐに配信するデバイス）は、低E_Aと低E_Pの両方を提供します。E_Aに影響を与える主な要因は、EFパケットが出力インターフェイスに到着した時点で送信を開始したばかりのMTUサイズの非EFパケットを先取りできないことに加えて、発生する可能性のある追加の遅延ができないことに注意してください。優先順位キューと物理インターフェイスの間の非排気可能なキューによって。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の実装のもう1つの例は、重み付けされたラウンドロビンスケジューラです。このような実装は、通常、リンク速度ほど高いRの値をサポートすることはできません。これは、競合するトラフィックの存在下でEFトラフィックを提供できる最大速度は、他のキューの数と与えられた重みによって影響を受けるため彼らへ。さらに、このような実装には、ラウンドロビンスケジューラによる非EFキューに費やされた時間の結果として、優先キューの実装よりも高いE_Aの値がある可能性があります。
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の集計はEF全体でサブフローで実行されるようになり、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の優先度インスタンスが提供されている場合、最も優先度の高い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アポロドライブチェルムスフォード、マサチューセッツ州、01824
EMail: bsd@cisco.com
Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
Anna Charny Cisco Systems 300 Apollo Drive Chelmsford、MA 01824
EMail: acharny@cisco.com
Jon Bennett Motorola 3 Highwood Drive East Tewksbury, MA 01876
ジョンベネットモトローラ3ハイウッドドライブイーストテュークスベリー、マサチューセッツ州01876
EMail: jcrb@motorola.com
Kent Benson Tellabs Research Center 3740 Edison Lake Parkway #101 Mishawaka, IN 46545
ケントベンソンテラバーズリサーチセンター3740エジソンレイクパークウェイ＃101ミシャワカ、46545
EMail: Kent.Benson@tellabs.com
Jean-Yves Le Boudec ICA-EPFL, INN Ecublens, CH-1015 Lausanne-EPFL, Switzerland
Jean-Yves Le Boudec ICA-EPFL、Inn Ecublens、CH-1015 Lausanne-Epfl、スイス
EMail: jean-yves.leboudec@epfl.ch
Bill Courtney TRW Bldg. 201/3702 One Space Park Redondo Beach, CA 90278
ビル・コートニーTRW Bldg。201/3702 One Space Park Redondo Beach、CA 90278
EMail: bill.courtney@trw.com
Shahram Davari
PMC-Sierra Inc
411 Legget Drive
Ottawa, ON K2K 3C9, Canada
EMail: shahram_davari@pmc-sierra.com
Victor Firoiu Nortel Networks 600 Tech Park Billerica, MA 01821
Victor Firoiu Nortel Networks 600 Tech Park Billerica、MA 01821
EMail: vfiroiu@nortelnetworks.com
Dimitrios Stiliadis Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
Dimitrios Stiliadis Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733
EMail: stiliadi@bell-labs.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エディター機能の資金は現在、インターネット協会によって提供されています。