RFC4689 日本語訳
4689 Terminology for Benchmarking Network-layer Traffic ControlMechanisms. S. Poretsky, J. Perser, S. Erramilli, S. Khurana. October 2006. (Format: TXT=62369 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Poretsky
Request for Comments: 4689 Reef Point Systems
Category: Informational J. Perser
Veriwave
S. Erramilli
Telcordia
S. Khurana
Motorola
October 2006
Poretskyがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4689年の暗礁ポイントシステムカテゴリ: 情報のJ.のS.Erramilli Telcordia S.KhuranaモトローラPerser Veriwave2006年10月
Terminology for Benchmarking Network-layer Traffic Control Mechanisms
ベンチマーキングネットワーク層トラフィックコントロールメカニズムのための用語
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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.
このドキュメントは定義された評価基準に基づくパケット分類を使用することでトラフィックコントロールを実行する装置のベンチマーキングのために用語について説明します。 用語はデータ飛行機の上でIPトラフィックコントロールメカニズムを評価するのがされた測定に適用されることです。パケット分類のための規則はIPヘッダーのどんな分野にも基づくことができます、Differentiated Services Code Point(DSCP)、またはパケットペイロードのどんな分野などのようにも、ポートナンバーなどのように。
Poretsky, et al. Informational [Page 1] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[1ページ]のRFC4689用語
Table of Contents
目次
1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Term Definitions ................................................4
3.1. Configuration Terms ........................................4
3.1.1. Classification ......................................4
3.1.2. Codepoint Set .......................................4
3.1.3. Forwarding Congestion ...............................5
3.1.4. Congestion Management ...............................6
3.1.5. Flow ................................................7
3.2. Measurement Terms ..........................................7
3.2.1. Forwarding Capacity .................................7
3.2.2. Conforming Packet ...................................8
3.2.3. Nonconforming Packet ................................9
3.2.4. Forwarding Delay ....................................9
3.2.5. Jitter .............................................11
3.2.6. Undifferentiated Response ..........................11
3.3. Sequence Tracking .........................................12
3.3.1. Test Sequence Number ...............................12
3.3.2. Stream .............................................12
3.3.3. In-Sequence Packet .................................13
3.3.4. Out-of-Order Packet ................................14
3.3.5. Duplicate Packet ...................................14
3.4. Vectors ...................................................15
3.4.1. Intended Vector ....................................15
3.4.2. Offered Vector .....................................16
3.4.3. Expected Vectors ...................................16
3.4.4. Output Vectors .....................................23
4. Security Considerations ........................................30
5. Acknowledgements ...............................................30
6. References .....................................................31
6.1. Normative References ......................................31
6.2. Informative References ....................................31
1. 序論…2 2. 既存の定義…3 3. 用語定義…4 3.1. 構成用語…4 3.1.1. 分類…4 3.1.2. Codepointはセットしました…4 3.1.3. 推進混雑…5 3.1.4. 混雑管理…6 3.1.5. 流れてください…7 3.2. 測定用語…7 3.2.1. 推進容量…7 3.2.2. パケットを従わせます…8 3.2.3. パケットをNonconformingします…9 3.2.4. 推進遅れ…9 3.2.5. ジター…11 3.2.6. 応答をUndifferentiatedしました…11 3.3. 系列追跡…12 3.3.1. 一連番号をテストしてください…12 3.3.2. 流れてください…12 3.3.3. 系列のパケット…13 3.3.4. 故障しているパケット…14 3.3.5. パケットをコピーしてください…14 3.4. ベクトル…15 3.4.1. ベクトルを意図します…15 3.4.2. ベクトルを提供します…16 3.4.3. ベクトルを予想します…16 3.4.4. ベクトルを出力してください…23 4. セキュリティ問題…30 5. 承認…30 6. 参照…31 6.1. 標準の参照…31 6.2. 有益な参照…31
1. Introduction
1. 序論
New terminology is needed because most existing measurements assume the absence of congestion and only a single per-hop behavior. This document introduces several new terms that will allow measurements to be taken during periods of congestion.
ほとんどの既存の測定値が混雑の欠如と1ホップあたり1つのただ一つの振舞いだけを仮定するので、新しい用語が必要です。 このドキュメントは測定値が混雑の期間、取るいくつかの新学期を紹介します。
Another key difference from existing terminology is the definition of measurements as observed on egress and ingress of a device/system under test. Again, the existence of congestion requires the addition of egress measurements, as well as of those taken on ingress; without observing traffic leaving a device/system, it is not possible to say whether traffic-control mechanisms effectively dealt with congestion.
既存の用語からの別の主要な違いは装置/システムの出口とイングレスでテストで観測されるように測定値の定義です。 一方、混雑の存在は出口測定値、およびイングレスで取られたものの添加を必要とします。 交通が装置/システムを残しているのを観測しない、事実上、トラフィックコントロールメカニズムが混雑に対処したかどうか言うのは可能ではありません。
Poretsky, et al. Informational [Page 2] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[2ページ]のRFC4689用語
The principal measurements introduced in this document are vectors for rate, delay, and jitter, all of which can be observed with or without congestion of the Device Under Test (DUT)/System Under Test (SUT). This document describes only those terms relevant to measuring behavior of a DUT or SUT at the egress during periods of congestion. End-to-end and service-level measurements are beyond the scope of this document.
本書では紹介された主要な測定はレート、遅れ、およびジターのためのベクトルです。Device Under Test(DUT)/システムUnder Test(SUT)の混雑のあるなしにかかわらずそのすべてを観測できます。 このドキュメントは混雑の期間、出口でDUTかSUTの測定動きに関連しているそれらの用語だけについて説明します。 終わりから終わりとサービスレベル測定値はこのドキュメントの範囲を超えています。
2. Existing Definitions
2. 既存の定義
RFC 1224, "Techniques for Managing Asynchronously Generated Alerts" [St91], is used for 'Time with fine enough units to distinguish between two events'.
「管理するためのテクニックは警戒を非同期に発生した」という[St91]RFC1224は'2回の出来事の間で区別する十分すばらしい単位がある時間'に使用されます。
RFC 1242, "Benchmarking Terminology for Network Interconnect Devices", and RFC 2285, "Benchmarking Terminology for LAN Switching Devices", should be consulted before attempting to make use of this document.
「ネットワーク内部連絡装置のためのベンチマーキング用語」、およびRFC2285、「LAN切換装置のためのベンチマーキング用語」というRFC1242はこのドキュメントを利用するのを試みる前に、相談されるべきです。
RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", section 2, contains discussions of a number of terms relevant to network-layer traffic control mechanisms and should also be consulted.
RFC2474、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」(セクション2)は、ネットワーク層トラフィックコントロールメカニズムに関連している項数の議論を含んでいて、また、相談されるべきです。
For the sake of clarity and continuity, this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference.
明快と連続のために、このRFCはRFC1242のセクション2を始められた定義のためのテンプレートを採用します。 定義は、セクションで一緒に参照する場合に便利なように索引をつけられて、分類されます。
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 BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[Br97]で説明されるように本書では解釈されることであるべきです。 RFC2119は、標準化過程ドキュメントの意図をできるだけ明確にするのを助けるためにこれらのキーワードの使用を定義します。 このドキュメントはこれらのキーワードを使用しますが、このドキュメントは標準化過程ドキュメントではありません。
2.1. Frequently Used Acronyms
2.1. 頻繁に使用された頭文字語
DA Destination Address DS DiffServ DSCP DiffServ Code Point DUT Device Under Test IP Internet Protocol PHB Per Hop Behavior SA Source Address SUT System Under Test
テスト中のホップ振舞いSAソースアドレスSUTシステムあたりのテストIPインターネットプロトコルPHBの下のDA目的地アドレスDS DiffServ DSCP DiffServコード・ポイントDUT装置
Poretsky, et al. Informational [Page 3] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[3ページ]のRFC4689用語
3. Term Definitions
3. 用語定義
3.1. Configuration Terms
3.1. 構成用語
3.1.1. Classification
3.1.1. 分類
Definition:
Selection of packets according to defined rules.
定義: 定義された規則に従ったパケットの品揃え。
Discussion:
Classification determines the per-hop behaviors and traffic
conditioning functions, such as shaping and dropping, that are to
be applied to the packet.
議論: 分類はパケットに適用されることになっている形成や低下などの機能を条件とさせる1ホップあたりの振舞いと交通を決定します。
Classification of packets can be based on the DS field or IP
Precedence in the packet header. Classification can be based on
other IP header fields, such as IP Source Address (SA),
Destination Address (DA), and protocol, or on fields in the packet
payload, such as port number. Classification can also be based on
ingress interface. It is possible to base classification on
Multi-Field (MF) criteria such as IP source and destination
addresses, protocol, and port number. For further discussion of
packet classification and its network applications, see [Bl98].
パケットの分類はDS分野に基づいたそうであることができますかIPがパケットのヘッダーのPrecedenceです。 分類はIP Source Address(SA)や、Destination Address(DA)や、プロトコルなどか、パケットペイロードのフィールドの上の他のIPヘッダーフィールドに基づくことができます、ポートナンバーなどのように。 また、分類はイングレスインタフェースに基づくことができます。 分類をIPソースや送付先アドレスなどのMulti-分野(MF)評価基準に基礎づけて、議定書を作って、数を移植するのは可能です。 パケット分類のさらなる議論とそのネットワーク応用に関しては、[Bl98]を見てください。
Measurement units:
n/a
測定単位: なし
See Also:
None
参照: なし
3.1.2. Codepoint Set
3.1.2. Codepointはセットしました。
Definition:
The set of all DS Code-points or IP precedence values used during
the test duration.
定義: すべてのDS Code-ポイントかIP先行値のセットはテストの間、持続時間を使用しました。
Discussion:
Describes all the code-point markings associated with packets that
are input to the DUT/SUT. For each entry in the codepoint set,
there are associated vectors describing the rate of traffic,
delay, loss, or jitter containing that particular DSCP or IP
precedence value.
議論: DUT/SUTに入力されるパケットに関連しているすべてのコード・ポイント印について説明します。 codepointセットにおける各エントリーには、その特定のDSCPかIP先行価値を含む交通の速度について説明する関連ベクトル、遅れ、損失、またはジターがあります。
The treatment that a packet belonging to a particular code-point
gets is subject to the DUT classifying packets to map to the
correct PHB. Moreover, the forwarding treatment in general is
also dependent on the complete set of offered vectors.
パケットが特定のコード・ポイントに属して、得られる処理は正しいPHBに写像するパケットを分類するDUTを受けることがあります。 そのうえ、また、一般に、推進処理も完全なセットの提供されたベクトルに依存しています。
Poretsky, et al. Informational [Page 4] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[4ページ]のRFC4689用語
Measurement Units:
n/a
測定単位: なし
See Also:
None
参照: なし
3.1.3. Forwarding Congestion
3.1.3. 推進混雑
Definition:
A condition in which one or more egress interfaces are offered
more packets than are forwarded.
定義: 状態進めるより多くのパケットが1つ以上の出口のインタフェースに提供される。
Discussion:
This condition is a superset of the overload definition [Ma98].
Overload [Ma98] deals with overloading input and output interfaces
beyond the maximum transmission allowed by the medium. Forwarding
congestion does not assume ingress interface overload as the only
source of overload on output interfaces.
議論: この状態はオーバーロード定義[Ma98]のスーパーセットです。 媒体が最大のトランスミッションを超えた入出力インタフェースを積みすぎさせられるとの[Ma98]取引を積みすぎてください。 出力でのオーバーロードの唯一の源が連結するとき、推進混雑は、イングレスがインタフェースオーバーロードであると仮定しません。
Another difference between Forwarding Congestion and overload
occurs when the SUT comprises multiple elements, in that
Forwarding Congestion may occur at multiple points. Consider an
SUT comprising multiple edge devices exchanging traffic with a
single core device. Depending on traffic patterns, the edge
devices may induce Forwarding Congestion on multiple egress
interfaces on the core device.
SUTが複数の要素を包括するとき、Forwarding Congestionとオーバーロードの別の違いは起こります、Forwarding Congestionが複数のポイントで起こるかもしれないので。 単芯装置と交通を交換する複数のエッジデバイスを包括するSUTを考えてください。 トラフィック・パターンによって、エッジデバイスはコア装置の上の複数の出口のインタフェースのForwarding Congestionを引き起こすかもしれません。
Throughput [Br91] defines the lower boundary of Forwarding
Congestion. Throughput is the maximum offered rate with no
Forwarding Congestion. At offered rates above throughput, the
DUT/SUT is considered to be in a state of Forwarding Congestion.
スループット[Br91]はForwarding Congestionの低い境界を定義します。 スループットはForwarding Congestionのない最大のオファードレートです。 スループットより高い、オファードレートで、DUT/SUTがForwarding Congestionの州にいると考えられます。
Packet Loss, not increased Forwarding Delay, is the external
observable metric used to indicate the condition of Forwarding
Congestion. Packet Loss is a deterministic indicator of
Forwarding Congestion. The condition of increased Forwarding
Delay without Packet Loss is an indicator of Forwarding Congestion
known as Incipient Congestion. Incipient Congestion is a non-
deterministic indicator of Forwarding Congestion [Fl93]. As
stated in [Ec98], RED [Br98] detects incipient congestion before
the buffer overflows, but the current Internet environment is
limited to packet loss as the mechanism for indicating congestion
to the end-nodes. [Ra99] implies that it is impractical to build
a black-box test to observe Incipient Congestion. [Ra99] instead
introduces Explicit Congestion Notification (ECN) as a
deterministic Black-Box method for observing Incipient Congestion.
[Ra99] is an Experimental RFC with limited deployment, so ECN is
not used for this particular methodology. For the purpose of
増加するForwarding Delayではなく、パケットLossが観察可能な外部である、メートル法、Forwarding Congestionの状態を示すのにおいて、使用されています。 パケットLossはForwarding Congestionの決定論的なインディケータです。 Packet Lossのない増加するForwarding Delayの状態はIncipient Congestionとして知られているForwarding Congestionのインディケータです。 始まりのCongestionはForwarding Congestion[Fl93]の非決定論的なインディケータです。 [Ec98]に述べられているように、バッファがあふれる前にRED[Br98]は始まりの混雑を検出しますが、現在のインターネット環境は混雑をエンドノードに示すためのメカニズムとしてパケット損失に制限されます。 [Ra99]は、Incipient Congestionを観測するためにブラックボックステストを組み込むのが非実用的であることを含意します。 [Ra99]は代わりに、Incipient Congestionを観測するための決定論的なブラックボックス方法としてExplicit Congestion Notification(電子証券取引ネットワーク)を導入します。 [Ra99]が限られた展開があるExperimental RFCであるので、電子証券取引ネットワークはこの特定の方法論に使用されません。 目的
Poretsky, et al. Informational [Page 5] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[5ページ]のRFC4689用語
"black-box" testing a DUT/SUT, this methodology uses Packet Loss
as the indicator of Forwarding Congestion.
DUT/SUT、この方法論をテストする「ブラックボックス」がForwarding CongestionのインディケータとしてPacket Lossを使用します。
Ingress observations alone are not sufficient to cover all cases
in which Forwarding Congestion may occur. A device with an
infinite amount of memory could buffer an infinite number of
packets and eventually forward all of them. However, these
packets may or may not be forwarded during the test duration.
Congestion Collapse [Na84] is defined as the state in which
buffers are full and all arriving packets MUST be dropped across
the network. Even though ingress interfaces accept all packets
without loss, Forwarding Congestion is present in this
hypothetical device.
イングレス観測だけが、Forwarding Congestionが起こるかもしれないすべての場合をカバーするために十分ではありません。 無限の量のメモリがある装置は、無限の数のパケットをバッファリングして、結局、それらを皆、進めるかもしれません。 しかしながら、テスト持続時間の間、これらのパケットを進めるかもしれません。 混雑Collapse[Na84]はバッファが完全である状態と定義されます、そして、ネットワークの向こう側にすべて到着しているパケットを落とさなければなりません。 イングレスインタフェースは損失なしですべてのパケットを受け入れますが、Forwarding Congestionはこの仮定している装置に存在しています。
The definition presented here explicitly defines Forwarding
Congestion as an event observable on egress interfaces.
Regardless of internal architecture, any device exhibiting Packet
Loss on one or more egress interfaces is experiencing Forwarding
Congestion.
ここに明らかに提示された定義は出口のインタフェースで観察可能な出来事とForwarding Congestionを定義します。 内部の構造にかかわらず、1つ以上の出口のインタフェースのPacket Lossを示すどんな装置もForwarding Congestionを経験しています。
Measurement units:
None
測定単位: なし
See Also:
Gateway Congestion Control Survey [Ma91]
参照: ゲートウェイ混雑基準測量[Ma91]
3.1.4. Congestion Management
3.1.4. ふくそう管理
Definition:
An implementation of one or more per-hop behaviors to avoid or
minimize the condition of congestion.
定義: 混雑の状態を避けるか、または最小にする1つ以上のホップの振舞いの実現。
Discussion:
Congestion management may seek either to control congestion or
avoid it altogether through Classification.
議論: ふくそう管理は、Classificationを通して混雑を制御しようとするか、またはそれを全体で避けようとするかもしれません。
Congestion avoidance mechanisms seek to prevent congestion before
it actually occurs.
実際に起こる前に輻輳回避メカニズムは混雑を防ごうとします。
Congestion control mechanisms give one or more flows (with a
discrete IP Precedence or DSCP value) preferential treatment over
other classes during periods of congestion.
混雑制御機構は混雑の期間、他のクラスの上で1回以上の流れ(離散的なIP PrecedenceかDSCP値がある)に優遇を与えます。
Measurement units:
n/a
測定単位: なし
See Also:
Classification
参照: 分類
Poretsky, et al. Informational [Page 6] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[6ページ]のRFC4689用語
3.1.5. Flow
3.1.5. 流れ
Definition:
A flow is one or more packets sharing a common intended pair of
ingress and egress interfaces.
定義: 流れは、イングレスの一般的な意図している組を共有する1つ以上のパケットと出口のインタフェースです。
Discussion:
Packets are grouped by the ingress and egress interfaces they use
on a given DUT/SUT.
議論: パケットはそれらが与えられたDUT/SUTで使用するイングレスと出口のインタフェースによって分類されます。
A flow can contain multiple source IP addresses and/or destination
IP addresses. All packets in a flow MUST enter on the same
ingress interface and exit on the same egress interface and have
some common network layer content.
流れは複数のソースIPアドレス、そして/または、送付先IPアドレスを含むことができます。 流れにおけるすべてのパケットが、同じイングレスインタフェースで入って、同じ出口のインタフェースで出て、何らかの一般的なネットワーク層内容を持たなければなりません。
Microflows [Ni98] are a subset of flows. As defined in [Ni98],
microflows require application-to-application measurement. In
contrast, flows use lower-layer classification criteria. Since
this document focuses on network-layer classification criteria, it
concentrates here on the use of network-layer identifiers in
describing a flow. Flow identifiers also may reside at the data-
link, transport, or application layers of the OSI model. However,
identifiers other than those at the network layer are out of scope
for this document.
Microflows[Ni98]は流れの部分集合です。 [Ni98]で定義されるように、microflowsはアプリケーションからアプリケーションへの測定を必要とします。 対照的に、流れは下層分類評価基準を使用します。 このドキュメントがネットワーク層分類評価基準に焦点を合わせるので、それはここ、流れについて説明することにおけるネットワーク層識別子の使用に集中します。 流れ識別子もOSIモデルのデータリンク、輸送、または応用層に住むかもしれません。 しかしながら、このドキュメントのための範囲の外にネットワーク層におけるそれら以外の識別子があります。
A flow may contain a single code point/IP precedence value or may
contain multiple values destined for a single egress interface.
This is determined by the test methodology.
流れは、ただ一つのコード・ポイント/IP先行価値を含んでいるか、または単一の出口のインタフェースに運命づけられた複数の値を含むかもしれません。 これはテスト方法論で決定します。
Measurement units:
n/a
測定単位: なし
See Also:
Microflow [Ni98]
Streams
参照: Microflow[Ni98]の流れ
3.2. Measurement Terms
3.2. 測定用語
3.2.1. Forwarding Capacity
3.2.1. 推進容量
Definition:
The number of packets per second that a device can be observed to
transmit successfully to the correct egress interface in response
to a specified offered load while the device drops none of the
offered packets.
定義: 装置が提供されたパケットのいずれも落としていない間、首尾よく指定された提供された負荷に対応して正しい出口のインタフェースに伝わるのを装置を観測できる秒あたりのパケットの数。
Poretsky, et al. Informational [Page 7] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[7ページ]のRFC4689用語
Discussion:
Forwarding Capacity measures the packet rate at the egress
interface(s) of the DUT/SUT. In contrast, throughput (as defined
in RFC 1242) measures the packet rate at the ingress interface(s)
of the DUT/SUT.
議論: 推進CapacityはDUT/SUTの出口のインタフェースでパケットレートを測定します。 対照的に、スループット(RFC1242で定義されるように)はDUT/SUTのイングレスインタフェースでパケットレートを測定します。
Ingress-based measurements do not account for queuing of the
DUT/SUT. Throughput rates can be higher than the Forwarding
Capacity because of queueing. The difference is dependent upon
test duration, packet rate, and queue size. Forwarding Capacity,
as an egress measurement, does take queuing into account.
イングレスベースの測定値は、DUT/SUTの列を作るのを説明しません。 押出量は待ち行列のためにForwarding Capacityより高い場合があります。 違いはテスト持続時間、パケットレート、および待ち行列サイズに依存しています。 出口測定としてCapacityを進めると、列を作りは考慮に入れられます。
Understanding Forwarding Capacity is a necessary precursor to any
measurement involving Traffic Control Mechanisms. The
accompanying methodology document MUST take into consideration
Forwarding Capacity when determining the expected forwarding
vectors. When the sum of the expected forwarding vectors on an
interface exceeds the Forwarding Capacity, the Forwarding Capacity
will govern the forwarding rate.
Forwarding Capacityを理解するのは、Traffic Control Mechanismsにかかわるどんな測定への必要な先駆です。予想された推進ベクトルを測定するとき、付随の方法論ドキュメントはForwarding Capacityを考慮に入れなければなりません。 インタフェースの予想された推進ベクトルの合計がForwarding Capacityを超えていると、Forwarding Capacityは伝送速度を決定するでしょう。
This measurement differs from forwarding rate at maximum offered
load (FRMOL) [Ma98] in that the Forwarding Capacity requires zero
loss.
この測定は最大の提供された負荷(FRMOL)[Ma98]において伝送速度とForwarding Capacityが損失を全く必要としないという点で異なっています。
Measurement units:
N-octet packets per second
測定単位: 1秒あたりのN-八重奏パケット
See Also:
Throughput [Br91]
Forwarding Rate at Maximum Offered Load [Ma98]
参照: 最大の提供された負荷におけるスループット[Br91]伝送速度[Ma98]
3.2.2. Conforming Packet
3.2.2. パケットを従わせます。
Definition:
Packets that lie within specific rate, delay, or jitter bounds.
定義: 特定のレート、遅れ、またはジター領域に属すパケット。
Discussion:
A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within predefined
delay or jitter boundaries. All packets that lie within specified
bounds are then said to be conforming, whereas those outside the
bounds are nonconforming.
議論: DUT/SUTは与えられた交通のクラスが与えられた量の帯域幅を消費するのを許容するために構成されたか、または中で秋まで事前に定義された遅れかジター境界であるかもしれません。 次に、指定された領域に属すすべてのパケットが従っていると言われていますが、領域の外のそれらは「非-従」っています。
Measurement units:
n/a
測定単位: なし
Poretsky, et al. Informational [Page 8] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[8ページ]のRFC4689用語
See Also:
Expected Vector
Forwarding Vector
Offered Vector
Nonconforming
参照: 予想されたベクトル推進ベクトル提供されたベクトルNonconforming
3.2.3. Nonconforming Packet
3.2.3. パケットをNonconformingします。
Definition:
Packets that do not lie within specific rate, delay, or jitter
bounds.
定義: 特定のレート、遅れ、またはジター領域に属さないパケット。
Discussion:
A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within predefined
delay or jitter boundaries. All packets that do not lie within
these bounds are then said to be nonconforming.
議論: DUT/SUTは与えられた交通のクラスが与えられた量の帯域幅を消費するのを許容するために構成されたか、または中で秋まで事前に定義された遅れかジター境界であるかもしれません。 そして、これらの領域に属さないすべてのパケットが「非-従」っていると言われています。
Measurement units:
n/a
測定単位: なし
See Also:
Expected Vector
Forwarding Vector
Offered Vector
Conforming
参照: 予想されたベクトル推進ベクトル提供されたベクトルの従うこと
3.2.4. Forwarding Delay
3.2.4. 推進遅れ
Definition:
The time interval starting when the last bit of the input IP
packet is offered to the input port of the DUT/SUT and ending when
the last bit of the output IP packet is received from the output
port of the DUT/SUT.
定義: DUT/SUTの出力ポートから出力IPパケットの最後のビットを受け取るとき、入力IPパケットの最後のビットであるときに始まる時間間隔をDUT/SUTと結末の入力ポートに提供します。
Discussion:
The delay time interval MUST be externally observed. The delay
measurement MUST NOT include delays added by test bed components
other than the DUT/SUT, such as propagation time introduced by
cabling or non-zero delay added by the test instrument.
Forwarding Delay differs from latency [Br91] and one-way delay
[Al99] in several key regards:
議論: 外部的に遅延時間間隔を観測しなければなりません。 遅れ測定はDUT/SUT以外のテストベッドの部品によって加えられた遅れを含んではいけません、時間がケーブリングで導入した伝播や試験計器によって加えられた非ゼロ遅延のように。 推進Delayはいくつかの主要な点の潜在[Br91]と片道遅れ[Al99]と異なっています:
1. Latency [Br91] assumes knowledge of whether the DUT/SUT uses
"store and forward" or "bit forwarding" technology. Forwarding
Delay is the same metric, measured the same way, regardless of
the architecture of the DUT/SUT.
1. 潜在[Br91]はDUT/SUTが「店とフォワード」を使用するか、そして、「噛み付いている推進」技術に関する知識を仮定します。 推進DelayはDUT/SUTの構造にかかわらずメートル法で、測定されていた状態で同じように同じです。
Poretsky, et al. Informational [Page 9] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[9ページ]のRFC4689用語
2. Forwarding Delay is a last-in, last-out (LILO) measurement,
unlike the last-in, first-out method [Br91] or the first-in,
last-out method [Al99].
2. 推進Delayは最後のコネの、そして、最後の出ている(LILO)測定中で持続するか、最初に出ている方法[Br91]または最初に、コネと異なって最後の出ている方法[Al99]です。
The LILO method most closely simulates the way a network-layer
device actually processes an IP datagram. IP datagrams are not
passed up and down the stack unless they are complete, and
processing begins only once the last bit of the IP datagram has
been received.
LILO方法は最も密接にネットワーク層装置が実際にIPデータグラムを処理する方法をシミュレートします。 それらが完全でない場合、IPデータグラムはスタックで上下に渡されません、そして、いったんIPデータグラムの最後のビットを受け取るとだけ、処理は始まります。
Further, the LILO method has an additive property, where the
sum of the parts MUST equal the whole. This is a key
difference from [Br91] and [Al99]. For example, the delay
added by two DUTs MUST equal the sum of the delay of the DUTs.
This may or may not be the case with [Br91] and [Al99].
さらに、LILO方法には、付加的な所有地があります。そこでは、部分の合計が全体と等しくなければなりません。 これは[Br91]と[Al99]からの主要な違いです。 例えば、2DUTsによって加えられた遅れはDUTsの遅れの合計と等しくなければなりません。 これは[Br91]と[Al99]があるそうであるかもしれません。
3. Forwarding Delay measures the IP datagram only, unlike [Br91],
which also includes link-layer overhead.
3. 推進Delayは[Br91]と異なってIPデータグラムだけを測定します。また、]はリンクレイヤオーバーヘッドを含んでいます。
A metric focused exclusively on the Internet protocol relieves
the tester from specifying the start/end for every link-layer
protocol that IP runs on. This avoids the need to determine
whether the start/stop delimiters are included. It also allows
the use of heterogeneous link-layer protocols in a test.
Aメートル法、排他的なインターネットに焦点を合わせられて、テスターは、プロトコルでIPが動くあらゆるリンク層プロトコルに始め/終わりを指定して、安心します。 これは始め/停止デリミタが含まれているかどうか決定する必要性を避けます。 また、それはテストにおける異種のリンク層プロトコルの使用を許します。
4. Forwarding Delay can be measured at any offered load, whereas
the latency methodology [Br99] recommends measurement at, and
only at, the throughput level. Comparing the Forwarding Delay
below the throughput to Forwarding Delay above the Forwarding
Capacity will give insight to the traffic control mechanisms.
4. どんな提供された負荷でも推進Delayを測定できますが、潜在方法論[Br99]はレベルにおけるスループットレベルにおけるだけ測定を推薦します。 Forwarding Capacityの上でスループットより下でForwarding DelayをForwarding Delayと比較すると、洞察はトラフィックコントロールメカニズムに与えられるでしょう。
For example, non-congested delay may be measured with an
offered load that does not exceed the Forwarding Capacity,
while congested delay may involve an offered load that exceeds
the Forwarding Capacity.
例えば、非混雑している遅れはForwarding Capacityを超えていない提供された負荷で測定されるかもしれません、混雑している遅れがForwarding Capacityを超えている提供された負荷を伴うかもしれませんが。
Note: Forwarding Delay SHOULD NOT be used as an absolute
indicator of DUT/SUT Forwarding Congestion. While Forwarding
Delay may rise when offered load nears or exceeds the
Forwarding Capacity, there is no universal point at which
Forwarding Delay can be said to indicate the presence or
absence of Forwarding Congestion.
以下に注意してください。 Delay SHOULDを進めて、DUT/SUT Forwarding Congestionの絶対インディケータとして使用されないでください。 提供された負荷がForwarding Capacityを近づくか、または超えていると、Forwarding Delayは上昇するかもしれませんが、Forwarding Congestionの存在か不在を示すとForwarding Delayを言うことができるどんな普遍的なポイントもありません。
Measurement units:
milliseconds
測定単位: ミリセカンド
Poretsky, et al. Informational [Page 10] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[10ページ]のRFC4689用語
See Also:
Latency [Br91]
Latency [Al99]
One-way Delay [Br99]
参照: 潜在[Br91]潜在[Al99]の片道遅れ[Br99]
3.2.5. Jitter
3.2.5. ジター
Definition:
The absolute value of the difference between the Forwarding Delay
of two consecutive received packets belonging to the same stream.
定義: 同じ流れに属す2つの連続した容認されたパケットのForwarding Delayの違いの絶対値。
Discussion:
The Forwarding Delay fluctuation between two consecutive received
packets in a stream is reported as the jitter. Jitter can be
expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay
and i is the order the packets were received.
議論: 流れの2つの連続した容認されたパケットの間のForwarding Delay変動はジターとして報告されます。 ジターを言い表すことができます。|D(i)--D(i-1)|, DがForwarding Delayと等しく、iがオーダーであるところでは、パケットを受け取りました。
Under loss, jitter can be measured between non-consecutive test
sequence numbers. When IP Traffic Control Mechanisms are dropping
packets, fluctuating Forwarding Delay may be observed. Jitter
MUST be able to benchmark the delay variation independently of
packet loss.
損失で、非連続したテスト一連番号の間でジターを測定できます。 IP Traffic Control Mechanismsがパケットを落としているとき、Forwarding Delayを変動させるのは観測されるかもしれません。 ジターはベンチマークにできるに違いありません。パケット損失の如何にかかわらず遅れ変化。
Jitter is related to the IPDV [De02] (IP Delay Variation) by
taking the absolute value of the ipdv. The two metrics will
produce different mean values. Mean Jitter will produce a
positive value, where the mean ipdv is typically zero. Also, IPDV
is undefined when one packet from a pair is lost.
ジターはipdvの絶対値を取るのによるIPDV[De02](IP Delay Variation)に関連します。 2つの測定基準が異なった平均値を生産するでしょう。 意地悪なJitterは正の数を生産するでしょう。そこでは、通常、意地悪なipdvがゼロです。 また、1組からの1つのパケットが無くなるとき、IPDVも未定義です。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Forwarding Delay
Jitter variation [Ja99]
ipdv [De02]
interarrival jitter [Sc96]
参照: 推進Delay Jitter変化[Ja99]ipdv[De02]interarrivalジター[Sc96]
3.2.6. Undifferentiated Response
3.2.6. 応答をUndifferentiatedしました。
Definition:
The vector(s) obtained when mechanisms used to support diff-serv
or IP precedence are disabled.
定義: メカニズムが以前はよくデフ-servかIP先行を支持していたとき得られたベクトルは障害があります。
Discussion:
Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead may
degrade performance even when traffic belonging to only one class,
議論: デフ-servかIP先行メカニズムを有効にすると、追加処理オーバヘッドはパケットのためにでしゃばるかもしれません。 1つのクラスだけに属す交通でさえあるときに、このオーバーヘッドは性能を下げるかもしれません。
Poretsky, et al. Informational [Page 11] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[11ページ]のRFC4689用語
the best-effort class, is offered to the device. Measurements
with "undifferentiated response" SHOULD be made to establish a
baseline.
ベストエフォート型は属して、装置に提供します。 「非分化している応答」SHOULDは基線を確立させられている測定値。
The vector(s) obtained with DSCP or IP precedence enabled can be
compared to the undifferentiated response to determine the effect
of differentiating traffic.
交通を微分するという効果を決定するためにDSCPかIP先行が有効にされている状態で得られたベクトルは非分化している応答にたとえることができます。
Measurement units:
n/a
測定単位: なし
3.3. Sequence Tracking
3.3. 系列追跡
3.3.1. Test Sequence Number
3.3.1. テスト一連番号
Definition:
A field in the IP payload portion of the packet that is used to
verify the order of the packets on the egress of the DUT/SUT.
定義: DUT/SUTの出口におけるパケットの注文について確かめるのに使用されるパケットのIPペイロード部分の分野。
Discussion:
The traffic generator sets the test sequence number value. Upon
receipt of the packet, the traffic receiver checks the value.
The traffic generator changes the value on each packet transmitted
based on an algorithm agreed to by the traffic receiver.
議論: 交通ジェネレータはテスト一連番号価値を設定します。 パケットを受け取り次第、交通受信機は値をチェックします。 交通ジェネレータは交通受信機によって同意されたアルゴリズムに基づいて伝えられた各パケットの値を変えます。
The traffic receiver keeps track of the sequence numbers on a
per-stream basis. In addition to the number of received packets,
the traffic receiver may also report the number of in-sequence
packets, the number of out-of-sequence packets, the number of
duplicate packets, and the number of reordered packets. The
RECOMMENDED algorithm to change the sequence number on sequential
packets is an incrementing value.
交通受信機は1流れあたり1個のベースで一連番号の動向をおさえます。 また、容認されたパケットの数に加えて、交通受信機は連続してパケットの数、順序が狂ってパケットの数、写しパケットの数、および再命令されたパケットの数を報告するかもしれません。 連続したパケットの一連番号を変えるRECOMMENDEDアルゴリズムは増加している値です。
Measurement units:
n/a
測定単位: なし
See Also:
Stream
参照: 流れ
3.3.2. Stream
3.3.2. 流れ
Definition:
A group of packets tracked as a single entity by the traffic
receiver. A stream MUST share common content, such as type (IP,
UDP), IP SA/DA, packet size, or payload.
定義: パケットのグループは単一体として交通受信機によって追跡されました。流れは一般的な内容を共有しなければなりません、タイプ(IP、UDP)、IP SA/DA、パケットサイズ、またはペイロードなどのように。
Poretsky, et al. Informational [Page 12] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[12ページ]のRFC4689用語
Discussion:
Streams are tracked by test sequence number or "unique signature
field" [Ma00]. Streams define how individual packet statistics
are grouped together to form an intelligible summary.
議論: 流れはテスト一連番号か「ユニークな署名分野」[Ma00]によって追跡されます。 流れは個々のパケット統計が明瞭な概要を形成するためにどう一緒に分類されるかを定義します。
Common stream groupings would be by egress interface, destination
address, source address, DSCP, or IP precedence. A stream using
test sequence numbers can track the ordering of packets as they
traverse the DUT/SUT.
一般的な流れの組分けが出口のインタフェース、送付先アドレス、ソースアドレス、DSCP、またはIP先行であるでしょう。 DUT/SUTを横断するとき、テスト一連番号を使用する流れはパケットの注文を追跡できます。
Streams are not restricted to a pair of source and destination
interfaces as long as all packets are tracked as a single entity.
A multicast stream can be forwarded to multiple destination
interfaces.
すべてのパケットが単一体として跡をつけられる限り、流れは1組のソースと目的地のインタフェースに制限されません。 複数の目的地のインタフェースにマルチキャスト小川を送ることができます。
Measurement units:
n/a
測定単位: なし
See Also:
Flow
Microflow [Ni98]
Test sequence number
参照: 流れMicroflow[Ni98]テスト一連番号
3.3.3. In-Sequence Packet
3.3.3. 連続してパケット
Definition:
A received packet with the expected Test Sequence number.
定義: 予想されたTest Sequence番号がある容認されたパケット。
Discussion:
In-sequence is done on a stream level. As packets are received on
a stream, each packet's Test Sequence number is compared with the
previous packet. Only packets that match the expected Test
Sequence number are considered in-sequence.
議論: 連続して、流れのレベルでは、します。 流れの上にパケットを受け取るように、各パケットのTest Sequence番号は前のパケットと比較されます。 予想されたTest Sequence番号に合っているパケットだけが連続して考えられます。
Packets that do not match the expected Test Sequence number are
counted as "not in-sequence" or out-of-sequence. Every packet
that is received is either in-sequence or out-of-sequence.
Subtracting the in-sequence from the received packets (for that
stream), the tester can derive the out-of-sequence count.
予想されたTest Sequence番号に合っていないパケットが「系列でない」か順序が狂って数えられます。 あらゆる受け取られていているパケットが連続してか順序が狂ってそうです。 容認されたパケット(その流れのための)から系列を引き算して、テスターは系列で出ているカウントを引き出すことができます。
Two types of events will prevent the in-sequence from
incrementing: packet loss and reordered packets.
2つのタイプの出来事は、系列が以下を増加するのを防ぐでしょう。 パケット損失と再命令されたパケット。
Measurement units:
Packet count
測定単位: パケットカウント
Poretsky, et al. Informational [Page 13] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[13ページ]のRFC4689用語
See Also:
Stream
Test Sequence number
参照: 流れのTest Sequence番号
3.3.4. Out-of-Order Packet
3.3.4. 故障しているパケット
Definition:
A received packet with a sequence number less than the sequence
number of any previously arriving packet.
定義: 一連番号がどんな以前に到着しているパケットの一連番号よりも少ない容認されたパケット。
Discussion:
As a stream of packets enters a DUT/SUT, they include a Stream
Test Sequence number indicating the order the packets were sent to
the DUT/SUT. On exiting the DUT/SUT, these packets may arrive in
a different order. Each packet that was reordered is counted as
an Out-of-Order Packet.
議論: パケットの流れがDUT/SUTに入るとき、それらはパケットが送られたオーダーをDUT/SUTに示すStream Test Sequence番号を含んでいます。 DUT/SUTを出ると、これらのパケットは異なったオーダーに到達するかもしれません。 再命令された各パケットはオーダーのOut Packetにみなされます。
Certain streaming protocols (such as TCP) require the packets to
be in a certain order. Packets outside this are dropped by the
streaming protocols even though they were properly received by the
IP layer. The type of reordering tolerated by a streaming
protocol varies from protocol to protocol, and also by
implementation.
あるストリーミングのプロトコル(TCPなどの)は、パケットが、あるオーダーにあるのを必要とします。 IP層のそばに適切にそれらを受け取りましたが、ストリーミングのプロトコルはこれの外のパケットを落とします。 ストリーミングのプロトコルによって許容された再命令のタイプはプロトコルからプロトコルまで実現でも異なります。
Packet loss does not affect the Out-of-Order Packet count. The
Out-of-Order Packet count is impacted only by packets that were
not received in the order that they were transmitted.
パケット損失はオーダーのOut Packetカウントに影響しません。 それらがオーダーでしたが、伝えられて、それが受け取られなかったパケットだけはオーダーのOut Packetカウントに影響を与えます。
Measurement units:
packets
測定単位: パケット
See Also:
Stream
Test Sequence number
Packet Reordering Metric for IPPM [Mo03]
参照: IPPMの流れのTest Sequence番号Packet Reordering Metric[Mo03]
3.3.5. Duplicate Packet
3.3.5. パケットをコピーしてください。
Definition:
A received packet with a Test Sequence number matching a
previously received packet.
定義: Test Sequence番号が以前に容認されたパケットに合っている容認されたパケット。
Discussion:
A Duplicate Packet is a packet that the DUT/SUT has successfully
transmitted out an egress interface more than once. The egress
interface has previously forwarded this packet.
議論: Duplicate Packetは一度よりDUT/SUTが出口のインタフェースからもう少し首尾よく伝えさせるパケットです。 出口のインタフェースは以前に、このパケットを進めました。
Poretsky, et al. Informational [Page 14] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[14ページ]のRFC4689用語
A Duplicate Packet SHOULD be a bit-for-bit copy of an already
transmitted packet (including Test Sequence number). If the
Duplicate Packet traversed different paths through the DUT/SUT,
some fields (such as TTL or checksum) may have changed.
Duplicate Packet SHOULD、既に伝えられたパケットのビットしばらくコピー(Test Sequence番号を含んでいて)になってください。 Duplicate PacketがDUT/SUTを通して異なった経路を横断したなら、いくつかの分野(TTLかチェックサムなどの)が変化したかもしれません。
A multicast packet is not a Duplicate Packet by definition. For a
given IP multicast group, a DUT/SUT SHOULD forward a packet once
on a given egress interface provided the path to one or more
multicast receivers is through that interface. Several egress
interfaces will transmit the same packet, but only once per
interface.
マルチキャストパケットは定義上Duplicate Packetではありません。 与えられたIPに関しては、そのインタフェースを通して1台以上のマルチキャスト受信機への経路があるなら、マルチキャストグループ、DUT/SUT SHOULDは与えられた出口のインタフェースで一度パケットを進めます。 インタフェース単位でいったんだけいくつかの出口のインタフェースが同じパケットを伝えるでしょう。
To detect a Duplicate Packet, each packet offered to the DUT/SUT
MUST contain a unique packet-by-packet identifier.
Duplicate Packet、DUT/SUT MUSTに提供された各パケットを検出するには、パケットごとのユニークな識別子を含んでください。
Measurement units:
Packet count
測定単位: パケットカウント
See Also:
Stream
Test Sequence number
参照: 流れのTest Sequence番号
3.4. Vectors
3.4. ベクトル
A vector is a group of packets all matching a specific classification criteria, such as DSCP. Vectors are identified by the classification criteria and benchmarking metrics, such as a Forwarding Capacity, Forwarding Delay, or Jitter.
ベクトルはDSCPなどの特定の分類評価基準に合っているパケットのすべて、グループです。 ベクトルはForwarding Capacity、Forwarding Delay、またはJitterなどの分類評価基準とベンチマーキング測定基準によって特定されます。
3.4.1. Intended Vector
3.4.1. 意図しているベクトル
Definition:
A description of the configuration on an external source
for the attempted rate of a stream transmitted to a DUT/SUT
matching specific classification rules.
定義: 流れの試みられた速度のための外部電源における構成の記述は合っている特定の分類規則をDUT/SUTに伝えました。
Discussion:
The Intended Vector of a stream influences the benchmark
measurements. The Intended Vector is described by the
classification criteria and attempted rate.
議論: 流れのIntended Vectorはベンチマーク測定に影響を及ぼします。 Intended Vectorは分類評価基準と試みられたレートによって説明されます。
Measurement Units:
N-bytes packets per second
測定単位: 1秒あたりのN-バイトパケット
Poretsky, et al. Informational [Page 15] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[15ページ]のRFC4689用語
See Also:
Stream
Offered Vector
Forwarding Vector
参照: 流れはベクトル推進ベクトルを提供しました。
3.4.2. Offered Vector
3.4.2. 提供されたベクトル
Definition:
A description for the attempted rate of a stream offered to
a DUT/SUT matching specific classification rules.
定義: 流れの試みられた速度のための記述は合っている特定の分類規則をDUT/SUTに提供しました。
Discussion:
The Offered Vector of a stream influences the benchmark
measurements. The Offered Vector is described by the
classification criteria and offered rate.
議論: 流れのOffered Vectorはベンチマーク測定に影響を及ぼします。 Offered Vectorは分類評価基準とオファードレートによって説明されます。
Measurement Units:
N-bytes packets per second
測定単位: 1秒あたりのN-バイトパケット
See Also:
Stream
Intended Vector
Forwarding Vector
参照: 意図しているベクトル推進ベクトルを流してください。
3.4.3. Expected Vectors
3.4.3. 予想されたベクトル
3.4.3.1. Expected Forwarding Vector
3.4.3.1. 予想された推進ベクトル
Definition:
A description of the expected output rate of packets matching a
specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っているパケットの予想された出力率の記述。
Discussion:
The value of the Expected Forwarding Vector is dependent on the
set of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
議論: Expected Forwarding Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Forwarding Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Forwarding Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement units:
N-octet packets per second
測定単位: 1秒あたりのN-八重奏パケット
Poretsky, et al. Informational [Page 16] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[16ページ]のRFC4689用語
See Also:
Classification
Stream
Intended Vector
Offered Vector
参照: 分類の流れの意図しているベクトル提供されたベクトル
3.4.3.2. Expected Loss Vector
3.4.3.2. 期待損失ベクトル
Definition:
A description of the percentage of packets having a specific
classification that should not be forwarded.
定義: 進められるべきでない特定の分類を持っているパケットの割合の記述。
Discussion:
The value of the Expected Loss Vector is dependent on the set of
offered vectors and Classification configuration on the DUT/SUT.
The DUT is configured in a certain way so that classification
occurs when a traffic mix consisting of multiple streams is
applied.
議論: Expected Loss Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Loss Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Loss Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement Units:
Percentage of intended packets expected to be dropped.
測定単位: 意図しているパケットの割合は、落とされると予想しました。
See Also:
Classification
Stream
Intended Vector
Offered Vector
One-way Packet Loss Metric [Ka99]
参照: 分類の流れの意図しているベクトルはメートル法でベクトルの片道パケット損失を提供しました。[Ka99]
3.4.3.3. Expected Sequence Vector
3.4.3.3. 予想された系列ベクトル
Definition:
A description of the expected in-sequence packets matching a
specific classification, such as DSCP.
定義: 系列のDSCPなどの特定の分類に合っている予想されたパケットの記述。
Discussion:
The value of the Expected Sequence Vector is dependent on the set
of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
議論: Expected Sequence Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
Poretsky, et al. Informational [Page 17] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[17ページ]のRFC4689用語
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Sequence Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Sequence Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement Units:
N-octet packets per second
測定単位: 1秒あたりのN-八重奏パケット
See Also:
Classification
Stream
In-Sequence Packet
Intended Vector
Offered Vector
参照: 系列の分類の流れのパケットの意図しているベクトル提供されたベクトル
3.4.3.4. Expected Delay Vector
3.4.3.4. 予想どおりの遅延ベクトル
Definition:
A description of the expected instantaneous Forwarding Delay for
packets matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っているパケットのための予想された瞬時に起こっているForwarding Delayの記述。
Discussion:
The value of the Expected Delay Vector is dependent on the set of
offered vectors and Classification configuration on the DUT/SUT.
The DUT is configured in a certain way so that classification
occurs when a traffic mix consisting of multiple streams is
applied.
議論: Expected Delay Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Delay Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Delay Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Delay
Intended Vector
Offered Vector
参照: 分類の推進の遅れの意図しているベクトル提供された流れのベクトル
Poretsky, et al. Informational [Page 18] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[18ページ]のRFC4689用語
3.4.3.5. Expected Average Delay Vector
3.4.3.5. 予想された平均した遅れベクトル
Definition:
A description of the expected average Forwarding Delay for packets
matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っているパケットのための予想された平均したForwarding Delayの記述。
Discussion:
The value of the Expected Average Delay Vector is dependent on the
set of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
議論: Expected Average Delay Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Average Delay Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Average Delay Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
参照: 分類の意図しているベクトル提供されたベクトル予想どおりの遅延流れの推進遅れベクトル
3.4.3.6. Expected Maximum Delay Vector
3.4.3.6. 予想された最大の遅れベクトル
Definition:
A description of the expected maximum Forwarding Delay for packets
matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っているパケットのための予想された最大のForwarding Delayの記述。
Discussion:
The value of the Expected Maximum Delay Vector is dependent on the
set of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
議論: Expected Maximum Delay Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Maximum Delay Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Maximum Delay Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Poretsky, et al. Informational [Page 19] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[19ページ]のRFC4689用語
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
参照: 分類の意図しているベクトル提供されたベクトル予想どおりの遅延流れの推進遅れベクトル
3.4.3.7. Expected Minimum Delay Vector
3.4.3.7. 予想された最小の遅れベクトル
Definition:
A description of the expected minimum Forwarding Delay for packets
matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っているパケットのための予想された最小のForwarding Delayの記述。
Discussion:
The value of the Expected Minimum Delay Vector is dependent on the
set of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
議論: Expected Minimum Delay Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Minimum Delay Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Minimum Delay Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
参照: 分類の意図しているベクトル提供されたベクトル予想どおりの遅延流れの推進遅れベクトル
3.4.3.8. Expected Instantaneous Jitter Vector
3.4.3.8. 予想された瞬時に起こっているジターベクトル
Definition:
A description of the expected Instantaneous Jitter between two
consecutive packets arrival times matching a specific
classification, such as DSCP.
定義: DSCPなどの特定の分類に合っている2つの連続したパケット到着時間の間の予想されたInstantaneous Jitterの記述。
Poretsky, et al. Informational [Page 20] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[20ページ]のRFC4689用語
Discussion:
Instantaneous Jitter is the absolute value of the difference
between the Forwarding Delay measurement of two packets belonging
to the same stream.
議論: 瞬時に起こっているJitterは同じ流れに属す2つのパケットのForwarding Delay測定の違いの絶対値です。
The Forwarding Delay fluctuation between two consecutive packets
in a stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter can be expressed as |D(i) - D(i-1)|, where D
equals the Forwarding Delay and i is the test sequence number.
Packets lost are not counted in the measurement.
流れの2つの連続したパケットの間のForwarding Delay変動は「瞬時に起こっているジター」として報告されます。 瞬時に起こっているJitterを急送できます。|D(i)--D(i-1)|, DがどこでForwarding Delayとiと等しいかは、テスト一連番号です。 失われたパケットは測定で数えられません。
The Forwarding Vector may contain several Jitter Vectors. For n
packets received in a Forwarding Vector, there is a total of (n-1)
Instantaneous Jitter Vectors.
Forwarding Vectorは数個のJitter Vectorsを含むかもしれません。 Forwarding Vectorに受け取られたnパケットのために、(n-1)瞬時に起こっているJitter Vectorsの合計があります。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Jitter
Intended Vector
Offered Vector
参照: 分類の流れのジターの意図しているベクトル提供されたベクトル
3.4.3.9. Expected Average Jitter Vector
3.4.3.9. 予想された平均したジターベクトル
Definition:
A description of the expected average jitter for packets arriving
in a stream matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っている流れに到達するパケットのための予想された平均したジターの記述。
Discussion:
Average Jitter Vector is the average of all the Instantaneous
Jitter Vectors measured during the test duration for the same
stream.
議論: 平均したJitter Vectorは同じ流れのためにテスト持続時間の間に測定されたすべてのInstantaneous Jitter Vectorsの平均です。
The value of the Expected Average Jitter Vector is dependent on
the set of offered vectors and Classification configuration on the
DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
Expected Average Jitter Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Average Jitter Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected Average Jitter Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Poretsky, et al. Informational [Page 21] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[21ページ]のRFC4689用語
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Jitter
Intended Vector
Offered Vector
Expected Instantaneous Jitter Vector
参照: 意図している分類の提供されたベクトル予想された瞬時に起こっているジター流れのジターベクトルベクトル
3.4.3.10. Expected Peak-to-peak Jitter Vector
3.4.3.10. 予想されたピークツーピークジターベクトル
Definition:
A description of the expected maximum variation in the Forwarding
Delay of packet arrival times for packets arriving in a stream
matching a specific classification, such as DSCP.
定義: DSCPなどの特定の分類に合っている流れに到達するパケットのためのパケット到着時間のForwarding Delayの予想された最大の変化の記述。
Discussion:
Peak-to-peak Jitter Vector is the maximum Forwarding Delay minus
the minimum Forwarding Delay of the packets (in a vector)
forwarded by the DUT/SUT.
議論: ピークツーピークJitter VectorはDUT/SUTによって進められたパケット(ベクトルにおける)の最小のForwarding Delayを引いた最大のForwarding Delayです。
Peak-to-peak Jitter is not derived from the Instantaneous Jitter
Vector. Peak-to-peak Jitter is based upon all the packets during
the test duration, not just two consecutive packets.
ピークツーピークJitterはInstantaneous Jitter Vectorから得られません。 ピークツーピークJitterはちょうど2つの連続したパケットではなく、テスト持続時間の間、すべてのパケットに基づいています。
The value of the Expected Peak-to-peak Jitter Vector is dependent
on the set of offered vectors and Classification configuration on
the DUT/SUT. The DUT is configured in a certain way so that
classification occurs when a traffic mix consisting of multiple
streams is applied.
Expected PeakからピークへのJitter Vectorの値はDUT/SUTでの提供されたベクトルとClassification構成のセットに依存しています。 DUTが、ある方法で構成されるので、複数の流れから成る交通ミックスが適用されているとき、分類は起こります。
This term captures the expected forwarding behavior from the DUT
receiving multiple Offered Vectors. The actual algorithm or
mechanism the DUT uses to achieve service differentiation is
implementation specific and is not important when describing the
Expected Peak-to-peak Jitter Vector.
今期は、複数のOffered Vectorsを受けながら、DUTから予想された推進の振舞いを得ます。 Expected PeakからピークへのJitter Vectorについて説明するとき、DUTがサービス分化を達成するのに使用する実際のアルゴリズムかメカニズムが、実現特有であり、重要ではありません。
Measurement units:
milliseconds
測定単位: ミリセカンド
Poretsky, et al. Informational [Page 22] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[22ページ]のRFC4689用語
See Also:
Classification
Stream
Jitter
Intended Vector
Offered Vector
Expected Instantaneous Jitter Vector
Expected Average Jitter Vector
参照: 意図している提供された予想された瞬時に起こっている分類のジターベクトル予想された平均したジター流れのジターベクトルベクトルベクトル
3.4.4. Output Vectors
3.4.4. 出力ベクトル
3.4.4.1. Forwarding Vector
3.4.4.1. 推進ベクトル
Definition:
The number of packets per second for a stream matching a specific
classification, such as DSCP, that a DUT/SUT is measured to
forward to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに送るために測定されるDSCPなどの特定の分類に合っている流れのための1秒あたりのパケットの数。
Discussion:
Forwarding Vector is expressed as a combination of values: the
classification rules AND the measured packets per second for the
stream matching the classification rules. Forwarding Vector is a
per-hop measurement. The DUT/SUT MAY remark the specific DSCP (or
IP precedence) value for a multi-hop measurement. The stream
remains the same.
議論: 推進Vectorは値の組み合わせとして急送されます: 分類は分類規則に合っている流れのために1秒あたりの測定パケットにANDを統治します。 1ホップあたり推進Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCP(または、IP先行)値を述べさせます。 流れは同じままで残っています。
Measurement units:
N-octet packets per second
測定単位: 1秒あたりのN-八重奏パケット
See Also:
Classification
Stream
Forwarding Capacity
Intended Vector
Offered Vector
Expected Vector
参照: 分類の意図しているベクトル提供されたベクトル予想された流れの推進容量ベクトル
3.4.4.2. Loss Vector
3.4.4.2. 損失ベクトル
Definition:
The percentage of packets per second for a stream matching a
specific classification, such as DSCP, that a DUT/SUT is measured
not to transmit to the correct destination interface in response
to an offered vector.
定義: 流れのための秒あたりのパケットがDUT/SUTが伝えないように測定されるDSCPなどの特定の分類に合っている対提供されたベクトルに対応した正しい目的地のインタフェースの割合。
Poretsky, et al. Informational [Page 23] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[23ページ]のRFC4689用語
Discussion:
Loss Vector is expressed as a combination of values: the
classification rules AND the measured percentage value of packet
loss. Loss Vector is a per-hop measurement. The DUT/SUT MAY
remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
議論: 損失Vectorは値の組み合わせとして急送されます: パケット損失の分類規則と測定割合値。 1ホップあたり損失Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Measurement Units:
Percentage of packets
測定単位: パケットの割合
See Also:
Classification
Stream
Intended Vector
Offered Vector
Expected Vector
One-way Packet Loss Metric [Ka99]
参照: 分類の流れの意図しているベクトルはメートル法でベクトルの予想されたベクトル片道パケット損失を提供しました。[Ka99]
3.4.4.3. Sequence Vector
3.4.4.3. 系列ベクトル
Definition:
The number of packets per second for all packets in a stream
matching a specific classification, such as DSCP, that a DUT/SUT
is measured to transmit in sequence to the correct destination
interface in response to an offered vector.
定義: DUT/SUTが連続して提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れにおけるすべてのパケットのための1秒あたりのパケットの数。
Discussion:
Sequence Vector is expressed as a combination of values: the
classification rules AND the number of packets per second that are
in-sequence.
議論: 系列Vectorは値の組み合わせとして急送されます: 1秒あたりの系列であるパケットの分類規則と数。
Sequence Vector is a per-hop measurement. The DUT/SUT MAY remark
the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
1ホップあたり系列Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Measurement Units:
N-octet packets per second
測定単位: 1秒あたりのN-八重奏パケット
See Also:
Classification
Stream
In-sequence Packet
Intended Vector
Offered Vector
Expected Vector
参照: 系列の分類の意図しているベクトル提供されたベクトル予想された流れのパケットベクトル
Poretsky, et al. Informational [Page 24] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[24ページ]のRFC4689用語
3.4.4.4. Instantaneous Delay Vector
3.4.4.4. 瞬時に起こっている遅れベクトル
Definition:
The instantaneous Forwarding Delay for a packet in a stream
matching a specific classification, such as DSCP, that a DUT/SUT
is measured to transmit to the correct destination interface
successfully in response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのための瞬時に起こっているForwarding Delay。
Discussion:
Instantaneous Delay Vector is expressed as a combination of
values: the classification rules AND Forwarding Delay. For every
packet received in a Forwarding Vector, there is a corresponding
Instantaneous Delay Vector.
議論: 瞬時に起こっているDelay Vectorは値の組み合わせとして急送されます: 分類はAND Forwarding Delayを統治します。 Forwarding Vectorに受け取られたあらゆるパケットのために、対応するInstantaneous Delay Vectorがあります。
Instantaneous Delay Vector is a per-hop measurement. The DUT/SUT
MAY remark the specific DSCP or IP precedence value for a multi-
hop measurement. The stream remains the same.
1ホップあたり瞬時に起こっているDelay Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Instantaneous Delay Vector can be obtained at any offered load.
It is RECOMMENDED that this vector be obtained at or below the
Forwarding Capacity in the absence of Forwarding Congestion. For
congested Forwarding Delay, run the offered load above the
Forwarding Capacity.
どんな提供された負荷でも瞬時に起こっているDelay Vectorを入手できます。 Forwarding CapacityかForwarding Congestionが不在のときForwarding Capacityの下にこのベクトルを得るのは、RECOMMENDEDです。 混雑しているForwarding Delayに関しては、Forwarding Capacityの上で提供された荷を動かしてください。
Measurement Units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
参照: 分類の意図しているベクトル提供されたベクトル予想どおりの遅延流れの推進容量推進遅れベクトル
3.4.4.5. Average Delay Vector
3.4.4.5. 平均した遅れベクトル
Definition:
The average Forwarding Delay for packets in a stream matching a
specific classification, such as DSCP, that a DUT/SUT is measured
to transmit to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのための平均したForwarding Delay。
Poretsky, et al. Informational [Page 25] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[25ページ]のRFC4689用語
Discussion:
Average Delay Vector is expressed as combination of values: the
classification rules AND average Forwarding Delay.
議論: 平均したDelay Vectorは値の組み合わせとして急送されます: 分類はANDの平均したForwarding Delayを統治します。
The average Forwarding Delay is computed by averaging all the
Instantaneous Delay Vectors for a given stream.
平均したForwarding Delayは、与えられた流れのためにすべてのInstantaneous Delay Vectorsを平均することによって、計算されます。
Average Delay Vector is a per-hop measurement. The DUT/SUT MAY
remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
1ホップあたり平均したDelay Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Average Delay Vector can be obtained at any offered load. It is
recommended that the offered load be at or below the Forwarding
Capacity in the absence of congestion. For congested Forwarding
Delay, run the offered load above the Forwarding Capacity.
どんな提供された負荷でも平均したDelay Vectorを入手できます。 Forwarding CapacityかForwarding Capacityの下に提供された負荷が混雑がないときあるのは、お勧めです。 混雑しているForwarding Delayに関しては、Forwarding Capacityの上で提供された荷を動かしてください。
Measurement Units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
Instantaneous Delay Vector
参照: 意図している提供された分類のベクトル予想どおりの遅延ベクトル瞬時に起こっている遅れ流れの推進容量推進遅れベクトルベクトル
3.4.4.6. Maximum Delay Vector
3.4.4.6. 最大の遅れベクトル
Definition:
The maximum Forwarding Delay for packets in a stream matching a
specific classification, such as DSCP, that a DUT/SUT is measured
to transmit to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのための最大のForwarding Delay。
Discussion:
Maximum Delay Vector is expressed as combination of values: the
classification rules AND maximum Forwarding Delay.
議論: 最大のDelay Vectorは値の組み合わせとして急送されます: 分類はANDの最大のForwarding Delayを統治します。
The maximum Forwarding Delay is computed by selecting the highest
value from the Instantaneous Delay Vectors for a given stream.
最大のForwarding Delayは、与えられた流れのためにInstantaneous Delay Vectorsから最も高い値を選択することによって、計算されます。
Maximum Delay Vector is a per-hop measurement. The DUT/SUT MAY
remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
1ホップあたり最大のDelay Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Poretsky, et al. Informational [Page 26] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[26ページ]のRFC4689用語
Maximum Delay Vector can be obtained at any offered load. It is
recommended that the offered load be at or below the Forwarding
Capacity in the absence of congestion. For congested Forwarding
Delay, run the offered load above the Forwarding Capacity.
どんな提供された負荷でも最大のDelay Vectorを入手できます。 Forwarding CapacityかForwarding Capacityの下に提供された負荷が混雑がないときあるのは、お勧めです。 混雑しているForwarding Delayに関しては、Forwarding Capacityの上で提供された荷を動かしてください。
Measurement Units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
Instantaneous Delay Vector
参照: 意図している提供された分類のベクトル予想どおりの遅延ベクトル瞬時に起こっている遅れ流れの推進容量推進遅れベクトルベクトル
3.4.4.7. Minimum Delay Vector
3.4.4.7. 最小の遅れベクトル
Definition:
The minimum Forwarding Delay for packets in a stream matching a
specific classification, such as DSCP, that a DUT/SUT is measured
to transmit to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのための最小のForwarding Delay。
Discussion:
Minimum Delay Vector is expressed as a combination of values: the
classification rules AND minimum Forwarding Delay. The minimum
Forwarding Delay is computed by selecting the lowest value from
the Instantaneous Delay Vectors for a given stream.
議論: 最小のDelay Vectorは値の組み合わせとして急送されます: 分類はANDの最小のForwarding Delayを統治します。 最小のForwarding Delayは、与えられた流れのためにInstantaneous Delay Vectorsから最も低い値を選択することによって、計算されます。
Minimum Delay Vector is a per-hop measurement. The DUT/SUT MAY
remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
1ホップあたり最小のDelay Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Minimum Delay Vector can be obtained at any offered load. It is
recommended that the offered load be at or below the Forwarding
Capacity in the absence of congestion. For congested Forwarding
Delay, run the offered load above the Forwarding Capacity.
どんな提供された負荷でも最小のDelay Vectorを入手できます。 Forwarding CapacityかForwarding Capacityの下に提供された負荷が混雑がないときあるのは、お勧めです。 混雑しているForwarding Delayに関しては、Forwarding Capacityの上で提供された荷を動かしてください。
Measurement Units:
milliseconds
測定単位: ミリセカンド
Poretsky, et al. Informational [Page 27] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[27ページ]のRFC4689用語
See Also:
Classification
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
参照: 分類の意図しているベクトル提供されたベクトル予想どおりの遅延流れの推進容量推進遅れベクトル
3.4.4.8. Instantaneous Jitter Vector
3.4.4.8. 瞬時に起こっているジターベクトル
Definition:
The jitter for two consecutive packets in a stream matching a
specific classification, such as DSCP, that a DUT/SUT is measured
to transmit to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れの2つの連続したパケットのためのジター。
Discussion:
Instantaneous Jitter is the absolute value of the difference
between the Forwarding Delay measurement of two packets belonging
to the same stream.
議論: 瞬時に起こっているJitterは同じ流れに属す2つのパケットのForwarding Delay測定の違いの絶対値です。
The Instantaneous Jitter vector is expressed as a pair of numbers.
Both the specific DSCP (or IP precedence) value AND jitter value
combine to make a vector.
Instantaneous Jitterベクトルは1組の数として表されます。 特定のDSCP(または、IP先行)値とジター値の両方が結合して、ベクトルを作ります。
The Forwarding Delay fluctuation between two consecutive packets
in a stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)|,
where D equals the Forwarding Delay and i is the test sequence
number. Packets lost are not counted in the measurement.
流れの2つの連続したパケットの間のForwarding Delay変動は「瞬時に起こっているジター」として報告されます。 瞬時に起こっているJitter Vectorを急送できます。|D(i)--D(i-1)|, DがどこでForwarding Delayとiと等しいかは、テスト一連番号です。 失われたパケットは測定で数えられません。
The Instantaneous Jitter Vector is a per-hop measurement. The
DUT/SUT MAY remark the specific DSCP or IP precedence value for a
multi-hop measurement. The stream remains the same.
1ホップあたりInstantaneous Jitter Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
There may be several Instantaneous Jitter Vectors for a single
stream. For n packets measured, there may be (n-1) Instantaneous
Jitter Vectors.
ただ一つの流れのための数個のInstantaneous Jitter Vectorsがあるかもしれません。 測定されたnパケットのために、(n-1)瞬時に起こっているJitter Vectorsがあるかもしれません。
Measurement units:
milliseconds
測定単位: ミリセカンド
Poretsky, et al. Informational [Page 28] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[28ページ]のRFC4689用語
See Also:
Classification
Stream
Forwarding Delay
Jitter
Forwarding Vector
Expected Vectors
参照: 分類の遅れのジターの推進のベクトルの予想された流れの推進ベクトル
3.4.4.9. Average Jitter Vector
3.4.4.9. 平均したジターベクトル
Definition:
The average jitter for packets in a stream matching a specific
classification, such as DSCP, that a DUT/SUT is measured to
transmit to the correct destination interface successfully in
response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのための平均したジター。
Discussion:
Average jitter is calculated by the average of all the
Instantaneous Jitter Vectors of the same stream measured during
the test duration. Average Jitter Vector is expressed as a
combination of values: the classification rules AND average
Jitter.
議論: 平均したジターはテスト持続時間の間に測定された同じ流れのすべてのInstantaneous Jitter Vectorsの平均で計算されます。 平均したJitter Vectorは値の組み合わせとして急送されます: 分類はANDの平均したJitterを統治します。
Average Jitter Vector is a per-hop measurement. The DUT/SUT MAY
remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
1ホップあたり平均したJitter Vectorは1つの測定です。 DUT/SUT MAYはマルチホップ測定のために特定のDSCPかIP先行価値を述べさせます。 流れは同じままで残っています。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Classification
Stream
Jitter
Forwarding Vector
Expected Vector
Instantaneous Jitter Vector
参照: 分類のベクトルの予想されたベクトル瞬時に起こっているジター流れのジター推進ベクトル
3.4.4.10. Peak-to-peak Jitter Vector
3.4.4.10. ピークツーピークジターベクトル
Definition:
The maximum possible variation in the Forwarding Delay for packets
in a stream matching a specific classification, such as DSCP, that
a DUT/SUT is measured to transmit to the correct destination
interface successfully in response to an offered vector.
定義: DUT/SUTが首尾よく提供されたベクトルに対応して正しい目的地のインタフェースに伝えるために測定されるDSCPなどの特定の分類に合っている流れのパケットのためのForwarding Delayの最大の可能な変化。
Poretsky, et al. Informational [Page 29] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[29ページ]のRFC4689用語
Discussion:
Peak-to-peak Jitter Vector is calculated by subtracting the
maximum Forwarding Delay from the minimum Forwarding Delay of the
packets forwarded by the DUT/SUT. Jitter vector is expressed as a
combination of values: the classification rules AND peak-to-peak
Jitter.
議論: ピークツーピークJitter Vectorは、DUT/SUTによって進められたパケットの最小のForwarding Delayから最大のForwarding Delayを引き算することによって、計算されます。 ジターベクトルは値の組み合わせとして表されます: 分類はANDピークツーピークJitterを統治します。
Peak-to-peak Jitter is not derived from the Instantaneous Jitter
Vector. Peak-to-peak Jitter is based upon all the packets during
the test duration, not just two consecutive packets.
ピークツーピークJitterはInstantaneous Jitter Vectorから得られません。 ピークツーピークJitterはちょうど2つの連続したパケットではなく、テスト持続時間の間、すべてのパケットに基づいています。
Measurement units:
milliseconds
測定単位: ミリセカンド
See Also:
Jitter
Forwarding Vector
Stream
Expected Vectors
Instantaneous Jitter Vector
Average Jitter Vector
参照: 瞬時に起こっているジターベクトル平均したジターベクトルをベクトルの流れの予想されたベクトルに送るジター
4. Security Considerations
4. セキュリティ問題
Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to production networks.
ベンチマーキングが生産ネットワークに接続された装置かシステムに実行されない限り、このタイプのドキュメントは直接インターネットか企業ネットワークのセキュリティに影響しません。
Packets with unintended and/or unauthorized DSCP or IP precedence values may present security issues. Determining the security consequences of such packets is out of scope for this document.
故意でない、そして/または、権限のないDSCPかIP先行値があるパケットは安全保障問題を提示するかもしれません。 このドキュメントのための範囲の外にそのようなパケットのセキュリティ結果を決定するのがあります。
5. Acknowledgements
5. 承認
The authors gratefully acknowledge the contributions of the IETF's Benchmarking Methodology Working Group members in reviewing this document. The authors would like to express our thanks to David Newman for his consistent and valuable assistance throughout the development of this document. The authors would also like to thank Al Morton and Kevin Dubray for their ideas and support.
作者は感謝してこのドキュメントを再検討することにおける、IETFのBenchmarking Methodology作業部会のメンバーの貢献を承諾します。 作者はこのドキュメントの開発の間中ときの彼の一貫して貴重な支援のためにデヴィッド・ニューマンに感謝したがっています。 また、作者は彼らの考えとサポートについてアル・モートンとケビンDubrayに感謝したがっています。
Poretsky, et al. Informational [Page 30] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[30ページ]のRFC4689用語
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[Br91] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
[Br91] ブラドナー、S.、「ネットワーク相互接続装置のためのベンチマーキング用語」、RFC1242、1991年7月。
[Br97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Br97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[Br98] ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(1998年4月)。
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998.
[Ma98] マンデヴィル、R.、「LAN切換装置のためのベンチマーキング用語」、RFC2285、1998年2月。
[Ni98] 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.
[Ni98] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[St91] Steinberg, L., "Techniques for managing asynchronously
generated alerts", RFC 1224, May 1991.
[St91] スタインバーグ、L.、「管理するためのテクニックは警戒を非同期に発生した」RFC1224、1991年5月。
6.2. Informative References
6.2. 有益な参照
[Al99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[Al99]Almes、G.、Kalidindi、S.、およびM.Zekauskas、「IPPMにおける、メートル法のA One-道の遅れ」、RFC2679、1999年9月。
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and
W. Weiss, "An Architecture for Differentiated Service", RFC
2475, December 1998.
[Bl98] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[Br99] ブラドナーとS.とJ.McQuaid、「ネットワーク内部連絡装置のためのベンチマーキング方法論」、RFC2544、1999年3月。
[De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, November
2002.
[De02]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
[Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
[Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection gateways
for Congestion Avoidance", IEEE/ACM Transactions on
Networking, V.1 N.4, August 1993, p. 397-413. URL
"ftp://ftp.ee.lbl.gov/papers/early.pdf".
Networkingの上の[Fl93]フロイド、S.とジェーコブソン、V.、「Congestion Avoidanceのための無作為のEarly Detectionゲートウェイ」IEEE/ACM Transactions、V.1 N.4、1993年8月(p)。 397-413. URL" ftp://ftp.ee.lbl.gov/papers/early.pdf "。
Poretsky, et al. Informational [Page 31] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[31ページ]のRFC4689用語
[Ja99] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
"An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[Ja99] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[Ka99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[Ka99]Almes、G.、Kalidindi、S.、およびM.Zekauskas、「IPPMにおける、メートル法のA One-道のパケット損失」、RFC2680、1999年9月。
[Ma91] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991.
[Ma91] マンキンとA.とK.Ramakrishnan、「ゲートウェイ混雑基準測量」、RFC1254、1991年8月。
[Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for
LAN Switching Devices", RFC 2889, August 2000.
[Ma00] マンデヴィルとR.とJ.Perser、「LAN切換装置のためのベンチマーキング方法論」、RFC2889、2000年8月。
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
Perser, J., "Packet Reordering Metric for IPPM", Work in
Progress.
[Mo03] モートン、A.、Ciavattone、L.、ラマチャンドラン、G.、Shalunov、S.、Perser、J.、「IPPMにおける、メートル法のパケットReordering」が進行中で働いています。
[Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
896, January 1984.
[Na84] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
[Ra99] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[Ra99] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD
64, RFC 3550, July 2003.
[Sc96] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Poretsky, et al. Informational [Page 32] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[32ページ]のRFC4689用語
Authors' Addresses
作者のアドレス
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA USA
ジェリーPerser Veriwave8770SW雨雲Ave。 スイートBビーバートン、または97008米国米国
Phone: + 1 818 338 4112 EMail: jerry@perser.org
以下に電話をしてください。 4112がメールする+1 818 338: jerry@perser.org
Scott Poretsky Reef Point Systems 8 New England Executive Park Burlington, MA 01803 USA
スコットPoretskyはMA01803米国のポイントシステム8ニューイングランドの幹部社員公園バーリントンを短縮します。
Phone: + 1 508 439 9008 EMail: sporetsky@reefpoint.com
以下に電話をしてください。 9008がメールする+1 508 439: sporetsky@reefpoint.com
Shobha Erramilli Telcordia Technologies 331 Newman Springs Road Red Bank, New Jersey 07701 USA
Shobha Erramilli Telcordia技術331ニューマン春の道路赤の銀行、ニュージャージー07701米国
EMail: shobha@research.telcordia.com
メール: shobha@research.telcordia.com
Sumit Khurana Motorola 7700 West Parmer Ln. Austin, TX 78729 USA
Sumit Khuranaモトローラ7700の西パーマーLn。 オースチン、テキサス78729米国
Phone: +1 512 996 6604 Email: skhurana@motorola.com
以下に電話をしてください。 +1 6604年の512 996メール: skhurana@motorola.com
Poretsky, et al. Informational [Page 33] RFC 4689 Terminology for Traffic Control Mechanisms October 2006
Poretsky、他 トラフィックコントロールメカニズム2006年10月のための情報[33ページ]のRFC4689用語
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Poretsky, et al. Informational [Page 34]
Poretsky、他 情報[34ページ]
一覧
スポンサーリンク
