Network Working Group P. Bagnall
Request for Comments: 2729 R. Briscoe
Category: Informational A. Poppitt
BT
December 1999
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）的通信需求定义一个分类系统。一个协议不太可能在涉及任何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
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.
这种分类法由大量被认为对描述LSMA的通信需求有用的参数组成。为了描述一个特定的应用，每个参数都会被指定一个值。尽可能给出典型值范围。否则，将给出任何可能值的类型。这些参数被收集到大约十个更高级别的类别中，但这纯粹是为了方便。
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. 这是LSMA定义其通信需求方式标准化的一步。这可能导致应用程序和协议适应中间件之间的标准API
5. Identification of limitations in current Internet technology for LSMAs to be added to the LSMA limitations memo [limitations]
5. 识别LSMA当前互联网技术中的限制，将其添加到LSMA限制备忘录[限制]
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 ?
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
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美元。另一个衡量标准可能是“平均工时”。
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.
类型：布尔值含义：事务性或非事务性最严格的要求：事务范围：每流示例应用程序：银行贷记转账、借记和贷记必须是原子的。注意：事务可能要复杂得多，但据信这是应用层的问题。
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帧可能丢失，I帧不丢失
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
Type: Time
Strictest Requirement: Web server - 1 second
Scope: per stream
Example Application: Name lookup - 5 seconds
Mean time between failures
平均无故障时间
The mean time between two consecutive total failures of the channel.
通道两次连续总故障之间的平均间隔时间。
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
}
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!)
含义：计时-事件为时间戳全局每个发送者无顺序-事件按发生顺序排列全局每个发送者无因果关系-事件形成一个关系因果图全局每个发送者无最严格的要求：全局、全局、全局范围：每流示例应用程序：游戏-{none，per sender，global}（确保子弹射中后发生！）
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
类型：布尔值含义：硬或软实时最严格要求：硬范围：每流示例应用程序：医疗监视器-硬
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唇形同步值80ms NB：范围不一定与会话相同。有些流可能不需要同步（例如，足球比赛中的记分器）
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
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
Fourier Transform of the b/w requirement) is possible but as complexity increases usefulness and computability decrease.
b/w要求的傅里叶变换是可能的，但随着复杂性的增加，有用性和可计算性降低。
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秒（有效期至少一小时）
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
类型：带宽最严格要求：无上限范围：每流示例应用：互联网电话8kb/s
Tolerable Bandwidth
容许带宽
Minimum bandwidth that application can tolerate
应用程序可以容忍的最小带宽
Type: Bandwidth Strictest Requirement: No upper limit Scope: per stream Example Application: Internet phone 4kb/s
类型：带宽最严格要求：无上限范围：每流示例应用：互联网电话4kb/s
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.
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.
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
类型：应用程序基准含义：应用程序所需的资源级别最严格的要求：完全消耗范围：每流示例应用程序：视频-每秒消耗15帧NB：主机性能很复杂，因为负载、媒体类型、媒体质量、h/w辅助和编码方案都会影响
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.
处理负载。在通信开始之前，这些很难预测。在某种程度上，随着通信的进行，需要对其进行测量和修改。
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
类型：数据大小最严格要求：不适用范围：每流示例应用程序：文档传输，4KB
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
Type: Date
Strictest Requirement: Now
Scope: per stream
Example Application: FTP - Now+30mins
Duration
期间
(end time) - (start time) = (duration), therefore only two of
three should be specified.
(end time) - (start time) = (duration), therefore only two of
three should be specified.
Type: Time
Strictest Requirement: - 0ms for discrete, indefinite for streams
Scope: per stream
Example Application: audio feed - 60mins
Type: Time
Strictest Requirement: - 0ms for discrete, indefinite for streams
Scope: per stream
Example Application: audio feed - 60mins
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
Type: Fraction
Meaning: Variance as a fraction of maximum bandwidth
Strictest Requirement: =bandwidth
Scope: per stream
Example Application: commentary & slide show: 90% of max
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.
类型：分数（要求比例）或整数（法定人数）最严格的要求：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
类型：布尔最严格要求：允许的范围：每个流或会话示例应用程序：游戏-不允许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
类型：布尔最严格的要求：允许的范围：每个流或会话示例应用程序：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
类型：布尔最严格的要求：允许的范围：每个流或会话示例应用程序：体育事件广播，允许的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，一个主视频，四个用户选择，一个音频评论
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
类型：整数最严格要求：无上限范围：每流示例应用程序：video mcast-100000
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
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)
1. 时间2。排序（相对于其他事件时）3。谁4。什么（事件本身）
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.
类型：抽象货币含义：发起拒绝服务攻击的成本大于指定金额。最严格的要求：最大攻击者范围的预算：每流示例应用程序：web托管，以防止单个黑客使系统陷入停滞。
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.
类型：每个操作的成员列表/规则。含义：用于确定角色权限的谓词最严格的要求：发送和接收具有不同的策略。范围：每流示例应用：电视广播，发送方策略定义发送方，接收方策略为空。注意：多个操作可能共享相同的成员策略。
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.
隐私定义主体身份的模糊程度。这可以用于任何交互。参与者列表可能会模糊，发件人在发送时可能会模糊其身份。还有不同类型的隐私。例如，知道两条消息是由同一个人发送的，即使发送者的身份仍然未知，也会破坏最强烈的隐私。对于每一个“级别”的隐私，都有违反它的成本。要求是，这一成本对于攻击者来说过高。
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
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
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.
如果委托人试图参与通信，则将进行检查，以确定是否允许其参与通信。要求是允许某些委托人，而排除其他委托人。鉴于应用程序受到网络详细信息的保护，只有两种类型的规范可用，即每个用户和每个组织（其中一个组织可能包含其他组织，每个用户可能是多个组织的成员）。但是，规则可以建立在用户的属性上，例如用户是否拥有密钥？还可以使用主机属性，这样就可以排除慢速主机上的用户或运行错误操作系统的主机上的用户。
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共享的成本（不是严格的跨会话共谋，不是一个会话内的共谋）-共谋成本最严格的要求：对于所有威胁成本攻击者组合资源范围：每流示例应用程序：允许启动信号延迟的竞赛，但一个参与者在从另一个参与者接收启动信号时可能会伪造数据包延迟。注：时间竞赛共谋是最难防止的。还要注意，虽然这些可能是某些系统的要求，但这并不意味着一定有解决方案。设置严格的要求可能会导致中间件无法创建有效的通道。
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
类型：时间范围：每流最严格要求：不确定示例应用：安全壳-1500小时
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
类型：时间范围：每个流最严格的要求：往返时间示例应用程序：Secure Shell-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.
违约后重新密封证券所需的最长时间。这与危害检测时间限制相结合，定义了系统必须保持不活动以避免更多安全漏洞的时间。例如，如果在一分钟内检测到泄露，而恢复需要五分钟，那么一分钟的通信现在是不安全的，并且在重新建立安全性时，通信成员必须在检测后保持沉默四分钟。
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
Type: Currency
Meaning: Maximum charge allowed
Scope: Per user per stream
Strictest Requirement: Free
Example Application: File Transfer: comms cost must be < 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
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Video Conference - 15p / minute
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
Type: Currency per data size
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Email advertising - 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 Peter, Poppitt Alan, Example LSMA
classifications, BT Tech report,
<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.
[限制]Pullen，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-1至10746-4或ITU-T（以前的CCITT）X.901至X.904。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]Blaze、Diffie、Rivest、Schneier、Shimomura、Thompson和Wiener，《对称密码提供充分商业安全的最小密钥长度》，1996年1月。
Peter Bagnall c/o B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
彼得·巴格纳尔c/o B54/77英国电信实验室Martlesham Heath Ipswich，IP5 3英国
EMail: pete@surfaceeffect.com
Home page: http://www.surfaceeffect.com/people/pete/
EMail: pete@surfaceeffect.com
Home page: http://www.surfaceeffect.com/people/pete/
Bob Briscoe B54/74 BT Labs Martlesham Heath Ipswich, IP5 3RE England
Bob Briscoe B54/74英国电信实验室Martlesham Heath Ipswich，IP5 3英国
Phone: +44 1473 645196
Fax: +44 1473 640929
EMail: bob.briscoe@bt.com
Home page: http://www.labs.bt.com/people/briscorj/
Phone: +44 1473 645196
Fax: +44 1473 640929
EMail: bob.briscoe@bt.com
Home page: http://www.labs.bt.com/people/briscorj/
Alan Poppitt B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
Alan Poppitt B54/77英国电信实验室Martlesham Heath Ipswich，IP5 3英国
Phone: +44 1473 640889
Fax: +44 1473 640929
EMail: apoppitt@jungle.bt.co.uk
Home page: http://www.labs.bt.com/people/poppitag/
Phone: +44 1473 640889
Fax: +44 1473 640929
EMail: apoppitt@jungle.bt.co.uk
Home page: 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编辑功能的资金目前由互联网协会提供。