RFC4883 日本語訳
4883 Benchmarking Terminology for Resource Reservation CapableRouters. G. Feher, K. Nemeth, A. Korn, I. Cselenyi. July 2007. (Format: TXT=54205 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Feher
Request for Comments: 4883 K. Nemeth
Category: Informational A. Korn
BUTE
I. Cselenyi
TeliaSonera
July 2007
コメントを求めるワーキンググループG.フェーヘルの要求をネットワークでつないでください: 4883年のK.Nemethカテゴリ: 情報のA.コルンビュートI.Cselenyi TeliaSonera2007年7月
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).
IETFが信じる著作権(C)(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.
このドキュメントのプライマリ目的はIntegrated Services(IntServ)IPルータの資源予約シグナリングのベンチマーキングに特定の用語を定義することです。 これらの用語は、資源予約をサポートするルータのためにベンチマーキング方法論を定義する追加ドキュメントで使用されるか、またはベンチマーキング測定値のために書式を報告できます。
Feher, et al. Informational [Page 1] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[1ページ]情報のRFC4883ベンチマーキング用語
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
1. 序論…2 2. 既存の定義…3 3. 用語の定義…4 3.1. 交通の流れはタイプされます…4 3.1.1. データは流れます…4 3.1.2. 顕著なデータは流れます…4 3.1.3. ベストエフォート型データは流れます…5 3.2. 資源予約プロトコル基礎…5 3.2.1. QoSセッション…5 3.2.2. 資源予約プロトコル…6 3.2.3. 資源予約のできるルータ…7 3.2.4. 予約状態…7 3.2.5. 資源予約プロトコルオリエンテーション…8 3.3. ルータ荷重係数…9 3.3.1. ベストエフォート型トラフィックは要素をロードします…9 3.3.2. 顕著なトラフィックは要素をロードします…10 3.3.3. セッション荷重係数…11 3.3.4. シグナリング強度荷重係数…11 3.3.5. シグナリングは荷重係数を押し破きました…12 3.4. パフォーマンス測定基準…13 3.4.1. シグナリングメッセージハンドリング時間…13 3.4.2. 顕著なトラフィックは延着します…14 3.4.3. ベストエフォート型トラフィックは延着します…15 3.4.4. シグナリングメッセージ赤字…15 3.4.5. セッションメインテナンス容量…16 3.5. ルータ負荷状態とスケーラビリティ限界…17 3.5.1. 無損失の状態…17 3.5.2. 損失性状態…18 3.5.3. QoS対応することの状態…19 3.5.4. QoS対応することの状態でない…20 3.5.5. スケーラビリティ限界…20 4. セキュリティ問題…21 5. 承認…21 6. 参照…21 6.1. 標準の参照…21 6.2. 有益な参照…21
1. Introduction
1. 序論
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]を使用するシグナリングベースの資源予約はアプローチに食糧を供給するService(QoS)の異なったQualityの重要な部分です。 したがって、シグナリングベースの資源予約を配布するのを計画しているネットワーク・オペレータは、性能を転送しながら、それらのデータで予約のできるルータのスケーラビリティ制限とシグナリングの影響を調べたがっているかもしれません。
Feher, et al. Informational [Page 2] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[2ページ]情報のRFC4883ベンチマーキング用語
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の標準のResource ReSerVationプロトコル(RSVP)[5]、Signaling(NSIS)[6][7][8][9]のNext Steps、およびYESSIR(しかし、Another Sender Sessionインターネット予約)[10]や、ST2+[11]や、Session記述プロトコル(SDP)[12]や、Boomerang[13]や、Ticket[14]などの実験的な数人の1つ。 また、これらのプロトコルのいくつかが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道具箱のテクニックは支配的にそうです。私たちの範囲を超えて。
2. Existing Definitions
2. 既存の定義
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.
RFC1242「ネットワーク相互接続デバイスのためのベンチマーキング用語」[1]とRFC2285「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]で広げられたSignalingワーキンググループにNext Stepsによって使用される用語と一致した方法で用語を定義します。
For the sake of clarity and continuity, this document adopts the template for definitions set out in Section 2 of RFC 1242.
明快と連続のために、このドキュメントはRFC1242のセクション2を始められた定義のためのテンプレートを採用します。
Feher, et al. Informational [Page 3] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[3ページ]情報のRFC4883ベンチマーキング用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Definition of Terms
3. 用語の定義
3.1. Traffic Flow Types
3.1. 交通の流れはタイプされます。
This group of definitions describes traffic flow types forwarded by resource reservation capable routers.
定義のこのグループは資源予約のできるルータによって進められた交通の流れタイプについて説明します。
3.1.1. Data Flow
3.1.1. データフロー
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-tuple「ソースアドレス」。 ソースポート。 送付先アドレス。 仕向港。 「プロトコル番号」は一般的にこのために(ポートナンバーが適切であるところ)使用されます。 また、IPv6パケットのFlow Label分野を利用するのも可能です。 流れ識別の、より多くのコメントについて、[6]を参照してください。
3.1.2. Distinguished Data Flow
3.1.2. 顕著なデータフロー
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.
顕著なデータフローの最も一般的な用法はベストエフォート型データフローのものよりさらに高い優先度処理を得る(次の定義を見てください)ことです。 これらの場合では、顕著なデータフローは「プレミアムデータフロー」と時々呼ばれます。 それにもかかわらず、理論的に、ベストエフォート型流れのものより悪い処理を必要とするのは可能です。
Feher, et al. Informational [Page 4] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[4ページ]情報のRFC4883ベンチマーキング用語
3.1.3. Best-Effort Data Flow
3.1.3. ベストエフォート型データフロー
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.
ベストエフォート型データフローに属すパケットはルータによって分類される必要はありません。 すなわち、ルータは、パケットがどの処理の権利を与えられるかを見つけるために関連する予約セッションを見つける必要はありません。
3.2. Resource Reservation Protocol Basics
3.2. 資源予約プロトコル基礎
This group of definitions applies to signaling-based resource reservation protocols implemented by IP router devices.
定義のこのグループはIPルータデバイスによって実装されたシグナリングベースの資源予約プロトコルに適用されます。
3.2.1. QoS Session
3.2.1. QoSセッション
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セッションは特定のデータフローに関係する1セットのネットワーク・ノードの間で共有された応用層概念です。 セッションに関連している情報は彼らが必要とする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アーキテクチャの上に実現されるケースに対処するだけです。 セッションが資源予約プロトコルに関するシグナリングメッセージを使用することで確立されると思われます。
Feher, et al. Informational [Page 5] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[5ページ]情報のRFC4883ベンチマーキング用語
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協定は同じである必要はありません。 代わりに、同じマルチキャストグループ(Cf 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]の中に個々のデータフローを示す上質の保証の違反に通じるかもしれません。
3.2.2. Resource Reservation Protocol
3.2.2. 資源予約プロトコル
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
シグナリングプロトコルのメッセージ処理規則は、シグナリングメッセージがノードが関したすべてのネットワークに達するのを確実にします。 いくつかの資源予約プロトコル、(例えば、RSVP、NSIS QoS NSLP[8])はこれに関係があるだけであり、すなわち、携帯はQoS関連です。
Feher, et al. Informational [Page 6] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[6ページ]情報のRFC4883ベンチマーキング用語
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.
内容を意識していることのないすべての適切なネットワーク・ノードへの情報。 この後者のアプローチで、QoSパラメタについて説明して、プロトコル自体を変える必要性なしで異種の食糧を供給することを実感できる方法を変えます。
3.2.3. Resource Reservation Capable Router
3.2.3. 資源予約のできるルータ
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として扱われるのを確実にします。
3.2.4. Reservation State
3.2.4. 予約状態
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
また、軟性国家の資源予約のできるルータがあります、どんな永久的な予約州もなくて、状態が定期的に適切な状態で壮快でなければならないそれぞれがシグナリングをリフレッシュするところで
Feher, et al. Informational [Page 7] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[7ページ]情報のRFC4883ベンチマーキング用語
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つのグループに分割できます。 まず最初に、プロトコルがそれがエンドポイントの責任であるところにあるか、または開始する彼らのプロキシはメッセージをリフレッシュします。 流れで影響を受ける各ルータで対応する予約州をリフレッシュしながら、データフローの経路に沿ってこれらのメッセージを転送します。 2番目に、他のプロトコルがあって、予約状態がリフレッシュして、これらに合図するので、ルータとエンドポイントにはそれら自身のがあるところでスケジュールは隣接しているルータにリフレッシュします。
3.2.5. Resource Reservation Protocol Orientation
3.2.5. 資源予約プロトコルオリエンテーション
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 PATHメッセージは最初に、資源配分メッセージが後方に移動するデータフローの経路を示します。
Feher, et al. Informational [Page 8] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[8ページ]情報のRFC4883ベンチマーキング用語
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つのデータフローのためのリソースを予約するプロトコルだけを考えます。 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セッションを使用して、受信機指向のプロトコルは、受信機がそれら自身の資源配分要求を管理して、その結果、ソースに関するタスクを緩和するのを可能にします。
3.3. Router Load Factors
3.3. ルータ荷重係数
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.
ベンチマークの間、テスト中のデバイスの性能は異なった制御負荷条件のもとで測定されなければならないでしょう、すなわち、これらの荷重係数の異価で。
3.3.1. Best-Effort Traffic Load Factor
3.3.1. ベストエフォート型トラヒック負荷要素
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秒後にルータを横断する等しいサイズのベストエフォート型データ・パケットの数と長さと定義されます。
Feher, et al. Informational [Page 9] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[9ページ]情報のRFC4883ベンチマーキング用語
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.
ベンチマーキングの目的のために、私たちはinterpacket遅れがあっても同じサイズのパケットの流れと交通の流れを定義します。 それらがここで定義されるとき複数のベストエフォート型トラフィックの重ね合わせが流れるのに従ってパケットサイズを変えるのにトラフィックを指定するのは可能です。
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.
測定単位: この荷重係数には合成ユニットがある、[2番目の(pps)あたりのパケット; バイト]。 例えば、[5pps; 100バイト]は5片の1秒あたりの100バイトのパケットを意味します。
3.3.2. Distinguished Traffic Load Factor
3.3.2. 顕著なトラヒック負荷要素
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.
ベンチマーキングの目的のために、私たちはinterpacket遅れがあっても同じサイズのパケットの流れと交通の流れを定義します。 それらがここで定義されるとき複数の顕著なトラフィックの重ね合わせが流れるのに従ってパケットサイズを変えるのにトラフィックを指定するのは可能です。
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
問題: ちょうどベストエフォート型ケースのように、同じデータ量はルータで異なった量の負荷を異なって大きさで分けられたパケット原因に区分しました。(それは、ベンチマーキングの間、考えられなければなりません)。
Feher, et al. Informational [Page 10] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[10ページ]情報のRFC4883ベンチマーキング用語
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.
測定単位: この荷重係数には合成ユニットがある、[2番目の(pps)あたりのパケット; バイト]。 例えば、[5pps; 100バイト]は5片の1秒あたりの100バイトのパケットを意味します。
3.3.3. Session Load Factor
3.3.3. セッション荷重係数
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セッションの数によって測定されます。
3.3.4. Signaling Intensity Load Factor
3.3.4. シグナリング強度荷重係数
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.
議論: シグナリングメッセージの処理はルータの制御飛行機に負荷を上げるプロセッサパワーを必要とします。
Feher, et al. Informational [Page 11] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[11ページ]情報のRFC4883ベンチマーキング用語
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.
測定単位: この要素の単位はメッセージ/秒を示しています。
3.3.5. Signaling Burst Load Factor
3.3.5. シグナリングは荷重係数を押し破きました。
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.
問題: 資源予約プロトコルの大部分は異なったシグナリングメッセージタイプにいくつかのプロトコル基関数を実現させます。 異なったメッセージについて確立された炸裂は異なった影響をルータに与えるかもしれません。 その結果、また、測定値の間、炸裂の内容は考えられなければなりません。
Feher, et al. Informational [Page 12] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[12ページ]情報のRFC4883ベンチマーキング用語
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.
同様に、それぞれまさに同じ終わりを達成する複数のベキ等元シグナリングメッセージの最初の1つは、その後のものとして処理されるにはたぶん同じ時間がかからないでしょう。 ベンチマーキング方法論はシグナリングメッセージの意図された効果を考えなければならないでしょう、彼らの到着時点のルータの状態と同様に。
Measurement unit:
This load factor is characterized by the number of messages in the
burst.
測定単位: この荷重係数は炸裂における、メッセージの数によって特徴付けられます。
3.4. Performance Metrics
3.4. パフォーマンス測定基準
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.
ベンチマークの間、これらの測定基準の値は異なった負荷条件のもとで測定されなければならないでしょう。
3.4.1. Signaling Message Handling Time
3.4.1. シグナリングメッセージハンドリング時間
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セッションの準備時間に影響するとき、信号取り扱い時間は重要な特性です。
Feher, et al. Informational [Page 13] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[13ページ]情報のRFC4883ベンチマーキング用語
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.
上で述べたように、それぞれまさに同じ終わりを達成する複数のベキ等元シグナリングメッセージの最初の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.
測定単位: シグナリングメッセージハンドリング時間の次元は解決が異なった出来事/DUTs(例えば、ミリセカンド)を見分けることができるくらい報告された2番目です。 報告された結果は、タイム・ユニットが使用したのを明確に示さなければなりません。
3.4.2. Distinguished Traffic Delay
3.4.2. 顕著な交通遅れ
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.
問題: ルータにおける、受信データパケットの列を作りがメートル法でこれに偏ることができるので、測定手順はこの効果を考えなければなりません。
Feher, et al. Informational [Page 14] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[14ページ]情報のRFC4883ベンチマーキング用語
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.
測定単位: 顕著な交通遅延時間の寸法は解決が異なった出来事/DUTs(例えば、ミリセカンドユニット)を見分けることができるくらい報告された2番目です。 報告された結果は、タイム・ユニットが使用したのを明確に示さなければなりません。
3.4.3. Best-effort Traffic Delay
3.4.3. ベストエフォート型交通遅れ
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.
測定単位: ベストエフォート型交通遅れの次元は解決が異なった出来事/DUTs(例えば、ミリセカンドユニット)を見分けることができるくらい報告された2番目です。 報告された結果は、タイム・ユニットが使用したのを明確に示さなければなりません。
3.4.4. Signaling Message Deficit
3.4.4. シグナリングメッセージ赤字
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.
彼らの処理が終わっているとすぐに、進めるのが、あるである予約のできるルータが必要であるというシグナリングメッセージのタイプがあります。 しかしながら、財源不足か他の理由のため、これらのシグナリングメッセージの推進か処理さえ行われないかもしれません。
Feher, et al. Informational [Page 15] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[15ページ]情報のRFC4883ベンチマーキング用語
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".
これらの状況を特徴付けるために、私たちはメートル法でシグナリングメッセージ赤字を紹介します。それは実際にいなくなると予想されたルータとそれらのものをルータに残したシグナリングメッセージの比率を表します。 私たちは、「メッセージ生存メートル法」でaの代わりにメートル法の損失タイプを得るために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つに間あります)。
3.4.5. Session Maintenance Capacity
3.4.5. セッション維持容量
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セッションが失われるでしょう。
Feher, et al. Informational [Page 16] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[16ページ]情報のRFC4883ベンチマーキング用語
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の間あります)。
3.5. Router Load Conditions and Scalability Limit
3.5. ルータ負荷状態とスケーラビリティ限界
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対応しません。 これらの状態はスケーラビリティ限界と共に以下で定義されます。
3.5.1. Loss-Free Condition
3.5.1. 無損失の状態
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".
議論: すべての既存のルータには、有限バッファ記憶と有限処理能力があります。 ルータが無損失の状態にあるなら、ルータに関するバッファはまだ到着するとき、次の入って来るパケットを収容できるくらいの空きスペースを含んでいます。 また、ルータはすべてのタスクに対処するパワーを処理しながら、堪能します、その結果、すべての必要な操作がプロトコル仕様が許容する時中に行われます。 「妥当な時間」(次に、ベンチマークで定義される)で今回がプロトコルによって指定されないときのその時。 ルータがもしあれば持っているかもしれない他のリソースに同様の問題を適用できます。 無損失の州では、これらのリソースの利用で、ルータが適切なプロトコル仕様と「妥当な時間」でまだタスクを行うことができます。
Feher, et al. Informational [Page 17] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[17ページ]情報のRFC4883ベンチマーキング用語
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 Compliant(以下を見る)であるルータも損失なしです。
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対応することの状態
3.5.2. Lossy Condition
3.5.2. 損失性状態
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) バッファメモリがなくなったので、入来かバッファリングされたパケットのどちらかが落とされなければなりません。
Feher, et al. Informational [Page 18] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[18ページ]情報のRFC4883ベンチマーキング用語
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
関連定義: 無料の損失Condition(特にパケット損失を引き起こす混雑制御機構の議論)スケーラビリティLimit Signaling Message Deficit QoS Compliant Condition Not QoS Compliant Condition
3.5.3. QoS Compliant Condition
3.5.3. 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対応することの状態にあるかを考えるとき、損失、ベストエフォート型データフローのジター遅れなどは無関係です。
Feher, et al. Informational [Page 19] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[19ページ]情報のRFC4883ベンチマーキング用語
Related definitions:
Loss-Free Condition
Lossy Condition
Not QoS Compliant Condition
Scalability Limit
関連定義: QoS対応することの状態スケーラビリティ限界ではなく、無損失の状態損失性状態
3.5.4. Not QoS Compliant Condition
3.5.4. 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対応することの状態スケーラビリティ状態限界
3.5.5. Scalability Limit
3.5.5. スケーラビリティ限界
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
ルータに影響を与えながら、荷重係数(3.3Router Load Factorsで定義されるように)の換算値で特定の負荷状態を特定できます。 数の7tupleとしてこれらの値を表すことができます(5つの荷重係数しかありませんが、交通荷重係数は、合成ユニットを持って、その結果、それぞれ急行への2つの番号を必要とします)。 私たちはともに損失から自由でQoS対応することの、または、損失なしでなくて(QoS対応する)のQoS対応するのと(損失なし)の、または、損失なしでなくてまたQoS対応でない状態に対応するベクトルとしてこれらのtuplesを考えることができます。 そして、間にルータのスケーラビリティ限界は境界です。
Feher, et al. Informational [Page 20] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[20ページ]情報のRFC4883ベンチマーキング用語
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.
損失なしの、そして、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.
ベンチマークが別々に中で損失なしとQoS対応することの状態の境界を特定しようとするかもしれない、(7、次元、)、負荷ベクトルによって定義されたスペース。
Related definitions:
Lossy Condition
Loss-Free Condition
QoS Compliant Condition
Non QoS Compliant Condition
関連定義: 損失性の状態のQoS対応することの状態非QoS対応する状態無損失の状態
4. Security Considerations
4. セキュリティ問題
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.
このドキュメントだけが用語を提供して、プロトコル、実現、または手順について説明しないとき、それに関連しているどんなセキュリティ問題もありません。
5. Acknowledgements
5. 承認
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.
Technologyのブダペスト大学のInformaticsとEconomics、研究開発における彼らのサポートのためのハンガリー(このドキュメントの創造に貢献した)が働くのをTelecommunicationとメディアの部のTelia Research AB、スウェーデンとHigh Speed Networks研究所に感謝申し上げます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[1] ブラドナー、S.、「ネットワーク相互接続装置のためのベンチマーキング用語」、RFC1242、1991年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998.
[3] マンデヴィル、R.、「LAN切換装置のためのベンチマーキング用語」、RFC2285、1998年2月。
6.2. Informative References
6.2. 有益な参照
[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、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
Feher, et al. Informational [Page 21] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[21ページ]情報のRFC4883ベンチマーキング用語
[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の機能的な仕様」、RFC2205、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] ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.バンデンボッシュ、「次に、シグナリング(NSIS)は中へ入ります」。 「枠組み」、RFC4080、2005年6月。
[7] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", Work in Progress, April 2007.
[7]Schulzrinne、H.、およびR.ハンコック、「要点:」 「一般インターネットは輸送を示し」て、進歩、2007年4月に働いてください。
[8] Manner, J., Ed., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", Work in Progress, June 2007.
[8] 方法、J.、エド、6月2007、G.、およびA.マクドナルド、「サービスの質シグナリングのためのNSLP」というKaragiannisは進行中で働いています。
[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:」 「インターネットへのSimple予約Mechanism」、コンピュータCommunication Review、オンラインバージョン、第29巻、No.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+」、RFC1819、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.クロウクロフト、「インターネットのダイナミックな送付者によって開始された予約のためのケース」、高速ネットワークVol.7No.2、QoSにおける増刊が掘って、合図することでの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.フェーヘル、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、「ユニキャストIP交通の強健で安全な軽量の資源予約」、QoS98年、IWQoS98年、1998年5月18日〜20日の国際WS
[15] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service
Signaling Protocols", RFC 4094, May 2005.
[15] 方法、J.、およびX.フー(「既存のサービスの質シグナリングプロトコルの分析」、RFC4094)は2005がそうするかもしれません。
[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.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
Feher, et al. Informational [Page 22] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[22ページ]情報のRFC4883ベンチマーキング用語
Authors' Addresses
作者のアドレス
Gabor Feher Budapest University of Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Technologyのガボールフェーヘルブダペスト大学とTelecommunicationsとメディアInformaticsマジャールのTudosok krtの経済学部。 2 H-1117、ブダペスト(ハンガリー)
Phone: +36 1 463-1538 EMail: Gabor.Feher@tmit.bme.hu
以下に電話をしてください。 +36 1 463-1538 メールしてください: 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
TechnologyのKrisztian Nemethブダペスト大学とTelecommunicationsとメディアInformaticsマジャールのTudosok krtの経済学部。 2 H-1117、ブダペスト(ハンガリー)
Phone: +36 1 463-1565 EMail: Krisztian.Nemeth@tmit.bme.hu
以下に電話をしてください。 +36 1 463-1565 メールしてください: 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
TechnologyのAndrasコルンブダペスト大学とTelecommunicationとメディアInformaticsマジャールのTudosok krtの経済学部。 2 H-1117、ブダペスト(ハンガリー)
Phone: +36 1 463-2664 EMail: Andras.Korn@tmit.bme.hu
以下に電話をしてください。 +36 1 463-2664 メールしてください: Andras.Korn@tmit.bme.hu
Istvan Cselenyi TeliaSonera International Carrier Vaci ut 22-24, H-1132 Budapest, Hungary
イシュトバーンCselenyi TeliaSonera国際のCarrierバーツut22-24、H-1132ブダペスト(ハンガリー)
Phone: +36 1 412-2705 EMail: Istvan.Cselenyi@teliasonera.com
以下に電話をしてください。 +36 1 412-2705 メールしてください: Istvan.Cselenyi@teliasonera.com
Feher, et al. Informational [Page 23] RFC 4883 Benchmarking Terms for RR Capable Routers July 2007
フェーヘル、他 ルータ2007年7月にできるRRのための[23ページ]情報のRFC4883ベンチマーキング用語
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Feher, et al. Informational [Page 24]
フェーヘル、他 情報[24ページ]
一覧
スポンサーリンク
