Network Working Group G. Feher
Request for Comments: 4883 K. Nemeth
Category: Informational A. Korn
BUTE
I. Cselenyi
TeliaSonera
July 2007
Benchmarking Terminology for Resource Reservation Capable Routers
リソース予約が可能なルータのためのベンチマーキング用語
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements.
このドキュメントの主な目的は、統合サービス（IntServの）IPルータのリソース予約シグナリングのベンチマーキングに特定の用語を定義することです。これらの用語は、ベンチマーク測定のためのリソース予約やレポートフォーマットをサポートするルータのためのベンチマーキング方法論を定義し、追加のドキュメントで使用することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Definition of Terms .............................................4
3.1. Traffic Flow Types .........................................4
3.1.1. Data Flow ...........................................4
3.1.2. Distinguished Data Flow .............................4
3.1.3. Best-Effort Data Flow ...............................5
3.2. Resource Reservation Protocol Basics .......................5
3.2.1. QoS Session .........................................5
3.2.2. Resource Reservation Protocol .......................6
3.2.3. Resource Reservation Capable Router .................7
3.2.4. Reservation State ...................................7
3.2.5. Resource Reservation Protocol Orientation ...........8
3.3. Router Load Factors ........................................9
3.3.1. Best-Effort Traffic Load Factor .....................9
3.3.2. Distinguished Traffic Load Factor ..................10
3.3.3. Session Load Factor ................................11
3.3.4. Signaling Intensity Load Factor ....................11
3.3.5. Signaling Burst Load Factor ........................12
3.4. Performance Metrics .......................................13
3.4.1. Signaling Message Handling Time ....................13
3.4.2. Distinguished Traffic Delay ........................14
3.4.3. Best-effort Traffic Delay ..........................15
3.4.4. Signaling Message Deficit ..........................15
3.4.5. Session Maintenance Capacity .......................16
3.5. Router Load Conditions and Scalability Limit ..............17
3.5.1. Loss-Free Condition ................................17
3.5.2. Lossy Condition ....................................18
3.5.3. QoS Compliant Condition ............................19
3.5.4. Not QoS Compliant Condition ........................20
3.5.5. Scalability Limit ..................................20
4. Security Considerations ........................................21
5. Acknowledgements ...............................................21
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................21
Signaling-based resource reservation using the IntServ paradigm [4] is an important part of the different Quality of Service (QoS) provisioning approaches. Therefore, network operators who are planning to deploy signaling-based resource reservation may want to examine the scalability limitations of reservation capable routers and the impact of signaling on their data forwarding performance.
IntServのパラダイムを使用して、シグナリングベースのリソース予約[4]の手法をプロビジョニングサービス（QOS）の異なる品質の重要な部分です。したがって、シグナル・ベースのリソース予約を展開することを計画しているネットワークオペレータは、予約が可能なルータのスケーラビリティの限界とそのデータ転送パフォーマンス上のシグナリングの影響を検討することをお勧めします。
An objective way of quantifying the scalability constraints of QoS signaling is to perform measurements on routers that are capable of IntServ-based resource reservation. This document defines terminology for a specific set of tests that vendors or network operators can carry out to measure and report the signaling performance characteristics of router devices that support resource reservation protocols. The results of these tests provide comparable data for different products, and thus support the decision-making process before purchase. Moreover, these measurements provide input characteristics for the dimensioning of a network in which resources are provisioned dynamically by signaling. Finally, the tests are applicable for characterizing the impact of the resource reservation signaling on the forwarding performance of the routers.
QoSのシグナリングのスケーラビリティの制約を定量化する客観的な方法は、IntServのベースのリソース予約の可能なルータ上で測定を実行することです。この文書では、ベンダーやネットワークオペレータは、リソース予約プロトコルをサポートするルータ装置のシグナリング性能特性を測定し、報告するように行うことができますテストの特定のセットのための用語を定義します。これらのテストの結果は、異なる製品に匹敵するデータを提供するため、購入前に意思決定プロセスをサポートしています。また、これらの測定は、リソースは、シグナリングによって動的にプロビジョニングされるネットワークの寸法の入力特性を提供します。最後に、テストは、ルータの転送性能上のシグナリングリソース予約の影響を特徴付けるために適用可能です。
This benchmarking terminology document is based on the knowledge gained by examination of (and experimentation with) different resource reservation protocols: the IETF standard Resource ReSerVation Protocol (RSVP) [5], Next Steps in Signaling (NSIS) [6][7][8][9], and several experimental ones, such as YESSIR (Yet Another Sender Session Internet Reservation) [10], ST2+ [11], Session Description Protocol (SDP) [12], Boomerang [13], and Ticket [14]. Some of these protocols were also analyzed by the IETF NSIS working group [15]. Although at the moment the authors are only aware of resource reservation capable router products that interpret RSVP, this document defines terms that are valid in general and not restricted to any of the protocols listed above.
文書は（とと実験）の検査によって得られた知識に基づいており、このベンチマーク用語異なるリソース予約プロトコル：IETF標準リソース予約プロトコル（RSVP）シグナリングにおける[5]次のステップ（NSIS）[6] [7] [ 8] [9]、及びそのようなYESSIR（もう一つの送信者セッション・インターネット予約）[10]、ST2 + [11]、セッション記述プロトコル（SDP）[12]、ブーメラン[13]、及びチケットのようないくつかの実験的なもの、[14 ]。これらのプロトコルのいくつかは、IETF NSISワーキンググループ[15]により分析しました。現時点で著者はRSVPを解釈リソース予約が可能なルータ製品だけを認識しているが、本書は一般的に有効であり、上記のプロトコルのいずれにも限定されていない用語を定義します。
In order to avoid any confusion, we would like to emphasize that this terminology considers only signaling protocols that provide IntServ resource reservation; for example, techniques in the DiffServ toolbox are predominantly beyond our scope.
混乱を避けるために、私たちは、この用語はイントサーブリソース予約を提供のみシグナリングプロトコルを考慮することを強調したいと思います。例えば、DiffServのツールボックスの技術は、主に私たちの範囲を超えています。
RFC 1242 "Benchmarking Terminology for Network Interconnection Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" [3] contain discussions and definitions for a number of terms relevant to the benchmarking of signaling performance of reservation-capable routers and should be consulted before attempting to make use of this document.
RFC 1242「ネットワーク相互接続デバイスのためのベンチマーキング用語」[1]とRFC 2285「スイッチングLANデバイスのためのベンチマーキング用語は、」[3]予約可能なルータのパフォーマンスをシグナルのベンチマーキングに関連する用語の数のための議論や定義を含むべきでありこのドキュメントを利用するように試みる前に相談すること。
Additionally, this document defines terminology in a way that is consistent with the terms used by the Next Steps in Signaling working group laid out in [6][7][8].
また、この文書はにレイアウトシグナリングワーキンググループにおける次のステップで使用される用語と一致するように用語を定義する[6] [7] [8]。
For the sake of clarity and continuity, this document adopts the template for definitions set out in Section 2 of RFC 1242.
明快さと継続性のために、この文書は、RFC 1242のセクション2に定めた定義のテンプレートを採用しています。
Definitions are indexed and grouped together into different sections for ease of reference.
定義は、インデックス付けおよび参照を容易にするための異なるセクションにグループ化されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
This group of definitions describes traffic flow types forwarded by resource reservation capable routers.
定義のこのグループは、リソース予約が可能なルータによって転送されたトラフィックフローのタイプについて説明します。
Definition: A data flow is a stream of data packets from one sender to one or more receivers, where each packet has a flow identifier unique to the flow.
定義：データフローは、各パケットフローに固有のフロー識別子を有する1つまたは複数の受信機、1つの送信者からのデータ・パケットのストリームです。
Discussion: The flow identifier can be an arbitrary subset of the packet header fields that uniquely distinguishes the flow from others. For example, the 5-tuple "source address; source port; destination address; destination port; protocol number" is commonly used for this purpose (where port numbers are applicable). It is also possible to take advantage of the Flow Label field of IPv6 packets. For more comments on flow identification, refer to [6].
ディスカッション：フロー識別子が一意に他人からの流れを区別するパケットヘッダフィールドの任意の部分集合であってもよいです。例えば、5タプル「の送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、プロトコル番号」は、一般的に（ポート番号が適用される）は、この目的のために使用されます。 IPv6パケットのフローラベルフィールドを利用することも可能です。フロー識別についてのコメントを、[6]を参照。
Definition: Distinguished data flows are flows that resource reservation capable routers intentionally treat better or worse than best-effort data flows, according to a QoS agreement defined for the distinguished flow.
定義：識別データフローは、リソース予約が可能なルータが意図的に著名な流れのために定義されたQoS契約によると、良くも悪くもベストエフォート型データフローよりも扱いが流れています。
Discussion: Routers classify the packets of distinguished data flows and identify the data flow to which they belong.
ディスカッション：ルータは著名なデータフローのパケットを分類し、それらが属するデータフローを識別する。
The most common usage of the distinguished data flow is to get higher-priority treatment than that of best-effort data flows (see the next definition). In these cases, a distinguished data flow is sometimes referred to as a "premium data flow". Nevertheless, theoretically it is possible to require worse treatment than that of best-effort flows.
著名なデータフローの最も一般的な使用法は、（次の定義を参照）ベストエフォート型データフローよりも優先度の高い治療を取得することです。これらのケースでは、識別データの流れは、時々、「プレミアムデータフロー」と呼ばれます。それにもかかわらず、理論的には、ベストエフォート型のフローよりも悪化し、治療を必要とすることが可能です。
Definition: Best-effort data flows are flows that are not treated in any special manner by resource reservation capable routers; thus, their packets are served (forwarded) in some default way.
定義：ベストエフォート型データフローは、リソース予約が可能なルータによって特別な方法で処理されていないが流れています。したがって、そのパケットは、いくつかのデフォルトの方法で（転送）提供しています。
Discussion: "Best-effort" means that the router makes its best effort to forward the data packet quickly and safely, but does not guarantee anything (e.g., delay or loss probability). This type of traffic is the most common in today's Internet.
ディスカッション：「ベストエフォート」は、ルータは、迅速かつ安全にデータパケットを転送するために最善の努力をすることを意味するが、何も（例えば、遅延や損失確率）を保証するものではありません。このタイプのトラフィックは、今日のインターネットで最も一般的です。
Packets that belong to best-effort data flows need not be classified by the routers; that is, the routers don't need to find a related reservation session in order to find out to which treatment the packet is entitled.
ベストエフォート型のデータ・フローは、ルータによって分類されていない必要に属するパケット。つまり、ルータはパケットを受ける権利があるうちどの治療法を見つけるために、関連する予約セッションを見つける必要がありません。
This group of definitions applies to signaling-based resource reservation protocols implemented by IP router devices.
定義のこのグループは、IPルータ装置によって実装さシグナリングベースのリソース予約プロトコルに適用されます。
Definition: A QoS session is an application layer concept, shared between a set of network nodes, that pertains to a specific set of data flows. The information associated with the session includes the data required to identify the set of data flows in addition to a specification of the QoS treatment they require.
定義：QoSのセッションは、データフローの特定のセットに関連するネットワークノードのセット間で共有アプリケーション層の概念、です。セッションに関連する情報は、彼らが必要とするQoS処理の仕様に加えて、データフローのセットを識別するために必要なデータを含みます。
Discussion: A QoS session is an end-to-end relationship. Whenever end-nodes decide to obtain special QoS treatment for their data communication, they set up a QoS session. As part of the process, they or their proxies make a QoS agreement with the network, specifying their data flows and the QoS treatment that the flows require.
ディスカッション：QoSのセッションは、エンド・ツー・エンドの関係です。エンドノードがデータ通信を行うための特別なQoS処理を取得することを決定したときはいつでも、彼らは、QoSセッションを設定しました。プロセスの一環として、彼らや彼らのプロキシは、データ・フローおよびフローが必要とQoS処理を指定して、ネットワークでのQoS契約を作ります。
It is possible for the same QoS session to span multiple network domains that have different resource provisioning architectures. In this document, however, we only deal with the case where the QoS session is realized over an IntServ architecture. It is assumed that sessions will be established using signaling messages of a resource reservation protocol.
同じQoSセッションは異なるリソースのプロビジョニング・アーキテクチャを持つ複数のネットワークドメインにまたがることが可能です。この文書では、しかし、我々は唯一のQoSセッションがイントサーブアーキテクチャ上で実現されている場合にも対応します。セッションがリソース予約プロトコルのシグナリングメッセージを使用して確立されることが想定されます。
QoS sessions must have unique identifiers; it must be possible to determine to which QoS session a given signaling message pertains. Therefore, each signaling message should include the identifier of its corresponding session. As an example, in the case of RSVP, the "session specification" identifies the QoS session plus refers to the data flow; the "flowspec" specifies the desired QoS treatment and the "filter spec" defines the subset of data packets in the data flow that receive the QoS defined by the flowspec.
QoSのセッションはユニークな識別子を持っている必要があります。与えられたシグナリング・メッセージが関係するQoSのセッション決定することが可能でなければなりません。したがって、各シグナリングメッセージは、対応するセッションの識別子を含むべきです。一例として、RSVPの場合には、「セッション仕様は、」QoSのセッションを識別するプラスデータフローを指します。 「フロースペック」は、所望のQoS処理を指定し、「フィルタ仕様」は、フロースペックによって規定されるQoSを受信データフローのデータパケットのサブセットを定義します。
QoS sessions can be unicast or multicast depending on the number of participants. In a multicast group, there can be several data traffic sources and destinations. Here the QoS agreement does not have to be the same for each branch of the multicast tree forwarding the data flow of the group. Instead, a dedicated network resource in a router can be shared among many traffic sources from the same multicast group (cf. multicast reservation styles in the case of RSVP).
QoSのセッションは、参加者の数に応じて、ユニキャストまたはマルチキャストすることができます。マルチキャストグループでは、いくつかのデータトラフィックの送信元と送信先があることができます。ここでのQoS契約は、グループのデータフローを転送するマルチキャストツリーの各ブランチで同じである必要はありません。代わりに、ルータ内の専用ネットワーク・リソースは、同じマルチキャストグループからの多くのトラフィックソース（RSVPの場合に参照マルチキャスト予約スタイル）の間で共有することができます。
Issues: Even though QoS sessions are considered to be unique, resource reservation capable routers might aggregate them and allocate network resources to these aggregated sessions at once. The aggregation can be based on similar data flow attributes (e.g., similar destination addresses) or it can combine arbitrary sessions as well. While reservation aggregation significantly lightens the signaling processing task of a resource reservation capable router, it also requires the administration of the aggregated QoS sessions and might also lead to the violation of the quality guaranties referring to individual data flows within an aggregation [16].
問題：QoSのセッションが一意であると考えられているにもかかわらず、リソース予約が可能なルータは、それらを集約し、一度にこれらのアグリゲートされたセッションにネットワークリソースを割り当てることがあります。凝集は、同様のデータフロー属性に基づくことができる（例えば、同様の宛先アドレス）、またはそれは同様に、任意のセッションを組み合わせることができます。予約凝集は有意に資源予約が可能なルータの信号処理タスクを軽減しながら、それはまた、凝集したQoSセッションの投与を必要とし、個々のデータを参照して品質保証を違反につながる可能性がある[16]凝集内を流れます。
Definition: Resource reservation protocols define signaling messages and message processing rules used to control resource allocation in IntServ architectures.
定義：リソース予約プロトコルはシグナリングメッセージとのIntServアーキテクチャにおけるリソース割り当てを制御するために使用されるメッセージの処理規則を定義します。
Discussion: It is the signaling messages of a resource reservation protocol that carry the information related to QoS sessions. This information includes a session identifier, the actual QoS parameters, and possibly flow descriptors.
ディスカッション：それは、QoSセッションに関連する情報を運ぶリソース予約プロトコルのシグナリングメッセージです。この情報は、セッション識別子、実際のQoSパラメータ、およびおそらく流れ記述子を含みます。
The message processing rules of the signaling protocols ensure that signaling messages reach all network nodes concerned. Some resource reservation protocols (e.g., RSVP, NSIS QoS NSLP [8]) are only concerned with this, i.e., carrying the QoS-related information to all the appropriate network nodes, without being aware of its content. This latter approach allows changing the way the QoS parameters are described, and different kinds of provisioning can be realized without the need to change the protocol itself.
シグナリングプロトコルのメッセージ処理ルールはシグナリングメッセージが関係するすべてのネットワークノードに到達することを確実。いくつかのリソース予約プロトコル（例えば、RSVP、NSISのQoS NSLP [8]）、すなわち、そのコンテンツを意識することなく、全ての適切なネットワークノードへのQoS関連情報を搬送する、これだけに関係しています。この後者のアプローチは、QoSパラメータが記載されている方法を変更することができ、およびプロビジョニングの異なる種類のプロトコル自体を変更することなく実現することができます。
Definition: A router is resource reservation capable (it supports resource reservation) if it is able to interpret signaling messages of a resource reservation protocol, and based on these messages is able to adjust the management of its flow classifiers and network resources so as to conform to the content of the signaling messages.
定義：ルーターがリソース予約が可能であるが、リソース予約プロトコルのシグナリングメッセージを解釈することができる場合（これは、リソース予約をサポート）、およびこれらのメッセージに基づいて適合するようにその流れの分類とネットワークリソースの管理を調整することができますシグナリングメッセージの内容に。
Discussion: Routers capture signaling messages and manipulate reservation states and/or reserved network resources according to the content of the messages. This ensures that the flows are treated as their specified QoS requirements indicate.
ディスカッション：ルータキャプチャシグナリングメッセージやメッセージの内容に応じて予約状態および/または予約のネットワーク資源を操作します。これは彼らの指定されたQoS要件が示すようフローが扱われることを保証します。
Definition: A reservation state is the set of entries in the router's memory that contain all relevant information about a given QoS session registered with the router.
定義：予約状況は、ルータに登録され与えられたQoSセッションに関するすべての関連情報が含まれているルータのメモリ内のエントリのセットです。
Discussion: States are needed because IntServ-related resource reservation protocols require the routers to keep track of QoS session and data-flow-related metadata. The reservation state includes the parameters of the QoS treatment, the description of how and where to forward the incoming signaling messages, refresh timing information, etc.
ディスカッション：イントサーブ関連のリソース予約プロトコルは、QoSセッションとデータ・フロー関連のメタデータを追跡するためにルータを必要とするため、国が必要とされています。予約状態は、QoS処理のパラメータを、どのように、どこタイミング情報を更新し、着信シグナリング・メッセージを転送する、等の記述を含みます
Based on how reservation states are stored in a reservation capable router, the routers can be categorized into two classes:
予約状態が予約できるルータに格納されている方法に基づいて、ルータは、2つのクラスに分類することができます。
Hard-state resource reservation protocols (e.g., ST2 [11]) require routers to store the reservation states permanently, established by a setup signaling primitive, until the router is explicitly informed that the QoS session is canceled.
ハード状態のリソース予約プロトコル（例えば、ST2 [11]）ルータは、明示的なQoSセッションがキャンセルされたことが通知されるまで、プリミティブのシグナリングの設定によって確立された、永続的予約状態を保存するために、ルータが必要です。
There are also soft-state resource reservation capable routers, where there are no permanent reservation states, and each state has to be regularly refreshed by appropriate refresh signaling messages. If no refresh signaling message arrives during a certain period, then the router stops the maintenance of the QoS session assuming that the end-points do not intend to keep the session up any longer or the communication lines are broken somewhere along the data path. This feature makes soft-state resource reservation capable routers more robust than hard-state routers, since no failures can cause resources to stay permanently stuck in the routers. (Note that it is still possible to have an explicit teardown message in soft-state protocols for quicker resource release.)
そこには永続的な予約状態が存在しないソフトステートリソース予約が可能なルータは、またしており、それぞれの状態を定期的に適切なリフレッシュシグナリングメッセージによってリフレッシュする必要があります。シグナリングメッセージを何もリフレッシュは、一定期間内に到着しない場合、ルータは、エンドポイントがもはやまたは通信線がどこかにデータパスに沿って切断されたセッションを維持するつもりはないと仮定したQoSセッションの維持を停止します。何の障害がリソースがルータに永続的に立ち往生滞在する原因となることができませんので、この機能は、ハードステートルータより対応ルータより堅牢なソフトステートリソース予約を行います。 （速く、リソース解放のためのソフトステートプロトコルにおいて明示的なティアダウンメッセージを有することが依然として可能であることに留意されたいです。）
Issues: Based on the initiating point of the refresh messages, soft-state resource reservation protocols can be divided into two groups. First, there are protocols where it is the responsibility of the end-points or their proxies to initiate refresh messages. These messages are forwarded along the path of the data flow refreshing the corresponding reservation states in each router affected by the flow. Second, there are other protocols, where routers and end-points have their own schedule for the reservation state refreshes and they signal these refreshes to the neighboring routers.
問題：リフレッシュメッセージ、ソフトステートリソース予約プロトコルの、開始点に基づいて2つのグループに分けることができます。まず、リフレッシュメッセージを開始するエンドポイントまたはそのプロキシの責任であるプロトコルがあります。これらのメッセージは、フローによって影響を受ける各ルータに対応する予約状態をリフレッシュデータフローのパスに沿って転送されます。第二に、ルータ及びエンドポイントは予約状態がリフレッシュのための独自のスケジュールを持っており、それらは隣接ルータにこれらのリフレッシュを知らせる他のプロトコルがあります。
Definition: The orientation of a resource reservation protocol tells which end of the protocol communication initiates the allocation of the network resources. Thus, the protocol can be sender- or receiver-oriented, depending on the location of the data flow source (sender) and destination (receiver) compared to the reservation initiator.
定義：リソース予約プロトコルの向きは、ネットワークリソースの割り当てを開始するプロトコル通信の終了指示します。従って、プロトコルは、データフローソース予約イニシエータに比べ（送信者）と宛先（受信機）の位置に応じて、センダまたはレシーバ配向させることができます。
Discussion: In the case of sender-oriented protocols (in some sources referred to as sender-initiated protocols), the resource reservation propagates in the same direction(s) as of the data flow(s). Consequently, in the case of receiver-oriented protocols, the signaling messages reserving resources are forwarded backward on the path of the data flow. Due to the asymmetric routing nature of the Internet, in this latter case, the path of the desired data flow should be known before the reservation initiator would be able to send the resource allocation messages. For example, in the case of RSVP, the RSVP PATH message, traveling from the data flow sources towards the destinations, first marks the path of the data flow on which the resource allocation messages will travel backward.
ディスカッション：送信者指向のプロトコルの場合には、（いくつかのソースに送信者によって開始プロトコルと称する）、リソース予約は、データ・フロー（単数または複数）の同じ方向（S）に伝播します。したがって、受信機指向のプロトコルの場合に、リソースを予約シグナリング・メッセージは、データフローの経路上後方に転送されます。インターネットの非対称ルーティング性質のために、この後者の場合には、所望のデータフローのパスは、リソース割当メッセージを送信することができるであろう予約開始前に知らなければなりません。例えば、RSVPの場合、宛先に向かうデータフローソースから走行RSVP PATHメッセージは、最初のリソース割当てメッセージが後方移動するれたデータフローのパスをマークします。
This definition considers only protocols that reserve resources for just one data flow between the end-nodes. The reservation orientation of protocols that reserve more than one data flow is not defined here.
この定義は、エンドノード間のちょうど1つのデータフローのためのリソースを予約プロトコルだけを考慮します。複数のデータフローを確保するプロトコルの予約の向きは、ここで定義されていません。
Issues: The location of the reservation initiator affects the basics of the resource reservation protocols and therefore is an important aspect of characterization. Most importantly, in the case of multicast QoS sessions, the sender-oriented protocols require the traffic sources to maintain a list of receivers and send their allocation messages considering the different requirements of the receivers. Using multicast QoS sessions, the receiver-oriented protocols enable the receivers to manage their own resource allocation requests and thus ease the task of the sources.
問題：予約開始剤の位置は、リソース予約プロトコルの基礎に影響を及ぼし、したがって、特性評価の重要な側面です。最も重要なのは、マルチキャストQoSのセッションの場合には、送信者指向のプロトコルは、受信機のリストを維持し、受信機のさまざまな要件を考慮し、その割り当てメッセージを送信するためにトラフィックソースを必要とします。マルチキャストQoSのセッションを使用して、受信機指向のプロトコルは、独自のリソース割り当て要求を管理し、これソースのタスクを容易にするために受信機を有効にします。
When a router is under "load", it means that there are tasks its
CPU(s) must attend to, and/or that its memory contains data it
must keep track of, and/or that its interface buffers are utilized
to some extent, etc. Unfortunately, we cannot assume that the
full internal state of a router can be monitored during a
benchmark; rather, we must consider the router to be a black box.
We need to look at router "load" in a way that makes this "load" measurable and controllable. Instead of focusing on the internal processes of a router, we will consider the external, and therefore observable, measurable and controllable processes that result in "load".
我々は、測定と制御、この「負荷」を作る方法でルータ「負荷」を見てする必要があります。代わりに、ルータの内部プロセスに焦点を当て、私たちは「負荷」になり、外部、およびので、観察、測定可能かつ制御可能なプロセスを検討します。
In this section we introduce several ways of creating "load" on a router; we will refer to these as "load factors" henceforth. These load factors are defined so that they each impact the performance of the router in a different way (or by different means), by utilizing different components of a resource reservation capable router as separately as possible.
このセクションでは、ルータの「負荷」を作成するためのいくつかの方法をご紹介します。私たちは今後、「負荷率」として、これらを参照してくださいます。これらの負荷率が定義されているので、可能な限り別々に資源予約が可能なルータのさまざまなコンポーネントを利用することにより、各衝撃異なる方法でルータの性能（または別の手段によって）。
During a benchmark, the performance of the device under test will have to be measured under different controlled load conditions, that is, with different values of these load factors.
ベンチマークの間、被試験デバイスの性能は、これらの負荷率の異なる値で、つまり、異なる制御された負荷条件で測定されなければなりません。
Definition: The best-effort traffic load factor is defined as the number and length of equal-sized best-effort data packets that traverse the router in a second.
定義：ベストエフォートトラフィック負荷率が第二のルータを横断する同じサイズのベストエフォート型のデータ・パケットの数と長さとして定義されます。
Discussion: Forwarding the best-effort data packets, which requires obtaining the routing information and transferring the data packet between network interfaces, requires processing power. This load factor creates load on the CPU(s) and buffers of the router.
議論：ルーティング情報を取得し、ネットワークインターフェースとの間でデータパケットを転送する必要がベストエフォートデータパケットを、転送、処理能力を必要とします。この負荷率は、CPU（S）およびルータのバッファに負荷がかかります。
For the purpose of benchmarking, we define a traffic flow as a stream of equal-sized packets with even interpacket delay. It is possible to specify traffic with varying packet sizes as a superposition of multiple best-effort traffic flows as they are defined here.
ベンチマークの目的のために、私たちも、パケット間遅延と同等のサイズのパケットのストリームとしてトラフィックフローを定義します。彼らがここで定義されているとして流れる複数のベストエフォート型トラフィックの重ね合わせとしてパケットサイズを変更することでトラフィックを指定することが可能です。
Issues: The same amount of data segmented into differently sized packets causes different amounts of load on the router, which has to be considered during benchmarking measurements. The measurement unit of this load factor reflects this as well.
問題：異なるサイズのパケットに分割し、同じ量のデータは、ベンチマークの測定時に考慮されなければならない、ルータの負荷の異なる量の原因となります。この負荷率の測定単位は、同様にこれを反映しています。
Measurement unit: This load factor has a composite unit of [packets per second (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces of one-hundred-byte packets per second.
測定ユニットは、この負荷率は、毎秒[パケット（PPS）の複合ユニットを有しています。バイト]。例えば、[5つのPPS。 100バイト]毎秒百バイトのパケットの5個を意味します。
Definition: The distinguished traffic load factor is defined as the number and length of the distinguished data packets that traverse the router in a second.
定義：区別トラフィック負荷率が第二のルータを横断する識別データ・パケットの数と長さとして定義されます。
Discussion: Similarly to the best-effort data, forwarding the distinguished data packets requires obtaining the routing information and transferring the data packet between network interfaces. However, in this case packets have to be classified as well, which requires additional processing capacity.
議論：同様にベストエフォート型のデータに、識別データパケットを転送するルーティング情報を取得し、ネットワークインターフェースとの間のデータパケットの転送を必要とします。しかし、この場合、パケットは、追加の処理能力を必要とする、同様に分類されなければなりません。
For the purpose of benchmarking, we define a traffic flow as a stream of equal-sized packets with even interpacket delay. It is possible to specify traffic with varying packet sizes as a superposition of multiple distinguished traffic flows as they are defined here.
ベンチマークの目的のために、私たちも、パケット間遅延と同等のサイズのパケットのストリームとしてトラフィックフローを定義します。彼らがここで定義されているように、複数の著名なトラフィックの重ね合わせが流れる際にパケットサイズを変更することでトラフィックを指定することが可能です。
Issues: Just as in the best-effort case, the same amount of data segmented into differently sized packets causes different amounts of load on the router, which has to be considered during the benchmarking measurements. The measurement unit of this load factor reflects this as well.
問題：ちょうどベストエフォート型の場合のように、異なるサイズのパケットに分割し、同じ量のデータは、ベンチマーク測定中に考慮しなければならないルータ、上の負荷の異なる量の原因となります。この負荷率の測定単位は、同様にこれを反映しています。
Measurement unit: This load factor has a composite unit of [packets per second (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces of one-hundred-byte packets per second.
測定ユニットは、この負荷率は、毎秒[パケット（PPS）の複合ユニットを有しています。バイト]。例えば、[5つのPPS。 100バイト]毎秒百バイトのパケットの5個を意味します。
Definition: The session load factor is the number of QoS sessions the router is keeping track of.
定義：セッションの負荷率は、ルータがの追跡されたQoSセッションの数です。
Discussion: Resource reservation capable routers maintain reservation states to keep track of QoS sessions. Obviously, the more reservation states are registered with the router, the more complex the traffic classification becomes, and the more time it takes to look up the corresponding resource reservation state. Moreover, not only the traffic flows, but also the signaling messages that control the reservation states have to be identified first, before taking any other action, and this kind of classification also means extra work for the router.
ディスカッション：リソース予約が可能なルータは、QoSセッションを追跡するために予約状態を維持します。明らかに、より多くの予約状態がルータに登録されている、より複雑なトラフィックの分類になり、そしてより多くの時間は、それが対応するリソース予約状態を調べるのにかかります。また、トラフィックフローだけでなく、予約状態を制御シグナリングメッセージは、他のアクションをとる前に、最初に同定する必要がある、と分類のこの種は、ルータのための余分な作業を意味します。
In the case of soft-state resource reservation protocols, the session load also affects reservation state maintenance. For example, the supervision of timers that watchdog the reservation state refreshes may cause further load on the router.
ソフトステートリソース予約プロトコルの場合には、セッション負荷も予約状態の維持に影響を与えます。例えば、予約状態のリフレッシュをウォッチドッグタイマの監督は、ルータ上で、さらに負荷が発生することがあります。
This load factor utilizes the CPU(s), the main memory, and the session management logic (e.g., content addressable memory), if any, of the resource reservation capable router.
この負荷率は、もしあれば、リソース予約が可能なルータのCPU（S）、メインメモリ、およびセッション管理ロジック（例えば、コンテンツアドレス可能メモリ）を利用します。
Measurement unit: This load component is measured by the number of QoS sessions that impact the router.
測定単位：このロードコンポーネントは、ルータに影響を与えたQoSセッションの数で測定されます。
Definition: The signaling intensity load factor is the number of signaling messages that are presented at the input interfaces of the router during one second.
定義：シグナル強度負荷率が1秒の間のルータの入力インターフェイスで提示されるシグナリングメッセージの数です。
Discussion: The processing of signaling messages requires processor power that raises the load on the control plane of the router.
議論：シグナリングメッセージの処理は、ルータの制御プレーンの負荷を上げるプロセッサパワーを必要とします。
In routers where the control plane and the data plane are not totally independent (e.g., certain parts of the tasks are served by the same processor; or the architecture has common memory buffers, transfer buses or any other resources) the signaling load can have an impact on the router's packet forwarding performance as well.
コントロールプレーンとデータプレーンは完全に独立していないルータでは、シグナリング負荷を有することができる（例えば、タスクの特定の部分には同一のプロセッサによって配信されまたはアーキテクチャ共通のメモリバッファ、転送バスまたは他の任意のリソースを持っています）ルータのパケット転送のパフォーマンスへの影響にも。
Naturally, just as everywhere else in this document, the term "signaling messages" refer only to the resource reservation protocol related primitives.
当然のことながら、同じように他のどこでも、この文書では、「シグナリングメッセージ」という用語は、リソース予約プロトコル関連のプリミティブにのみ参照してください。
Issues: Most resource reservation protocols have several protocol primitives realized by different signaling message types. Each of these message types may require a different amount of processing power from the router. This fact has to be considered during the benchmarking measurements.
問題：ほとんどのリソース予約プロトコルは、異なるシグナリングメッセージの種類によって実現いくつかのプロトコルプリミティブを持っています。これらのメッセージタイプの各々は、ルータからの処理能力の異なる量を必要とするかもしれません。この事実は、ベンチマーク測定中に考慮しなければなりません。
Measurement unit: The unit of this factor is signaling messages/second.
測定単位：この因子の単位は、メッセージ/秒シグナリングされます。
Definition: The signaling burst load factor is defined as the number of signaling messages that arrive to one input port of the router back-to-back ([1]), causing persistent load on the signaling message handler.
定義：バーストシグナリング負荷係数はバックツーバックルータの一方の入力ポートに到着するシグナリングメッセージの数として定義される（[1]）、シグナリング・メッセージ・ハンドラに永続的な負荷を引き起こします。
Discussion: The definition focuses on one input port only and does not consider the traffic arriving at the other input ports. As a consequence, a set of messages arriving at different ports, but with such a timing that would be a burst if the messages arrived at the same port, is not considered to be a burst. The reason for this is that it is not guaranteed in a black-box test that this would have the same effect on the router as a burst (incoming at the same interface) has.
ディスカッション：定義は一つだけの入力ポートに焦点を当て、他の入力ポートに到着するトラフィックを考慮していません。その結果、異なるポートに到着するメッセージのセットが、メッセージは同じポートに到着した場合、バーストになり、このようなタイミングと同様に、バーストとはみなされません。その理由は、このバースト（同じインターフェースで受信）を有するようルータに同じ効果を有するであろうことをブラックボックステストでは保証されないということです。
This definition conforms to the burst definition given in [3].
この定義は、[3]で与えられたバーストの定義に従います。
Issues: Most of the resource reservation protocols have several protocol primitives realized by different signaling message types. Bursts built up of different messages may have a different effect on the router. Consequently, during measurements the content of the burst has to be considered as well.
問題：リソース予約プロトコルの大半は、異なるシグナリングメッセージの種類によって実現いくつかのプロトコルプリミティブを持っています。異なるメッセージの構築バーストは、ルータ上の異なる効果を有することができます。これにより、測定中にバーストの内容も考慮しなければなりません。
Likewise, the first one of multiple idempotent signaling messages that each accomplish exactly the same end will probably not take the same amount of time to be processed as subsequent ones. Benchmarking methodology will have to consider the intended effect of the signaling messages, as well as the state of the router at the time of their arrival.
同様に、それぞれがまったく同じ目的を達成する複数の冪等のシグナリングメッセージの最初のものは、おそらくそれ以降のものとして処理されるように同じ時間を取ることはありません。ベンチマークの方法論は、到着時にシグナリングメッセージの意図した効果だけでなく、ルータの状態を考慮する必要があります。
Measurement unit: This load factor is characterized by the number of messages in the burst.
測定ユニット：この負荷率は、バースト内のメッセージの数によって特徴付けられます。
This group of definitions is a collection of measurable quantities that describe the performance impact the different load components have on the router.
定義のこのグループは、ルータ上の異なる負荷コンポーネントが持っている性能への影響を記述する測定可能な量の集合です。
During a benchmark, the values of these metrics will have to be measured under different load conditions.
ベンチマーク時には、これらのメトリックの値が異なる負荷条件で測定する必要があります。
Definition: The signaling message handling time (or, in short, signal handling time) is the latency ([1], for store-and-forward devices) of a signaling message passing through the router.
定義：時間（または、要するに、信号処理時間）を処理シグナリングメッセージがルータを通過するシグナリングメッセージの（ストアアンドフォワードデバイスのための[1]）の待ち時間です。
Discussion: The router interprets the signaling messages, acts based on their content and usually forwards them in an unmodified or modified form. Thus the message handling time is usually longer than the forwarding time of data packets of the same size.
議論：ルータはシグナリングメッセージを解釈し、その内容に基づいて、通常、未修飾または修飾された形態でそれらを転送する役割を果たす。したがってハンドリング時間メッセージは、同じサイズのデータパケットの転送時間よりも通常長いです。
There might be signaling message primitives, however, that are drained or generated by the router, like certain refresh messages. In this case, the signal handling time is not necessarily measureable, therefore it is not defined for such messages.
特定のリフレッシュメッセージのように、ルータによって排水または生成されているが、シグナリングメッセージプリミティブ、あるかもしれません。この場合、信号処理時間は、したがって、それはそのようなメッセージのために定義されていない、必ずしも測定可能ではありません。
In the case of signaling messages that carry information pertaining to multicast flows, the router might issue multiple signaling messages after processing them. In this case, by definition, the signal handling time is the latency between the incoming signaling message and the last outgoing signaling message related to the received one.
マルチキャストフローに関連する情報を運ぶシグナリングメッセージの場合、ルータは、それらを処理した後、複数のシグナリングメッセージを発行することがあります。この場合には、定義により、ハンドリング時間信号は、着信シグナリング・メッセージと受信された1つに関連する最後の発信シグナリングメッセージ間の遅延です。
The signal handling time is an important characteristic as it directly affects the setup time of a QoS session.
それが直接のQoSセッションのセットアップ時間に影響を与えたように、信号処理時間が重要な特性です。
Issues: The signal handling time may be dependent on the type of the signaling message. For example, it usually takes a shorter time for the router to remove a reservation state than to set it up. This fact has to be considered during the benchmarking process.
問題：シグナル処理時間は、シグナリングメッセージのタイプに依存してもよいです。例えば、それは通常それを設定するよりも、予約状態を除去するためのルータのための短い時間を要します。この事実は、ベンチマーク処理中に考慮しなければなりません。
As noted above, the first one of multiple idempotent signaling messages that each accomplish exactly the same end will probably not take the same amount of time to be processed as subsequent ones. Benchmarking methodology will have to consider the intended effect of the signaling messages, as well as the state of the router at the time of their arrival.
上述したように、それぞれがおそらく同じ時間を取ることはありません正確に同じ目的を達成複数冪等のシグナリングメッセージの最初のものは、後続のものとして処理されます。ベンチマークの方法論は、到着時にシグナリングメッセージの意図した効果だけでなく、ルータの状態を考慮する必要があります。
Measurement unit: The dimension of the signaling message handling time is the second, reported with a resolution sufficient to distinguish between different events/DUTs (e.g., milliseconds). Reported results MUST clearly indicate the time unit used.
測定単位：時間ハンドリングシグナリングメッセージの寸法が第二では、異なるイベント/用のDUT（例えば、ミリ秒）間を区別するのに十分な解像度で報告しました。報告された結果は、使用時間の単位を指定する必要があります。
Definition: Distinguished traffic delay is the latency ([1], for store-and-forward devices) of a distinguished data packet passing through the tested router device.
定義：識別トラフィックの遅延は、試験したルータ装置を通過する識別データパケットの（ストアアンドフォワードデバイスのための[1]）の待ち時間です。
Discussion: Distinguished traffic packets must be classified first in order to assign the network resources dedicated to the flow. The time of the classification is added to the usual forwarding time (including the queuing) that a router would spend on the packet without any resource reservation capability. This classification procedure might be quite time consuming in routers with vast amounts of reservation states.
ディスカッション：著名なトラフィックパケットが流れ専用のネットワークリソースを割り当てるために、最初に分類されなければなりません。分類の時間は、ルータが任意のリソース予約機能なしパケットに費やすだろう（キューイングを含む）通常の転送時間に加算されます。この分類法は、予約状態の膨大な量とルータに非常に時間がかかるかもしれません。
There are routers where the processing power is shared between the control plane and the data plane. This means that the processing of signaling messages may have an impact on the data forwarding performance of the router. In this case, the distinguished traffic delay metric also indicates the influence the two planes have on each other.
処理能力は、制御プレーンとデータプレーンとの間で共有されているルータがあります。これは、シグナリングメッセージの処理は、ルータのデータ転送性能に影響を与えることを意味します。この場合、識別トラフィック遅延メトリックはまた、2つの平面が互いに与える影響を示しています。
Issues: Queuing of the incoming data packets in routers can bias this metric, so the measurement procedures have to consider this effect.
問題：ルータで着信データパケットのキューイングが偏り、このメトリックは、測定手順を持っているので、この効果を検討することができます。
Measurement unit: The dimension of the distinguished traffic delay time is the second, reported with resolution sufficient to distinguish between different events/DUTs (e.g., millisecond units). Reported results MUST clearly indicate the time unit used.
測定単位：区別トラフィック遅延時間の次元は異なるイベント/用のDUT（例えば、ミリ秒単位）を区別するのに十分な解像度で報告され、第二です。報告された結果は、使用時間の単位を指定する必要があります。
Definition: Best-effort traffic delay is the latency of a best-effort data packet traversing the tested router device.
定義：ベストエフォートトラフィックの遅延は、試験されたルータ装置を通過するベストエフォート型のデータパケットのレイテンシーです。
Discussion: If the processing power of the router is shared between the control and data plane, then the processing of signaling messages may have an impact on the data forwarding performance of the router. In this case, the best-effort traffic delay metric is an indicator of the influence the two planes have on each other.
議論：ルータの処理能力は、制御及びデータプレーンの間で共有されている場合、シグナリングメッセージの処理は、ルータのデータ転送性能に影響を与えることができます。この場合は、ベストエフォート型トラフィックの遅延メトリックは、二つの面がお互いに与える影響の指標です。
Issues: Queuing of the incoming data packets in routers can bias this metric as well, so measurement procedures have to consider this effect.
問題：ルータで着信データパケットのキューイングが偏り、このメトリックは、同様に、その測定手順は、この効果を考慮することができます。
Measurement unit: The dimension of the best-effort traffic delay is the second, reported with resolution sufficient to distinguish between different events/DUTs (e.g., millisecond units). Reported results MUST clearly indicate the time unit used.
測定単位：ベストエフォートトラフィックの遅延の寸法は、異なるイベント/用のDUT（例えば、ミリ秒単位）を区別するのに十分な解像度で報告され、第二です。報告された結果は、使用時間の単位を指定する必要があります。
Definition: Signaling message deficit is one minus the ratio of the actual and the expected number of signaling messages leaving a resource reservation capable router.
定義：シグナリングメッセージ赤字は1マイナス実際の比率とリソース予約が可能なルータを残すシグナリングメッセージの期待数です。
Discussion: This definition gives the same value as the ratio of the lost (that is, not forwarded or not generated) and the expected messages. The above calculation must be used because the number of lost messages cannot be measured directly.
考察：この定義は失われたの比と同じ値（つまり、転送またはない生成されていない）と予想されるメッセージを示します。失われたメッセージの数を直接測定することができないため、上記の計算を使用する必要があります。
There are certain types of signaling messages that reservation capable routers are required to forward as soon as their processing is finished. However, due to lack of resources or other reasons, the forwarding or even the processing of these signaling messages might not take place.
予約が可能なルータは、すぐにその処理が終了すると転送するために必要とされるシグナリングメッセージの特定の種類があります。しかし、リソースまたはその他の理由が不足しているため、転送またはこれらのシグナリングメッセージであっても処理が行われない場合があります。
Certain other kinds of signaling messages must be generated by the router in the absence of any corresponding incoming message. It is possible that an overloaded router does not have the resources necessary to generate such a message.
シグナリングメッセージの特定の他の種類は、任意の対応する着信メッセージの非存在下で、ルータによって生成されなければなりません。オーバーロードされたルータは、このようなメッセージを生成するために必要なリソースを持っていない可能性があります。
To characterize these situations we introduce the signaling message deficit metric that expresses the ratio of the signaling messages that have actually left the router and those ones that were expected to leave the router. We subtract this ratio from one in order to obtain a loss-type metric instead of a "message survival metric".
私たちが実際にルータやルータを残すことが予想されたそれらのものを残してきたシグナリングメッセージの割合を表してシグナリングメッセージ赤字メトリックを導入し、これらの状況を特徴づけるために。我々は、損失型メトリックの代わりに「メッセージ生存メトリック」を得るために、1つのこの割合を差し引きます。
Since the most frequent reason for signaling message deficit is high router load, this metric is suitable for sounding out the scalability limits of resource reservation capable routers.
メッセージ赤字をシグナリングするための最も頻繁な理由は、高いルータ負荷であるため、このメトリックは、リソース予約が可能なルータのスケーラビリティの制限を発音するのに適しています。
During the measurements one must be able to determine whether a signaling message is still in the queues of the router or if it has already been dropped. For this reason we define a signaling message as lost if no forwarded signaling message is emitted within a reasonably long time period. This period is defined along with the benchmarking methodology.
測定中1は、シグナリングメッセージは、ルータのキューに残っているか、すでに削除されている場合かどうかを決定できなければなりません。このような理由から、私たちは何も転送され、シグナリングメッセージが合理的に長い時間内に放出されていない場合失われたとして、シグナリングメッセージを定義します。この期間は、ベンチマーク手法と一緒に定義されています。
Measurement unit: This measure has no unit; it is expressed as a real number, which is between zero and one, including the limits.
測定単位：この措置には単位がありません。これは、制限を含む0と1の間の実数、として表現されます。
Definition: The session maintenance capacity metric is used in the case of soft-state resource reservation protocols only. It is defined as the ratio of the number of QoS sessions actually being maintained and the number of QoS sessions that should have been maintained.
定義：セッション維持容量メトリックは唯一のソフトステートリソース予約プロトコルの場合に使用されています。これは、実際に維持されたQoSセッションの数の比と維持されているはずのQoSセッションの数として定義されます。
Discussion: For soft-state protocols maintaining a QoS session means refreshing the reservation states associated with it.
ディスカッション：それに関連付けられた予約状態をリフレッシュするのQoSセッション維持手段をソフトステートプロトコルの場合。
When a soft-state resource reservation capable router is overloaded, it may happen that the router is not able to refresh all the registered reservation states, because it does not have the time to run the state refresh task. In this case, sooner or later some QoS sessions will be lost even if the endpoints still require their maintenance.
ソフトステートリソース予約が可能なルータが過負荷になると、それは状態の更新タスクを実行する時間を持っていないので、ルータが登録されているすべての予約状態をリフレッシュすることができないことが起こり得ます。この場合、遅かれ早かれ、いくつかのQoSセッションは、エンドポイントがまだ彼らのメンテナンスが必要な場合でも失われます。
The session maintenance capacity sounds out the maximal number of QoS sessions that the router is capable of maintaining.
セッション維持能力は、ルータが維持することができるのQoSセッションの最大数を鳴らします。
Issues: The actual process of session maintenance is protocol and implementation dependent, thus so is the method to examine whether a session is maintained or not.
問題：セッション維持の実際のプロセスは、プロトコル及び実装依存であり、したがってのでセッションが維持されているか否かを調べる方法です。
In the case of soft-state resource reservation protocols, where the network nodes are responsible for generating the refresh messages, a router that fails to maintain a QoS session may not emit refresh signaling messages either. This has direct consequences on the signaling message deficit metric.
ネットワークノードは、リフレッシュメッセージを生成するための責任を負うソフトステートリソース予約プロトコルの場合には、QoSのセッションを維持するために失敗したルータは、いずれかのリフレッシュシグナリングメッセージを発しなくてもよいです。これは、シグナリングメッセージ赤字メトリックに直接的な影響を持っています。
Measurement unit: This measure has no unit; it is expressed as a real number, which is between zero and one (including the limits).
測定単位：この措置には単位がありません。これは、（限界値を含む）0と1の間の実数で表されます。
Depending mainly, but not exclusively, on the overall load of a router, it can be in exactly one of the following four conditions at a time: loss-free and QoS compliant; lossy and QoS compliant; loss-free but not QoS compliant; and neither loss-free nor QoS compliant. These conditions are defined below, along with the scalability limit.
ルータの全体的な負荷に、独占的に主に依存ではなく、それは正確に一度、以下の4つの条件のいずれかになります。損失フリー対応とQoS。非可逆およびQoS対応。損失のないが、QoSの準拠していません。損失のないものQoS対応でもありません。これらの条件は、スケーラビリティの制限とともに、以下に定義されています。
Definition: A router is in loss-free condition, or loss-free state, if and only if it is able to perform its tasks correctly and in a timely fashion.
定義：ルータは、損失のない状態、または損失のない状態にある場合、正確かつタイムリーにそのタスクを実行することが可能である場合にのみ。
Discussion: All existing routers have finite buffer memory and finite processing power. If a router is in loss-free state, the buffers of the router still contain enough free space to accommodate the next incoming packet when it arrives. Also, the router has enough processing power to cope with all its tasks, thus all required operations are carried out within the time the protocol specification allows; or, if this time is not specified by the protocol, then in "reasonable time" (which is then defined in the benchmarks). Similar considerations can be applied to other resources a router may have, if any; in loss-free states, the utilization of these resources still allows the router to carry out its tasks in accordance with applicable protocol specifications and in "reasonable time".
ディスカッション：すべての既存のルータは、有限のバッファメモリと、有限の処理能力を持っています。ルータが損失のない状態になっている場合は、ルータのバッファはまだそれが到着したときに次の着信パケットを収容するのに十分な空き領域が含まれています。また、ルータは、このように必要なすべての操作はプロトコル仕様が許す時間内で行われるすべてのタスクに対処するのに十分な処理能力を有しています。又は、この時間は、その後、（その後、ベンチマークで定義されている）「合理的な時間」に、プロトコルによって指定されていない場合。もしあれば同様の考察は、ルータが持つ他のリソースに適用することができます。損失のない状態では、これらのリソースの利用はまだルータが適用されるプロトコル仕様に従っておよび「妥当な時間」でそのタスクを実行することができます。
Note that loss-free states as defined above are not related to the reservation states of resource reservation protocols. The word "state" is used to mean "condition".
上記で定義されたリソース予約プロトコルの予約状態に関係しないように、その損失のない状態に注意してください。単語「状態」「状態」を意味するために使用されます。
Also note that it is irrelevant what internal reason causes a router to fail to perform in accordance with protocol specifications or in "reasonable time"; if it is not high load but -- for example -- an implementation error that causes the device to perform inadequately, it still cannot be said to be in a loss-free state. The same applies to the random early dropping of packets in order to prevent congestion. In a black-box measurement it is impossible to determine whether a packet was dropped as part of a congestion control mechanism or because the router was unable to forward it; therefore, if packet loss is observed except as noted below, the router is by definition in lossy state (lossy condition).
また、プロトコル仕様に合わせてか、「妥当な時間」で実行するために失敗するようにルータを引き起こし内部どのような理由は無関係であることに注意してください。例えば - - が高負荷ではなく、ある場合にデバイスが不十分実行させる実装エラー、まだ損失のない状態にあると言うことができません。同じことが、混雑を防ぐために、パケットのランダム早期ドロップに適用されます。 、ブラックボックスの測定では、パケットが輻輳制御機構の一部として、またはルータがそれを転送することができなかったために廃棄されたかどうかを決定することは不可能ですパケット損失は、以下に記載されている場合を除き認められた場合、したがって、ルータは、損失状態（ロッシー状態）で定義することによるものです。
If a distinguished data flow exceeds its allotted bandwidth, it is acceptable for routers to drop excess packets. Thus, a router that is QoS Compliant (see below) is also loss-free provided that it only drops packets from distinguished data flows.
識別データフローは、その割り当てられた帯域幅を超えている場合、ルータは、過剰なパケットを廃棄することが許容されます。このように、QoSの準拠（下記参照）であるルータはまた、損失のない、それが唯一の区別データフローからのパケットを廃棄することを提供しています。
If a device is not in a loss-free state, it is in a lossy condition/state.
デバイスは、損失のない状態ではない場合、それは非可逆状態/状態になっています。
Related definitions: Lossy Condition QoS Compliant Condition Not QoS Compliant Condition Scalability Limit
関連定義：ロッシー条件のQoS準拠条件ではないQoSの準拠状況スケーラビリティの制限
Definition: A router is in a lossy condition, or lossy state, if it cannot perform its duties adequately for some reason; that is, if it does not meet protocol specifications (except QoS guarantees, which are treated separately), or -- if time-related specifications are missing -- doesn't complete some operations in "reasonable time" (which is then defined in the benchmarks).
定義：それはいくつかの理由で適切にその職務を行うことができない場合、ルータは、非可逆状態、あるいは非可逆状態にあります。時間関連の仕様が不足している場合 - - 「合理的な時間」にいくつかの操作を完了していない（当時で定義されていることが（別々に処理されているQoS保証を除く）プロトコル仕様を満たしていない場合、またはそれは、ありますベンチマーク）。
Discussion: A router may be in a lossy state for several reasons, including but not necessarily limited to the following:
議論：ルータは、次のように必ずしも限定されるものではないが、いくつかの理由で損失の多い状態であってもよいです。
a) Buffer memory has run out, so either an incoming or a buffered packet has to be dropped.
a）は、バッファメモリがなくなったので、着信またはバッファリングしたパケットのいずれかが廃棄されなければなりません。
b) The router doesn't have enough processing power to cope with all its duties. Some required operations are skipped, aborted or suffer unacceptable delays.
b）のルータは、すべてその職務に対処するのに十分な処理能力を持っていません。いくつかの必要な操作は、スキップされた中断されたか、容認できない遅延を受けています。
c) Some other finite internal resource is exhausted.
C）他のいくつかの有限な内部リソースが消耗しています。
d) The router runs a defective (non-conforming) protocol implementation.
D）ルータは、欠陥（不適合）プロトコルの実装を実行します。
e) Hardware malfunction.
e）のハードウェアの故障。
f) A congestion control mechanism is active.
F）の輻輳制御機構がアクティブです。
Loss can mean the loss of data packets as well as signaling message deficit.
損失は、データパケットの損失だけでなく、シグナリングメッセージ赤字を意味することができます。
A router that does not lose data packets and does not experience signaling message deficit but fails to meet required QoS parameters is in the loss-free, but not in the QoS compliant state.
データパケットを失うことはありません。また、メッセージの赤字をシグナリングを経験していないが、必要なQoSパラメータを満たすために失敗したルータは、損失のないではなく、QoSの対応状態にあります。
If a device is not in a lossy state, it is in a loss-free condition/state.
デバイスが非可逆状態にない場合、それは損失のない状態/状態になっています。
Related definitions: Loss-Free Condition (especially the discussion of congestion control mechanisms that cause packet loss) Scalability Limit Signaling Message Deficit QoS Compliant Condition Not QoS Compliant Condition
関連定義：ロスのない状態（パケット損失の原因となる輻輳制御機構の特に議論）スケーラビリティ制限シグナリングメッセージ赤字のQoS準拠条件ではないQoSの準拠状況
Definition: A router is in the QoS compliant state if and only if all distinguished data flows receive the QoS treatment they are entitled to.
定義：ルータは、すべての区別のデータ・フローは、QoS処理を受けた場合にのみ、それらがに資格を与えている場合の状態を準拠のQoSです。
Discussion: Defining what specific QoS guarantees must be upheld is beyond the scope of this document because every reservation model may specify a different set of such parameters.
ディスカッション：すべての予約モデルは、このようなパラメータの異なるセットを指定する可能性があるため、このドキュメントの範囲を超えてどのような特定のQoS保証が守られなければならないの定義。
Loss, delay, jitter etc. of best-effort data flows are irrelevant when considering whether a router is in the QoS compliant state.
ベストエフォート型データフローの損失、遅延、ジッタなどのルータがQoSに準拠した状態にあるかどうかを検討する際には無関係です。
Related definitions: Loss-Free Condition Lossy Condition Not QoS Compliant Condition Scalability Limit
関連定義：ロスのない状態ロッシー条件ではないQoSの準拠状況スケーラビリティの制限
Definition: A router is in the not QoS compliant state if and only if it is not in the QoS compliant condition.
定義：ルーターがあればないのQoSに準拠した状態にあり、それがQoSに対応した状態でない場合にのみ。
Related definitions: Loss-Free Condition Lossy Condition QoS Compliant Condition Scalability Limit
関連定義：ロスのない状態ロッシー条件のQoS対応状況スケーラビリティの制限
Definition: The scalability limits of a router are the boundary load conditions where the router is still in the loss-free and QoS compliant state, but the smallest amount of additional load would drive it to a state that is either QoS compliant but not loss-free, or not QoS compliant but loss-free, or neither loss-free nor QoS compliant.
定義：ルータのスケーラビリティの制限は、ルータが損失のないおよびQoSの準拠状態にある境界負荷条件がありますが、追加の負荷の最小量は、いずれかのQoSが準拠けどloss-がない状態にそれを運転でしょう無料、またはQoS対応が、損失のない、またはどちらも損失のないものQoSに準拠していません。
Discussion: An unloaded router that operates correctly is in a loss-free and QoS compliant state. As load increases, the resources of the router are becoming more and more utilized. At a certain point, the router enters a state that is either not QoS compliant, or not loss-free, or neither QoS compliant nor loss-free. Note that such a point may be impossible to reach in some cases (for example if the bandwidth of the physical medium prevents increasing the traffic load any further).
ディスカッション：損失のないおよびQoS対応の状態になって、正しく動作し、無負荷ルータ。負荷が増加すると、ルータの資源はますます利用になっています。特定の時点で、ルータは、いずれかのQoSに準拠しない、または損失のない、またはどちらのQoS対応や損失、自由ではない状態になります。 （物理媒体の帯域幅は、任意のさらなるトラフィック負荷を増加できない場合など）、このような点がいくつかのケースでは到達することは不可能であり得ることに留意されたいです。
A particular load condition can be identified by the corresponding values of the load factors (as defined in 3.3 Router Load Factors) impacting the router. These values can be represented as a 7- tuple of numbers (there are only five load factors, but the traffic load factors have composite units and thus require two numbers each to express). We can think of these tuples as vectors that correspond to a state that is either both loss free and QoS compliant, or not loss-free (but QoS compliant), or not QoS compliant (but loss-free), or neither loss-free nor QoS compliant. The scalability limit of the router is, then, the boundary between the sets of vectors corresponding to the loss-free and QoS compliant states and all other states. Finding these boundary points is one of the objectives of benchmarking.
特定の負荷状態は、ルータに影響を与える（3.3ルータの負荷率で定義されるように）負荷率の対応する値によって同定することができます。これらの値は、（5つのみの負荷要因があるが、トラフィックの負荷率は、複合ユニットを有し、従ってそれぞれが表現するために2つの数値を必要とする）数字の7タプルとして表すことができます。私たちは、自由な損失とQoSに準拠しない、または損失のない（しかし、QoSの準拠）のいずれかの両方である状態に対応するベクターとしてこれらのタプルを考える、またはQoS対応（ただし、損失のない）ではない、またはどちらも損失のないことができますQoSが準拠します。ルータのスケーラビリティの制限は、それから、損失のないおよびQoS対応の状態や他のすべての状態に対応するベクトルのセット間の境界です。これらの境界点を見つけることがベンチマークの目的の一つです。
Benchmarks may try to separately identify the boundaries of the loss-free and of the QoS compliant conditions in the (seven-dimensional) space defined by the load-vectors.
ベンチマークは別に、負荷ベクトルによって定義された（7次元）空間での損失のないおよびQoSの準拠条件の境界を識別しようとするかもしれません。
Related definitions: Lossy Condition Loss-Free Condition QoS Compliant Condition Non QoS Compliant Condition
関連定義：ロッシー条件損失のないコンディションのQoS準拠条件以外のQoS対応状況
As this document only provides terminology and does not describe a protocol, an implementation, or a procedure, there are no security considerations associated with it.
この文書は唯一の専門用語を提供し、プロトコル、実装、またはプロシージャを記述していないとして、それに関連付けられたセキュリティ上の考慮事項はありません。
We would like to thank Telia Research AB, Sweden and the High Speed Networks Laboratory at the Department of Telecommunication and Media Informatics of the Budapest University of Technology and Economics, Hungary for their support in the research and development work, which contributed to the creation of this document.
私たちは、の創造に貢献した研究開発の仕事に彼らのサポートのためにハンガリー、ブダペスト工科経済大学の通信およびメディア情報学専攻でテリア研究AB、スウェーデン、高速ネットワーク研究所に感謝したいと思いますこのドキュメント。
[1] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[1]ブラドナーの、S.、 "ネットワーク相互接続デバイスのためのベンチマーキング用語"、RFC 1242、1991年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[3]マンデビル、R.、RFC 2285、1998年2月 "LANスイッチングデバイスのためのベンチマーキング用語を"。
[4] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[5] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[5]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[6]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[7] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", Work in Progress, April 2007.
[7] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、進歩、2007年4月に作業。
[8] Manner, J., Ed., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, June 2007.
[8]マナー、J.、エド。、Karagiannis、G.、およびA.マクドナルド、 "サービス品質シグナリングのためのNSLP"、進歩、2007年6月に作業。
[9] Ash, J., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", Work in Progress, March 2007.
[9]アッシュ、J.、ベイダー、A.、Kappler、C.、およびD.オラン、 "QoSのNSLP QSPECテンプレート"、進歩、2007年3月に作業。
[10] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet", Computer Communication Review, on-line version, volume 29, number 2, April 1999
[10] P.パン、H. Schulzrinneと、「YESSIR：インターネットのための簡単な予約メカニズム」、コンピュータコミュニケーションレビュー、オンライン版、ボリューム29、ナンバー2、1999年4月
[11] Delgrossi, L. and L. Berger, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[11] Delgrossi、L.およびL.バーガー、 "インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様 - バージョンST2 +"、RFC 1819、1995年8月。
[12] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated Reservation in the Internet", Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998
[12] P.ホワイト、J.クロウクロフト、「インターネットにおける動的な送信者が開始した予約のためのケース」、ジャーナル高速ネットワーク、QoSルーティングとシグナリング、巻特集で。 7第2号、1998
[13] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for Resource Reservation in IP Networks", Vancouver, IEEE Real-Time Technology and Applications Symposium, June 1999
[13] J. Bergkvist、D. Ahlard、T. Engborg、K. Nemethの、G. Feher、I. Cselenyi、M. Maliosz、 "ブーメラン：IPネットワークにおけるリソース予約のための単純なプロトコル"、バンクーバー、IEEE実時間技術と応用シンポジウム、1999年6月
[14] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight Resource Reservation for Unicast IP Traffic", International WS on QoS'98, IWQoS'98, May 18-20, 1998
[14] A.エリクソン、C. Gehrmann、QoS'98、IWQoS'98、月18-20、1998年の国際WS、 "堅牢かつセキュアな軽量のリソース予約ユニキャストIPトラフィックのために"
[15] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.
[15]マナー、J.およびX.フー、「既存のサービス品質シグナリングプロトコルの分析」、RFC 4094、2005年5月。
[16] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[16]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
Authors' Addresses
著者のアドレス
Gabor Feher Budapest University of Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
ガボールFeherブダペスト工科大学と経済学部通信とメディア情報ハンガリーの科学者たちはKRT。 2 H-1117ブダペスト、ハンガリー
Phone: +36 1 463-1538 EMail: Gabor.Feher@tmit.bme.hu
電話：+36 1 463-1538 Eメール：Gabor.Feher@tmit.bme.hu
Krisztian Nemeth Budapest University of Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
テクノロジーのネーメト・クリスティアーンブダペスト大学とテレコミュニケーションとメディア情報マジャールTudosok KRTの経済学部。 2、H-1117、ブダペスト、ハンガリー
Phone: +36 1 463-1565 EMail: Krisztian.Nemeth@tmit.bme.hu
電話：+36 1 463-1565 Eメール：Krisztian.Nemeth@tmit.bme.hu
Andras Korn Budapest University of Technology and Economics Department of Telecommunication and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
テクノロジーのアンドラーシュKornシェルブダペスト大学と通信の経済学部とメディア情報マジャールTudosok KRT。 2、H-1117、ブダペスト、ハンガリー
Phone: +36 1 463-2664 EMail: Andras.Korn@tmit.bme.hu
電話：+36 1 463-2664 Eメール：Andras.Korn@tmit.bme.hu
Istvan Cselenyi TeliaSonera International Carrier Vaci ut 22-24, H-1132 Budapest, Hungary
テリアソネラ国際キャリアCselényiイシュトヴァーンヴァーツィは、UT 22-24間、H-1132ブダペスト、ハンガリー
Phone: +36 1 412-2705 EMail: Istvan.Cselenyi@teliasonera.com
電話：+36 1 412-2705 Eメール：Istvan.Cselenyi@teliasonera.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。