[要約] RFC 3247は、EF PHB（Expedited Forwarding Per-Hop Behavior）の新しい定義に関する補足情報を提供しています。このRFCの目的は、EF PHBの実装と運用に関するガイダンスを提供することです。
Network Working Group A. Charny
Request for Comments: 3247 Cisco Systems, Inc.
Category: Informational J.C.R. Bennett
Motorola
K. Benson
Tellabs
J.Y. Le Boudec
EPFL
A. Chiu
Celion Networks
W. Courtney
TRW
S. Davari
PMC-Sierra
V. Firoiu
Nortel Networks
C. Kalmanek
AT&T Research
K.K. Ramakrishnan
TeraOptic Networks
March 2002
Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)
EF PHBの新しい定義のための補足情報（迅速な転送ごとの動作）
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
概要
This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures.
このドキュメントは、RFC2598の明確化のプロセス中に作成されました。「迅速な転送PHB」で、EFの修正仕様「迅速な転送PHB」の公開につながりました。その主な動機は、改訂されたEF定義とその特性に追加の説明を提供することです。また、このドキュメントは追加の実装例を提供し、いくつかのよく知られているスケジューラーとルーターアーキテクチャの新しい定義の数値パラメーターの計算のガイダンスを提供します。
Table of Contents
目次
1 Introduction ........................................... 2
2 Definition of EF PHB ................................... 3
2.1 The formal definition .................................. 3
2.2 Relation to Packet Scale Rate Guarantee ................ 6
2.3 The need for dual characterization of EF PHB ........... 7
3 Per Packet delay ....................................... 9
3.1 Single hop delay bound ................................. 9
3.2 Multi-hop worst case delay ............................. 10
4 Packet loss ............................................ 10
5 Implementation considerations .......................... 11
5.1 The output buffered model with EF FIFO at the output. .. 12
5.1.1 Strict Non-preemptive Priority Queue ................... 12
5.1.2 WF2Q ................................................... 13
5.1.3 Deficit Round Robin (DRR) .............................. 13
5.1.4 Start-Time Fair Queuing and Self-Clocked Fair Queuing .. 13
5.2 Router with Internal Delay and EF FIFO at the output ... 13
6 Security Considerations ................................ 14
7 References ............................................. 14
Appendix A. Difficulties with the RFC 2598 EF PHB Definition .. 16
Appendix B. Alternative Characterization of Packet Scale Rate
Guarantee ......................................... 20
Acknowledgements .............................................. 22
Authors' Addresses ............................................ 22
Full Copyright Statement ...................................... 24
The Expedited Forwarding (EF) Per-Hop Behavior (PHB) was designed to be used to build a low-loss, low-latency, low-jitter, assured bandwidth service. The potential benefits of this service, and therefore the EF PHB, are enormous. Because of the great value of this PHB, it is critical that the forwarding behavior required of and delivered by an EF-compliant node be specific, quantifiable, and unambiguous.
Expedited Forwarding（EF）PER HOP Behavior（PHB）は、低下、低遅延、低ジッター、保証された帯域幅サービスを構築するために使用されるように設計されています。このサービスの潜在的な利点、したがってEF PHBは膨大です。このPHBの価値があるため、EFに準拠したノードによって必要な転送挙動が特定、定量化可能、および明確であることが重要です。
Unfortunately, the definition of EF PHB in the original RFC2598 [10] was not sufficiently precise (see Appendix A and [4]). A more precise definition is given in [6]. This document is intended to aid in the understanding of the properties of the new definition and provide supplemental information not included in the text of [6] for sake of brevity.
残念ながら、元のRFC2598 [10]におけるEF PHBの定義は十分に正確ではありませんでした（付録Aおよび[4]を参照）。[6]には、より正確な定義が示されています。このドキュメントは、新しい定義の特性の理解を支援し、簡潔にするために[6]のテキストに含まれていない補足情報を提供することを目的としています。
This document is outlined as follows. In section 2, we briefly restate the definition for EF PHB of [6]. We then provide some additional discussion of this definition and describe some of its properties. We discuss the issues associated with per-packet delay and loss in sections 3 and 4. In section 5 we discuss the impact of known scheduling architectures on the critical parameters of the new definition. We also discuss the impact of deviation of real devices from the ideal output-buffered model on the magnitude of the critical parameters in the definition.
このドキュメントは、次のように概説されています。セクション2では、[6]のEF PHBの定義を簡単に再定義します。次に、この定義の追加の議論を提供し、そのプロパティの一部を説明します。セクション3および4のパケットごとの遅延と損失に関連する問題について説明します。セクション5では、新しい定義の重要なパラメーターに対する既知のスケジューリングアーキテクチャの影響について説明します。また、定義の重要なパラメーターの大きさに対する理想的な出力バッファーモデルからの実際のデバイスの偏差の影響についても説明します。
An intuitive explanation of the new EF definition is described in [6]. Here we restate the formal definition from [6] verbatim.
新しいEF定義の直感的な説明は[6]で説明されています。ここでは、[6] Verbatimから正式な定義を再定義します。
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 actual departure time of an EF packet and 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.
EFに準拠したノードは、これらの方程式に準拠しながら、各インターフェイスでサポートできる可能性のあるR値の範囲と、各インターフェイスで満たすことができるE_Pの値によって特徴付けられる必要があります。E_Pは、考えられるすべてのR値に対して最悪の値として指定されているか、Rの関数として表される場合があります。「未定義」のE_P値を指定できます。
Finally, there is an additional recommendation in [6] that an EF compliant node SHOULD NOT reorder packets within a micorflow.
最後に、[6]には、EFに準拠したノードがマイコルフロー内のパケットを再注文しないでください。
The definitions described in this section are referred to as aggregate and packet-identity-aware packet scale rate guarantee [4],[2]. An alternative mathematical characterization of packet scale rate guarantee is given in Appendix B.
このセクションで説明した定義は、集計およびパケットアイデンティティを認識したパケットスケールレート保証[4]、[2]と呼ばれます。パケットスケールレート保証の代替数学的特性評価は、付録Bに記載されています。
Consider the case of an ideal output-buffered device with an EF FIFO at the output. For such a device, the i-th packet to arrive to the device is also the i-th packet to depart from the device. Therefore, in this ideal model the aggregate behavior and packet-identity-aware characteristics are identical, and E_a = E_p. In this section we therefore omit the subscript and refer to the latency term simply as E.
出力にEF FIFOを備えた理想的な出力バッファーデバイスの場合を考えてください。このようなデバイスの場合、デバイスに到着するi番目のパケットは、デバイスから出発するi番目のパケットでもあります。したがって、この理想的なモデルでは、骨材の動作とパケットアイデンティティアウェア特性は同一であり、e_a = e_pです。したがって、このセクションでは、添え字を省略し、レイテンシー用語を単にEと呼びます。
It could be shown that for such an ideal device the definition of section 2.1 is stronger than the well-known rate-latency curve [2] in the sense that if a scheduler satisfies the EF definition it also satisfies the rate-latency curve. As a result, all the properties known for the rate-latency curve also apply to the modified EF definition. However, we argue below that the definition of section 2.1 is more suitable to reflect the intent of EF PHB than the rate-latency curve.
このような理想的なデバイスでは、セクション2.1の定義は、スケジューラがEFの定義を満たしている場合、レート遅延曲線も満たすという意味で、よく知られている速度速度曲線[2]よりも強いことが示されます。その結果、速度遅延曲線で知られているすべてのプロパティも、変更されたEF定義にも適用されます。ただし、セクション2.1の定義は、レート遅延曲線よりもEF PHBの意図を反映する方が適切であると主張します。
It is shown in [2] that the rate-latency curve is equivalent to the following definition:
[2]では、レート遅延曲線が次の定義と同等であることが示されています。
Definition of Rate Latency Curve (RLC):
レート潜時曲線（RLC）の定義：
D(j) <= F'(j) + E (eq_5)
where
ただし
F'(0)=0, F'(j)=max(a(j), F'(j-1))+ L(j)/R for all j>0 (eq_6)
It can be easily verified that the EF definition of section 2.1 is stronger than RLC by noticing that for all j, F'(j) >= F(j).
すべてのj、f '（j）> = f（j）に対してそれに気付くことにより、セクション2.1のEF定義がRLCよりも強いことを簡単に確認できます。
It is easy to see that F'(j) in the definition of RLC corresponds to the time the j-th departure should have occurred should the EF aggregate be constantly served exactly at its configured rate R. Following the common convention, we refer to F'(j) as the "fluid finish time" of the j-th packet to depart.
RLCの定義のf '（j）は、ef集合体がその構成レートRで常に正確に提供された場合に、j-forteが発生するはずです。f '（j）出発するJ-Thパケットの「流体仕上げ時間」として。
The intuitive meaning of the rate-latency curve of RLC is that any packet is served at most time E later than this packet would finish service in the fluid model.
RLCの速度遅延曲線の直感的な意味は、このパケットがこのパケットが流体モデルでサービスを終了するよりも、ほとんどの場合、パケットがeを提供することです。
For RLC (and hence for the stronger EF definition) it holds that in any interval (0,t) the EF aggregate gets close to the desired service rate R (as long as there is enough traffic to sustain this rate). The discrepancy between the ideal and the actual service in this interval depends on the latency term E, which in turn depends on the scheduling implementation. The smaller E, the smaller the difference between the configured rate and the actual rate achieved by the scheduler.
RLC（したがって、より強いEF定義の場合）の場合、任意の間隔（0、t）では、EF集合体が目的のサービスレートrに近づくことがわかります（このレートを維持するのに十分なトラフィックがある限り）。この間隔での理想と実際のサービスの矛盾は、潜在項Eに依存します。これは、スケジューリングの実装に依存します。Eが小さいほど、構成されたレートとスケジューラによって達成される実際のレートの差が小さくなります。
While RLC guarantees the desired rate to the EF aggregate in all intervals (0,t) to within a specified error, it may nevertheless result in large gaps in service. For example, suppose that (a large number) N of identical EF packets of length L arrived from different interfaces to the EF queue in the absence of any non-EF traffic. Then any work-conserving scheduler will serve all N packets at link speed. When the last packet is sent at time NL/C, where C is the capacity of output link, F'(N) will be equal to NL/R. That is, the scheduler is running ahead of ideal, since NL/C < NL/R for R < C. Suppose now that at time NL/C a large number of non-EF packets arrive, followed by a single EF packet. Then the scheduler can legitimately delay starting to send the EF packet until time F'(N+1)=(N+1)L/R + E - L/C. This means that the EF aggregate will have no service at all in the interval (NL/C, (N+1)L/R + E - L/C). This interval can be quite large if R is substantially smaller than C. In essence, the EF aggregate can be "punished" by a gap in service for receiving faster service than its configured rate at the beginning.
RLCは、すべての間隔（0、t）で指定されたエラー内でEF集計の目的のレートを保証しますが、それでもサービスが大きなギャップをもたらす可能性があります。たとえば、長さlの同一のEFパケットの（多数）Nが異なるインターフェイスからEFキューに到着したとします。その後、作業制度スケジューラは、すべてのNパケットをリンク速度で提供します。最後のパケットが時間nl/cで送信されると、cは出力リンクの容量である場合、f '（n）はnl/rに等しくなります。つまり、R <CのNL/C <NL/R/Rが多数の非EFパケットが到着し、1つのEFパケットが到着したと仮定すると、スケジューラは理想よりも先に実行されています。スケジューラは、時間f '（n 1）=（n 1）l/r e -l/cまでEFパケットの送信を開始することを正当に遅らせることができます。これは、EF集合体が間隔（NL/C、（n 1）L/R E -L/C）にまったくサービスがないことを意味します。RがCよりも大幅に小さい場合、この間隔は非常に大きくなる可能性があります。本質的に、EFの骨材は、最初に構成されたレートよりも速いサービスを受けるためのサービスのギャップによって「罰」される可能性があります。
The new EF definition alleviates this problem by introducing the term min(D(j-1), F(j-1)) in the recursion. Essentially, this means that the fluid finishing time is "reset" if that packet is sent before its "ideal" departure time. As a consequence of that, for the case where the EF aggregate is served in the FIFO order, suppose a packet arrives at time t to a server satisfying the EF definition. The packet will be transmitted no later than time t + Q(t)/R + E, where Q(t) is the EF queue size at time t (including the packet under discussion)[4].
新しいEF定義は、再帰にMIN（D（J-1）、F（J-1））という用語を導入することにより、この問題を軽減します。基本的に、これは、そのパケットが「理想的な」出発時間の前に送信される場合、流体仕上げ時間が「リセット」されることを意味します。その結果、EF集計がFIFO順序で提供される場合、パケットがEF定義を満たすサーバーに時間Tに到着するとします。このパケットは、時間t q（t）/r eまでに送信されます。ここで、q（t）は時間t（議論中のパケットを含む）のefキューサイズです[4]。
In a more general case, where either the output scheduler does not serve the EF packets in a FIFO order, or the variable internal delay in the device reorders packets while delivering them to the output (or both), the i-th packet destined to a given output interface to arrive to the device may no longer be the i-th packet to depart from that interface. In that case the packet-identity-aware and the aggregate definitions are no longer identical.
より一般的なケースでは、出力スケジューラがFIFO順序でEFパケットを提供しないか、デバイスの変数内部遅延がパケットを再配置しながら、出力（またはその両方）に配信し、デバイスに到着するための特定の出力インターフェイスは、そのインターフェイスから出発するi番目のパケットではなくなる可能性があります。その場合、パケットアイデンティティアウェアと集約定義はもはや同一ではありません。
The aggregate behavior definition can be viewed as a truly aggregate characteristic of the service provided to EF packets. For an analogy, consider a dark reservoir to which all arriving packets are placed. A scheduler is allowed to pick a packet from the reservoir in a random order, without any knowledge of the order of packet arrivals. The aggregate part of the definition measures the accuracy of the output rate provided to the EF aggregate as a whole. The smaller E_a, the more accurate is the assurance that the reservoir is drained at least at the configured rate.
集約的な動作定義は、EFパケットに提供されるサービスの真の集計特性と見なすことができます。類推のために、到着するすべてのパケットが配置される暗い貯水池を検討してください。スケジューラは、パケットの到着の順序を知らずに、ランダム順序で貯水池からパケットを選択することができます。定義の総部分は、EF集合体全体に提供される出力速度の精度を測定します。E_Aが小さいほど、貯水池が少なくとも構成された速度で排出されるという保証はより正確です。
Note that in this reservoir analogy packets of EF aggregate may be arbitrarily reordered. However, the definition of EF PHB given in [6] explicitly requires that no packet reordering occur within a microflow. This requirement restricts the scheduling implementations, or, in the reservoir analogy, the order of pulling packets out of the reservoir to make sure that packets within a microflow are not reordered, but it still allows reordering at the aggregate level.
この貯水池では、EF凝集体の類推パケットが任意に並べ替えられる可能性があることに注意してください。ただし、[6]に与えられたEF PHBの定義では、マイクロフロー内でパケットの再注文が発生しないことを明示的に必要とします。この要件は、スケジューリングの実装、または貯水池の類推では、マイクロフロー内のパケットが並べ替えられないことを確認するために、リザーバーからパケットを引き出す順序を制限しますが、それでも集約レベルで並べ替えることができます。
Note that reordering within the aggregate, as long as there is no flow-level reordering, does not necessarily reflect a "bad" service. Consider for example a scheduler that arbitrates among 10 different EF "flows" with diverse rates. A scheduler that is aware of the rate requirements may choose to send a packet of the faster flow before a packet of the slower flow to maintain lower jitter at the flow level. In particular, an ideal "flow"-aware WFQ scheduler will cause reordering within the aggregate, while maintaining packet ordering and small jitter at the flow level.
集合体内での並べ替えは、フローレベルの再注文がない限り、必ずしも「悪い」サービスを反映しているわけではないことに注意してください。たとえば、10種類のEFが流れる10の異なるEFの間で調停するスケジューラを、多様なレートで検討してください。レート要件を認識しているスケジューラは、フローレベルで低いジッターを維持するために、より速いフローのパケットの前に、より速いフローのパケットを送信することを選択できます。特に、理想的な「フロー」を覚めるWFQスケジューラは、パケットの順序と小規模ジッターをフローレベルで維持しながら、集計内で並べ替えを引き起こします。
It is intuitively clear that for such a scheduler, as well as for a simpler FIFO scheduler, the "accuracy" of the service rate is crucial for minimizing "flow"-level jitter. The packet-identity-aware definition quantifies this accuracy of the service rate.
このようなスケジューラの場合、およびよりシンプルなFIFOスケジューラにとって、「フロー」レベルのジッターを最小化するためにサービスレートの「精度」が重要であることは直感的に明らかです。パケットアイデンティティアウェア定義は、サービスレートのこの精度を定量化します。
However, the small value of E_a does not give any assurances about the absolute value of per-packet delay. In fact, if the input rate exceeds the configured rate, the aggregate behavior definition may result in arbitrarily large delay of a subset of packets. This is the primary motivation for the packet-identity-aware definition.
ただし、E_Aのわずかな値は、パケットごとの遅延の絶対値について保証しません。実際、入力レートが構成されたレートを超えた場合、集約動作定義により、パケットのサブセットが任意に大きな遅延が発生する可能性があります。これは、パケットアイデンティティを意識する定義の主な動機です。
The primary goal of the packet-aware characterization of the EF implementation is that, unlike the aggregate behavior characterization, it provides a way to find a per-packet delay bound as a function of input traffic parameters.
EF実装のパケット認識の特性評価の主な目標は、集約的な動作の特性評価とは異なり、入力トラフィックパラメーターの関数としてバインドされたパケットごとの遅延を見つける方法を提供することです。
While the aggregate behavior definition characterizes the accuracy of the service rate of the entire EF aggregate, the packet-identity-aware part of the definition characterizes the deviation of the device from an ideal server that serves the EF aggregate in FIFO order at least at the configured rate.
集約的な動作定義は、EF全体のサービスレートの精度を特徴づけますが、定義のパケット同一性を認識する部分は、少なくともfifo順序でEF集合体にサービスを提供する理想的なサーバーからのデバイスの偏差を特徴づけます。構成されたレート。
The value of E_p in the packet-identity-aware definition is therefore affected by two factors: the accuracy of the aggregate rate service and the degree of packet reordering within the EF aggregate (under the constraint that packets within the same microflow are not reordered). Therefore, a sub-aggregate aware device that provides an ideal service rate to the aggregate, and also provides an ideal rate service for each of the sub-aggregates, may nevertheless have a very large value of E_p (in this case E_p must be at least equal to the ratio of the maximum packet size divided by the smallest rate of any sub aggregate). As a result, a large value of E_p does not necessarily mean that the service provided to EF aggregate is bad - rather it may be an indication that the service is good, but non-FIFO. On the other hand, a large value of E_p may also mean that the aggregate service is very inaccurate (bursty), and hence in this case the large value of E_p reflects a poor quality of implementation.
したがって、パケットアイデンティティアウェア定義におけるE_Pの値は、2つの要因の影響を受けます。集約レートサービスの精度とEF集合体内のパケットの並べ替えの程度（同じマイクロフロー内のパケットが再注文されないという制約の下で）。したがって、集計に理想的なサービスレートを提供するサブアグレージ型の意識的なデバイスは、サブアグレッジのそれぞれに理想的なレートサービスを提供する場合でも、E_Pの非常に大きな値を持つ場合があります（この場合、E_Pは最大パケットサイズの比率をサブ集約の最小レートで割った比率に最小等しくなります）。その結果、E_Pの大きな値は、必ずしもEFの集計に提供されるサービスが悪いことを意味するわけではありません - むしろ、それはサービスが良いが、非FIFOであることを示すものかもしれません。一方、E_Pの大きな値は、集計サービスが非常に不正確であることを意味する可能性があります（バースト）。したがって、この場合、E_Pの大きな値は実装の質の低さを反映しています。
As a result, a large number of E_p does not necessarily provide any guidance on the quality of the EF implementation. However, a small value of E_p does indicate a high quality FIFO implementation.
その結果、多数のE_Pが必ずしもEF実装の品質に関するガイダンスを提供するわけではありません。ただし、E_Pのわずかな値は、高品質のFIFO実装を示しています。
Since E_p and E_a relate to different aspects of the EF implementation, they should be considered together to determine the quality of the implementation.
E_PとE_AはEF実装のさまざまな側面に関連するため、実装の品質を決定するために一緒に考慮する必要があります。
The primary motivation for the packet-identity-aware definition is that it allows quantification of the per-packet delay bound. This section discusses the issues with computing per-packet delay.
パケットアイデンティティアウェアの定義の主な動機は、パケットごとの遅延バウンドの定量化を可能にすることです。このセクションでは、パケットごとのコンピューティング遅延に関する問題について説明します。
If the total traffic arriving to an output port I from all inputs is constrained by a leaky bucket with parameters (R, B), where R is the configured rate at I, and B is the bucket depth (burst), then the delay of any packet departing from I is bounded by D_p, given by
すべての入力から出力ポートIに到着する総トラフィックがパラメーター（R、B）を備えた漏れやすいバケットによって制約されている場合、RはIで構成されたレート、Bはバケット深度（バースト）、次にの遅延iから出発するパケットは、d_pによって境界を掲載しています。
D_p = B/R + E_p (eq_7)
d_p = b/r e_p（eq_7）
(see appendix B).
（付録Bを参照）。
Because the delay bound depends on the configured rate R and the input burstiness B, it is desirable for both of these parameters to be visible to a user of the device. A PDB desiring a particular delay bound may need to limit the range of configured rates and allowed burstiness that it can support in order to deliver such bound. Equation (eq_7) provides a means for determining an acceptable operating region for the device with a given E_p. It may also be useful to limit the total offered load to a given output to some rate R_1 < R (e.g. to obtain end-to-end delay bounds [5]). It is important to realize that, while R_1 may also be a configurable parameter of the device, the delay bound in (eq_7) does not depend on it. It may be possible to get better bounds explicitly using the bound on the input rate, but the bound (eq_7) does not take advantage of this information.
遅延境界は構成されたレートrと入力バースティネスBに依存するため、これらのパラメーターの両方がデバイスのユーザーに表示されることが望ましいです。特定の遅延境界を望むPDBは、構成されたレートの範囲を制限し、そのような境界を届けるためにサポートできる爆発を許可する必要がある場合があります。方程式（EQ_7）は、特定のE_Pでデバイスの許容可能な動作領域を決定するための手段を提供します。また、提供された総負荷を特定の出力に制限して、R_1 <r（例えば、エンドツーエンドの遅延境界を取得するため[5]）。R_1もデバイスの構成可能なパラメーターである可能性があるが、（EQ_7）にバインドされた遅延はそれに依存していないことを認識することが重要です。入力レートのバウンドを明示的に使用してより良い境界を取得することは可能かもしれませんが、バウンド（EQ_7）はこの情報を利用しません。
Although the PHB defines inherently local behavior, in this section we briefly discuss the issue of per-packet delay as the packet traverses several hops implementing EF PHB. Given a delay bound (eq_7) at a single hop, it is tempting to conclude that per-packet bound across h hops is simply h times the bound (eq_7). However, this is not necessarily the case, unless B represents the worst case input burstiness across all nodes in the network.
PHBは本質的にローカルな動作を定義していますが、このセクションでは、パケットがEF PHBを実装するいくつかのホップを横断するため、パケットごとの遅延の問題を簡単に説明します。1回のホップでのバウンドバウンド（EQ_7）を考えると、Hホップ全体にバインドされたパケットごとにh hopに縛られたパケットごとに、バウンド（Eq_7）が単純にあると結論付けるのは魅力的です。ただし、Bがネットワーク内のすべてのノードに最悪のケース入力の爆発を表す場合を除き、これは必ずしもそうではありません。
Unfortunately, obtaining such a worst case value of B is not trivial. If EF PHB is implemented using aggregate class-based scheduling where all EF packets share a single FIFO, the effect of jitter accumulation may result in an increase in burstiness from hop to hop. In particular, it can be shown that unless severe restrictions on EF utilization are imposed, even if all EF flows are ideally shaped at the ingress, then for any value of delay D it is possible to construct a network where EF utilization on any link is bounded not to exceed a given factor, no flow traverses more than a specified number of hops, but there exists a packet that experiences a delay more than D [5]. This result implies that the ability to limit the worst case burstiness and the resulting end-to-end delay across several hops may require not only limiting EF utilization on all links, but also constraining the global network topology. Such topology constraints would need to be specified in the definition of any PDB built on top of EF PHB, if such PDB requires a strict worst case delay bound.
残念ながら、Bのこのような最悪の値を取得することは些細なことではありません。すべてのEFパケットが単一のFIFOを共有するアグリゲートクラスベースのスケジューリングを使用してEF PHBが実装されている場合、ジッターの蓄積の効果により、ホップからホップへの爆発が増加する可能性があります。特に、すべてのEFフローが入り口で理想的に形作られていても、EFの使用率が課せられない場合を除き、遅延dの値に対して、リンクでのEF使用率があるネットワークを構築することが可能であることを示すことができます。特定の係数を超えないように制限されているため、フローは指定された数のホップ数を超えて移動しませんが、Dを超える遅延を経験するパケットが存在します[5]。この結果は、最悪のケースの破裂を制限する能力と、いくつかのホップにわたる結果として生じるエンドツーエンドの遅延が、すべてのリンクのEF使用を制限するだけでなく、グローバルネットワークトポロジを制約する必要があることを意味します。このようなトポロジーの制約は、EF PHBの上に構築されたPDBの定義で指定する必要があります。そのようなPDBには、厳密な最悪の遅延バウンドが必要です。
Any device with finite buffering may need to drop packets if the input burstiness becomes sufficiently high. To meet 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 as a token bucket of rate r <= R and burst size B that can be offered from all inputs to a given output interface without loss.
入力の爆発が十分に高くなった場合、有限バッファリングのあるデバイスはパケットをドロップする必要がある場合があります。EFの低損失目標を達成するために、ノードは、うっ血によるEFの損失が発生しない動作領域によって特徴付けられる場合があります。これは、すべての入力から特定の出力インターフェイスに提供できるレートr <= rおよびバーストサイズBのトークンバケットとして指定できます。
However, as discussed in the previous section, the phenomenon of jitter accumulation makes it generally difficult to guarantee that the input burstiness never exceeds the specified operating region for nodes internal to the DiffServ domain. A no-loss guarantee across multiple hops may require specification of constraints on network topology which are outside the scope of inherently local definition of a PHB. Thus, it must be possible to establish whether a device conforms to the EF definition even when some packets are lost.
ただし、前のセクションで説明したように、ジッターの蓄積の現象により、入力の爆発がDiffservドメインの内部ノードの指定された動作領域を決して超えないことを保証することが一般的に困難になります。複数のホップにわたる非ロス保証では、PHBの本質的にローカルな定義の範囲外であるネットワークトポロジの制約の指定が必要になる場合があります。したがって、一部のパケットが失われた場合でも、デバイスがEF定義に適合するかどうかを確立することが可能である必要があります。
This can be done by performing an "off-line" test of conformance to equations (eq_1)- (eq_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 and the packets which left the node constitute the departure stream. Conformance to the equations can thus be verified by considering only those packets that successfully passed through the node.
これは、方程式（EQ_1） - （EQ_4）への適合の「オフライン」テストを実行することで実行できます。ノードを入力して出発するパケットのシーケンスを観察した後、残っていないパケットは失われ、入力ストリームから概念的に削除されます。残りのパケットは到着ストリームを構成し、ノードを残したパケットは出発ストリームを構成します。したがって、方程式への適合は、ノードを正常に通過したパケットのみを考慮することで検証できます。
Note that specification of which packets are lost in the case when loss does occur is beyond the scope of the definition of EF PHB. However, those packets that were not lost must conform to the equations definition of EF PHB in section 2.1.
損失が発生した場合にパケットが失われるパケットの仕様は、EF PHBの定義の範囲を超えていることに注意してください。ただし、失われなかったパケットは、セクション2.1のEF PHBの方程式定義に準拠する必要があります。
A packet passing through a router will experience delay for a number of reasons. Two familiar components of this delay are the time the packet spends in a buffer at an outgoing link waiting for the scheduler to select it and the time it takes to actually transmit the packet on the outgoing line.
ルーターを通過するパケットは、いくつかの理由で遅延が発生します。この遅延の2つの馴染みのあるコンポーネントは、スケジューラが選択するのを待つ発信リンクのバッファーでパケットを使用する時間と、パケットを発信ラインに実際に送信するのにかかる時間です。
There may be other components of a packet's delay through a router, however. A router might have to do some amount of header processing before the packet can be given to the correct output scheduler, for example. In another case a router may have a FIFO buffer (called a transmission queue in [7]) where the packet sits after being selected by the output scheduler but before it is transmitted. In cases such as these, the extra delay a packet may experience can be accounted for by absorbing it into the latency terms E_a and E_p.
ただし、ルーターを介したパケットの遅延の他のコンポーネントがある場合があります。たとえば、パケットを正しい出力スケジューラに与える前に、ルーターはある程度のヘッダー処理を行う必要がある場合があります。別のケースでは、ルーターには、出力スケジューラによって選択された後、送信される前にパケットが座るFIFOバッファ（[7]の伝送キューと呼ばれる）があります。このような場合、パケットが経験する可能性のある余分な遅延は、潜在項E_AおよびE_Pに吸収することで説明できます。
Implementing EF on a router with a multi-stage switch fabric requires special attention. A packet may experience additional delays due to the fact that it must compete with other traffic for forwarding resources at multiple contention points in the switch core. The delay an EF packet may experience before it even reaches the output-link scheduler should be included in the latency term. Input-buffered and input/output-buffered routers based on crossbar design may also require modification of their latency terms. The factors such as the speedup factor and the choice of crossbar arbitration algorithms may affect the latency terms substantially.
マルチステージスイッチファブリックを使用してルーターにEFを実装するには、特に注意が必要です。パケットは、スイッチコアの複数の競合ポイントでリソースを転送するために他のトラフィックと競合する必要があるため、追加の遅延が発生する場合があります。EFパケットが出力リンクスケジューラに到達する前に発生する可能性のある遅延は、レイテンシ項に含める必要があります。クロスバーの設計に基づいた入力バッファー/出力/出力バッファールーターも、レイテンシ項の変更が必要になる場合があります。スピードアップ係数やクロスバー仲裁アルゴリズムの選択などの因子は、遅延項に大きく影響する可能性があります。
Delay in the switch core comes from two sources, both of which must be considered. The first part of this delay is the fixed delay a packet experiences regardless of the other traffic. This component of the delay includes the time it takes for things such as packet segmentation and reassembly in cell based cores, enqueueing and dequeuing at each stage, and transmission between stages. The second part of the switch core delay is variable and depends on the type and amount of other traffic traversing the core. This delay comes about if the stages in the core mix traffic flowing between different input/output port pairs. Thus, EF packets must compete against other traffic for forwarding resources in the core. Some of this competing traffic may even be traffic from other, non-EF aggregates. This introduces extra delay, that can also be absorbed by the latency term in the definition.
スイッチコアの遅延は、2つのソースから得られ、どちらも考慮する必要があります。この遅延の最初の部分は、他のトラフィックに関係なくパケットエクスペリエンスの固定遅延です。遅延のこのコンポーネントには、セルベースのコアでのパケットセグメンテーションや再組み立て、各段階でのエンキューとデキューイング、段階間の伝送などの時間がかかる時間が含まれます。スイッチコア遅延の2番目の部分は可変であり、コアを横断する他のトラフィックのタイプと量に依存します。この遅延は、異なる入出力ポートペア間で流れるコアミックストラフィックのステージが発生します。したがって、EFパケットは、コアのリソースを転送するために他のトラフィックと競合する必要があります。この競合するトラフィックの一部は、他の非EF集合体からのトラフィックでさえある場合があります。これにより、定義の遅延用語によって吸収される可能性のある追加の遅延が導入されます。
To capture these considerations, in this section we will consider two simplified implementation examples. The first is an ideal output buffered node where packets entering the device from an input interface are immediately delivered to the output scheduler. In this model the properties of the output scheduler fully define the values of the parameters E_a and E_p. We will consider the case where the output scheduler implements aggregate class-based queuing, so that all EF packets share a single queue. We will discuss the values of E_a and E_p for a variety of class-based schedulers widely considered.
これらの考慮事項をキャプチャするために、このセクションでは、2つの簡素化された実装の例を検討します。1つ目は、入力インターフェイスからデバイスに入るパケットが出力スケジューラにすぐに配信される理想的な出力バッファーノードです。このモデルでは、出力スケジューラのプロパティがパラメーターE_AおよびE_Pの値を完全に定義します。すべてのEFパケットが単一のキューを共有するように、出力スケジューラがクラスベースのキューイングの集約を実装する場合を検討します。広く考慮されているさまざまなクラスベースのスケジューラのE_AとE_Pの値について説明します。
The second example will consider a router modeled as a black box with a known bound on the variable delay a packet can experience from the time it arrives to an input to the time it is delivered to its destination output. The output scheduler in isolation is assumed to be an aggregate scheduler where all EF packets share a single FIFO queue, with a known value of E_a(S)=E_p(S)=E(S). This model provides a reasonable abstraction to a large class of router implementations.
2番目の例では、パケットが到着してから入力まで体験できる可変遅延に既知のバウンドを持つブラックボックスとしてモデル化されたルーターを考慮します。分離した出力スケジューラは、すべてのEFパケットがE_A（s）= e_p（s）= e（s）の既知の値を持つ単一のFIFOキューを共有する集約スケジューラであると想定されています。このモデルは、ルーターの実装の大規模なクラスに合理的な抽象化を提供します。
5.1. The output buffered model with EF FIFO at the output.
5.1. 出力にefFIFOを備えた出力バッファリングモデル。
As has been mentioned earlier, in this model E_a = E_p, so we shall omit the subscript and refer to both terms as latency E. The remainder of this subsection discusses E for a number of scheduling implementations.
先に述べたように、このモデルE_A = E_Pでは、下付き文字を省略し、両方の用語をレイテンシEと呼びます。
A Strict Priority scheduler in which all EF packets share a single FIFO queue which is served at strict non-preemptive priority over other queues satisfies the EF definition with the latency term E = MTU/C where MTU is the maximum packet size and C is the speed of the output link.
すべてのEFパケットが他のキューよりも厳密な非偏見の優先度で提供される単一のFIFOキューを共有する厳格な優先スケジューラは、潜在用語E = MTU/CでEF定義を満たします。ここで、MTUは最大パケットサイズであり、CはCです。出力リンクの速度。
Another scheduler that satisfies the EF definition with a small latency term is WF2Q described in [1]. A class-based WF2Q scheduler, in which all EF traffic shares a single queue with the weight corresponding to the configured rate of the EF aggregate satisfies the EF definition with the latency term E = MTU/C+MTU/R.
小さなレイテンシ項でEF定義を満たす別のスケジューラは、[1]で説明されているWF2Qです。すべてのEFトラフィックが、EF集合体の設定されたレートに対応する重量と単一のキューを共有するクラスベースのWF2Qスケジューラは、潜在項E = MTU/C MTU/RでEF定義を満たします。
For DRR [12], E can be shown to grow linearly with N*(r_max/r_min)*MTU, where r_min and r_max denote the smallest and the largest rate among the rate assignments of all queues in the scheduler, and N is the number of queues in the scheduler.
DRR [12]の場合、eはn*（r_max/r_min）*mtuで線形に成長することが示されます。ここで、R_minとr_maxはスケジューラのすべてのキューのレート割り当ての中で最小で最大のレートを示します。スケジューラのキューの数。
For Start-Time Fair Queuing (SFQ) [9] and Self-Clocked Fair Queuing (SCFQ) [8] E can be shown to grow linearly with the number of queues in the scheduler.
開始時のフェアキューイング（SFQ）[9]およびセルフクロックされたフェアキューイング（SCFQ）[8] Eは、スケジューラのキューの数とともに直線的に成長することが示されます。
In this section we consider a router which is modeled as follows. A packet entering the router may experience a variable delay D_v with a known upper bound D. That is, 0<=D_v<=D. At the output all EF packets share a single class queue. Class queues are scheduled by a scheduler with a known value E_p(S)=E(S) (where E(S) corresponds to the model where this scheduler is implemented in an ideal output buffered device).
このセクションでは、次のようにモデル化されたルーターを検討します。ルーターに入るパケットは、既知の上限Dを使用して可変遅延d_vを経験する場合があります。つまり、0 <= d_v <= d。出力では、すべてのEFパケットが単一のクラスキューを共有します。クラスキューは、既知の値E_P（s）= e（s）（E（s）が理想的な出力バッファーデバイスにこのスケジューラが実装されるモデルに対応するスケジューラによってスケジュールされます。
The computation of E_p is more complicated in this case. For such device, it can be shown that E_p = E(S)+2D+2B/R (see [13]).
この場合、E_Pの計算はより複雑です。このようなデバイスについては、E_P = E（s）2d 2b/rであることを示すことができます（[13]を参照）。
Recall from the discussion of section 3 that bounding input burstiness B may not be easy in a general topology. In the absence of the knowledge of a bound on B one can bound E_p as E_p = E(S) + D*C_inp/R (see [13]).
セクション3の議論から、一般的なトポロジーでは、境界の入力バースティネスBは容易ではないかもしれないことを思い出してください。bの境界の知識がない場合、e_p = e（s）d*c_inp/rとしてe_pを結合できます（[13]を参照）。
Note also that the bounds in this section are derived using only the bound on the variable portion of the interval delay and the error bound of the output scheduler. If more details about the architecture of a device are available, it may be possible to compute better bounds.
また、このセクションの境界は、間隔遅延の変数部分と出力スケジューラのエラー境界のみのバウンドのみを使用して導出されることに注意してください。デバイスのアーキテクチャの詳細が利用可能な場合は、より良い境界線を計算できる可能性があります。
This informational document provides additional information to aid in understanding of the EF PHB described in [6]. It adds no new functions to it. As a result, it adds no security issues to those described in that specification.
この情報文書は、[6]に記載されているEF PHBの理解を支援するための追加情報を提供します。新しい機能は追加されません。その結果、その仕様に記載されているものにセキュリティの問題は追加されません。
[1] J.C.R. Bennett and H. Zhang, "WF2Q: Worst-case Fair Weighted Fair Queuing", INFOCOM'96, March 1996.
[1] J.C.R.Bennett and H. Zhang、「WF2Q：最悪のフェアの加重公正なキューイング」、Infocom'96、1996年3月。
[2] J.-Y. Le Boudec, P. Thiran, "Network Calculus", Springer Verlag Lecture Notes in Computer Science volume 2050, June 2001 (available online at http://lcawww.epfl.ch).
[2] J.-Y。Le Boudec、P。Thiran、「Network Calculus」、Springer Verlag講義ノート2001年6月（http://lcawww.epfl.ch）。
[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] J.C.R. Bennett, K. Benson, A. Charny, W. Courtney, J.Y. Le Boudec, "Delay Jitter Bounds and Packet Scale Rate Guarantee for Expedited Forwarding", Proc. Infocom 2001, April 2001.
[4] J.C.R.ベネット、K。ベンソン、A。チャーニー、W。コートニー、J.Y。Le Boudec、「迅速な転送のためのジッターの境界とパケットスケールレート保証の遅延」、Proc。Infocom 2001、2001年4月。
[5] A. Charny, J.-Y. Le Boudec "Delay Bounds in a Network with Aggregate Scheduling". Proc. of QoFIS'2000, September 25-26, 2000, Berlin, Germany.
[5] A.チャーニー、J.-Y。Le Boudec「集約スケジューリングを備えたネットワーク内の遅延境界」。Proc。Qofis'2000、2000年9月25〜26日、ベルリン、ドイツ。
[6] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[6] Davie、B.、Charny、A.、Baker、F.、Bennett、J.C.R.、Benson、K.、Boudec、J.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、ラマクリシュナン、K.K。D. Stiliadis、「迅速な転送PHB（ホップごとの行動）」、RFC 3246、2002年3月。
[7] T. Ferrari and P. F. Chimento, "A Measurement-Based Analysis of Expedited Forwarding PHB Mechanisms," Eighth International Workshop on Quality of Service, Pittsburgh, PA, June 2000.
[7] T. FerrariおよびP. F. Chimento、「迅速な転送PHBメカニズムの測定ベースの分析」、2000年6月、ペンシルベニア州ピッツバーグのサービス品質に関する第8回国際ワークショップ。
[8] S.J. Golestani. "A Self-clocked Fair Queuing Scheme for Broad-band Applications". In Proceedings of IEEE INFOCOM'94, pages 636-646, Toronto, CA, April 1994.
[8] S.J.ゴレスニ。「ブロードバンドアプリケーションのための自己詰まった公正キューイングスキーム」。IEEE InfoCom'94の議事録、ページ636-646、カリフォルニア州トロント、1994年4月。
[9] P. Goyal, H.M. Vin, and H. Chen. "Start-time Fair Queuing: A Scheduling Algorithm for Integrated Services". In Proceedings of the ACM-SIGCOMM 96, pages 157-168, Palo Alto, CA, August 1996.
[9] P.ゴイヤル、H.M。ヴィン、およびH.チェン。「開始時のフェアキューイング：統合サービスのスケジューリングアルゴリズム」。1996年8月、ACM-Sigcomm 96、157-168、パロアルト157〜168ページの議事録。
[10] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[10] Jacobson、V.、Nichols、K。およびK. Poduri、「迅速な転送PHB」、RFC 2598、1999年6月。
[11] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire' Behavior Aggregate", Work in Progress.
[11] Jacobson、V.、Nichols、K。およびK. Poduri、「「仮想ワイヤ」の動作集合体」は、進行中の作業です。
[12] M. Shreedhar and G. Varghese. "Efficient Fair Queuing Using Deficit Round Robin". In Proceedings of SIGCOMM'95, pages 231-243, Boston, MA, September 1995.
[12] M.シュリーダーとG.バルゲーゼ。「赤字ラウンドロビンを使用した効率的な公正キューイング」。1995年9月、マサチューセッツ州ボストンの231〜243ページのSigcomm'95の議事録。
[13] Le Boudec, J.-Y., Charny, A. "Packet Scale Rate Guarantee for non-FIFO Nodes", Infocom 2002, New York, June 2002.
[13] Le Boudec、J.-Y.、Charny、A。
The definition of the EF PHB as given in [10] states:
[10]の状態で与えられたEF PHBの定義：
"The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It [the EF PHB departure rate] SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate."
「EF PHBは、DiffServノードからの集合体のパケットの出発速度が構成可能な速度を等しく、または超える特定のDiffServ骨材の転送処理として定義されます。EFトラフィックは、他のトラフィックの強度とは無関係にこのレートを受け取る必要があります。ノードを通過しようとします。IT[EF PHB出発率]は、設定されたレートで出力リンクMTUサイズのパケットを送信するのにかかる時間以下の時間間隔で測定された場合、少なくとも構成されたレートを平均する必要があります。」
A literal interpretation of the definition would consider the behaviors given in the next two subsections as non-compliant. The definition also unnecessarily constrains the maximum configurable rate of an EF aggregate.
定義の文字通りの解釈は、次の2つのサブセクションで与えられた動作を非準拠と見なします。また、この定義は、EF集合体の最大構成レートを不必要に制約します。
Consider the following stream forwarded from a router with EF-configured rate R=C/2, where C is the output line rate. In the illustration, E is an MTU-sized EF packet while x is a non-EF packet or unused capacity, also of size MTU.
eFが構成されたレートr = c/2のルーターから転送された次のストリームを考えてみましょう。ここで、Cは出力ラインレートです。イラストでは、EはMTUサイズのEFパケットであり、XはサイズのMTUの非EFパケットまたは未使用容量です。
E x E x E x E x E x E x...
|-----|
The interval between the vertical bars is 3*MTU/C, which is greater than MTU/(C/2), and so is subject to the EF PHB definition. During this interval, 3*MTU/2 bits of the EF aggregate should be forwarded, but only MTU bits are forwarded. Therefore, while this forwarding pattern should be considered compliant under any reasonable interpretation of the EF PHB, it actually does not formally comply with the definition of RFC 2598.
垂直バー間の間隔は3*mtu/Cであり、これはmtu/（c/2）よりも大きいため、EF PHB定義の対象となります。この間隔では、EF凝集体の3*MTU/2ビットを転送する必要がありますが、MTUビットのみが転送されます。したがって、この転送パターンは、EF PHBの合理的な解釈の下で準拠していると見なされるべきですが、実際にはRFC 2598の定義に正式に準拠していません。
Note that this forwarding pattern can occur in any work-conserving scheduler in an ideal output-buffered architecture where EF packets arrive in a perfectly clocked manner according to the above pattern and are forwarded according to exactly the same pattern in the absence of any non-EF traffic.
この転送パターンは、上記のパターンに応じてEFパケットが完全にクロックされた方法で到着する理想的な出力バッファーアーキテクチャで、作業制度のスケジューラで発生する可能性があり、非以外の場合はまったく同じパターンに従って転送されることに注意してください。EFトラフィック。
Trivial as this example may be, it reveals the lack of mathematical precision in the formal definition. The fact that no work-conserving scheduler can formally comply with the definition is unfortunate, and appears to warrant some changes to the definition that would correct this problem.
この例が些細なことであるかもしれませんが、正式な定義には数学的な精度がないことが明らかになります。作業担当スケジューラが定義に正式に準拠することができないという事実は不幸であり、この問題を修正する定義のいくつかの変更を保証しているようです。
The underlying reason for the problem described here is quite simple - one can only expect that the EF aggregate is served at configured rate in some interval where there is enough backlog of EF packets to sustain that rate. In the example above the packets come in exactly at the rate at which they are served, and so there is no persistent backlog. Certainly, if the input rate is even smaller than the configured rate of the EF aggregate, there will be no backlog as well, and a similar formal difficulty will occur.
ここで説明する問題の根本的な理由は非常に単純です - EF集計は、そのレートを維持するためにEFパケットのバックログが十分にある間隔で構成されたレートで提供されることのみを期待できます。上の例では、パケットが提供される速度で正確に入っているため、永続的なバックログはありません。確かに、EF集合体の構成されたレートよりも入力率がさらに小さい場合、バックログもありません。また、同様の正式な難易度が発生します。
A seemingly simple solution to this difficulty might be to require that the EF aggregate is served at its configured rate only when the queue is backlogged. However, as we show in the remainder of this section, this solution does not suffice.
この困難に対する一見シンプルな解決策は、キューがバックログされた場合にのみ、EF集合体がその構成レートで提供されることを要求することです。ただし、このセクションの残りの部分で示すように、このソリューションでは十分ではありません。
We now argue that the example considered in the previous section is not as trivial as it may seem at first glance.
私たちは今、前のセクションで考慮された例は、一見したように見えるほど些細なものではないと主張しています。
Consider a router with EF configured rate R = C/2 as in the previous example, but with an internal delay of 3T (where T = MTU/C) between the time that a packet arrives at the router and the time that it is first eligible for forwarding at the output link. Such things as header processing, route look-up, and delay in switching through a multi-layer fabric could cause this delay. Now suppose that EF traffic arrives regularly at a rate of (2/3)R = C/3. The router will perform as shown below.
前の例のように、EF構成レートr = c/2のルーターを考えてみましょうが、パケットがルーターに到着する時間と最初の時間までの間に3T（t = mtu/c）の内部遅延があります出力リンクで転送する資格があります。ヘッダー処理、ルートの検索、多層ファブリックの切り替えの遅延などのものは、この遅延を引き起こす可能性があります。ここで、EFトラフィックが（2/3）r = c/3のレートで定期的に到着するとします。ルーターは、以下に示すように実行されます。
EF Packet Number 1 2 3 4 5 6 ...
EFパケット番号1 2 3 4 5 6 ...
Arrival (at router) 0 3T 6T 9T 12T 15T ...
到着（ルーターで）0 3t 6t 9t 12t 15t ...
Arrival (at scheduler) 3T 6T 9T 12T 15T 18T ...
到着（スケジューラに）3t 6t 9t 12t 15t 18t ...
Departure 4T 7T 10T 13T 16T 19T ...
出発4t 7t 10t 13t 16t 19t ...
Again, the output does not satisfy the RFC 2598 definition of EF PHB. As in the previous example, the underlying reason for this problem is that the scheduler cannot forward EF traffic faster than it arrives. However, it can be easily seen that the existence of internal delay causes one packet to be inside the router at all times. An external observer will rightfully conclude that the number of EF packets that arrived to the router is always at least one greater than the number of EF packets that left the router, and therefore the EF aggregate is constantly backlogged. However, while the EF aggregate is continuously backlogged, the observed output rate is nevertheless strictly less that the configured rate.
繰り返しますが、出力はEF PHBのRFC 2598定義を満たしていません。前の例のように、この問題の根本的な理由は、スケジューラが到着よりも速くEFトラフィックを転送できないことです。ただし、内部遅延の存在により、1つのパケットが常にルーター内にあることがわかります。外部オブザーバーは、ルーターに到着したEFパケットの数は、ルーターを離れたEFパケットの数より少なくとも1つ大きいため、EF集約が常にバックログされていると正当に結論付けます。ただし、EF集合体は継続的にバックログされますが、それでも観測された出力率は、構成レートよりも厳密に少ないです。
This example indicates that the simple addition of the condition that EF aggregate must receive its configured rate only when the EF aggregate is backlogged does not suffice in this case.
この例は、EF凝集体がバックログに詰まっている場合にのみ、EF凝集体が構成されたレートを受信する必要があるという条件の単純な追加では、この場合には十分ではないことを示しています。
Yet, the problem described here is of fundamental importance in practice. Most routers have a certain amount of internal delay. A vendor declaring EF compliance is not expected to simultaneously declare the details of the internals of the router. Therefore, the existence of internal delay may cause a perfectly reasonable EF implementation to display seemingly non-conformant behavior, which is clearly undesirable.
しかし、ここで説明する問題は、実際には根本的に重要です。ほとんどのルーターには、一定量の内部遅延があります。EFコンプライアンスを宣言するベンダーは、ルーターの内部の詳細を同時に宣言することは期待されていません。したがって、内部遅延の存在により、完全に合理的なEF実装が一見不適合な動作を表示する可能性がありますが、これは明らかに望ましくありません。
It is well understood that with any non-preemptive scheduler, the RFC-2598-compliant configurable rate for an EF aggregate cannot exceed C/2 [11]. This is because an MTU-sized EF packet may arrive to an empty queue at time t just as an MTU-sized non-EF packet begins service. The maximum number of EF bits that could be forwarded during the interval [t, t + 2*MTU/C] is MTU. But if configured rate R > C/2, then this interval would be of length greater than MTU/R, and more than MTU EF bits would have to be served during this interval for the router to be compliant. Thus, R must be no greater than C/2.
非プリエンプティブスケジューラーでは、EF凝集体のRFC-2598に準拠した構成レートはC/2を超えることはできないことがよく理解されています[11]。これは、MTUサイズのEFパケットがMTUサイズの非EFパケットがサービスを開始するのと同じように、時間tで空のキューに到着する可能性があるためです。間隔[t、t 2*mtu/c]中に転送できるEFビットの最大数はmtuです。ただし、構成されたレートr> c/2の場合、この間隔はMTU/Rよりも長くなり、ルーターが準拠するためにはこの間隔中にMTU EFビット以上を提供する必要があります。したがって、rはc/2以下でなければなりません。
It can be shown that for schedulers other than PQ, such as various implementations of WFQ, the maximum compliant configured rate may be much smaller than 50%. For example, for SCFQ [8] the maximum configured rate cannot exceed C/N, where N is the number of queues in the scheduler. For WRR, mentioned as compliant in section 2.2 of RFC 2598, this limitation is even more severe. This is because in these schedulers a packet arriving to an empty EF queue may be forced to wait until one packet from each other queue (in the case of SCFQ) or until several packets from each other queue (in the case of WRR) are served before it will finally be forwarded.
WFQのさまざまな実装など、PQ以外のスケジューラの場合、最大準拠の構成レートは50％よりはるかに小さいことが示されます。たとえば、SCFQ [8]の場合、最大構成速度はC/Nを超えることはできません。ここで、nはスケジューラのキューの数です。RFC 2598のセクション2.2で準拠していると言及されているWRRの場合、この制限はさらに深刻です。これは、これらのスケジューラーでは、空のefキューに到着するパケットが、互いのキュー（SCFQの場合）から1つのパケット（scfqの場合）またはお互いのキューからのいくつかのパケット（WRRの場合）が提供されるまで待つことを余儀なくされる可能性があるためです。最終的に転送される前に。
While it is frequently assumed that the configured rate of EF traffic will be substantially smaller than the link bandwidth, the requirement that this rate should never exceed 50% of the link bandwidth appears unnecessarily limiting. For example, in a fully connected mesh network, where any flow traverses a single link on its way from source to its destination there seems no compelling reason to limit the amount of EF traffic to 50% (or an even smaller percentage for some schedulers) of the link bandwidth.
EFトラフィックの構成された速度はリンク帯域幅よりも大幅に小さくなると頻繁に想定されていますが、このレートが決してリンク帯域幅の50％を超えないという要件は不必要に制限されていると思われます。たとえば、フローがソースから目的地に向かう途中で単一のリンクを通過する完全に接続されたメッシュネットワークでは、EFトラフィックの量を50％に制限する説得力のある理由はないように思われます（または一部のスケジューラーではさらに少ない割合）リンク帯域幅の。
Another, perhaps even more striking example is the fact that even a TDM circuit with dedicated slots cannot be configured to forward EF packets at more than 50% of the link speed without violating RFC 2598 (unless the entire link is configured for EF). If the configured rate of EF traffic is greater than 50% (but less than the link speed), there will always exist an interval longer than MTU/R in which less than the configured rate is achieved. For example, suppose the configured rate of the EF aggregate is 2C/3. Then the forwarding pattern of the TDM circuit might be
もう1つのさらに顕著な例は、専用スロットを備えたTDM回路でさえ、RFC 2598に違反することなくリンク速度の50％以上でEFパケットを転送するように構成できないという事実です（リンク全体がEFに対して構成されていない限り）。EFトラフィックの構成されたレートが50％を超える（ただし、リンク速度よりも少ない）場合、構成されたレートよりも少ないMTU/Rよりも長い間隔が存在します。たとえば、EF凝集体の構成された速度が2c/3であるとします。次に、TDM回路の転送パターンは
E E x E E x E E x ... |---|
e e x e e x e e x ... | --- |
where only one packet is served in the marked interval of length 2T = 2MTU/C. But at least 4/3 MTU would have to be served during this interval by a router in compliance with the definition in RFC 2598. The fact that even a TDM line cannot be booked over 50% by EF traffic indicates that the restriction is artificial and unnecessary.
ここで、長さ2T = 2MTU/Cのマークされた間隔で1つのパケットのみが提供されます。しかし、RFC 2598の定義に準拠して、この間隔中にルーターによってこの間隔中に提供される必要があります。TDMラインでさえEFトラフィックで50％以上予約できないという事実は、制限が人工的であり、不要。
One possibility to correct the problems discussed in the previous sections might be to attempt to clarify the definition of the intervals to which the definition applied or by averaging over multiple intervals. However, an attempt to do so meets with considerable analytical and implementation difficulties. For example, attempting to align interval start times with some epochs of the forwarded stream appears to require a certain degree of global clock synchronization and is fraught with the risk of misinterpretation and mistake in practice.
前のセクションで議論された問題を修正する可能性の1つは、定義が適用される間隔の定義を明確にしようとするか、複数の間隔で平均化することで明確にすることです。ただし、そうする試みは、かなりの分析と実装の困難に満ちています。たとえば、転送されたストリームのいくつかのエポックと間隔開始時間を調整しようとすると、ある程度のグローバルなクロック同期が必要であるように見え、実際に誤った解釈と間違いのリスクがあります。
Another approach might be to allow averaging of the rates over some larger time scale. However, it is unclear exactly what finite time scale would suffice in all reasonable cases. Furthermore, this approach would compromise the notion of very short-term time scale guarantees that are the essence of EF PHB.
別のアプローチは、いくつかのより大きな時間尺度にわたってレートの平均化を許可することです。ただし、すべての合理的なケースで、どのような有限時間スケールが十分であるかは正確には不明です。さらに、このアプローチは、EF PHBの本質である非常に短期的な時間スケール保証の概念を損なうでしょう。
We also explored a combination of two simple fixes. The first is the addition of the condition that the only intervals subject to the definition are those that fall inside a period during which the EF aggregate is continuously backlogged in the router (i.e., when an EF packet is in the router). The second is the addition of an error (latency) term that could serve as a figure-of-merit in the advertising of EF services.
また、2つの簡単な修正の組み合わせも検討しました。1つ目は、定義の対象となる間隔のみが、EF集合体がルーターで連続的にバックログされる期間内（つまり、EFパケットがルーターにある場合）の期間内に落ちる条件の追加です。2つ目は、EFサービスの広告におけるメリットの数字として機能する可能性のあるエラー（レイテンシ）用語の追加です。
With the addition of these two changes the candidate definition becomes as follows: In any interval of time (t1, t2) in which EF traffic is continuously backlogged, at least R(t2 - t1 - E) bits of EF traffic must be served, where R is the configured rate for the EF aggregate and E is an implementation-specific latency term.
これらの2つの変更を追加すると、候補定義は次のようになります。EFトラフィックが継続的にバックログされる時間間隔（T1、T2）で、少なくともR（T2 -T1 -E）のEFトラフィックのビットを提供する必要があります。ここで、RはEF集合体の構成レートであり、Eは実装固有のレイテンシ項です。
The "continuously backlogged" condition eliminates the insufficient-packets-to-forward difficulty while the addition of the latency term of size MTU/C resolves the perfectly-clocked forwarding example (section A.1), and also removes the limitation on EF configured rate.
「継続的にバックログされた」条件は、サイズのMTU/Cのレイテンシ項の追加が完全に2枚の転送例（セクションA.1）を解決し、構成されたEFの制限を削除しながら、不十分なパケットから前方への難易度を排除します。レート。
However, neither fix (nor the two of them together) resolves the example of section A.2. To see this, recall that in the example of section A.2 the EF aggregate is continuously backlogged, but the service rate of the EF aggregate is consistently smaller than the configured rate, and therefore no finite latency term will suffice to bring the example into conformance.
ただし、修正（それらの2つも一緒に）も、セクションA.2の例を解決しません。これを確認するには、セクションA.2の例ではEF集合体が連続的にバックログされているが、EF集合体のサービスレートは構成されたレートよりも一貫して小さく、したがって、例を実現するのに十分な有限遅延項が十分ではないことを思い出してください適合。
The proofs of several bounds in this document can be found in [13]. These proofs use an algebraic characterization of the aggregate definition given by (eq_1), (eq_2), and packet identity aware definition given by (eq_3), (eq_4). Since this characterization is of interest on its own, we present it in this section.
このドキュメントのいくつかの境界の証明は[13]にあります。これらの証明は、（eq_1）、（eq_2）、および（eq_3）、（eq_4）によって与えられたパケットアイデンティティ認識定義によって与えられた凝集定義の代数的特性評価を使用します。この特性はそれ自体が興味深いので、このセクションで提示します。
Theorem B1. Characterization of the aggregate definition without f_n.
定理B1。f_nなしの集約定義の特性評価。
Consider a system where packets are numbered 1, 2, ... in order of arrival. As in the aggregate definition, call a_n the n-th arrival time, d_n - the n-th departure time, and l_n the size of the n-th packet to depart. Define by convention d_0=0. The aggregate definition with rate R and latency E_a is equivalent to saying that for all n and all 0<=j<= n-1:
パケットに番号が付けられているシステムを考えてみましょう。集約定義のように、n-thriver到着時間、d_n- n第3出発時間、l_nを出発するn番目のパケットのサイズを呼び出します。コンベンションD_0 = 0で定義します。レートrおよびレイテンシe_aを使用した集約定義は、すべてのnおよびすべての0 <= j <= n-1についてそれを言うことと同等です。
d_n <= E_a + d_j + (l_(j+1) + ... + l_n)/R (eq_b1)
or
または又はそれとも若しくは乃至或るいは
there exists some j+1 <= k <= n such that
d_n <= E_a + a_k + (l_k + ... + l_n)/R (eq_b2)
Theorem B2. Characterization of packet-identity-aware definition without F_n.
定理B2。f_nなしのパケットアイデンティティアウェア定義の特性評価。
Consider a system where packets are numbered 1, 2, ... in order of arrival. As in the packet-identity-aware definition, call A_n, D_n the arrival and departure times for the n-th packet, and L_n the size of this packet. Define by convention D_0=0. The packet identity aware definition with rate R and latency E_p is equivalent to saying that for all n and all 0<=j<= n-1:
パケットに番号が付けられているシステムを考えてみましょう。パケットアイデンティティアウェアの定義と同様に、A_N、D_Nを呼び出し、N-THパケットの到着時間と出発時間、およびこのパケットのサイズをL_N。コンベンションD_0 = 0で定義します。レートrおよびレイテンシe_pを使用したパケットアイデンティティ認識定義は、すべてのnおよびすべての0 <= j <= n-1についてそれを言うことと同等です。
D_n <= E_p + D_j + (L_{j+1} + ... + L_n)/R (eq_b3)
or
または又はそれとも若しくは乃至或るいは
there exists some j+1 <= k <= n such that
D_n <= E_p + A_k + (L_k + ... + L_n)/R (eq_b4)
For the proofs of both Theorems, see [13].
両方の定理の証明については、[13]を参照してください。
Acknowledgements
謝辞
This document could not have been written without Fred Baker, Bruce Davie and Dimitrios Stiliadis. Their time, support and insightful comments were invaluable.
この文書は、フレッド・ベイカー、ブルース・デイビー、ディミトリオス・スティリアディスなしでは書かれていなかったでしょう。彼らの時間、サポート、洞察力のあるコメントは非常に貴重でした。
Authors' Addresses
著者の住所
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
Angela Chiu Celion Networks 1 Sheila Drive, Suite 2 Tinton Falls, NJ 07724
アンジェラチウセリオンネットワーク1シーラドライブ、スイート2ティントンフォールズ、ニュージャージー07724
EMail: angela.chiu@celion.com
Bill Courtney
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
Shahram Davari PMC-Sierra Inc 411 Legget Drive Ottawa、K2K 3C9、カナダ
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
Charles Kalmanek AT&T Labs-Research 180 Park Avenue, Room A113, Florham Park NJ
チャールズ・カルマネクAT＆T Labs-Research 180 Park Avenue、Room A113、Florham Park NJ
EMail: crk@research.att.com
K.K. Ramakrishnan TeraOptic Networks, Inc. 686 W. Maude Ave Sunnyvale, CA 94086
K.K.Ramakrishnan Teraoptic Networks、Inc。686 W. Maude Ave Sunnyvale、CA 94086
EMail: kk@teraoptic.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エディター機能の資金は現在、インターネット協会によって提供されています。