RFC3246 日本語訳
3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A.Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S.Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT=33896 bytes) (Obsoletes RFC2598) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.デイビー要求をネットワークでつないでください: 3246 A.シャルニーは以下を時代遅れにします。 2598年のシスコシステムズInc.カテゴリ: 規格は2002年のD.Stiliadisルーセントテクノロジーズの行進のときにJ.C.R.ベネットモトローラK.ベンソンTellabs J.Y.Le Boudec EPFL W.コートニーTRW S.Davari PMC-連峰V.Firoiuノーテルネットワークを追跡します。
An Expedited Forwarding PHB (Per-Hop Behavior)
完全優先転送PHB(1ホップあたりの振舞い)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(1ホップあたりの振舞い)を定義します。 PHBはDifferentiated Services構造の基本的なブロックです。 EF集合が、ある構成されたレートで役立たれているのを確実にすることによってEFが低い遅れ、低いジター、および低い損失サービスにブロックを提供することを意図します。 このドキュメントはRFC2598を時代遅れにします。
Davie, et. al. Standards Track [Page 1] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[1ページ]。
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
1つの序論… 2 RFC2598との1.1関係… EF PHBの3 2定義… 3 2.1 EFの直感的な記述… 3 2.2 EF PHBの公式の定義… 5 長所の2.3の数字… 8 2.4の遅れとジター… 8 2.5の損失… 9 2.6Microflow misordering… 9 2.7 このPHBのためのcodepointは推薦しました… 9 2.8の無常… 10 2.9 トンネリング… 他のPHBsとの10 2.10相互作用… 10 3 セキュリティ問題… 10 4 IANA問題… 11 5つの承認… 11 6つの参照箇所… 11付録: 実現の例… 12人の作者のアドレス… 14 完全な著作権宣言文… 16
1. Introduction
1. 序論
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に実行するネットワーク・ノードは、そのパケット[3、4]に関する特定の推進処理として1ホップあたり1つの振舞い(PHB)を選定するのにIPヘッダーでcodepointを使用します。 このメモは完全優先転送(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を提供することです。 その上、また、待ち行列が利用可能なバッファ領域に比例して短いままで残っているなら、パケット損失は最小限に保たれます。
Davie, et. al. Standards Track [Page 2] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[2ページ]。
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がただ一つのノードの動きを定義するだけであることに注意してください。 このドキュメントの範囲の外にノードの収集の振舞いの仕様があります。 Per-ドメインBehavior(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はDifferentiated Services構造の義務的な部分ではありません--ノードはDS対応であると考えられるためにEF PHBを実行するNOT REQUIREDです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
1.1. Relationship to RFC 2598
1.1. RFC2598との関係
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].
このドキュメントはRFC2598[1]を取り替えます。 主な違いは説明された振舞いの、より厳しい定義を与えるために数学の形式を加えるということです。 [6]でこれのための完全な原理を与えます。
2. Definition of EF PHB
2. EF PHBの定義
2.1. Intuitive Description of EF
2.1. EFの直感的な記述
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交通が与えられた出力インタフェースで役立たれている速度は少なくとも構成されたレートRであるべきである、適当に定義された間隔の間、そのインタフェースへの非EF交通の提供された負荷の如何にかかわらず。 私たちがこの直観を正式にしようとするとき、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.Byを測定するために、私たちがサンプリング誤差を導入するかもしれない適切なスケールを定義するのは難しいです。 長いスケールでは、私たちは過度のジターを許すかもしれません。
Davie, et. al. Standards Track [Page 3] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[3ページ]。
- 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パケットが全くなければ、明確にレートRでEF交通を出すことができませんが、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.
以下での公式の定義はこれらの問題を考慮に入れます。 それは、パケットが理想的にレートRにおいてより速く役立たれるべきであるそのEF、および領域がそのパケットの「理想的な」出発時間からのそれぞれのパケットの実際の出発時間の逸脱であると仮定します。 私たちはそのパケットの最後のビットがノードを出る時とパケットの出発時間を定義します。 それぞれの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.Forの長さL_jのパケット、構成のそのトランスミッション時間が評価する理想的な時代に、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つのケースがあります。 前の(j1番目)出発がそれ自身の理想的な出発時間の後に起こったなら、スケジューラは「遅く、」走ります。 この場合、新しいパケットのサービスを始める理想的な時間は、前の(j1番目)パケットの理想的な出発時間、または新しいパケットの到着時間です、どれがさらに遅れているかなら、到着する前に私たちが、パケットがサービスを始めることを期待できないので。 前の(j1番目)出発がそれ自身の理想的な出発時間の前に起こったなら、スケジューラは「早くに、」走ります。 この場合、新しいパケットのサービスは前のパケットの実際の出発時に始まるべきです。
Once we know the time at which service of the j-th packet should (ideally) begin, then the ideal departure time of the j-th packet is L_j/R seconds later. Thus we are able to express the ideal departure time of the j-th packet in terms of the arrival time of the j-th packet, the actual departure time of the j-1-th packet, and the ideal departure time of the j-1-th packet. Equations eq_1 and eq_2 in Section 2.2 capture this relationship.
一度、私たちがどのサービスのときに時間を知っているか、j、-、パケットが(理想的に)始まるはずであり、その時が理想的な出発第時間である、j、-、何秒も後にパケットはL_j/第Rです。 その結果、私たちが理想的な出発時間を表すことができる、j、-、到着によるパケットが第調節する、j、-、j1番目のパケット、およびj1番目のパケットの理想的な出発時間の実際の出発時間の第パケット。 セクション2.2の方程式eq_1とeq_2はこの関係を得ます。
Davie, et. al. Standards Track [Page 4] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[4ページ]。
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つの部品から成ります: 「集合振舞い」セットとa、「パケットのアイデンティティ意識する、」 方程式のセット。 集合振舞い方程式(eq_1とeq_2)は単に装置によってEF集合に提供されたサービスの特性について説明します。 「パケットのアイデンティティ意識する、」 装置の運転条件に関する知識を考えて、方程式(eq_3とeq_4)は、個々のパケットの遅れにおけるバウンドが計算されるのを可能にします。 セクション2.2で、より詳しくこれらの2セットの方程式の意味について議論します。 これらの2セットの方程式が振舞いの2つの異なった方法ではなく、単一の装置の働きを特徴付ける2つの方法を提供することに注意してください。
2.2. Formal Definition of the EF PHB
2.2. EF PHBの公式の定義
A node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
何らかの構成されたレートRにおける私が以下の方程式を満たさなければならないインタフェースのEFを支えるノード:
d_j <= f_j + E_a for all j > 0 (eq_1)
すべてのj>0のためのd_j<=f_j+E(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)
f_jはすべてのj>0のために+ 最大(_j、分(__d j-1、f j-1))l_j/Rと等しいです。(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、-、去る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、-、噛み付いたことにおいて最終がどれに噛み付くかの前にI、「理想的な」時間から出発するパケットがノードを残すはずであるEF第パケット。
- a_j is the time that the last bit of the j-th EF packet
destined to the output I actually arrives at the node.
- EFパケットは出力に運命づけられました。a_jが最終が噛み付いた時間である、j、-、私は実際にノードに第到着します。
- 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がサイズ(ビット)である、j、-、I.l_jを去るEFパケットは、IPデータグラム(IPヘッダープラスペイロード)の上に測定されて、少しの下層(例えば、MACは層にする)オーバーヘッドも第含んでいません。
- R is the EF configured rate at output I (in bits/second).
- RによるEFが出力I(ビット/秒の)でレートを構成したということです。
Davie, et. al. Standards Track [Page 5] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[5ページ]。
- 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はEF集合の処理のための誤差項です。 EがEFパケットの実際の出発時間と同じパケットの理想的な出発時間の最悪の場合逸脱を表して、すなわち、Eが(d_j--f_j)ですべてのjに上限を提供することに注意してください。
- d_0 and f_0 do not refer to a real packet departure but are
used purely for the purposes of the recursion. The time origin
should be chosen such that no EF packets are in the system at
time 0.
- d_0とf_0は、本当のパケット出発について言及しませんが、再帰の目的に純粋に使用されます。 時間の起源が選ばれるべきであるので、EFパケットが全く時0にシステムにありません。
- for the definitions of a_j and d_j, the "last bit" of the
packet includes the layer 2 trailer if present, because a
packet cannot generally be considered available for forwarding
until such a trailer has been received.
- _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の値で特徴付けることができなければなりません。 Rは、ライン料率か以下であるかもしれません。 E5月は、すべての可能なRのための最悪の場合値が評価するように指定されるか、またはRの機能として言い表されるかもしれません。
Note also that, since a node may have multiple inputs and complex internal scheduling, the j-th EF packet to arrive at the node destined for a certain interface may not be the j-th EF packet to depart from that interface. It is in this sense that eq_1 and eq_2 are unaware of packet identity.
また、それに注意してください、ノードには複数の入力と複雑な内部のスケジューリングがあるかもしれないのでj、-、あるインタフェースに運命づけられたノードに到着するEFパケットが第そうでない、j、-、そのインタフェースを去るEF第パケット。 この意味で、eq_1とeq_2がパケットのアイデンティティに気づかないということです。
In addition, a node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
添加、インタフェースのEFを支えるノードでは、何らかの構成されたレートRにおける私は以下の方程式を満たさなければなりません:
D_j <= F_j + E_p for all j > 0 (eq_3)
D_j<はすべてのj>0のためにF_j+E_pと等しいです。(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)
F_jはすべてのj>0のために+ 最大(_j、分(__D j-1、F j-1))L_j/Rと等しいです。(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がすなわちそうするパケットを考えて、時A_jにインタフェースIに運命づけられたノードに到着した個々のEFパケットの実際の出発時間である、j、-、私がどんな入力でもノードに到着するように運命づけられたEFパケット、D_jはその個々のパケットの最後のビットが実際にインタフェースからのノードをIに出る第時です。
Davie, et. al. Standards Track [Page 6] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[6ページ]。
- 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.
- EFパケットは出力にIを運命づけました。A_jが最終が噛み付いた時間である、j、-、到着するのは実際にノードに第到着します。
- 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、-、I.L_jを出力するために運命づけられているノードに到着するEFパケットは、IPデータグラム(IPヘッダープラスペイロード)の上に測定されて、少しの下層(例えば、MACは層にする)オーバーヘッドも第含んでいません。
- R is the EF configured rate at output I (in bits/second).
- RによるEFが出力I(ビット/秒の)でレートを構成したということです。
- 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パケットの実際の出発時間と同じパケットの理想的な出発時間の最悪の場合逸脱を表して、すなわち、E_pが(D_j--F_j)ですべてのjに上限を提供することに注意してください。
- D_0 and F_0 do not refer to a real packet departure but are
used purely for the purposes of the recursion. The time origin
should be chosen such that no EF packets are in the system at
time 0.
- D_0とF_0は、本当のパケット出発について言及しませんが、再帰の目的に純粋に使用されます。 時間の起源が選ばれるべきであるので、EFパケットが全く時0にシステムにありません。
- for the definitions of A_j and D_j, the "last bit" of the
packet includes the layer 2 trailer if present, because a
packet cannot generally be considered available for forwarding
until such a trailer has been received.
- A_jとD_jの定義のために、存在しているなら、パケットの「最後のビット」は層の2トレーラを含んでいます、推進に利用可能であるとそのようなトレーラを受け取るまで一般にパケットを考えることができないので。
It is the fact that D_j and F_j refer to departure times for the j-th packet to arrive that makes eq_3 and eq_4 aware of packet identity. This is the critical distinction between the last two equations and the first two.
それがD_jとF_jが出発時間を参照する事実である、j、-、到着するeq_3とeq_4をパケットのアイデンティティを意識するようにする第パケット。 これは最後の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対応することのノードSHOULD、それがこれらの方程式に従っている間にそれぞれのインタフェースで支持できる可能なR値の範囲、および各インタフェースで満たすことができるE_pの値で特徴付けることができてください。 E_p5月は、すべての可能なRのための最悪の場合値が評価するように指定されるか、または指定されていて、「未定義」の5月のR.An E_p価値の関数として言い表されるかもしれません。 E_pが未定義であるかもしれない状況の議論に関しては、Appendixと[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
これらの方程式に順応をテストする目的に、時間内に密接に区切られる異なったインタフェースにおけるパケット到着に対処するのが必要であるかもしれません。 2つ以上のEFパケットがインタフェースがほとんど到達する(異なった入力に関して)同じ出力のために運命づけられました。
Davie, et. al. Standards Track [Page 7] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[7ページ]。
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.3. Figures of merit
2.3. 長所の数字
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とE_pは装置のための「長所の数字」として考えられるかもしれません。 Eの、より小さい値は、装置が比較的短いスケールの上で速度Rで、よりスムーズにEF集合に役立つことを意味しますが、Eの、より大きい値は、より長い間隔にわたって測定される場合にだけ速度RでEF集合に役立つよりburstyなスケジューラを含意します。 装置より大きい量に従って、より大きいEがある装置は、より小さいEと共に理想的なサービス率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_pを増加させて、ものが、注意したその結果E_pがそうであるEを通常より増加させるその要素を観測します。E。 概要では、EはレートRにおけるEF集合の理想的なサービスからの逸脱の基準です、E_pが集合の中で非理想的なサービスとパケットの非先入れ先出し法処理の両方を測定しますが。
For more discussion of these issues see the Appendix and [6].
これらの問題の、より多くの議論に関しては、Appendixと[6]を見てください。
2.4. Delay and jitter
2.4. 遅れとジター
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
- Rとレートr<の象徴バケツ=深さBに従って、すべての入力インタフェースにわたってまとめられた出力インタフェースに運命づけられたEF交通の総提供された負荷は境界があります。
Davie, et. al. Standards Track [Page 8] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[8ページ]。
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_変数が修理されたE_と等しいです。
where E_fixed represents the minimum delay that can be experienced by an EF packet through the node.
修理されたE_が最小の遅れを表すところでは、EFパケットはノードを通してそれを経験できます。
2.5. Loss
2.5. 損失
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に順応の「オフライン」のテストを方程式に実行することによって、これをします。 パケットの系列がノードを入力して、残しているのを観測した後に、いなくならなかったパケットを、無くなると思って、入力ストリームから概念的に取り除きます。 残っているパケットは現在到着の流れ(jのa_もの)を構成します、そして、ノードを残したパケットは出発の流れ(jのd_もの)を構成します。 その結果、それらの唯一のパケットがノードを首尾よく通り抜けるそれであると考えることによって、方程式への順応について確かめることができます。
In addition, to assist in meeting the low loss objective of EF, a node MAY be characterized by the operating region in which loss of EF due to congestion will not occur. This MAY be specified, using a token bucket of rate r <= R and burstsize B, as the sum of traffic across all inputs to a given output interface that can be tolerated without loss.
さらに、EFの低い損失目的を満たすのを助けるために、ノードは混雑によるEFの損失が発生しない操作領域によって特徴付けられるかもしれません。 これは指定されるかもしれません、Rとレートr<=burstsize Bの象徴バケツを使用して、損失なしで許容できる与えられた出力インタフェースへのすべての入力の向こう側の交通の合計として。
In the event that loss does occur, the specification of which packets are lost is beyond the scope of this document. However it is a requirement that those packets not lost MUST conform to the equations of Section 2.2.
損失が発生する場合、パケットが無くなる仕様はこのドキュメントの範囲を超えています。 しかしながら、それは失われなかったそれらのパケットがセクション2.2の方程式に従わなければならないという要件です。
2.6. Microflow misordering
2.6. Microflow misordering
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の中で単一のmicroflowに属すパケットが装置の通常の操作で再注文するという装置SHOULD NOT経験を通り抜けるのに集められます。
2.7. Recommended codepoint for this PHB
2.7. このPHBのためのお勧めのcodepoint
Codepoint 101110 is RECOMMENDED for the EF PHB.
Codepoint101110はEF PHBのためのRECOMMENDEDです。
Davie, et. al. Standards Track [Page 9] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[9ページ]。
2.8. Mutability
2.8. 無常
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 MAYのためにマークされて、DSドメイン境界でEF PHBを満たす他のcodepointsだけに述べてください。 DSドメインによって格下げされないか、または別のPHBに促進されたEF PHBs SHOULDのためにマークされたパケット。
2.9. Tunneling
2.9. トンネリング
When EF packets are tunneled, the tunneling packets SHOULD be marked as EF. A full discussion of tunneling issues is presented in [5].
EFであるときに、パケットはトンネルを堀られて、トンネリングパケットはSHOULDです。EFとして、マークされます。 問題にトンネルを堀る十分な議論は[5]に提示されます。
2.10. Interaction with other PHBs
2.10. 他のPHBsとの相互作用
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.
他のPHBsと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は評価して、適切であるなら、サイズを押し破きます、ネットワークによる「舗装用敷石-可能」が管理者であったに違いない(ノードが非揮発性の構成のためにサポートするどんなメカニズムも使用して)なら。
3. Security Considerations
3. セキュリティ問題
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ドメインの縁に対して我が身をかばうために、SHOULDは厳密に隣接している上流のドメインと交渉されたレートまでパケットであるとマークされたすべてのEFを取り締まります。 交渉を超えたパケットはSHOULDを評定します。落とされます。 2つの隣接しているドメインがEFレートを交渉していないなら、川下のドメインSHOULDはレートとして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に対応するDSCPsを持っているパケットだけがDS-ドメインの中でEFに対応するDSCPと共にマークされるのを確実にしなければなりません。 そのような振舞いは必要に応じてそうです。Differentiated Services構造[4]で。 それはイングレスインタフェースで食糧を供給されたどんなTraffic Conditioning Specificationでも特定されないDSCPsを利用しますが、DS-ドメインをEF内部に写像するサービスの否定とサービスの窃盗攻撃から守ります。
Davie, et. al. Standards Track [Page 10] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[10ページ]。
4. IANA Considerations
4. IANA問題
This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [3].
このドキュメントは[3]によって定義されたコードスペースのPool1に1codepoint、101110を割り当てます。
5. Acknowledgments
5. 承認
This document was the result of collaboration and discussion among a large number of people. In particular, Fred Baker, Angela Chiu, Chuck Kalmanek, and K. K. Ramakrishnan made significant contributions to the new EF definition. John Wroclawski provided many helpful comments to the authors. This document draws heavily on the original EF PHB definition of Jacobson, Nichols, and Poduri. It was also greatly influenced by the work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, Kumar, and Schnizlein.
このドキュメントは多くの人々での共同と議論の結果でした。 フレッド・ベイカー、アンジェラ・チウ、チャックKalmanek、およびK.K.Ramakrishnanは新しいEF定義への重要な貢献を特に、しました。 ジョンWroclawskiは多くの役に立つコメントを作者に提供しました。 このドキュメントは大いにジェーコブソン、ニコルズ、およびPoduriのオリジナルのEF PHB定義を利用します。 また、アーミテージ、カサーティ、クロウクロフト、アルペルン、クマー、およびSchnizleinのEFRESOLVEチームの仕事でそれは大いに影響を及ぼされました。
6. References
6. 参照
[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[1] ジェーコブソンとV.とニコルズとK.とK.Poduri、「完全優先転送PHB」、RFC2598 1999年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[4] 黒とD.とブレークとS.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[5] 黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日
[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]シャルニー、A.、パン屋、F.、デイビー、B.、ベネット、J.C.R.、ベンソン、K.、Le Boudec、J.Y.、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、Ramakrishnan、K.K.、およびD.Stiliadis、「EF PHB(1ホップあたりの完全優先転送の振舞い)の新しい定義のための補足的情報」、RFC3247(2002年3月)。
[7] Nichols K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification", RFC 3086, April 2001.
[7] ニコルズK.とB.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」、RFC3086、2001年4月。
Davie, et. al. Standards Track [Page 11] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[11ページ]。
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と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の実現の正準な例であると広くみなされます。 「完全な」出力は交通が安値Eと低いE_pの両方を供給するEFのための優先待ち行列で装置(すなわち、すぐ適切な出力キューにパケットを届けるもの)をバッファリングしました。 EFパケットが出力インタフェースに到着するとき、私たちは、Eに影響を及ぼす主な要因がちょうどトランスミッションを始めた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の実現に関する別の例は荷重している連続スケジューラです。 そのような実現はRの値を通常リンクが疾走するほど高く支持できないでしょう、競争している交通があるときEF交通に役立つことができる最高率が他の待ち行列の数とそれらに与えられた重りで影響を受けるので。 その上、そのような実現は優先待ち行列実現より高いEの値を持っていそうです、連続スケジューラで非EF待ち行列に役立ちながら費やされた時間の結果、等しいすべてのほかの存在。
Finally, it is possible to implement hierarchical scheduling algorithms, such that some non-FIFO scheduling algorithm is run on sub-flows within the EF aggregate, while the EF aggregate as a whole could be served at high priority or with a large weight by the top- level scheduler. Such an algorithm might perform per-input scheduling or per-microflow scheduling within the EF aggregate, for example. Because such algorithms lead to non-FIFO service within the EF aggregate, the value of E_p for such algorithms may be higher than for other implementations. For some schedulers of this type it may be difficult to provide a meaningful bound on E_p that would hold for any pattern of traffic arrival, and thus a value of "undefined" may be most appropriate.
最終的に、階層的なスケジューリングアルゴリズムを実行するのは可能です、何らかの非先入れ先出し法スケジューリングアルゴリズムは高い優先度において、または、大きい重りで全体に役立つことができたようにEFが集める間のEF集合の中のサブ流れで先端の平らなスケジューラによって走らされるように。 そのようなアルゴリズムは例えば、EF集合の中で1入力あたりのスケジューリングかmicroflowスケジューリングを実行するかもしれません。 そのようなアルゴリズムがEF集合の中で非先入れ先出し法サービスにつながるので、そのようなアルゴリズムのためのE_pの値は他の実現より高いかもしれません。 このタイプのいくつかのスケジューラに関しては、交通到着のどんなパターンにも当てはまるE_pで重要なバウンドを提供するのが難しいかもしれなく、その結果、「未定義」の値は最も適切であるかもしれません。
Davie, et. al. Standards Track [Page 12] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[12ページ]。
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の方程式で特殊化可能であるはずです。 EFの複数の例を持っているというEへの効果とそれぞれの例のE_p値は複数の例がどう実行されるかにかなり依存するでしょう。 例えば、マルチレベル優先度スケジューラでは、最優先にはないEFの例はEFの、より高い優先権例が役立たれていますが、それがサービスを全く受けない比較的長い期間になるかもしれません。 これはEとE_pの比較的大きい値をもたらすでしょう。 対照的に、WFQのようなスケジューラでは、EFの各例は何らかの構成されたレートとEの値に役立つ待ち行列で表されるでしょう、そして、ただ一つのEF例に、E_pはそれらと同様であるかもしれません。
Davie, et. al. Standards Track [Page 13] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[13ページ]。
Authors' Addresses
作者のアドレス
Bruce Davie Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、ブルースデイビーシスコシステムズInc.300アポロMA 01824
EMail: bsd@cisco.com
メール: bsd@cisco.com
Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
アンナシャルニーシスコシステムズ300アポロDriveチェルムズフォード、MA 01824
EMail: acharny@cisco.com
メール: acharny@cisco.com
Jon Bennett Motorola 3 Highwood Drive East Tewksbury, MA 01876
ジョン・ベネット・モトローラ3Highwoodのドライブの東テュークスベリー、MA 01876
EMail: jcrb@motorola.com
メール: jcrb@motorola.com
Kent Benson Tellabs Research Center 3740 Edison Lake Parkway #101 Mishawaka, IN 46545
46545におけるケントベンソンTellabsリサーチセンター3740エディソンミシワカ湖公園道路#101
EMail: Kent.Benson@tellabs.com
メール: Kent.Benson@tellabs.com
Jean-Yves Le Boudec ICA-EPFL, INN Ecublens, CH-1015 Lausanne-EPFL, Switzerland
ジーン-イヴLe Boudecイカ-EPFL、旅館Ecublens、CH-1015ローザンヌ-EPFL、スイス
EMail: jean-yves.leboudec@epfl.ch
メール: jean-yves.leboudec@epfl.ch
Bill Courtney TRW Bldg. 201/3702 One Space Park Redondo Beach, CA 90278
ビルコートニーTRW Bldg. リドンドビーチ、201/3702 oneスペースParkカリフォルニア 90278
EMail: bill.courtney@trw.com
メール: bill.courtney@trw.com
Davie, et. al. Standards Track [Page 14] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[14ページ]。
Shahram Davari PMC-Sierra Inc 411 Legget Drive Ottawa, ON K2K 3C9, Canada
K2K 3C9、カナダのShahram Davari PMC-連峰Inc411Legget Driveオタワ
EMail: shahram_davari@pmc-sierra.com
メール: shahram_davari@pmc-sierra.com
Victor Firoiu Nortel Networks 600 Tech Park Billerica, MA 01821
ビルリカ、ビクタFiroiuノーテルネットワーク600の科学技術のPark MA 01821
EMail: vfiroiu@nortelnetworks.com
メール: vfiroiu@nortelnetworks.com
Dimitrios Stiliadis Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
デーメートリオスStiliadisルーセントテクノロジーズ101Crawfordsコーナー道路Holmdel、ニュージャージー 07733
EMail: stiliadi@bell-labs.com
メール: stiliadi@bell-labs.com
Davie, et. al. Standards Track [Page 15] RFC 3246 An Expedited Forwarding PHB March 2002
etデイビー、アル。 規格は2002年の完全優先転送PHB行進のときにRFC3246を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Davie, et. al. Standards Track [Page 16]
etデイビー、アル。 標準化過程[16ページ]
一覧
スポンサーリンク
