[要約] RFC 4883は、リソース予約可能なルータのベンチマーク用語に関する規格です。その目的は、リソース予約機能を持つルータの性能評価における共通の用語と定義を提供することです。
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）The IETF Trust（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] [7] [7] [8] [9]、およびYessir（さらに別の送信者セッションインターネット予約）[10]、ST2 [11]、セッション説明プロトコル（SDP）[12]、Boomerang [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.
混乱を避けるために、この用語は、IntServリソースの予約を提供するシグナル伝達プロトコルのみを考慮していることを強調したいと思います。たとえば、DiffServ Toolboxのテクニックは、主に私たちの範囲を超えています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
議論：「Best-Effort」とは、ルーターがデータパケットを迅速かつ安全に転送するために最善を尽くすことを意味しますが、何も保証しません（たとえば、遅延または損失の確率）。このタイプのトラフィックは、今日のインターネットで最も一般的です。
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セッションがIntServアーキテクチャを介して実現される場合のみを扱います。リソース予約プロトコルの信号メッセージを使用してセッションが確立されると想定されています。
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セッションを識別し、データフローを指します。「FlowsPec」は、目的のQoS処理を指定し、「フィルター仕様」は、FlowsPecで定義された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.
ディスカッション：IntServ関連のリソース予約プロトコルには、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セッションのメンテナンスを停止します。この機能により、ソフトステートリソースのリソース対応ルーターは、ハードステートルーターよりも堅牢になります。これは、リソースがルーターに永久に詰まらせることができないためです。（ソフトステートプロトコルに明示的な断downメッセージがあるため、リソースをより迅速にリリースすることはまだ可能であることに注意してください。）
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.
議論：送信者指向のプロトコルの場合（送信者開始プロトコルと呼ばれるいくつかのソースで）、リソースの予約はデータフローと同じ方向に伝播します。その結果、レシーバー指向のプロトコルの場合、リソースをリソースするシグナリングメッセージは、データフローの経路に後方に転送されます。インターネットの非対称ルーティングの性質により、この後者の場合、予約イニシエーターがリソース割り当てメッセージを送信する前に、目的のデータフローのパスを知っておく必要があります。たとえば、RSVPの場合、RSVPパスメッセージはデータフローソースから目的地に向かって移動し、最初にリソース割り当てメッセージが後方に移動するデータフローのパスを示します。
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.
ルーターが「負荷」にある場合、CPUが注意を払わなければならないタスクがあることを意味します。など。残念ながら、ルーターの完全な内部状態をベンチマーク中に監視できるとは想定できません。むしろ、ルーターをブラックボックスと見なす必要があります。
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.
定義：最良のトラフィック負荷係数は、ルーターを1秒で横断する等しいサイズのベストエフォートデータパケットの数と長さとして定義されます。
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およびバッファーに負荷を作成します。
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バイト]は、1秒あたり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.
定義：識別されたトラフィック負荷係数は、ルーターを1秒で横断する識別されたデータパケットの数と長さとして定義されます。
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バイト]は、1秒あたり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、メインメモリ、およびセッション管理ロジック（コンテンツアドレス可能なメモリなど）を使用します。
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つの入力ポートに連続して到着するシグナリングメッセージの数（[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.
ディスカッション：定義は1つの入力ポートのみに焦点を当てており、他の入力ポートに到着するトラフィックを考慮していません。結果として、さまざまなポートに到着するメッセージのセットですが、メッセージが同じポートに到着した場合に破裂するようなタイミングがあるため、バーストとは見なされません。この理由は、ブラックボックステストでは、これがバースト（同じインターフェイスで着信）と同じ効果があることが保証されていないためです。
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.
同様に、それぞれがまったく同じ端を達成した複数のiDempotentシグナリングメッセージの最初の1つは、おそらく後続のものと同じ時間をかけて処理されることはありません。ベンチマークの方法論では、シグナリングメッセージの意図した効果と、到着時のルーターの状態を考慮する必要があります。
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.
マルチキャストフローに関連する情報を伝達するシグナリングメッセージの場合、ルーターはそれらを処理した後に複数のシグナリングメッセージを発行する可能性があります。この場合、定義上、信号処理時間は、着信シグナリングメッセージと受信したメッセージに関連する最後の発信信号メッセージとの間の遅延です。
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.
上記のように、それぞれがまったく同じ端を達成した複数のiDempotentシグナリングメッセージの最初の1つは、おそらく後続のものと同じ時間をかけて処理されることはありません。ベンチマークの方法論では、シグナリングメッセージの意図した効果と、到着時のルーターの状態を考慮する必要があります。
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.
測定ユニット：シグナリングメッセージ処理時間の次元は2番目であり、異なるイベント/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.
測定ユニット：識別されたトラフィック遅延時間の寸法は2番目であり、異なるイベント/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.
説明：ルーターの処理能力がコントロールプレーンとデータプレーンの間で共有されている場合、シグナリングメッセージの処理はルーターのデータ転送パフォーマンスに影響を与える可能性があります。この場合、最良のトラフィック遅延メトリックは、2つの飛行機が互いに及ぼす影響の指標です。
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.
測定ユニット：最も効果的なトラフィック遅延の次元は2番目であり、異なるイベント/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.
定義：シグナリングメッセージの赤字は、リソース予約対応ルーターを残す実際のシグナリングメッセージの比率と予想される数の比率を差し引いたものです。
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.
測定中、シグナリングメッセージがまだルーターのキューにあるかどうか、またはすでに削除されているかどうかを判断できる必要があります。このため、合理的に長い期間内に転送された信号メッセージが放出されない場合、シグナリングメッセージを失われたものとして定義します。この期間は、ベンチマーク方法論とともに定義されています。
Measurement unit: This measure has no unit; it is expressed as a real number, which is between zero and one, including the limits.
測定単位：この測定にはユニットがありません。これは、制限を含むゼロと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).
測定単位：この測定にはユニットがありません。これは、ゼロから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つの条件のうち正確な1つになります。損失なしおよび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準拠条件ではない
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準拠ですが損失ではない状態に駆り立てます - 無料、または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ルーター負荷係数で定義されている）の対応する値によって識別できます。これらの値は、7タプルの数字として表すことができます（5つの負荷係数は5つしかありませんが、トラフィック負荷係数には複合単位があるため、それぞれ2つの数値が必要です）。これらのタプルは、損失フリーとQoSに準拠しているか、損失のない（ただしQoS準拠）、またはQoS準拠（ただし損失のない）、または損失のないものではない状態に対応するベクトルと考えることができますQoS準拠もありません。ルーターのスケーラビリティ限界は、損失のない状態とQoS準拠の状態に対応するベクターのセット間の境界と他のすべての状態です。これらの境界点を見つけることは、ベンチマークの目的の1つです。
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.
スウェーデンのTelia Research AB、およびBudapest Technology and Economics大学の電気通信およびメディア情報学部の高速ネットワーク研究所、ハンガリーの研究開発作業への支援に感謝します。このドキュメント。
[1] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[1] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[3] Mandeville、R。、「LANスイッチングデバイスのベンチマーク用語」、RFC 2285、1998年2月。
[4] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4] Braden、R.、Clark、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] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[6] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「Signalingの次のステップ（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. Hancock、「Gist：General Internet Signling Transport」、2007年4月、進行中の作業。
[8] Manner, J., Ed., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, June 2007.
[8] Mather、J.、ed。、Karagiannis、G。、およびA. McDonald、「サービス品質シグナリングのためのNSLP」、2007年6月、進行中の作業。
[9] Ash, J., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", Work in Progress, March 2007.
[9] Ash、J.、Bader、A.、Kappler、C。、およびD. Oran、「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。シュルツリン、「Yessir：インターネットの簡単な予約メカニズム」、コンピューター通信レビュー、オンラインバージョン、第29巻、29番、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. Berger、「インターネットストリームプロトコルバージョン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. White、J。Crowcroft、「インターネットでの動的送信者が開始する予約のケース」、高速ネットワークに関するジャーナル、QoSルーティングとシグナリングに関する特別号、Vol。7 No. 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、「Boomerang：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、「ユニキャストIPトラフィックのための堅牢で安全な軽量リソース予約」、1998年5月18〜20日、QOS'98、IWQOS'98のInternational WS
[15] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.
[15] Mather、J。およびX. Fu、「既存のサービス品質シグナル伝達プロトコルの分析」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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
Gabor Feher Budapest工科大学経済学部の電気通信およびメディア情報学部Magyar Tudosok Krt。2、H-1117、ブダペスト、ハンガリー
Phone: +36 1 463-1538
EMail: 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
Krisztian Nemeth Budapest Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok Krt。2、H-1117、ブダペスト、ハンガリー
Phone: +36 1 463-1565
EMail: 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
アンドラス・コーン・ブダペスト工科大学経済学部の電気通信およびメディア情報学部門Magyar Tudosok Krt。2、H-1117、ブダペスト、ハンガリー
Phone: +36 1 463-2664
EMail: Andras.Korn@tmit.bme.hu
Istvan Cselenyi TeliaSonera International Carrier Vaci ut 22-24, H-1132 Budapest, Hungary
Istvan Cselenyi Teliasonera International Carrier Vaci UT 22-24、H-1132 Budapest、ハンガリー
Phone: +36 1 412-2705
EMail: Istvan.Cselenyi@teliasonera.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。