Network Working Group P. Bagnall
Request for Comments: 2729 R. Briscoe
Category: Informational A. Poppitt
BT
December 1999
Taxonomy of Communication Requirements
for Large-scale Multicast Applications
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardization.
このメモの意図は、任意の大規模なマルチキャストアプリケーション（LSMA）の通信要件の分類システムを定義することです。 1つのプロトコルがどのLSMAに関わるすべての関係者の多様な要件の間の妥協を達成することができ非常に低いです。必要なプロトコルの範囲を最小限にするために、最悪のシナリオを理解する必要があります。ダイナミックプロトコル適合は、特定の機構に要求の特定の組み合わせをマップするためのロジックを必要とするどの必要である可能性が高いです。アプリケーションは、その要件を定義する方法を標準化することは、この方の必要なステップです。分類は、標準化に向けた最初のステップです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Sessions. . . . . . . . . . . . . . . . . 3
3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Summary of Communications Parameters . . . . . . . . 4
3.2. Definitions, types and strictest requirements. . . . 5
3.2.1. Types . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Reliability . . . . . . . . . . . . . . . . . . 7
3.2.2.1. Packet Loss . . . . . . . . . . . . . . . . 7
3.2.2.2. Component Reliability . . . . . . . . . . . 8
3.2.3. Ordering . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Timeliness . . . . . . . . . . . . . . . . . . . 9
3.2.5. Session Control . . . . . . . . . . . . . . . .13
3.2.6. Session Topology . . . . . . . . . . . . . . . .16
3.2.7. Directory . . . . . . . . . . . . . . . . . . .17
3.2.8. Security . . . . . . . . . . . . . . . . . . . .17
3.2.8.1. Security Dynamics . . . . . . . . . . . . .23
3.2.9. Payment & Charging . . . . . . . . . . . . . . .24
4. Security Considerations . . . . . . . . . . . . . . . .25
5. References . . . . . . . . . . . . . . . . . . . . . .25
6. Authors' Addresses . . . . . . . . . . . . . . . . . . .26
7. Full Copyright Statement . . . . . . . . . . . . . . . .27
This taxonomy consists of a large number of parameters that are considered useful for describing the communication requirements of LSMAs. To describe a particular application, each parameter would be assigned a value. Typical ranges of values are given wherever possible. Failing this, the type of any possible values is given. The parameters are collected into ten or so higher level categories, but this is purely for convenience.
この分類はLSMAsの通信要件を説明するために有用であると考えられる多数のパラメータから成ります。特定のアプリケーションを記述するために、各パラメータの値を割り当てられます。値の典型的な範囲は、可能な限り与えられています。これを失敗し、すべての可能な値のタイプが与えられています。パラメータは、10個のほど高いレベルのカテゴリに収集されるが、これは便宜のために純粋です。
The parameters are pitched at a level considered meaningful to application programmers. However, they describe communications not applications - the terms '3D virtual world', or 'shared TV' might imply communications requirements, but they don't accurately describe them. Assumptions about the likely mechanism to achieve each requirement are avoided where possible.
パラメータは、アプリケーションプログラマにとって有意義と考えるレベルで投げています。しかし、そうではないアプリケーションの通信を記述 - 用語「3D仮想世界」、または「共有テレビ」通信の要件を意味するものではありかもしれませんが、彼らはそれらを正確に記述しないでください。各要件を達成する可能性のメカニズムについての仮定は、可能な限り回避されます。
While the parameters describe communications, it will be noticed that few requirements concerning routing etc. are apparent. This is because applications have few direct requirements on these second order aspects of communications. Requirements in these areas will have to be inferred from application requirements (e.g. latency).
パラメータは、通信を記載しているが、などのルーティングに関するいくつかの要件が明らかであることに留意されます。アプリケーションは、通信のこれらの二次的側面に関するいくつかの直接的な要件があるためです。これらの分野での要件は、アプリケーションの要件（例えば、レイテンシ）から推論されなければなりません。
The taxonomy is likely to be useful in a number of ways:
分類は、いくつかの方法で有用である可能性が高いです。
1. Most simply, it can be used as a checklist to create a requirements statement for a particular LSMA. Example applications will be classified [bagnall98] using the taxonomy in order to exercise (and improve) it
1.最も単純に、特定のLSMAの要件のステートメントを作成するためのチェックリストとして使用することができます。サンプルアプリケーションは、それを行使（及び改善）するために、タクソノミーを使用して、[bagnall98]分類します
2. Because strictest requirement have been defined for many parameters, it will be possible to identify worst case scenarios for the design of protocols
2.最も厳しい要件は、多くのパラメータに定義されているので、プロトコルの設計のための最悪のシナリオを特定することが可能になります
3. Because the scope of each parameter has been defined (per session, per receiver etc.), it will be possible to highlight where heterogeneity is going to be most marked
3.各パラメータの範囲は、（セッションごとに、あたりの受信機など）が定義されているので、異質性が最もマークされようとしている場所をハイライトすることが可能となります
4. It is a step towards standardization of the way LSMAs define their communications requirements. This could lead to standard APIs between applications and protocol adaptation middleware
4.それはLSMAsが彼らのコミュニケーションの要件を定義する方法の標準化に向けたステップです。これは、アプリケーションおよびプロトコル適合ミドルウェア間の標準APIにつながる可能性があります
5. Identification of limitations in current Internet technology for LSMAs to be added to the LSMA limitations memo [limitations]
LSMA制限メモに追加するLSMAsための現在のインターネット技術の制限[制限]の5同定
6. Identification of gaps in Internet Engineering Task Force (IETF) working group coverage
インターネットエンジニアリングタスクフォースのギャップの6識別（IETF）ワーキンググループのカバレッジ
This approach is intended to complement that used where application scenarios for Distributed Interactive Simulation (DIS) are proposed in order to generate network design metrics (values of communications parameters). Instead of creating the communications parameters from the applications, we try to imagine applications that might be enabled by stretching communications parameters.
分散対話型シミュレーション（DIS）のためのアプリケーションシナリオは、ネットワーク設計指標（通信パラメータの値）を生成するために提案されている場合、このアプローチは、使用されている補完することを意図しています。代わりに、アプリケーションからの通信パラメータを作成するのではなく、我々は通信パラメータを延伸することによって有効にされるかもしれないアプリケーションを想像してみてください。
The following terms have no agreed definition, so they will be defined for this document.
次の用語には合意された定義を持っていないので、彼らはこのドキュメントのために定義されます。
Session a happening or gathering consisting of flows of information related by a common description that persists for a non-trivial time (more than a few seconds) such that the participants (be they humans or applications) are involved and interested at intermediate times. A session may be defined recursively as a super-set of other sessions.
セッション参加者（彼らは、ヒトまたはアプリケーションである）の中間時間に関与し、興味を持っているような非自明な時間（数秒以上）持続する一般的記述により関連情報の流れからなる出来事または集まり。セッションは他のセッションのスーパーセットとして再帰的に定義することができます。
Secure session a session with restricted access
アクセスが制限されたセッションセキュアセッション
A session or secure session may be a sub and/or super set of a multicast group. A session can simultaneously be both a sub and a super-set of a multicast group by spanning a number of groups while time-sharing each group with other sessions.
セッションまたはセキュアセッションは、サブ及び/又はマルチキャストグループのスーパーセットであってもよいです。セッションは、同時に他のセッションと時分割各グループながら、グループの数にまたがることによってサブマルチキャストグループのスーパーセットの両方であることができます。
Before the communications parameters are defined, typed and given worst-case values, they are simply listed for convenience. Also for convenience they are collected under classification headings.
通信パラメータが定義される前に、入力されたと最悪の場合の値が与えられ、彼らは単に便宜のために記載されています。また、利便性のために、彼らは、分類の見出しの下で収集されます。
Reliability . . . . . . . . . . . . . . . . . . . . . . 3.2.1
Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1
Transactional
Guaranteed
Tolerated loss
Semantic loss
Component reliability . . . . . . . . . . . . . . . 3.2.1.2
Setup fail-over time
Mean time between failures
Fail over time during a stream
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2
Ordering type
Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3
Hard Realtime
Synchronicity
Burstiness
Jitter
Expiry
Latency
Optimum bandwidth
Tolerable bandwidth
Required by time and tolerance
Host performance
Fair delay
Frame size
Content size
Session Control . . . . . . . . . . . . . . . . . . . . 3.2.4
Initiation
Start time
End time
Duration
Active time
Session Burstiness
Atomic join
Late join allowed ?
Temporary leave allowed ?
Late join with catch-up allowed ?
Potential streams per session
Active streams per sessions
Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5
Number of senders
Number of receivers
Directory . . . . . . . . . . . . . . . . . . . . . . . 3.2.6
Fail-over time-out (see Reliability: fail-over time)
Mobility
Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7
Authentication strength
Tamper-proofing
Non-repudiation strength
Denial of service
Action restriction
Privacy
Confidentiality
Retransmit prevention strength
Membership criteria
Membership principals
Collusion prevention
Fairness
Action on compromise
Security dynamics . . . . . . . . . . . . . . . . . . . 3.2.8
Mean time between compromises
Compromise detection time limit
compromise recovery time limit
Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9
Total Cost
Cost per time
Cost per Mb
The terms used in the above table are now defined for the context of this document. Under each definition, the type of their value is given and where possible worst-case values and example applications that would exhibit this requirement.
上記の表で使用される用語について本明細書の文脈のために定義されています。各定義の下では、その値の型が与えられ、どこでこの要件を示すであろう最悪の場合の値とサンプルアプリケーション可能です。
There is no mention of whether a communication is a stream or a discrete interaction. An attempt to use this distinction as a way of characterizing communications proved to be remarkably unhelpful and was dropped.
通信は、ストリームまたは個別の相互作用であるかどうかの言及はありません。通信を特徴付ける方法として、この区別を使用する試みが著しく役に立たないことが判明し、滴下しました。
Each requirement has a type. The following is a list of all the types used in the following definitions.
各要件にはタイプがあります。以下は、次の定義で使用されるすべてのタイプのリストです。
Application Benchmark
アプリケーションベンチマーク
This is some measure of the processor load of an application, in some architecture neutral unit. This is non-trivial since the processing an application requires may change radically with different hardware, for example, a video client with and without hardware support.
これは、いくつかのアーキテクチャ中性ユニットで、アプリケーションの処理負荷の一部の測定値です。アプリケーションに必要な処理を用いて、ハードウェアのサポートなしに、例えば、異なるハードウェアでラジカルビデオクライアントを変更することができるので、これは非自明です。
Bandwidth Measured in bits per second, or a multiple of.
毎秒ビット単位で測定帯域幅、または複数の。
Boolean
ブーリアン
Abstract Currency An abstract currency is one which is adjusted to take inflation into account. The simplest way of doing this is to use the value of a real currency on a specific date. It is effectively a way of assessing the cost of something in "real terms". An example might be 1970 US$. Another measure might be "average man hours".
抽象通貨抽象通貨のアカウントにインフレを取るように調整されるものです。これを行う最も簡単な方法は、特定の日付に実際の通貨の価値を使用することです。これは、効果的に「実質」で何かのコストを評価する方法です。例では、1970 US $かもしれません。別の尺度は、「平均的な人の時間」であるかもしれません。
Currency - current local
通貨 - 現在のローカル
Data Size
データサイズ
Date (time since epoch)
日付（エポックからの時間）
Enumeration
列挙
Fraction
分数
Identifiers A label used to distinguish different parts of a communication
識別子通信の異なる部分を区別するために使用されるラベル
Integer
整数
Membership list/rule
会員リスト/ルール
Macro A small piece of executable code used to describe policies
ポリシーを記述するために使用される実行可能コードのマクロ小片
Time
時間
Transactional
トランザクション
When multiple operations must occur atomically, transactional communications guarantee that either all occur or none occur and a failure is flagged.
複数の操作がアトミックに行われなければならない場合には、トランザクションの通信はどちらかのすべてが発生したり、何も起こらず、障害がフラグを立てていることを保証します。
Type: Boolean Meaning: Transactional or Not transaction Strictest Requirement: Transactional Scope: per stream Example Application: Bank credit transfer, debit and credit must be atomic. NB: Transactions are potentially much more complex, but it is believed this is an application layer problem.
型：Boolean意味：トランザクションまたはNot取引最も厳密要件：トランザクション範囲：ストリームアプリケーション例あたり：銀行のクレジット移転、借方と貸方はアトミックでなければなりません。 NB：トランザクションは、潜在的にはるかに複雑ですが、アプリケーション層の問題であると考えられています。
Guaranteed
保証付き
Guarantees communications will succeed under certain conditions.
保証通信は、一定の条件の下で成功します。
Type: Enumerated Meaning: Deferrable - if communication fails it will be deferred until a time when it will be successful. Guaranteed - the communication will succeed so long as all necessary components are working. No guarantee - failure will not be reported. Strictest Requirement: Deferrable Example Application: Stock quote feed - Guaranteed Scope: per stream NB: The application will need to set parameters to more fully define Guarantees, which the middleware may translate into, for example, queue lengths.
タイプ：列挙意味：繰延 - 通信が失敗した場合、それが成功するまで延期されます。保証 - 通信が必要なすべてのコンポーネントが動作している限り、成功します。保証しない - 障害が報告されません。最も厳しい要件：繰延アプリケーション例：株価フィード - 保証範囲：ストリームNBあたり：アプリケーションは、より完全にミドルウェアは、例えば、キューの長さ、に翻訳することができる保証を、定義するためのパラメータを設定する必要があります。
Tolerated loss
許容損失
This specifies the proportion of data from a communication that can be lost before the application becomes completely unusable.
これは、アプリケーションが完全に使用できなくなる前に失われる可能性が通信からのデータの割合を指定します。
Type: Fraction Meaning: fraction of the stream that can be lost Strictest Requirement: 0% Scope: per stream Example Application: Video - 20%
タイプ：フラクション意味：0％の範囲：ストリームごとのアプリケーション例：ビデオ - 20％最も厳密要件を失ったことができたストリームの割合
Semantic loss
セマンティック損失
The application specifies how many and which parts of the communication can be discarded if necessary.
アプリケーションは、必要に応じて通信の部分を破棄することができますどのように多くのとを指定します。
Type: Identifiers, name disposable application level frames Meaning: List of the identifiers of application frames which may be lost Strictest Requirement: No loss allowed Scope: per stream
タイプ：識別子、意味の名前使い捨てアプリケーションレベルのフレーム：いいえ損失許可範囲：：最も厳密要件を失われる可能性があるアプリケーションフレームの識別子のリストをストリームあたり
Example Application: Video feed - P frames may be lost, I frames not
アプリケーション例：ビデオフィード - Pフレームが失われる可能性があり、私がいないフレーム
Setup Fail-over time
セットアップが失敗オーバータイム
The time before a failure is detected and a replacement component is invoked. From the applications point of view this is the time it may take in exceptional circumstances for a channel to be set-up. It is not the "normal" operating delay before a channel is created.
故障までの時間が検出され、交換部品が呼び出されます。ビューのアプリケーションの観点から、これはそれがアップ設定するチャンネルのために例外的な状況で取ることが時間です。チャネルが作成される前に、それは「通常」の動作遅延はありません。
Type: Time Strictest Requirement: Web server - 1 second Scope: per stream Example Application: Name lookup - 5 seconds
タイプ：時間最も厳密要件：Webサーバー - 1秒範囲：ストリームアプリケーション例あたり：名前のルックアップ - 5秒
Mean time between failures
平均故障間隔
The mean time between two consecutive total failures of the channel.
チャネルの2つの連続した総平均故障間隔。
Type: Time Strictest Requirement: Indefinite Scope: per stream Example Application: Telephony - 1000 hours
タイプ：タイム最も厳密要件：不定範囲：ストリームごとのアプリケーション例：テレフォニー - 1000時間
Fail over time during a stream
ストリーム中に時間をかけて失敗
The time between a stream breaking and a replacement being set up.
ストリームの破壊と交換との間の時間は設定されています。
Type: Time Strictest Requirement: Equal to latency requirement Scope: per stream Example Application: File Transfer - 10sec
タイプ：タイム最も厳密要件：レイテンシー要件の適用範囲に等しい：ストリームアプリケーション例あたり：ファイル転送 - 10秒
Ordering type
発注タイプ
Specifies what ordering must be preserved for the application
順序がアプリケーションのために保存しなければならないものを指定します
Type: { Enumeration timing, Enumeration sequencing, Enumeration causality }
タイプ：{列挙タイミング、列挙配列、列挙因果}
Meaning: Timing - the events are timestamped Global Per Sender none Sequencing - the events are sequenced in order of occurrence Global Per Sender none Causality - the events form a graph relating cause and effect Global Per Sender none Strictest Requirement: Global, Global, Global Scope: per stream Example Application: Game - { none, per sender, global } (to make sure being hit by bullet occurs after the shot is fired!)
意味：タイミング - イベントが送信者なしシーケンス毎のタイムスタンプグローバルです - イベントが発生したグローバルごとの送信者なし因果関係の順に配列決定されている - イベントは、送信者なし最も厳密要件ごとのグローバル原因と結果に関するグラフを形成：グローバル、グローバル、グローバルスコープを：ストリームアプリケーション例あたり：ゲーム - {どれも、送信者ごとに、グローバル}（！弾丸によってショットが発射された後に発生するヒットしていることを確認していないため）
Hard real- time
ハードリアルタイム
There is a meta-requirement on timeliness. If hard real-time is required then the interpretation of all the other requirements changes. Failures to achieve the required timeliness must be reported before the communication is made. By contrast soft real-time means that there is no guarantee that an event will occur in time. However statistical measures can be used to indicate the probability of completion in the required time, and policies such as making sure the probability is 95% or better could be used.
適時にメタ要件があります。ハードリアルタイムは、その後、他のすべての要件の変化の解釈を必要とする場合。通信が行われる前に、必要な適時性を達成するための障害が報告されなければなりません。これとは対照的に、ソフトリアルタイムイベントが時間内に発生するという保証がないことを意味します。しかし、統計的な対策が必要な時間で完了する可能性を示すために使用される、そのような確率は95％以上を使用することができるであることを確認することなどのポリシーすることができます。
Type: Boolean Meaning: Hard or Soft realtime Strictest Requirement: Hard Scope: per stream Example Application: Medical monitor - Hard
型：Boolean意味：ハードやソフトリアルタイム最も厳密要件：ハード範囲：ストリームごとのアプリケーション例：医療モニター - ハード
Synchronicity
シンクロニシティ
To make sure that separate elements of a session are correctly synchronized with respect to each other
セッションの別の要素が正しく互いに対して同期していることを確認します
Type: Time Meaning: The maximum time drift between streams Strictest Requirement: 80ms for human perception Scope: per stream pair/set Example Application: TV lip-sync value 80ms NB: the scope is not necessarily the same as the session. Some streams may no need to be sync'd, (say, a score ticker in a football match
タイプ：時間意味：人間の知覚スコープの80msで：ストリームペア/設定例アプリケーションごと：TVリップシンク値の80ミリ秒のNB：範囲は必ずしもセッションと同じではない最も厳密な要件は、ストリーム間の最大時間ドリフト。いくつかのストリームはsync'dする必要はありません、（たとえば、サッカーの試合中にスコアティッカーをしてもよいです
Burstiness
バースト
This is a measure of the variance of bandwidth requirements over time.
これは、時間をかけて帯域幅要件の分散の尺度です。
Type: Fraction Meaning: either: Variation in b/w as fraction of b/w for variable b/w communications or duty cycle (fraction of time at peak b/w) for intermittent b/w communications. Strictest Requirement: Variation = max b/w Duty cycle ~ 0 Scope: per stream Example Application: Sharing video clips, with chat channel - sudden bursts as clips are swapped. Compressed Audio - difference between silence and talking NB: More detailed analysis of communication flow (e.g. max rate of b/w change or
タイプ：フラクション意味：次のいずれか間欠B / Wの通信用変数B / Wの通信又はデューティサイクル（ピーク時間の割合B / W）のためのB / Wの分数としてBにW /バリエーション。最も厳しい要件：バリエーション=最大W / Bデューティ・サイクル〜0範囲：ストリームアプリケーション例あたり：チャットチャンネルで、ビデオクリップの共有 - クリップなどの突然のバーストがスワップされます。圧縮オーディオ - 沈黙と話すNBとの間の差：通信フローのより詳細な分析（B / Wの変化、例えば最大速度又は
Fourier Transform of the b/w requirement) is
possible but as complexity increases
usefulness and computability decrease.
Jitter
ジッター
Jitter is a measure of variance in the time taken for communications to traverse from the sender (application) to the receiver, as seen from the application layer.
ジッタは、アプリケーション層から分かるように、受信機に送信者（アプリケーション）から横断する通信のために要した時間の分散の尺度です。
Type: Time Meaning: Maximum permissible time variance Strictest Requirement: <1ms Scope: per stream Example Application: audio streaming - <1ms NB: A jitter requirement implies that the communication is a real-time stream. It makes relatively little sense for a file transfer for example.
意味時間：タイプ最大許容時間分散最も厳密要件：<1msの範囲：ストリームアプリケーション例あたり：オーディオストリーミング - <1msののNB：ジッタ要件は、通信は、リアルタイムのストリームであることを意味します。これは、例えば、ファイル転送のために比較的ほとんど意味がありません。
Expiry
有効期限
This specifies how long the information
being transferred remains valid for.
Type: Date Meaning: Date at which data expires Strictest Requirement: For ever Scope: per stream Example Application: key distribution - now+3600 seconds (valid for at least one hour)
種類：日付の意味：これまで対象範囲の場合：ストリームアプリケーション例あたり：キー配布 - 今+ 3600秒（有効な少なくとも1時間）のデータが最も厳密要件を期限が切れる日
Latency
潜在
Time between initiation and occurrence of
an action from application perspective.
Type: Time Strictest Requirement: Near zero for process control apps Scope: per stream Example Application: Audio conference 20ms NB: Where an action consists of several distinct sequential parts the latency budget must be split over those parts. For process control the requirement may take any value.
タイプ：タイム最も厳密要件：プロセス制御アプリケーションスコープのためのゼロ付近：ストリームアプリケーション例あたり：オーディオ会議20msののNB：アクションは、待ち時間の予算は、これらの部分に分割されなければならないいくつかの明確なシーケンシャルの部分から構成されています。プロセス制御のための要件は、任意の値をとることがあります。
Optimum Bandwidth
最適な帯域
Bandwidth required to complete communication in time
時間内に通信を完了するのに必要な帯域幅
Type: Bandwidth Strictest Requirement: No upper limit Scope: per stream Example Application: Internet Phone 8kb/s
タイプ：帯域幅の最も厳密要件：上限なし範囲：ストリームアプリケーション例あたり：インターネット電話の8キロバイト/秒
Tolerable Bandwidth
許容帯域幅
Minimum bandwidth that application can tolerate
アプリケーションが許容できる最小の帯域幅
Type: Bandwidth Strictest Requirement: No upper limit Scope: per stream Example Application: Internet phone 4kb/s
タイプ：帯域幅の最も厳密要件：上限なし範囲：ストリームアプリケーション例あたり：インターネット電話4キロバイト/秒
Required by time and tolerance
時間と寛容で必要とされます
Time communication should complete by and time when failure to complete renders communication useless (therefore abort).
時間通信が完了するまでに障害が無駄な通信をレンダリングする際に（それゆえ中止）との時間をすることによって完了する必要があります。
Type: { Date - preferred complete time, Date - essential complete time } Strictest Requirement: Both now. Scope: per stream Example Application: Email - Preferred 5 minutes & Essential in 1 day NB: Bandwidth * Duration = Size; only two of these parameters may be specified. An API though could allow application authors to think in terms of any two.
タイプ：{日 - 好ま完全な時間、日付 - 不可欠な完全な時間}最も厳密要件：今両方。有効範囲：ストリームアプリケーション例あたり： - メール1日のNBにおける優先5分＆エッセンシャル：帯域幅*期間=サイズ;のみ、これらのパラメータの2を指定することができます。 APIは、しかし、アプリケーション作成者が任意の二つの観点から考えるする可能性があります。
Host performance
ホストのパフォーマンス
Ability of host to create/consume communication
作成するホストの能力/コミュニケーションを消費
Type: Application benchmark Meaning: Level of resources required by Application Strictest Requirement: Full consumption Scope: per stream Example Application: Video - consume 15 frames a second NB: Host performance is complex since load, media type, media quality, h/w assistance, and encoding scheme all affect the processing load. These are difficult to predict prior to a communication starting. To some extent these will need to be measured and modified as the communication proceeds.
タイプ：アプリケーションベンチマークの意味：フル消費スコープ：ストリームごとのアプリケーション例：アプリケーションの最も厳密要件によって必要なリソースのレベル - ：ホストのパフォーマンス負荷、メディアタイプ、メディア品質、H / W支援するので複雑で動画が二NBは15個のフレームを消費、および符号化方式は、すべての処理負荷に影響を与えます。これらは、以前の通信開始に予測することは困難です。ある程度まで、これらを測定し、通信が進行するように変更する必要があります。
Frame size
フレームサイズ
Size of logical data packets from application perspective
アプリケーションの観点から論理データ・パケットのサイズ
Type: data size Strictest Requirement: 6 bytes (gaming) Scope: per stream Example Application: video = data size of single frame update
タイプ：データサイズ最も厳密な要件：6バイト（ゲーム）範囲：ストリームごとの応用例：単一フレーム更新のビデオ=データサイズ
Content size
コンテンツのサイズ
The total size of the content (not relevant for continuous media)
コンテンツの合計サイズ（連続メディアに関連していません）
Type: data size Strictest Requirement: N/A Scope: per stream Example Application: document transfer, 4kbytes
タイプ：データサイズ最も厳密な要件：ストリーム応用例ごとに：N /スコープ文書の転送、4Kバイト
Initiation
イニシエーション
Which initiation mechanism will be used.
どの開始メカニズムが使用されます。
Type: Enumeration Meaning: Announcement - session is publicly announced via a mass distribution system Invitation - specific participants are explicitly invited, e.g. my email Directive - specific participants are forced to join the session Strictest Requirement: Directive Scope: per stream Example Application: Corporate s/w update - Directive
タイプ：列挙意味：お知らせ - セッションが公に質量分布システムの招待状を経て発表される - 特定の参加者が明示的に招待され、例えば指令範囲： - 私の電子メールの指令の特定の参加者は、セッション最も厳密要件に参加することを余儀なくされている企業のS / Wアップデート - 指令：ストリームサンプルアプリケーションごとに
Start Time
始まる時間
Time sender starts sending!
時間送信者は送信を開始します！
Type: Date Strictest Requirement: Now Scope: per stream Example Application: FTP - at 3am
タイプ：日付最も厳密要件：今すぐ有効範囲：ストリームごとのアプリケーション例：FTP - 午前3時
End Time
終了時間
Type: Date Strictest Requirement: Now Scope: per stream Example Application: FTP - Now+30mins
タイプ：日付最も厳密要件：今すぐ有効範囲：ストリームごとのアプリケーション例：FTP - 今すぐ+ 30分
Duration
期間
(end time) - (start time) = (duration), therefore only two of three should be specified.
（終了時刻） - （開始時刻）=（持続時間）、従って3つだけの両者が指定されなければなりません。
Type: Time Strictest Requirement: - 0ms for discrete, indefinite for streams Scope: per stream Example Application: audio feed - 60mins
タイプ：タイム最も厳密要件： - 離散については0ms、ストリームスコープについて無期限：ストリームごとのアプリケーション例：オーディオフィード - 60分
Active Time
アクティブ時間
Total time session is active, not including breaks
合計時間のセッションでは、休憩を含めない、アクティブであります
Type: Time Strictest Requirement: equals duration Scope: per stream Example Application: Spectator sport transmission
タイプ：タイム最も厳密要件は：期間スコープに等しい：ストリーム例アプリケーションごと：スペクテイタースポーツの送信を
Session Burstiness
セッションのバースト性
Expected level of burstiness of the session
セッションのバースト性の期待されるレベル
Type: Fraction Meaning: Variance as a fraction of maximum bandwidth Strictest Requirement: =bandwidth Scope: per stream Example Application: commentary & slide show: 90% of max
タイプ：フラクション意味：ストリームアプリケーション例あたり：：=帯域幅範囲：解説＆スライドショー：最大90％、最大帯域幅を最も厳密要件の一部として分散
Atomic join
アトミック参加します
Session fails unless a certain proportion of the potential participants accept an invitation to join. Alternatively, may be specified as a specific numeric quorum.
潜在的な参加者の一定割合が参加する招待を承諾しない限り、セッションは失敗します。代替的に、特定の数値定足数として指定することができます。
Type: Fraction (proportion required) or int (quorum) Strictest Requirement: 1.0 (proportion) Example Application: price list update, committee meeting Scope: per stream or session NB: whether certain participants are essential is application dependent.
タイプ：フラクション（割合必須）またはINT（定足数）最も厳密要件：1.0（割合）アプリケーション例：価格表を更新、委員会の範囲：ストリームまたはセッションNBあたり：特定の参加が不可欠であるかどうかはアプリケーションに依存します。
Late join allowed ?
後期許さでしょうか？
Does joining a session after it starts make sense
それは意味をなさないを開始した後、セッションに参加してい
Type: Boolean Strictest Requirement: allowed Scope: per stream or session Example Application: game - not allowed NB: An application may wish to define an alternate session if late join is not allowed
型：Boolean最も厳密要件：許可範囲：ストリームまたはセッションアプリケーション例あたり： - ：アプリケーションが遅く参加した場合、代替セッションを定義したい場合があり許可されていないゲームNBが許可されていません
Temporary leave allowed ?
一時的な休暇を許可しますか？
Does leaving and then coming back make sense for session
残し、その後のセッションのために理にかなって戻って来てい
Type: Boolean Strictest Requirement: allowed Scope: per stream or session Example Application: FTP - not allowed
型：Boolean最も厳密要件：許可範囲：ストリームまたはセッションアプリケーション例あたり：FTP - 許可されていません
Late join with catch-up allowed ?
後期許さキャッチアップに参加しますか？
Is there a mechanism for a late joiner to see what they've missed
彼らが見逃しているかを確認するには遅建具のためのメカニズムがあります
Type: Boolean Strictest Requirement: allowed Scope: per stream or session Example Application: sports event broadcast, allowed NB: An application may wish to define an alternate session if late join is not allowed
型：Boolean最も厳密要件：許可範囲：ストリームまたはセッションアプリケーション例あたり：スポーツイベント放送、許可NB：アプリケーションが遅く参加した場合、代替セッションを定義することを望むかもしれないが許可されていません
Potential streams per session
セッションあたりの潜在的な流れ
Total number of streams that are part of session, whether being consumed or not
セッションの一部であるストリームの総数、消費されているかどうか
Type: Integer Strictest Requirement: No upper limit Scope: per session Example Application: football match mcast - multiple camera's, commentary, 15 streams
タイプ：整数最も厳密要件：上限なし範囲：セッションアプリケーション例あたり：サッカーの試合のMCAST - 複数のカメラの、解説、15個のストリーム
Active streams per sessions (i.e. max app can handle)
セッションあたりのアクティブなストリーム（すなわち、最大のアプリを扱うことができます）
Maximum number of streams that an application can consume simultaneously
アプリケーションが同時に消費することができるストリームの最大数
Type: Integer Strictest Requirement: No upper limit Scope: per session Example Application: football match mcast - 6, one main video, four user selected, one audio commentary
タイプ：整数最も厳密な要件：なし上限範囲：セッション応用例ごとに：サッカーの試合のMCAST - 6、一つのメインビデオ、4人のユーザが選択した一本の音声解説
Note: topology may be dynamic. One of the challenges in designing adaptive protocol frameworks is to predict the topology before the first join.
注意：トポロジは動的であってもよいです。適応プロトコルのフレームワークを設計する上での課題の一つは、最初に参加する前にトポロジを予測することです。
Number of senders
送信者の数
The number of senders is a result the middleware may pass up to the application
送信者の数は、ミドルウェアは、アプリケーションに渡すことができる結果であります
Type: Integer Strictest Requirement: No upper limit Scope: per stream Example Application: network MUD - 100
タイプ：整数最も厳密な要件：なし上限範囲：ストリーム例アプリケーションごと：ネットワークMUD - 100
Number of receivers
受信機の数
The number of receivers is a results the middleware may pass up to the application
受信機の数は、ミドルウェアは、アプリケーションに渡すことができる結果であります
Type: Integer Strictest Requirement: No upper limit Scope: per stream Example Application: video mcast - 100,000
タイプ：整数最も厳密要件：上限なし範囲：ストリームアプリケーション例あたり：ビデオMCAST - 10万
Fail-over timeout (see Reliability: fail-over time)
タイムアウトオーバー失敗（：フェールオーバ時の信頼性を参照してください）
Mobility
可動性
Defines restrictions on when directory entries may be changed
ディレクトリエントリを変更することができるときに制限を定義します
Type: Enumeration Meaning: while entry is in use while entry in unused never Strictest Requirement: while entry is in use Scope: per stream Example Application: voice over mobile phone, while entry is in use (as phone gets new address when changing cell).
タイプ：列挙意味：エントリが使用されている間、しばらく使用されていない決して最も厳密要件のエントリ：エントリが使用範囲にあるとき：ストリームごとのアプリケーション例：携帯電話上での音声、エントリが使用されている間（電話は新しいアドレスを取得するように、セルを変更する場合） 。
The strength of any security arrangement can be stated as the expected cost of mounting a successful attack. This allows mechanisms such as physical isolation to be considered alongside encryption mechanisms. The cost is measured in an abstract currency, such as 1970 UD$ (to inflation proof).
任意のセキュリティ機構の強度は、成功した攻撃を仕掛けるの予想コストとして述べることができます。これは、物理的な分離などのメカニズムを暗号化メカニズムと一緒に検討することができます。コストは、1970 UD $として（インフレ証拠に）、抽象通貨で測定されます。
Security is an orthogonal requirement. Many requirements can have a security requirement on them which mandates that the cost of causing the system to fail to meet that requirement is more than the specified amount. In terms of impact on other requirements though, security does potentially have a large impact so when a system is trying to determine which mechanisms to use and whether the requirements can be met security will clearly be a major influence.
セキュリティは、直交条件です。多くの要件は、システムの原因のコストはその要件が規定量以上である満たすために失敗することを義務付け、それらのセキュリティ要件を持つことができます。しかし、他の要件への影響という点では、セキュリティは、潜在的にシステムを使用し、要件を満たすことができるかどうか、セキュリティは明らかに大きな影響されるメカニズムを決定しようとしているので、時に大きな影響を与えません。
Authentication Strength
認証強度
Authentication aims to ensure that a principal is who they claim to be. For each role in a communication, (e.g. sender, receiver) there is a strength for the authentication of the principle who has taken on that role. The principal could be a person, organization or other legal entity. It could not be a process since a process has no legal representation.
認証は、校長は、彼らがあると主張する人であることを保証することを目指しています。通信中の各役割のために、（例えば、送信者、受信者）その役割を担っている原理の認証のための強さがあります。校長は、人、組織、または他の法人である可能性があります。プロセスは法的な表現を持っていないので、それはプロセスであることができませんでした。
Type: Abstract Currency Meaning: That the cost of hijacking a role is in excess of the specified amount. Each role is a different requirement.
タイプ：抽象通貨意味：役割をハイジャックするコストが規定量を超えていること。それぞれの役割は異なる要件です。
Strictest Requirement: budget of largest attacker Scope: per stream Example Application: inter-governmental conference
最も厳しい要件：最大の攻撃範囲の予算：ストリームごとのアプリケーション例：政府間会議
Tamper-proofing
タンパープルーフ
This allows the application to specify how much security will be applied to ensuring that a communication is not tampered with. This is specified as the minimum cost of successfully tampering with the communication. Each non-security requirement has a tamper-proofing requirement attached to it.
これは、アプリケーションが通信が改ざんされていないことを確実にすることに適用されますどのくらいのセキュリティを指定することができます。これが正常に通信を改ざんの最小コストとして指定されています。各非セキュリティ要件は、それに接続された耐タンパープルーフ要件があります。
Requirement: The cost of tampering with the communication is in excess of the specified amount.
要件：通信を改ざんのコストが規定量を超えています。
Type: { Abstract Currency, Abstract Currency, Abstract Currency } Meaning: cost to alter or destroy data, cost to replay data (successfully), cost to interfere with timeliness. Scope: per stream Strictest Requirement: Each budget of largest attacker Example Application: stock price feed
タイプ：{抽象通貨、抽象通貨、抽象通貨}意味：データを変更または破壊するためのコスト、（正常に）データを再生するためのコスト、適時性を妨害するコスト。適用範囲：ストリームあたりの最も厳密要件：最大攻撃アプリケーション例の各予算：株価フィード
Non-repudiation strength
否認防止強度
The non-repudiation strength defines how much care is taken to make sure there is a reliable audit trail on all interactions. It is measured as the cost of faking an audit trail, and therefore being able to "prove" an untrue event. There are a number of possible parameters of the event that need to be proved. The following list is not exclusive but shows the typical set of requirements.
否認防止強度は、すべての相互作用に関する信頼できる監査証跡があることを確認するために取られているどのくらいのケアを定義します。これは、監査証跡を偽造し、したがって虚偽イベントを「証明」することができるというコストとして測定されます。証明する必要のあるイベントの可能なパラメータの数があります。以下のリストは、排他的ではなく、要件の代表的なセットを示しています。
1. Time 2. Ordering (when relative to other events) 3. Whom 4. What (the event itself)
4.どのような（イベント自体）1.時間2.発注（ときに、他のイベントと比較して）3。
There are a number of events that need to be provable. 1. sender proved sent 2. receiver proves received 3. sender proves received.
証明可能である必要はイベントの数があります。 1.送信者が送信2.受信機が受信証明受け取っ3.送信者を証明する証明しました。
Type: Abstract Currency Meaning: minimum cost of faking or denying an event Strictest Requirement: Budget of largest attacker Scope: per stream Example Application: Online shopping system
タイプ：抽象通貨は意味：イベント最も厳密要件を偽造または拒否の最小コスト：ストリームアプリケーション例あたり：最大の攻撃スコープの予算オンラインショッピングシステム
Denial of service
サービス拒否
There may be a requirement for some systems (999,911,112 emergency services access for example) that denial of service attacks cannot be launched. While this is difficult (maybe impossible) in many systems at the moment it is still a requirement, just one that can't be met.
サービス拒否攻撃を起動することができないことをいくつかのシステム（例えば999911112緊急サービスへのアクセス）の要件があるかもしれません。これは、現時点では多くのシステムでは（多分不可能）難しいですが、それはまだ会ったことができない要件で、ただ一つです。
Type: Abstract Currency Meaning: Cost of launching a denial of service attack is greater than specified amount. Strictest Requirement: budget of largest attacker Scope: per stream Example Application: web hosting, to prevent individual hackers stalling system.
タイプ：抽象通貨意味：サービス拒否攻撃を開始するコストが規定量よりも大きくなります。最も厳しい要件：最大の攻撃範囲の予算：ストリームごとのアプリケーション例：ウェブホスティング、システムをストール個々のハッカーを防止します。
Action restriction
アクション制限
For any given communication there are a two actions, send and receive. Operations like adding to members to a group are done as a send to the membership list. Examining the list is a request to and receive from the list. Other actions can be generalized to send and receive on some communication, or are application level not comms level issues.
任意の通信のために二つの作用があり、送受信します。グループにメンバーを追加するなどの操作は、メンバーシップリストへの送信として行われます。リストを調べると、リストから受信するための要求です。他のアクションは、いくつかの通信に送受信するために一般化することができる、またはアプリケーション・レベルはレベルの問題を途切れされていません。
Type: Membership list/rule for each action. Meaning: predicate for determining permission for role Strictest Requirement: Send and receive have different policies. Scope: per stream Example Application: TV broadcast, sender policy defines transmitter, receiver policy is null. NB: Several actions may share the same membership policy.
タイプ：各アクションの会員リスト/ルール。意味：役割の最も厳密要件の許可を決定するための述語を：異なるポリシーを持って送信し、受信します。範囲：ストリームごとの応用例：TV放送は、送信者ポリシーは、受信ポリシーがヌルであり、送信機を定義します。 NB：いくつかのアクションが同じメンバーシップ・ポリシーを共有することがあります。
Privacy
プライバシー
Privacy defines how well obscured a principals identity is. This could be for any interaction. A list of participants may be obscured, a sender may obscure their identity when they send. There are also different types of privacy. For example knowing two messages were sent by the same person breaks the strongest type of privacy even if the identity of that sender is still unknown. For each "level" of privacy there is a cost associated with violating it. The requirement is that this cost is excessive for the attacker.
プライバシープリンシパルのアイデンティティがどのようにうまく隠さ定義します。これは、任意の相互作用のためである可能性があります。参加者のリストは、彼らが送信するとき、送信者が自分のアイデンティティを不明瞭も、不明瞭にすることができます。プライバシーの異なったタイプもあります。同じ人が、その送信者の身元はまだ不明である場合でも、プライバシーの最強タイプを壊すことにより、2つのメッセージを知っ例えば送られました。プライバシーの各「レベル」の場合はそれに違反に関連したコストがあります。要件は、このコストは攻撃者にとって過大であるということです。
Type: { Abstract Currency, Abstract Currency, Abstract Currency, Abstract Currency } Meaning: Level of privacy, expected cost to violate privacy level for:- openly identified - this is the unprotected case anonymously identified - (messages from the same sender can be linked) unadvertised (but traceable) - meaning that traffic can be detected and traced to it's source or destination, this is a breach if the very fact that two specific principals are communicating is sensitive. undetectable Strictest Requirement: All levels budget of attacker Scope: per stream Example Application: Secret ballot voting system openly identified - budget of any interested party anonymously identified - zero unadvertised - zero undetectable - zero
タイプ：{抽象通貨、抽象通貨、抽象通貨、抽象通貨}意味：プライバシーのレベル、予想されるため、プライバシーレベルに違反するためのコスト： - 公然識別 - これは匿名で特定され、保護されていない場合である - 同じ送信者からの（メッセージがリンクすることができます））非通知（ただしトレーサブル - 2つの特定の主体が通信しているという事実が敏感であれば、それはソースまたは宛先のにトラフィックを検出し、追跡することができることを意味し、これは違反です。検出できない最も厳密要件：攻撃範囲のすべてのレベルの予算：ストリームアプリケーション例あたり：公然と識別秘密投票の投票システム - 匿名で識別されるすべての利害関係者の予算 - ゼロ非通知 - ゼロ検出できない - ゼロ
Confidentiality
機密性
Confidentiality defines how well protected the content of a communication is from snooping.
機密性は、通信の内容がスヌーピングからどのように十分に保護を定義します。
Type: Abstract Currency Meaning: Level of Confidentiality, the cost of gaining illicit access to the content of a stream Strictest Requirement: budget of attacker Scope: per stream Example Application: Secure email - value of transmitted information
タイプ：抽象通貨意味：機密性のレベル、ストリーム最も厳密要件の内容への不正アクセス獲得の費用：攻撃範囲の予算：ストリームサンプルアプリケーションごとに：セキュアメール - 送信された情報の価値
Retransmit prevention strength
再送防止の強さ
This is extremely hard at the moment. This is not to say it's not a requirement.
これは、現時点では非常に困難です。これは、必要条件ではないと言うことではありません。
Type: Abstract Currency Meaning: The cost of retransmitting a secure piece of information should exceed the specified amount. Strictest Requirement: Cost of retransmitting value of information Scope: per stream
タイプ：抽象通貨意味：指定された量を超えなければならない情報の安全な部分を再送信するコスト。最も厳しい要件：情報スコープの値を再送するコスト：ストリームあたり
Membership Criteria
メンバーシップ基準
If a principal attempts to participate in a communication then a check will be made to see if it is allowed to do so. The requirement is that certain principals will be allowed, and others excluded. Given the application is being protected from network details there are only two types of specification available, per user, and per organization (where an organization may contain other organizations, and each user may be a member of multiple organizations). Rules could however be built on properties of a user, for example does the user own a key? Host properties could also be used, so users on slow hosts or hosts running the wrong OS could be excluded.
校長は、チェックは、そうすることを許可されているかどうかを確認するために行われる通信に参加しようとします。要件は、特定のプリンシパルが許可され、他は除外ということです。所与のアプリケーションは、ユーザごとに利用可能な仕様の2種類のみが存在するネットワークの詳細から保護され、そして組織当たり（組織は他の組織を含有してもよく、ここで、各ユーザは、複数の組織のメンバーであってもよいです）。ルールは、しかし、たとえば、ユーザーがキーを所有しない、ユーザーのプロパティに基づいて構築されるだろうか？間違ったOSを実行している遅いホストまたはホスト上のユーザーを除外することができるようホストのプロパティも使用することができます。
Type: Macros Meaning: Include or exclude users (list) organizations (list) hosts (list) user properties (rule) org properties (rule) hosts properties (rule) Strictest Requirement: List of individual users Scope: per stream Example Application: Corporate video-conference - organization membership
タイプ：意味マクロ：含めるまたは除外するユーザー（リスト）組織（リスト）ホスト（リスト）ユーザープロパティ（ルール）組織の特性（ルール）がプロパティ（ルール）をホストする最も厳密要件：個々のユーザースコープの一覧：ストリームアプリケーション例あたり：企業ビデオ会議 - 組織のメンバーシップ
Collusion prevention
共謀防止
Which aspects of collusion it is required to prevent. Collusion is defined as malicious co-operation between members of a secure session. Superficially, it would appear that collusion is not a relevant threat in a multicast, because everyone has the same information, however, wherever there is differentiation, it can be exploited.
防止するために必要とされる共謀の側面。共謀は、安全なセッションのメンバー間の協力悪意のあるとして定義されます。表面的には、共謀は、誰もが同じ情報を持っているので、しかし、差別があるところはどこでも、それが悪用される可能性があります、マルチキャストの関連する脅威ではありませんように思われます。
Type: { Abstract Currency, Abstract Currency, Abstract Currency
タイプ：{抽象通貨、抽象通貨、抽象通貨
} Meaning: time race collusion - cost of colluding key encryption key (KEK) sharing - cost of colluding sharing of differential QoS (not strictly collusion as across sessions not within one) - cost of colluding Strictest Requirement: For all threats cost attackers combined resources Scope: per stream Example Application: A race where delay of the start signal may be allowed for, but one participant may fake packet delay while receiving the start signal from another participant. NB: Time race collusion is the most difficult one to prevent. Also note that while these may be requirements for some systems this does not mean there are necessarily solutions. Setting tough requirements may result in the middleware being unable to create a valid channel.
}意味：時間レース共謀を - キーの暗号化キーを共謀の費用（KEK）の共有 - 差動のQoSの共有を共謀の費用（厳密には共謀1内のセッションではない全体として） - 最も厳密要件を共謀の費用：すべての脅威に対して攻撃を組み合わせたリソースのコスト範囲：ストリーム応用例ごとに別の参加者から開始信号を受信しながら、スタート信号の遅延が許容されることができるレースが、一人の参加者よい偽パケット遅延。 NB：時間レース共謀がないようにする最も困難なものです。また、これらは、いくつかのシステムの要件かもしれないが、これは解決策が必ずしもある意味ではないことに注意してください。厳しい要件を設定すると、ミドルウェアは有効なチャネルを作成することができなくなる場合があります。
Fairness
公正
Fairness is a meta-requirement of many other requirements. Of particular interest are Reliability and Timeliness requirements. When a communication is first created the creator may wish to specify a set of requirements for these parameters. Principals which join later may wish to set tighter limits. Fairness enforces a policy that any improvement is requirement by one principal must be matched by all others, in effect requirements can only be set for the whole group. This increases the likelihood that requirements of this kind will fail to be met. If fairness if not an issue then some parts of the network can use more friendly methods to achieve those simpler requirements.
公正は、他の多くの要件のメタ要件です。特に興味深いのは、信頼性と適時性の要件があります。通信が最初に作成されると、作成者は、これらのパラメータのための要件のセットを指定することもできます。後で参加プリンシパルは、より厳しい制限を設定することもできます。公平性は、任意の改善のみ全グループに設定することができるという効果要件に、一の主面によって要件が他のすべてにマッチしなければならないでポリシーを施行します。これは、この種の要件が満たさなければ失敗する可能性が高くなります。公正でない場合、問題は、ネットワークのいくつかの部分は、これらの単純な要件を達成するために、より親しみやすい方法を使用することができます。
Type: Level of variance of the requirement that needs to be fair. For example, if the latency requirement states within 2 seconds, the level of fairness required may be that variations in latency are not more than 0.1s. This has in fact become an issue in online gaming (e.g. Quake) Meaning: The variance of performance with respect to any other requirement is less than the specified amount. Scope: per stream, per requirement
タイプ：公正であることが必要要件の分散のレベル。例えば、2秒以内の待ち時間要件状態ならば、必要な公平性のレベルは、待ち時間の変化が0.1秒以下であることがあってもよいです。他の要件に関しては、性能のばらつきが規定量より少ない：これは実際には意味のオンラインゲーム（例えばクエイク）で問題となっています。適用範囲：ストリームごとに、要件ごと
Example Application: Networked game, latency to receive positions of players must be within 5ms for all players.
アプリケーション例：プレイヤーの位置を受信するためのネットワークゲーム、待ち時間は、すべてのプレーヤーのために5ミリ秒以内でなければなりません。
Action on compromise
妥協のアクション
The action to take on detection of compromise (until security reassured).
（セキュリティが安心するまで）妥協の検出に実行するアクション。
Type: Enumeration Meaning: warn but continue pause abort Scope: Per stream Strictest Requirement: pause Example Application: Secure video conference - if intruder alert, everyone is warned, but they can continue while knowing not to discuss sensitive matters (cf. catering staff during a meeting).
タイプ：列挙の意味：警告するが、一時停止を継続適用範囲を中止：ストリームごとの最も厳密要件：サンプルアプリケーションを一時停止：セキュアなビデオ会議 - 侵入者警報、誰もが警告されますが、敏感な問題を議論していない知りながら、彼らは続けることができるかどうか（参照ケータリングスタッフの間に打ち合わせ、会議）。
Security dynamics are the temporal properties of the security
mechanisms that are deployed. They may affect other requirements
such as latency or simply be a reflection of the security
limitations of the system. The requirements are often concerned
with abnormal circumstances (e.g. system violation).
Mean time between compromises
妥協の間の平均時間
This is not the same as the strength of a system. A fairly weak system may have a very long time between compromises because it is not worth breaking in to, or it is only worth it for very few people. Mean time between compromises is a combination of strength, incentive and scale.
これは、システムの強さと同じではありません。それはに破壊価値がないので、かなり弱いシステムは、妥協の間に非常に長い時間を有していてもよく、またはそれは非常に少数の人々のために、それだけの価値があります。妥協間の平均時間は、強度、インセンティブや規模の組み合わせです。
Type: Time Scope: Per stream Strictest Requirement: indefinite Example Application: Secure Shell - 1500hrs
タイプ：時間範囲：ストリーム毎の最も厳密要件：不定アプリケーション例：セキュアシェル - 1500hrs
Compromise detection time limit
妥協の検出時間制限
The average time it must take to detect a compromise (one predicted in the design of the detection system, that is).
それは妥協を検出するために必要平均時間（一つはつまり、検出システムの設計で予測しました）。
Type: Time Scope: Per stream Strictest Requirement: Round trip time Example Application: Secure Shell - 2secs
タイプ：時間範囲：ストリーム毎の最も厳密要件：ラウンドトリップ時間アプリケーション例：セキュアシェル - 2secs
Compromise recovery time limit
妥協の回復時間制限
The maximum time it must take to re-seal the security after a breach. This combined with the compromise detection time limit defines how long the system must remain inactive to avoid more security breaches. For example if a compromise is detected in one minute, and recovery takes five, then one minute of traffic is now insecure and the members of the communication must remain silent for four minutes after detection while security is re-established.
最大時間は、それが違反後にセキュリティを再密封するために取る必要があります。妥協検出時間制限と組み合わせるこれは、システムがより多くのセキュリティ侵害を避けるために、非アクティブのままにしなければならない時間を定義します。妥協は1分で検出され、回復が5を取るされている場合たとえば、その後、トラフィックの1分は現在安全ではないとセキュリティが再確立されている間通信のメンバーは、検出後の4分間沈黙している必要があります。
Type: Time Scope: Per stream Strictest Requirement: 1 second Example Application: Audio conference - 10 seconds
タイプ：時間範囲：ストリーム毎の最も厳密要件：1秒アプリケーション例：オーディオ会議 - 10秒
Total Cost
総費用
The total cost of communication must be limited to this amount. This would be useful for transfer as opposed to stream type applications.
通信の総費用はこの額に限定する必要があります。タイプのアプリケーションをストリーミングするのではなく、これは転送のために有用であろう。
Type: Currency Meaning: Maximum charge allowed Scope: Per user per stream Strictest Requirement: Free Example Application: File Transfer: comms cost must be < 1p/Mb
タイプ：通貨意味：最大充電許可範囲：ユーザー毎のストリームあたりの最も厳密要件：無料アプリケーション例：ファイル転送：途切れコストは<1P / MBでなければなりません
Cost per Time
時間あたりのコスト
This is the cost per unit time. Some applications may not be able to predict the duration of a communication. It may be more meaningful for those to be able to specify price per time instead. Type: Currency per timeS
これは、単位時間あたりのコストです。一部のアプリケーションでは、通信の継続時間を予測することができないかもしれません。それらの代わりに、時間あたりの価格を指定できるようにすることが、より有意義かもしれません。タイプ：回あたりの通貨
Scope: Per user per stream Strictest Requirement: Free Example Application: Video Conference - 15p / minute
スコープ：ユーザー毎のストリームあたりの最も厳密要件：無料アプリケーション例：ビデオ会議 - 15P /分
Cost per Mb
Mbのあたりのコスト
This is the cost per unit of data. Some communications may be charged by the amount of data transferred. Some applications may prefer to specify requirements in this way.
これは、データの単位あたりのコストです。いくつかの通信は、転送されたデータの量によって充電することができます。一部のアプリケーションでは、このように要件を指定することもできます。
Type: Currency per data size Scope: Per user per stream Strictest Requirement: Free Example Application: Email advertising - 15p / Mb
タイプ：データサイズ範囲ごとの通貨：ユーザー毎のストリームあたりの最も厳密要件：無料アプリケーション例：電子メールの広告 - 15P / MB
See comprehensive security section of taxonomy.
分類学の包括的なセキュリティセクションを参照してください。
[Bagnall98] Bagnall Peter, Poppitt Alan, Example LSMA classifications, BT Tech report, <URL:http://www.labs.bt.com/projects/mware/>
[Bagnall98] Bagnallピーター、Poppittアラン、例LSMA分類、BTテックレポート、<URL：のhttp：//www.labs.bt.com/projects/mware/>
[limitations] Pullen, M., Myjak, M. and C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment", RFC 2502, February 1999.
[制限]プーレン、M.、Myjak、M.とC. Bouwens、「大規模なマルチキャスト環境における分散シミュレーションのためのインターネットプロトコルスイートの制限」、RFC 2502、1999年2月。
[rmodp] Open Distributed Processing Reference Model (RM-ODP), ISO/IEC 10746-1 to 10746-4 or ITU-T (formerly CCITT) X.901 to X.904. Jan 1995.
【rmodp】分散オープン処理参照モデル（RM-ODP）、ISO / IEC 10746から4に10746から1又はITU-T（旧CCITT）X.904にX.901。 1995年1月。
[blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and Wiener, Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security, January 1996.
[blaze95]ブレイズ、ディフィー、リベスト、シュナイアー、下村、トンプソンとウィーン、共通鍵暗号のための最小限のキーの長さは、十分な商業セキュリティ、1996年1月を提供します。
Peter Bagnall c/o B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
/ O B54 / 77 BT研究所Martleshamヒースイプスウィッチ、IP5 3REイングランドCピーターBagnall
EMail: pete@surfaceeffect.com Home page: http://www.surfaceeffect.com/people/pete/
電子メール：pete@surfaceeffect.comホームページ：http://www.surfaceeffect.com/people/pete/
Bob Briscoe B54/74 BT Labs Martlesham Heath Ipswich, IP5 3RE England
ボブ・ブリスコーB54 / 74 BT研究所Martleshamヒースイプスウィッチ、IP5 3REイングランド
Phone: +44 1473 645196 Fax: +44 1473 640929 EMail: bob.briscoe@bt.com Home page: http://www.labs.bt.com/people/briscorj/
電話：+44 1473 645196ファックス：+44 1473 640929 Eメール：bob.briscoe@bt.comホームページ：http://www.labs.bt.com/people/briscorj/
Alan Poppitt B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
アランPoppitt B54 / 77 BT研究所Martleshamヒースイプスウィッチ、IP5 3REイングランド
Phone: +44 1473 640889 Fax: +44 1473 640929 EMail: apoppitt@jungle.bt.co.uk Home page: http://www.labs.bt.com/people/poppitag/
電話：+44 1473 640889ファックス：+44 1473 640929 Eメール：apoppitt@jungle.bt.co.ukのホームページ：http://www.labs.bt.com/people/poppitag/
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。