Network Working Group B. Adamson
Request for Comments: 5401 Naval Research Laboratory
Obsoletes: 3941 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2008
Network Working Group B. Adamson
Request for Comments: 5401 Naval Research Laboratory
Obsoletes: 3941 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2008
Multicast Negative-Acknowledgment (NACK) Building Blocks
多播否定确认（NACK）构建块
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941.
本文档讨论如何创建利用负面确认（NACK）反馈的可靠多播协议。介绍了协议设计目标和假设的基本原理。确定了基于NACK（在某些情况下是通用的）可靠多播协议操作的技术挑战。这些目标和挑战被分解为一组功能“构建块”，用于解决可靠多播协议操作的不同方面。预计这些构建块将有助于生成可靠多播协议的不同实例。本文件废除了RFC 3941。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Rationale .......................................................4
2.1. Delivery Service Model .....................................5
2.2. Group Membership Dynamics ..................................6
2.3. Sender/Receiver Relationships ..............................6
2.4. Group Size Scalability .....................................6
2.5. Data Delivery Performance ..................................7
2.6. Network Environments .......................................7
2.7. Intermediate System Assistance .............................8
3. Functionality ...................................................8
3.1. Multicast Sender Transmission .............................11
3.2. NACK Repair Process .......................................13
3.3. Multicast Receiver Join Policies and Procedures ...........26
3.4. Node (Member) Identification ..............................26
3.5. Data Content Identification ...............................27
3.6. Forward Error Correction (FEC) ............................28
3.7. Round-Trip Timing Collection ..............................29
3.8. Group Size Determination/Estimation .......................33
3.9. Congestion Control Operation ..............................34
3.10. Intermediate System Assistance ...........................34
4. NACK-Based Reliable Multicast Applicability ....................35
5. Security Considerations ........................................36
6. Changes from RFC 3941 ..........................................38
7. Acknowledgements ...............................................38
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Rationale .......................................................4
2.1. Delivery Service Model .....................................5
2.2. Group Membership Dynamics ..................................6
2.3. Sender/Receiver Relationships ..............................6
2.4. Group Size Scalability .....................................6
2.5. Data Delivery Performance ..................................7
2.6. Network Environments .......................................7
2.7. Intermediate System Assistance .............................8
3. Functionality ...................................................8
3.1. Multicast Sender Transmission .............................11
3.2. NACK Repair Process .......................................13
3.3. Multicast Receiver Join Policies and Procedures ...........26
3.4. Node (Member) Identification ..............................26
3.5. Data Content Identification ...............................27
3.6. Forward Error Correction (FEC) ............................28
3.7. Round-Trip Timing Collection ..............................29
3.8. Group Size Determination/Estimation .......................33
3.9. Congestion Control Operation ..............................34
3.10. Intermediate System Assistance ...........................34
4. NACK-Based Reliable Multicast Applicability ....................35
5. Security Considerations ........................................36
6. Changes from RFC 3941 ..........................................38
7. Acknowledgements ...............................................38
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
Reliable multicast transport is a desirable technology for efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users (see [RFC2357]). This document addresses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. NACK-based protocols generally entail less frequent feedback messaging than reliability protocols based on positive acknowledgment (ACK). The less frequent feedback messaging helps simplify the problem of feedback implosion as group size grows larger. While different protocol instantiations may be required to meet specific application and network architecture demands [ArchConsiderations], there are a number of fundamental components that may be common to these different instantiations.
可靠的多播传输是一种理想的技术，可以在Internet上高效可靠地向组分发数据。组通信范例的复杂性需要不同的协议类型和实例化，以满足不同潜在可靠多播应用程序和用户的性能和可伸缩性要求（参见[RFC2357]）。本文档介绍如何创建利用负面确认（NACK）反馈的可靠多播协议。与基于肯定确认（ACK）的可靠性协议相比，基于NACK的协议通常需要更少的反馈消息传递。随着团队规模的扩大，不太频繁的反馈消息传递有助于简化反馈内爆的问题。虽然可能需要不同的协议实例化来满足特定的应用程序和网络体系结构需求[ArchConferences]，但这些不同的实例化可能有许多共同的基本组件。
This document describes the framework and common "building block" components relevant to multicast protocols that are based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NACK-based reliable multicast protocol design, it specifically addresses in detail the following building blocks, which are not addressed in other IETF documents:
本文档描述了与多播协议相关的框架和通用“构建块”组件，这些协议主要基于NACK操作以实现可靠传输。虽然本文件讨论了大量可靠多播组件以及与基于NACK的可靠多播协议设计相关的问题，但它具体阐述了其他IETF文件中未涉及的以下构建块：
1. NACK-based multicast sender transmission strategies,
1. 基于NACK的多播发送方传输策略，
2. NACK repair process with timer-based feedback suppression, and
2. 具有基于定时器的反馈抑制的NACK修复过程，以及
3. Round-trip timing for adapting NACK and other timers.
3. 调整NACK和其他计时器的往返时间。
NACK-based reliable multicast implementations SHOULD make use of Forward Error Correction (FEC) erasure coding techniques, as described in the FEC Building Block [RFC5052] document. Packet-level erasure coding allows missing packets from a given FEC block to be recovered using the parity packets instead of classical, individualized retransmission of original source data content. For this reason, this document refers to the protocol mechanisms for reliability as a "repair process." Note that NACK-based protocols can reactively provide the parity packets in response to receiver requests for repair rather than just proactively sending added FEC parity content as part of the original transmission. Hybrid proactive/reactive use of FEC content is also possible with the mechanisms described in this document. Some classes of FEC coding, such as Maximal Separable Distance (MDS) codes, allow senders to dynamically implement deterministic, highly efficient receiver group repair strategies as part of a NACK-based, selective automated repeat-request (ARQ) scheme.
基于NACK的可靠多播实现应使用前向纠错（FEC）擦除编码技术，如FEC构建块[RFC5052]文档中所述。分组级擦除编码允许使用奇偶校验分组而不是原始源数据内容的经典的、个性化的重传来恢复来自给定FEC块的丢失分组。因此，本文件将可靠性协议机制称为“修复过程”。请注意，基于NACK的协议可以反应性地提供奇偶校验包，以响应接收器的修复请求，而不仅仅是作为原始传输的一部分主动发送添加的FEC奇偶校验内容。通过本文档中描述的机制，也可以混合主动/被动使用FEC内容。某些类型的FEC编码，如最大可分离距离（MDS）码，允许发送方动态实施确定性、高效的接收机组修复策略，作为基于NACK的选择性自动重复请求（ARQ）方案的一部分。
The potential relationships to other reliable multicast transport building blocks (e.g., FEC, congestion control) and general issues with NACK-based reliable multicast protocols are also discussed. This document follows the guidelines provided in [RFC3269].
还讨论了与其他可靠多播传输构建块（如FEC、拥塞控制）的潜在关系以及基于NACK的可靠多播协议的一般问题。本文件遵循[RFC3269]中提供的指南。
Statement of Intent
意向书
This memo contains descriptions of building blocks that can be applied in the design of reliable multicast protocols utilizing negative-acknowledgement (NACK) feedback. [RFC3941] contains a previous description of this specification. RFC 3941 was published in the "Experimental" category. It was the stated intent of the Reliable Multicast Transport (RMT) working group at that time to resubmit this specification as an IETF Proposed Standard in due course.
本备忘录包含可应用于利用否定确认（NACK）反馈设计可靠多播协议的构建块的描述。[RFC3941]包含本规范的先前描述。RFC 3941发表在“实验”类别中。当时，可靠多播传输（RMT）工作组的明确意图是在适当的时候将本规范作为IETF提议的标准重新提交。
This Proposed Standard specification is thus based on [RFC3941] and has been updated according to accumulated experience and growing protocol maturity since the publication of RFC 3941. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
因此，本拟议标准规范以[RFC3941]为基础，并根据RFC 3941发布以来积累的经验和不断增长的协议成熟度进行了更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
The differences between [RFC3941] and this document are listed in Section 6.
第6节列出了[RFC3941]与本文件之间的差异。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
使用此处（以及其他适用的构建块文档）提供的构建块进行的每个潜在协议实例化将具有可能影响单个协议设计的特定标准。为了支持适用构建块的开发，确定和总结驱动通用协议设计目标和假设非常有用。这些是每个协议实例化都需要详细解决的领域。本文件中的每个构建块描述将包括对这些设计标准影响的讨论。此处考虑的设计标准类别包括：
1. Delivery Service Model,
1. 配送服务模式，
2. Group Membership Dynamics,
2. 集团成员动态，
3. Sender/Receiver Relationships,
3. 发送方/接收方关系，
4. Group Size Scalability,
4. 组大小可扩展性，
5. Data Delivery Performance, and
5. 数据交付性能，以及
6. Network Environments.
6. 网络环境。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents, such as [RFC5052], have been created to address areas outside of the scope of this document. NACK-based reliable multicast protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NACK-based reliable multicast but may be used in concert with the other building block areas. In some cases, a building block may be
至少对所有这些领域进行了简要讨论。此外，还创建了其他可靠的多播传输构建块文档，如[RFC5052]，以解决本文档范围之外的问题。基于NACK的可靠多播协议实例可能依赖于这些其他构建块以及此处提供的构建块。本文档主要关注基于NACK的可靠多播所特有的领域，但可以和其他构建块领域一起使用。在某些情况下，构建块可能是
able to address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment. The forms of "bulk data transfer" covered here include reliable transport of bulky, fixed-length, a priori static content and also transmission of non-predetermined, perhaps streamed, content of indefinite length. Section 3.5 discusses these different forms of bulk data content in further detail.
能够解决广泛的假设，而在其他情况下，需要权衡以满足不同的应用程序需求或操作环境。如有必要，构建块特征设计为参数化，以满足不同的要求。当然，一个基本目标是最小化设计复杂性，并至少为任何此类参数推荐默认值，以满足典型互联网环境中的通用“批量数据传输”要求。此处所述的“批量数据传输”形式包括可靠传输大容量、固定长度、先验静态内容，以及传输不确定长度的非预定（可能是流式）内容。第3.5节将进一步详细讨论这些不同形式的批量数据内容。
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. The most basic service model for reliable multicast transport is that of "bulk transfer", which is a primary focus of this and other related RMT working group documents. However, the same principles in protocol design may also be applied to other service models, e.g., more interactive exchanges of small messages such as with white-boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
可靠多播传输协议的隐含目标是在使用IP多播数据报服务进行通信的一组成员之间可靠地传递数据。但是，应用程序试图提供的特定服务可能会影响设计决策。可靠多播传输最基本的服务模型是“批量传输”，这是本文件和其他相关RMT工作组文件的主要关注点。然而，协议设计中的相同原则也可应用于其他服务模型，例如，更具互动性的小消息交换，如白板或文本聊天。在这些不同的模型中，存在一些问题，例如发送方缓存传输数据（或引用数据的状态）以便重新传输或修复的能力。根据数据内容，对组中成员之间的传输和接收序列中的顺序和/或因果关系的需求可能不同。组通信范式与点对点模型的显著不同之处在于，根据数据内容类型，一些接收器可以完成部分数据内容的接收，并且能够在其他成员接收到内容之前对其采取行动。这对于某些应用可能是可接受的（甚至是可取的），但对于其他应用则不是。这些不同的需求推动了对许多不同协议实例化设计的需求。开发普遍有用的构建块机制的一个重大挑战是在不定义特定的应用程序级细节的情况下，甚至可以容纳有限范围的这些功能。
Another factor impacting the delivery service model is the potential for different receivers in the multicast group to have significantly differing quality of network connectivity. This may involve receivers with very limited goodput due to connection rate or substantial packet loss. NACK-based protocol implementations may wish to provide policies by which extremely poor-performing receivers are excluded from the main group or migrated to a separate delivery
影响交付服务模型的另一个因素是多播组中的不同接收者可能具有显著不同的网络连接质量。这可能涉及由于连接速率或大量数据包丢失而导致的具有非常有限的输出的接收器。基于NACK的协议实现可能希望提供一些策略，通过这些策略，性能极差的接收器被排除在主组之外，或者被迁移到单独的交付中
group. Note that some application models may require that the entire group be constrained to the performance of the "weakest member" to satisfy operational requirements. In either case, protocol designs should consider this aspect of the reliable multicast delivery service model.
组请注意，某些应用模型可能要求整个团队受限于“最弱成员”的性能，以满足运营要求。在任何一种情况下，协议设计都应该考虑可靠组播传输服务模型的这一方面。
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
组通信与点对点通信的不同之处在于，即使组的组成发生变化，通信的“线程”仍然存在。这与点对点通信模型形成对比，在点对点通信模型中，如果双方中的任何一方离开，则通信过程（数据交换）终止（或至少暂停）。根据应用程序目标，参与可靠多播传输“会话”的发送方和接收方可能能够延迟加入、离开和/或潜在地重新加入，而正在进行的组通信“线程”仍然保持功能和有用。还要注意，这可能会影响协议消息内容。如果支持“延迟加入者”，则可以在消息头中放置一些附加信息以适应此功能。或者，如果认为对典型消息传输的开销的影响太大，则可以在其自己的消息中发送信息（按需或间歇）。组动态还可能影响其他协议机制，如NACK定时、拥塞控制操作等。
The relationship of senders and receivers among group members requires consideration. In some applications, there may be a single sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender and receiver of data may exist.
需要考虑组成员之间发送者和接收者的关系。在某些应用中，可能存在单个发送方对一组接收方的多播。在其他情况下，可能有多个发送者，或者组中的每个人都可能成为数据的发送者和接收者。
Native IP multicast [RFC1112] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-based protocol can be applied without the potential for the volume of NACK feedback messages to overwhelm network capacity. This is often referred to as "feedback implosion". Research suggests that NACK-based reliable multicast group sizes on the order of tens of thousands of receivers may operate with acceptable levels of feedback to the sender using probabilistic, timer-based suppression techniques [NormFeedback]. Instead of receivers immediately transmitting feedback messages when loss is detected, these techniques specify use
本机IP多播[RFC1112]可以扩展到非常大的组大小。一些应用程序可能需要随着多播基础设施的扩展能力进行扩展。在其最简单的形式中，基于NACK的协议可以应用到的组大小存在限制，而NACK反馈消息的量不可能超过网络容量。这通常被称为“反馈内爆”。研究表明，基于NACK的可靠多播组大小约为数万个接收器，可以使用概率、基于计时器的抑制技术，以对发送方可接受的反馈水平运行[正常反馈]。这些技术不是在检测到丢失时立即发送反馈消息，而是指定使用
of purposefully-scaled, random back-off timeouts such that some potential NACKing receivers can self-suppress their feedback upon hearing messages from other receivers that have selected shorter random timeout intervals. However, there may be additional NACK suppression heuristics that can be applied to enable these protocols to scale to even larger group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
有目的地调整随机退避超时，使得一些潜在的振铃接收器在听到来自选择了较短随机超时间隔的其他接收器的消息时可以自我抑制其反馈。然而，可能存在额外的NACK抑制试探法，可用于使这些协议能够扩展到更大的组大小。在大规模情况下，可能禁止成员对集团中的所有其他成员（特别是其他接收者）保持状态。在开发适用的构建块时，需要考虑群体规模的影响。
Group size scalability may also be aided by intermediate system assistance; see section 2.7 below.
组大小的可扩展性也可以通过中间系统辅助来辅助；见下文第2.7节。
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer-based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and to allow the sender of data to identify appropriate content for efficient repair transmission. For example, back-off timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at the cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
在设计面向NACK的协议时，需要在可伸缩性和数据交付延迟之间进行权衡。如果要使用基于定时器的概率NACK抑制，NACK过程中会有一些延迟，以允许抑制发生，并允许数据发送者识别适当的内容以进行有效的修复传输。例如，退避超时可用于确保有效的NACK抑制和修复传输，但这是以增加发送延迟和增加发送方和接收方的缓冲要求为代价的。构建块应允许应用程序为数据交付性能建立界限。请注意，应用程序设计人员必须了解在应用此类边界时所做的可伸缩性权衡。
The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively operating across a wide range of the networks to which general purpose IP service applies. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite, and other wireless communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fan-out" to which IP multicast service is highly applicable. Additionally, policy and/or technical issues may result in topologies where multicast connectivity is limited to a source-specific multicast (SSM) model from a specific source [RFC4607]. Receivers in the group may be
Internet协议历来承担着跨异构网络拓扑提供服务的角色。期望可靠的多播协议能够在应用通用IP服务的广泛网络上有效地操作。今天，单个组成员之间链路上的可用带宽可能在无线链路的低kbit/s和高速LAN连接的多Gbit/s之间变化，来自其他流的争用程度不同。最近，包括56K/ADSL调制解调器、有线电视互联网服务、卫星和其他无线通信服务在内的许多非对称网络服务开始激增。其中许多是固有的广播媒体，具有潜在的大“扇出”，IP多播服务非常适用于这些媒体。此外，策略和/或技术问题可能导致多播连接仅限于来自特定源的源特定多播（SSM）模型的拓扑[RFC4607]。组中的接收器可以是
restricted to unicast feedback for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks.
仅限于NACK和其他消息的单播反馈。在构建块开发和协议设计中，必须考虑底层网络的性质。
Intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to increase the performance and scalability of NACK-based reliable multicast protocols. Feedback aggregation and filtering of sender repair data may be possible with NACK-based protocols using FEC-based repair strategies as described in the present and other reliable multicast transport building block documents. However, there will continue to be a number of instances where intermediate system assistance is not available or practical. Any building block components for NACK-oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
来自直接了解底层网络拓扑的设备/系统的中间协助可用于提高基于NACK的可靠多播协议的性能和可伸缩性。使用基于FEC的修复策略的基于NACK的协议，可以对发送方修复数据进行反馈聚合和过滤，如本文档和其他可靠多播传输构建块文档中所述。然而，在许多情况下，中间系统援助仍然不可用或不实用。面向NACK的可靠多播的任何构建块组件应能够在没有此类协助的情况下运行。然而，建议这样的协议也考虑在可用时利用这些特征。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NACK-based reliable multicast building block identification/design. This section describes different building block areas applicable to NACK-based reliable multicast protocols. Some of these areas are specific to NACK-based protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those general building block areas from the standpoint of NACK-based reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NACK-based reliable multicast protocols.
上一节介绍了协议构建块的作用以及可能影响基于NACK的可靠多播构建块识别/设计的一些标准。本节描述了适用于基于NACK的可靠多播协议的不同构建块区域。其中一些领域特定于基于NACK的协议。提供了这些区域的详细说明。在其他情况下，这些区域（例如，节点标识符、前向纠错（FEC）等）可适用于其他形式的可靠多播。在这些情况下，下面的讨论从基于NACK的可靠多播的角度描述了对这些通用构建块区域的要求。在适用的情况下，参考其他构建块文档，以了解对基于NACK的可靠多播协议的可能贡献。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NACK-
对于每个构建块，提供了概念上的“接口描述”，以说明一个构建块组件对另一个构建块组件或其他协议参数的依赖关系。构建块组件可能需要来自另一个构建块组件或其他源的某种形式的“输入”来执行其功能。构建块组件所需的任何“输入”和/或提供的任何结果“输出”将在每个构建块组件的接口描述中定义和描述。请注意，这里提供的构建块集不能完全满足彼此的“输入”和“输出”需求。在某些情况下，此处构建块的“输入”必须来自本文档外部的其他构建块（例如，拥塞控制或FEC）。在其他情况下，NACK-
based reliable multicast building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
基于可靠的多播构建块“输入”必须由特定的协议实例化或实现（例如，应用程序数据和控制）来满足。
The following building block components relevant to NACK-based reliable multicast are identified:
确定了与基于NACK的可靠多播相关的以下构建块组件：
NORM (NACK-Oriented Reliable Multicast)-Specific
NORM（面向NACK的可靠多播）-特定
1. Multicast Sender Transmission
1. 多播发送方传输
2. NACK Repair Process
2. NACK修复工艺
3. Multicast Receiver Join Policies and Procedures
3. 多播接收器加入策略和过程
General Purpose
通用
1. Node (Member) Identification
1. 节点（成员）标识
2. Data Content Identification
2. 数据内容识别
3. Forward Error Correction (FEC)
3. 前向纠错（FEC）
4. Round-Trip Timing Collection
4. 往返定时采集
5. Group Size Determination/Estimation
5. 群体规模的确定/估计
6. Congestion Control Operation
6. 拥塞控制操作
7. Intermediate System Assistance
7. 中间系统辅助
8. Ancillary Protocol Mechanisms
8. 辅助协议机制
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components, while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
图1提供了这些构建块区域及其一些关系的图形概述。例如，发送方最初发送的数据消息的内容取决于“节点标识”、“数据内容标识”和“FEC”组件，而消息传输速率通常取决于“拥塞控制”组件。随后，接收器对这些传输的响应（例如，为维修而呼叫）将取决于数据消息内容和来自其他构建块组件的输入。最后，发送方对接收方响应的处理将反馈到其传输策略中。
The components on the left side of this figure are areas that may be applicable beyond NACK-based reliable multicast. The more significant of these components are discussed in other building block documents, such as the FEC Building Block [RFC5052]. Brief
此图左侧的组件是可能适用于基于NACK的可靠多播之外的区域。这些组件中更重要的部分将在其他构建块文档中讨论，例如FEC构建块[RFC5052]。简明的
descriptions of these areas and their roles in NACK-based reliable multicast protocols are given below, and "RTT Collection" is discussed in detail in Section 3.7 of this document.
下面给出了这些区域的描述及其在基于NACK的可靠多播协议中的作用，本文件第3.7节详细讨论了“RTT收集”。
The components on the right are seen as specific to NACK-based reliable multicast protocols, most notably the NACK repair process. These areas are discussed in detail below (most notably, "Multicast Sender Transmission" and "NACK Repair Process" in Sections 3.1 and 3.2). Some other components (e.g., "Security") impact many aspects of the protocol, and others may be more transparent to the core protocol processing. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NACK-based reliable multicast transport for the Internet.
右侧的组件被视为特定于基于NACK的可靠多播协议，最显著的是NACK修复过程。下面将详细讨论这些领域（最显著的是第3.1节和第3.2节中的“多播发送方传输”和“NACK修复过程”）。其他一些组件（例如，“安全性”）影响协议的许多方面，其他组件可能对核心协议处理更透明。在适用的情况下，针对适当满足基于NACK的Internet可靠多播传输目标的机制提出了具体的技术建议。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |-------+-->| Sender Transmission |<---.
`---------------------' | `-----------------------' |
.---------------------. | | .------------------. |
| Data Identification |-------+ | | Rcvr Join Policy | |
`---------------------' | V `------------------' |
.---------------------. | .----------------------. |
.->| Congestion Control |-------+ | Receiver NACK | |
| `---------------------' | | Repair Process | |
| .---------------------. | | .------------------. | |
| | |-------' | | NACK Initiation | | |
| | FEC |-----. | `------------------' | |
| | |--. | | .------------------. | |
| `---------------------' | | | | NACK Content | | |
| .---------------------. | | | `------------------' | |
`--| RTT Collection |--|--+---->| .------------------. | |
| |--+ | | | NACK Suppression | | |
`---------------------' | | | `------------------' | |
.---------------------. | | `----------------------' |
| Group Size Est. |--|--' | .-----------------. |
| |--+ | | Intermediate | |
`---------------------' | | | System Assist | |
.---------------------. | v `-----------------' |
| Other | | .-------------------------. |
`---------------------' `------->| Sender NACK Processing |--'
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |-------+-->| Sender Transmission |<---.
`---------------------' | `-----------------------' |
.---------------------. | | .------------------. |
| Data Identification |-------+ | | Rcvr Join Policy | |
`---------------------' | V `------------------' |
.---------------------. | .----------------------. |
.->| Congestion Control |-------+ | Receiver NACK | |
| `---------------------' | | Repair Process | |
| .---------------------. | | .------------------. | |
| | |-------' | | NACK Initiation | | |
| | FEC |-----. | `------------------' | |
| | |--. | | .------------------. | |
| `---------------------' | | | | NACK Content | | |
| .---------------------. | | | `------------------' | |
`--| RTT Collection |--|--+---->| .------------------. | |
| |--+ | | | NACK Suppression | | |
`---------------------' | | | `------------------' | |
.---------------------. | | `----------------------' |
| Group Size Est. |--|--' | .-----------------. |
| |--+ | | Intermediate | |
`---------------------' | | | System Assist | |
.---------------------. | v `-----------------' |
| Other | | .-------------------------. |
`---------------------' `------->| Sender NACK Processing |--'
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Figure 1: NACK-Based Reliable Multicast Building Block Framework
图1：基于NACK的可靠多播构建块框架
Reliable multicast senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of the FEC Building Block [RFC5052]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), the sender transmission rate SHALL be controlled
可靠的多播发送方将向多播会话传输数据内容。数据内容将取决于应用程序。发送方将以应用程序和/或网络架构要求确定的速率和消息大小传输数据内容。发送方传输的任何FEC编码应符合FEC构建块[RFC5052]的指南。当需要拥塞控制机制（一般互联网操作所需）时，应控制发送方传输速率
by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from multicast senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
通过拥塞控制机制。在任何情况下，建议来自多播发送方的所有数据传输受到应用程序或拥塞控制算法确定的速率限制。发送方的传输应充分利用可用容量（可能受到应用程序和/或拥塞控制的限制）。因此，预计新数据内容传输将与修复内容重叠和复用。与应用程序操作相关的其他因素可能决定发送方传输格式和方法。例如，当发送方没有数据传输时，需要考虑发送方在间歇空闲期间的行为。
In addition to data content, other sender messages or commands may be employed as part of protocol operation. These messages may occur outside of the scope of application data transfer. In NACK-based reliable multicast protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require, following the rules of the NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK responses from the receivers to this command.
除了数据内容之外，还可以使用其他发送方消息或命令作为协议操作的一部分。这些消息可能发生在应用程序数据传输范围之外。在基于NACK的可靠多播协议中，当由于组大小可伸缩性问题而禁止肯定确认时，可通过冗余传输来尝试此类协议消息的可靠性。请注意，协议设计应提供处理组未收到此类消息的情况的机制。例如，命令消息可能由发送方冗余传输，以指示其暂时（或永久）停止传输。此时，根据NACK程序的规则，接收者可能适合就其所需的任何未完成维修向NACK作出响应。为了提高效率，发送方应在冗余传输之间留出足够的时间，以接收来自接收方对该命令的任何NACK响应。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NACK-based reliable multicast protocol timeouts should be dependent upon the group greatest round-trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The sender GRTT is an estimate of the worst-case round-trip timing from a given sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to a given sender. NACK-based reliable multicast instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
通常，当存在任何结果NACK或其他反馈操作时，发送方发出的控制消息的冗余传输的定时和其他基于NACK的可靠多播协议超时应取决于组最大往返定时（GRTT）估计和任何预期结果NACK或其他反馈操作。发送方GRTT是对从给定发送方到组中任何接收方的最坏情况下往返时间的估计。假定GRTT间隔是跨网络拓扑的多播组相对于给定发送方的最大跨度（相对于延迟）的保守估计。基于NACK的可靠多播实例化应该能够动态地适应广泛的多播网络拓扑。
Inputs:
投入：
1. Application data and control.
1. 应用程序数据和控制。
2. Sender node identifier.
2. 发送方节点标识符。
3. Data identifiers.
3. 数据标识符。
4. Segmentation and FEC parameters.
4. 分割和FEC参数。
5. Transmission rate.
5. 传输速率。
6. Application controls.
6. 应用程序控件。
7. Receiver feedback messages (e.g., NACKs).
7. 接收器反馈信息（例如，NACK）。
Outputs:
产出：
1. Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the reliable multicast session.
1. 消息的受控传输，消息头唯一标识可靠多播会话上下文中的数据或修复内容。
2. Commands indicating sender's status or other transport control actions to be taken.
2. 指示发送方状态或要采取的其他传输控制操作的命令。
A critical component of NACK-based reliable multicast protocols is the NACK repair process. This includes both the receiver's role in detecting and requesting repair needs and the sender's response to such requests. There are four primary elements of the NACK repair process:
基于NACK的可靠多播协议的一个关键组件是NACK修复过程。这包括接收方在检测和请求维修需求方面的作用以及发送方对此类请求的响应。NACK维修流程有四个主要要素：
1. Receiver NACK process initiation,
1. 接收器NACK进程启动，
2. NACK suppression,
2. NACK抑制，
3. NACK message content,
3. NACK消息内容，
4. Sender NACK processing and repair response.
4. 发送方NACK处理和修复响应。
The NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the sender data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
NACK过程（周期）将由检测到需要修复来自特定发送方的传输以实现可靠接收的接收器启动。当应用FEC时，仅当已知其修复需求超过数据内容的给定编码块的未决FEC传输量时，接收机才应启动NACK过程。这可以在当前传输块结束时（如果指示）或在开始接收后续编码块或传输对象时确定。这意味着对发送方数据内容进行标记以识别其FEC块号，并按照传输顺序保留顺序关系。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK process earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events, such as at the end-of-transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
或者，如果发送方的传输播发它已经计划为块发送的修复分组的数量，则接收机可能能够更早地发起NACK过程。允许接收机在检测到其维修需求已超过待维修传输的任何时候启动NACK周期，可能会导致维修周期稍微加快。然而，将NACK处理发起限制到特定事件可能是有用的，例如在FEC编码块的传输结束时或在检测到后续编码块时。这可以允许接收机将NACK内容聚合成更小数量的NACK消息，并在接收机集合之间提供一些隐式的松散同步，以帮助促进对NACK反馈的有效概率抑制。接收方必须保存从发送方收到的数据内容的历史记录，以确定其当前的修复需求。当采用FEC时，预期历史将对应于挂起或部分接收的编码块的记录。
For probabilistic, timer-based suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
对于基于定时器的概率反馈抑制，NACK周期应从接收机观察退避超时开始。在启动该退避超时的同时，接收机记录其启动NACK循环的发送方传输序列中的位置非常重要。当抑制退避超时结束时，接收机在做出发送或抑制NACK的决定时，应该只考虑到其所需的传输位置直到所记录的传输位置。在没有该限制的情况下，当NACK消息通过网络传播到发送方和其他接收方期间从发送方接收到额外内容时，抑制被大大降低。
Inputs:
投入：
1. Sender data content with sequencing identifiers from sender transmissions.
1. 发送方数据内容，带有来自发送方传输的序列标识符。
2. History of content received from sender.
2. 从发件人接收的内容的历史记录。
Outputs:
产出：
1. NACK process initiation decision.
1. NACK进程启动决策。
2. Recorded sender transmission sequence position.
2. 记录发送器传输顺序位置。
An effective feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [SrmFramework]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have
一种有效的反馈抑制机制是在需要修复的接收机进行NACK传输之前使用随机退避超时[SRM框架]。退避超时到期后，接收方将请求修复，除非其待修复需求已得到满足
been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or by providing some other indicator of the repair information it will be subsequently transmitting.
已被从其他接收器（当接收器为多播NACK时）或从发送方的某个指示器听到的NACK消息完全取代。当接收机单播NACK消息时，发送方可通过将其已接收到的NACK内容的表示转发给整个组或通过提供其随后将要发送的修复信息的一些其他指示符来促进NACK抑制。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [McastFeedback]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of the sender's GRTT assessment and a group size estimate that is either determined by other mechanisms within the protocol or is preset by the multicast application.
为了有效且可扩展的抑制性能，接收机使用的退避超时时间应由具有截断指数分布的接收机独立随机选取[MCASTFEEDING]。这导致在假设较小数量的“早期nacker”将取代组中其余部分的修复需求的情况下，大多数接收机组延迟NACK消息的传输。分布的平均值应根据发送方的GRTT评估的当前估计值和由协议内的其他机制确定或由多播应用程序预设的组大小估计值来确定。
A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers ("R") potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g., NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout ("T_maxBackoff") can be set to control reliable delivery latency versus volume of feedback traffic. A larger value of "T_maxBackoff" will result in a lower density of feedback traffic for a given repair cycle. A smaller value of "T_maxBackoff" results in shorter latency, which also reduces the buffering requirements of senders and receivers for reliable transport.
可以构造一个简单的算法来生成具有适当分布的随机退避超时。此外，该算法可被设计为在给定可能产生反馈的接收器（“R”）的数量的情况下优化退避分布。这种“优化”使所有接收机生成NACK的最坏情况下的反馈消息（例如，NACK）的数量最小化。可以设置最大退避超时（“T_maxBackoff”），以控制可靠的传递延迟与反馈通信量。较大的“T_maxBackoff”值将导致给定维修周期的反馈流量密度较低。“T_maxBackoff”的值越小，延迟越短，这也降低了发送方和接收方对可靠传输的缓冲要求。
In the functions below, the "log()" function specified refers to the "natural logarithm" and the "exp()" function is similarly based upon the mathematical constant 'e' (a.k.a. Euler's number) where "exp(x)" corresponds to '"e"' raised to the power of '"x"'. Given the receiver group size ("groupSize") and maximum allowed backoff timeout ("T_maxBackoff"), random backoff timeouts ("t'") with a truncated exponential distribution can be picked with the following algorithm:
在下面的函数中，指定的“log（）”函数指的是“自然对数”，而“exp（）”函数类似地基于数学常数“e”（也称为欧拉数），其中“exp（x）”对应于“e”，并提升为“x”的幂。给定接收器组大小（“groupSize”）和最大允许退避超时（“T_maxBackoff”），可以使用以下算法选择具有截断指数分布的随机退避超时（“T”）：
1. Establish an optimal mean ("L") for the exponential backoff based on the "groupSize":
1. 根据“组大小”确定指数退避的最佳平均值（“L”）：
L = log(groupSize) + 1
L = log(groupSize) + 1
2. Pick a random number ("x") from a uniform distribution over a range of:
2. 从以下范围内的均匀分布中选择一个随机数（“x”）：
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
3. Transform this random variate to generate the desired random backoff time ("t'") with the following equation:
3. 使用以下等式转换此随机变量以生成所需的随机退避时间（“t”）：
t' = T_maxBackoff/L * log(x * (exp(L) - 1) * (T_maxBackoff/L))
t' = T_maxBackoff/L * log(x * (exp(L) - 1) * (T_maxBackoff/L))
This "C" language function can be used to generate an appropriate random backoff time interval:
此“C”语言函数可用于生成适当的随机退避时间间隔：
double RandomBackoff(double T_maxBackoff, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/T_maxBackoff) +
lambda / (T_maxBackoff*(exp(lambda)-1));
return ((T_maxBackoff/lambda) *
log(x*(exp(lambda)-1)*(T_maxBackoff/lambda)));
} // end RandomBackoff()
double RandomBackoff(double T_maxBackoff, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/T_maxBackoff) +
lambda / (T_maxBackoff*(exp(lambda)-1));
return ((T_maxBackoff/lambda) *
log(x*(exp(lambda)-1)*(T_maxBackoff/lambda)));
} // end RandomBackoff()
where "UniformRand(double max)" returns random numbers with a uniform distribution from the range of "0..max". For example, based on the POSIX "rand()" function, the following "C" code can be used:
其中“UniformRand（double max）”返回均匀分布在“0..max”范围内的随机数。例如，基于POSIX“rand（）”函数，可以使用以下“C”代码：
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
The number of expected NACK messages generated ("N") within the first round-trip time for a single feedback event is approximately:
在单个反馈事件的第一个往返时间内生成的预期NACK消息（“N”）数量约为：
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
Thus, the maximum backoff time can be adjusted to trade off worst-case NACK feedback volume versus latency. This is derived from the equations given in [McastFeedback] and assumes "T_maxBackoff >= GRTT", and "L" is the mean of the distribution optimized for the given group size as shown in the algorithm above. Note that other mechanisms within the protocol may work to reduce redundant NACK generation further. It is suggested that "T_maxBackoff" be selected as an integer multiple of the sender's current advertised GRTT estimate such that: T_maxBackoff = K * GRTT; where K >= 1
因此，可以调整最大退避时间，以权衡最坏情况下的NACK反馈量与延迟。这是从[McastFeedback]中给出的方程推导出来的，并假设“T_maxBackoff>=GRTT”，“L”是针对上述算法中所示的给定组大小优化的分布平均值。注意，协议内的其他机制可用于进一步减少冗余NACK生成。建议选择“T_maxBackoff”作为发送方当前公布的GRTT估计值的整数倍，即：T_maxBackoff=K*GRTT；其中K>=1
For general Internet operation, a default value of "K=4" is RECOMMENDED for operation with multicast (to the group at large) NACK delivery; a value of "K=6" is the RECOMMENDED default for unicast NACK delivery. Alternate values may be used to achieve desired buffer utilization, reliable delivery latency, and group size scalability trade-offs.
对于一般的互联网操作，对于多播（对整个组）NACK交付的操作，建议使用默认值“K=4”；对于单播NACK传递，建议默认值为“K=6”。备选值可用于实现所需的缓冲区利用率、可靠的传递延迟和组大小可伸缩性权衡。
Given that ("K*GRTT") is the maximum backoff time used by the receivers to initiate NACK transmission, other timeout periods related to the NACK repair process can be scaled accordingly. One of those timeouts is the amount of time a receiver should wait after generating a NACK message before allowing itself to initiate another NACK backoff/transmission cycle ("T_rcvrHoldoff"). This delay should be sufficient for the sender to respond to the received NACK with repair messages. An appropriate value depends upon the amount of time for the NACK to reach the sender and the sender to provide a repair response. This MUST include any amount of sender NACK aggregation period during which possible multiple NACKs are accumulated to determine an efficient repair response. These timeouts are further discussed in Section 3.2.4.
假设（“K*GRTT”）是接收机用于发起NACK传输的最大退避时间，则与NACK修复过程相关的其他超时时间可以相应地缩放。其中一个超时是在生成NACK消息之后，接收机在允许自己启动另一个NACK退避/传输周期（“T_rcvrHoldoff”）之前应等待的时间量。此延迟应足以使发送方通过修复消息响应接收到的NACK。适当的值取决于NACK到达发送方和发送方提供修复响应的时间量。这必须包括任何数量的发送方NACK聚合期，在此期间可能会累积多个NACK以确定有效的修复响应。第3.2.4节将进一步讨论这些超时。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
还有一些辅助措施可用于改善反馈抑制的性能。例如，发送方的数据内容传输可以遵循顺序传输序列。当对数据内容进行修复时，接收机可以通过观察数据对象、FEC块号和FEC符号标识符来注意到发送方已经“重绕”了其数据内容传输位置。接收方应将NACK的传输限制为仅当发送方的当前传输位置超过接收方接收不完全的点时。这减少了发送方可能计划为响应其他接收方请求而提供的数据修复过早请求。当来自其他接收器（或来自发送方的指示符）的nack的传输丢失时，该机制对于高丢失条件下的协议收敛非常有效。另一种机制（当使用FEC时特别适用）用于发送方在当前发送的分组中嵌入即将进行的修复传输的指示。例如，该指示可以简单到为当前适用编码块发送的FEC分组的数量的广告。
Finally, some consideration might be given to using the NACKing history of receivers to bias their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not always be present in multicast networks. This adjustment of backoff timeout selection may
最后，可以考虑使用接收机的NACK历史来偏置其NACK退避超时间隔的选择。例如，如果一个接收器在历史上经历了最大程度的损失，那么它可能会比其他接收器更快地将自己提升到统计上的NACK。注：这需要在接收机所经历的损失的连续时间间隔内进行相关。这种相关性在多播网络中可能并不总是存在。这种退避超时选择的调整可能会
require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process that may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network.
需要为这些历史珍珠创建“早期珍珠”槽。NACK退避窗口中的这一额外插槽将导致更长的维修周期，这对于某些应用来说可能是不可取的。这些权衡的解决方案可能取决于协议的目标应用程序集或网络。
After the random backoff timeout has expired, the receiver will make a decision on whether to generate a NACK repair request or not (i.e., it has been suppressed). The NACK will be suppressed when any of the following conditions has occurred:
在随机退避超时过期之后，接收器将决定是否生成NACK修复请求（即，它已被抑制）。当出现以下任一情况时，NACK将被抑制：
1. The accumulated state of NACKs heard from other receivers (or forwarding of this state by the sender) is equal to or supersedes the repair needs of the local receiver. Note that the local receiver should consider its repair needs only up to the sender transmission position recorded at the NACK cycle initiation (when the backoff timer was activated).
1. 从其他接收者听到的nack的累积状态（或发送者转发此状态）等于或取代本地接收者的修复需求。注意，本地接收器应该只考虑到在NACK周期启动时记录的发送器发送位置（当激活退避定时器时）。
2. The sender's data content transmission position "rewinds" to a point ordinally less than that of the lowest sequence position of the local receiver's repair needs. (This detection of sender "rewind" indicates the sender has already responded to other receiver repair needs of which the local receiver may not have been aware). This "rewind" event can occur any time between 1) when the NACK cycle was initiated with the backoff timeout activation and 2) the current moment when the backoff timeout has expired to suppress the NACK. Another NACK cycle must be initiated by the receiver when the sender's transmission sequence position exceeds the receiver's lowest ordinal repair point. Note it is possible that the local receiver may have had its repair needs satisfied as a result of the sender's response to the repair needs of other receivers and no further NACKing is required.
2. 发送方的数据内容传输位置“倒回”到一个点，该点顺序小于本地接收方修复需求的最低序列位置。（检测到发送方“倒带”表明发送方已经响应了本地接收方可能不知道的其他接收方维修需求）。该“倒带”事件可以在1）通过退避超时激活启动NACK循环和2）退避超时过期以抑制NACK的当前时刻之间的任何时间发生。当发送方的传输序列位置超过接收方的最低顺序修复点时，接收方必须启动另一个NACK循环。注：由于发送方对其他接收方的维修需求作出响应，本地接收方可能已经满足了其维修需求，因此不需要进一步的NACK。
If these conditions have not occurred and the receiver still has pending repair needs, a NACK message is generated and transmitted. The NACK should consist of an accumulation of repair needs from the receiver's lowest ordinal repair point up to the current sender transmission sequence position. A single NACK message should be generated and the NACK message content should be truncated if it exceeds the payload size of single protocol message. When such NACK payload limits occur, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender.
如果这些情况尚未发生，且接收器仍有待修复需求，则生成并发送NACK消息。NACK应包括从接收器最低顺序维修点到当前发送器传输序列位置的维修需求累积。应生成单个NACK消息，如果NACK消息内容超过单个协议消息的有效负载大小，则应截断NACK消息内容。当出现此类NACK有效负载限制时，NACK内容应包含对发送方所需的通常最低修复内容的请求。
Inputs:
投入：
1. NACK process initiation decision.
1. NACK进程启动决策。
2. Recorded sender transmission sequence position.
2. 记录发送器传输顺序位置。
3. Sender GRTT.
3. 发送方：GRTT。
4. Sender group size estimate.
4. 发送方组大小估计。
5. Application-defined bound on backoff timeout period.
5. 应用程序定义的回退超时绑定。
6. NACKs from other receivers.
6. 来自其他接收器的nack。
7. Pending repair indication from sender (may be forwarded NACKs).
7. 发送方的待修复指示（可转发至NACKs）。
8. Current sender transmission sequence position.
8. 当前发送器传输顺序位置。
Outputs:
产出：
1. Yes/no decision to generate NACK message upon backoff timer expiration.
1. 是/否决定在退避计时器到期时生成NACK消息。
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NACK repair process. The identification of repair needs is dependent upon the data content identification (see Section 3.5 below). At the highest level, the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NACK-based reliable multicast can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
可靠多播接收器生成的NACK消息的内容将包括详细说明其当前修复需求的信息。具体信息取决于NACK修复过程中FEC的使用和类型。维修需求的识别取决于数据内容识别（见下文第3.5节）。在最高级别，NACK内容将标识NACK被寻址到的发送方以及发送方传输中需要修复的数据传输对象（或流）。对于所指示的传输实体，NACK内容随后将识别重构完整传输数据所需的特定FEC编码块和/或符号。该内容可以包括FEC块擦除计数和/或数据和FEC内容的丢失块或符号（段）的明确指示。还应注意，使用这里讨论的技术，可以有效地实例化基于NACK的可靠多播，而无需可靠的NACK交付。
Where FEC-based repair is used, the NACK message content will minimally need to identify the coding block(s) for which repair is needed and a count of erasures (missing packets) for the coding
在使用基于FEC的修复的情况下，NACK消息内容将最低限度地需要识别需要修复的编码块和用于编码的擦除（丢失分组）计数
block. An exact count of erasures implies the FEC algorithm is capable of repairing any loss combination within the coding block. This count may need to be adjusted for some FEC algorithms.
块擦除的精确计数意味着FEC算法能够修复编码块内的任何丢失组合。对于某些FEC算法，可能需要调整此计数。
Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually effect repair. For the most efficient repair strategy, the NACK content will need to also explicitly identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small- to medium-size block FEC codes (e.g., Reed Solomon [FecSchemes]) that are capable of providing a limited number of parity symbols per FEC coding block.
考虑到成功完成修复可能需要多轮修复，擦除计数还意味着服务器可传输的唯一FEC奇偶校验数据包的数量基本上是无限的（即，服务器将始终能够提供新的、唯一的、以前未发送的奇偶校验包，以响应对同一编码块的任何后续修复请求）。或者，发送方可以“循环”通过给定编码块的可用FEC符号集进行传输，并最终实现修复。为了实现最有效的修复策略，NACK内容还需要明确标识哪些符号（信息和/或奇偶校验）接收机需要成功地重构编码块的内容。对于能够为每个FEC编码块提供有限数量奇偶校验符号的中小型块FEC码（例如，Reed-Solomon[FEC方案]），尤其如此。
When FEC is not used as part of the repair process, or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the "(delay*bandwidth*loss)" characteristics of the network topology), the NACK content will need to contain explicit coding block and/or segment loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set.
当FEC未被用作修复过程的一部分，或者即使发送方已传输了给定编码块的所有可用奇偶校验（或者发送方缓冲传输历史的能力被网络拓扑的“（延迟*带宽*损耗）”特征所超出），协议实例化仍需提供可靠性时，NACK内容将需要包含明确的编码块和/或段丢失信息，以便发送方能够提供适当的修复分组和/或数据重传。NACK内容中的明确丢失信息也可能用于其他目的。例如，它可以用于解相关一组接收机之间的损耗特性，以帮助区分接收机集合之间的候选拥塞控制瓶颈。
When FEC is used and NACK content is designed to contain explicit repair requests, there is a strategy where the receivers can NACK for specific content that will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that the sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity symbols to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block (e.g., Reed Solomon) is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of data content to the group.
当使用FEC并且NACK内容被设计为包含明确的修复请求时，存在一种策略，其中接收机可以针对特定内容进行NACK，这将有助于促进NACK抑制和修复效率。该策略的假设是，发送方可能会耗尽其对给定编码块可用的新的、唯一的奇偶校验分组的供应，并且需要显式地重新传输一些数据或奇偶校验符号以完成可靠的传输。另一个假设是使用FEC算法，其中任何奇偶校验分组可以填充编码块内的任何擦除（例如，Reed-Solomon）。此策略的目标是最大限度地利用可用奇偶校验，并在向集团可靠传输数据内容的过程中提供最少的数据量并修复传输。
When systematic FEC codes are used, the sender transmits the data content of the coding block (and optionally some quantity of parity packets) in its initial transmission. Note that a systematic FEC coding block is considered to be logically made up of the contiguous set of source data vectors plus parity vectors for the given FEC algorithm used. For example, a systematic coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
当使用系统FEC码时，发送方在其初始传输中传输编码块的数据内容（以及可选的一些奇偶校验分组）。注意，对于所使用的给定FEC算法，系统FEC编码块被认为在逻辑上由源数据向量的连续集合加上奇偶校验向量组成。例如，为每个编码块提供64个数据符号和32个奇偶校验符号的系统编码方案将包含0到95范围内的FEC符号标识符。
Receivers then can construct NACK messages requesting sufficient content to satisfy their repair needs. For example, if the receiver has three erasures in a given received coding block, it will request transmission of the three lowest ordinal parity vectors in the coding block. In our example coding scheme from the previous paragraph, the receiver would explicitly request parity symbols 64 to 66 to fill its three erasures for the coding block. Note that if the receiver's loss for the coding block exceeds the available parity quantity (i.e., greater than 32 missing symbols in our example), the receiver will be required to construct a NACK requesting all (32) of the available parity symbols plus some additional portions of its missing data symbols in order to reconstruct the block. If this is done consistently across the receiver group, the resulting NACKs will comprise a minimal set of sender transmissions to satisfy their repair needs.
然后，接收器可以构造NACK消息，请求足够的内容以满足其修复需求。例如，如果接收机在给定的接收编码块中有三次擦除，它将请求传输编码块中的三个最低顺序奇偶校验向量。在上一段中的示例编码方案中，接收机将明确请求奇偶校验符号64到66以填充编码块的三次擦除。注意，如果接收机对编码块的丢失超过可用奇偶校验数量（即，在我们的示例中大于32个缺失符号），则接收机将被要求构造NACK，请求所有（32）可用奇偶校验符号加上其缺失数据符号的一些附加部分，以便重构块。如果在整个接收机组中一致地执行此操作，则产生的nack将包括最小的发送方传输集，以满足其修复需求。
In summary, the rule is to request the lower ordinal portion of the parity content for the FEC coding block to satisfy the erasure repair needs on the first NACK cycle. If the available number of parity symbols is insufficient, the receiver will also request the subset of ordinally highest missing data symbols to cover what the parity symbols will not fill. Note this strategy assumes FEC codes such as Reed-Solomon for which a single parity symbol can repair any erased symbol. This strategy would need minor modification to take into account the possibly limited repair capability of other FEC types. On subsequent NACK repair cycles where the receiver may receive some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender.
总之，规则是请求FEC编码块的奇偶校验内容的较低顺序部分以满足第一NACK周期上的擦除修复需要。如果奇偶校验符号的可用数量不足，则接收器还将请求顺序最高的缺失数据符号的子集，以覆盖奇偶校验符号不会填充的内容。注：该策略假设FEC代码（如Reed Solomon）的单个奇偶校验符号可以修复任何已擦除符号。该策略需要稍作修改，以考虑到其他FEC类型的维修能力可能有限。在接收机可能接收其先前请求的修复内容的一部分的后续NACK修复周期上，接收机将使用相同的策略，但仅对其尚未接收到的奇偶校验和/或数据符号集使用NACK。可选地，接收机还可以提供擦除计数，以方便发送方。
Other types of FEC schemes may require alteration to the NACK and repair strategy described here. For example, some of the large block or expandable FEC codes described in [RFC3453] may be less deterministic with respect to defining optimal repair requests by receivers or repair transmission strategies by senders. For these types of codes, it may be sufficient for receivers to NACK with an estimate of the quantity of additional FEC symbols required to
其他类型的FEC方案可能需要修改这里描述的NACK和修复策略。例如，[RFC3453]中描述的一些大块或可扩展FEC代码在定义接收机的最佳修复请求或发送方的修复传输策略方面可能不太确定。对于这些类型的码，接收机可以通过估计所需的附加FEC符号的数量来NACK
complete reliable reception and for the sender to respond accordingly. This apparent disadvantage, as compared to codes such as Reed Solomon, may be offset by the reduced computational requirements and/or ability to support large coding blocks for increased repair efficiency that these codes can offer.
完成可靠的接收，并让发送方做出相应的响应。与诸如Reed-Solomon之类的代码相比，这种明显的缺点可能被计算需求的减少和/或支持大型编码块以提高这些代码所能提供的修复效率的能力所抵消。
After receipt and accumulation of NACK messages during the aggregation period, the sender can begin transmission of fresh (previously untransmitted) parity symbols for the coding block based on the highest receiver erasure count if it has a sufficient quantity of parity symbols that were not previously transmitted. Otherwise, the sender MUST resort to transmitting the explicit set of repair vectors requested. With this approach, the sender needs to maintain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use the same consistent algorithm to express their explicit repair needs, NACK suppression among receivers is simplified over the course of multiple repair cycles. The receivers can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages.
在聚合期间接收和累积NACK消息之后，如果发送方具有足够数量的先前未发送的奇偶校验符号，则发送方可以基于最高接收方擦除计数开始为编码块发送新的（先前未发送的）奇偶校验符号。否则，发送方必须发送请求的修复向量的显式集合。使用这种方法，发送方需要在从组收到的请求上保持很少的状态，而不需要同步来自组的修复请求。由于所有接收机使用相同的一致性算法来表达其明确的修复需求，因此在多个修复周期的过程中简化了接收机之间的NACK抑制。接收机可以简单地将从其他接收机听到的NACK与它们自己计算的修复需求进行比较，以确定它们是否应该发送或抑制它们的挂起NACK消息。
The format of NACK content will depend on the protocol's data service model and the format of data content identification the protocol uses. This NACK format also depends upon the type of FEC encoding (if any) used. Figure 2 illustrates a logical, hierarchical transmission content identification scheme, denoting that the notion of objects (or streams) and/or FEC blocking is optional at the protocol instantiation's discretion. Note that the identification of objects is with respect to a given sender. It is recommended that transport data content identification is done within the context of a sender in a given session. Since the notion of session "streams" and "blocks" is optional, the framework degenerates to that of typical transport data segmentation and reassembly in its simplest form.
NACK内容的格式将取决于协议的数据服务模型和协议使用的数据内容标识格式。此NACK格式还取决于所使用的FEC编码类型（如果有）。图2说明了一个逻辑、分层传输内容标识方案，表示对象（或流）和/或FEC阻塞的概念是由协议实例化决定的可选概念。请注意，对象的标识与给定的发送者有关。建议在给定会话中的发送方上下文中进行传输数据内容标识。由于会话“流”和“块”的概念是可选的，因此该框架退化为典型的传输数据分割和重组的最简单形式。
Session_ \_ Sender_ \_ [Object/Stream(s)]_ \_ [FEC Blocks]_ \_ Symbols
会话\发送方\对象/流\ FEC块\符号
Figure 2: Reliable Multicast Data Content Identification Hierarchy
图2：可靠的多播数据内容标识层次结构
The format of NACK messages should enable the following:
NACK消息的格式应支持以下功能：
1. Identification of transport data units required to repair the received content, whether this is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1. 识别修复接收内容所需的传输数据单元，无论该内容是整个缺失对象/流（或范围）、整个FEC编码块还是符号集，
2. Simple processing for NACK aggregation and suppression,
2. NACK聚集和抑制的简单处理，
3. Inclusion of NACKs for multiple objects, FEC coding blocks, and/or symbols in a single message, and
3. 在单个消息中包含多个对象、FEC编码块和/或符号的NACK，以及
4. A reasonably compact format.
4. 一种相当紧凑的格式。
If the reliable multicast transport object/stream is identified with an <objectId> and the FEC symbol being transmitted is identified with an <fecPayloadId>, the concatenation of <objectId::fecPayloadId> comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receiver's repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
如果可靠多播传输对象/流用<objectId>标识，并且正在传输的FEC符号用<fecPayloadId>标识，则<objectId:：fecPayloadId>的串联包括用于来自给定源的符号的基本传输协议数据单元（TPDU）标识符。NACK内容可以由这些TPDU标识符的列表和/或范围组成，以建立NACK消息来描述接收机的修复需求。如果没有使用分层对象描绘或FEC块，则TPDU是发送方发送的数据符号的简单线性表示。当TPDU表示用于对象/流描绘和/或FEC阻塞的层次时，NACK内容单元可能需要标志来指示TPDU的哪个部分是适用的。例如，如果接收到的数据中缺少整个“对象”（或对象范围），则接收器不一定知道要请求修复的<sourceBlockNumbers>或<encodingsymbols>的适当范围，因此需要某种机制来请求修复（或重传）由<objectId>表示的整个单元。如果由一个或一系列<sourceBlockNumbers>表示的整个FEC编码块丢失，情况也是如此。
Inputs:
投入：
1. Sender identification.
1. 发送者标识。
2. Sender data identification.
2. 发送方数据标识。
3. Sender FEC object transmission information.
3. 发送方FEC对象传输信息。
4. Recorded sender transmission sequence position.
4. 记录发送器传输顺序位置。
5. Current sender transmission sequence position. History of repair needs for this sender.
5. 当前发送器传输顺序位置。此发件人的维修需求历史记录。
Outputs:
产出：
1. NACK message with repair requests.
1. 带有修复请求的NACK消息。
Upon reception of a repair request from a receiver in the group, the sender will initiate a repair response procedure. The sender may wish to delay transmission of repair content until it has had sufficient time to accumulate potentially multiple NACKs from the receiver set. This allows the sender to determine the most efficient repair strategy for a given transport stream/object or FEC coding block. Depending upon the approach used, some protocols may find it beneficial for the sender to provide an indicator of pending repair transmissions as part of its current transmitted message content. This can aid some NACK suppression mechanisms. The amount of time to perform this NACK aggregation should be sufficient to allow for the maximum receiver NACK backoff window (""T_maxBackoff"" from Section 3.2.2) and propagation of NACK messages from the receivers to the sender. Note the maximum transmission delay of a message from a receiver to the sender may be approximately "(1*GRTT)" in the case of very asymmetric network topology with respect to transmission delay. Thus, if the maximum receiver NACK backoff time is "T_maxBackoff = K*GRTT", the sender NACK aggregation period should be equal to at least:
在接收到来自组中接收者的维修请求后，发送者将启动维修响应程序。发送方可能希望延迟修复内容的传输，直到其有足够的时间从接收方集合累积潜在的多个nack为止。这允许发送方确定给定传输流/对象或FEC编码块的最有效修复策略。根据所使用的方法，一些协议可能会发现，发送方提供未决修复传输的指示符作为其当前传输的消息内容的一部分是有益的。这有助于某些NACK抑制机制。执行此NACK聚合的时间量应足以允许最大接收器NACK退避窗口（“T_maxBackoff”（第3.2.2节中的“T_maxBackoff”）以及NACK消息从接收器传播到发送者。注：在传输延迟方面非常不对称的网络拓扑的情况下，从接收器到发送器的消息的最大传输延迟大约为“（1*GRTT）”。因此，如果最大接收机NACK退避时间为“T_maxBackoff＝K×GRTT”，则发送方NACK聚合周期应至少等于：
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
Immediately after the sender NACK aggregation period, the sender will begin transmitting repair content determined from the aggregate NACK state and continue with any new transmission. Also, at this time, the sender should observe a "hold-off" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "hold-off" time should be:
在发送方NACK聚合周期之后，发送方将立即开始传输根据聚合NACK状态确定的修复内容，并继续任何新的传输。此外，此时，发送方应观察到一个“保持”期，其中它限制自己启动新的NACK聚合期，以允许由于对接收器组的修复响应而传播新的传输序列位置。考虑到最坏情况下的不对称性，该“延迟”时间应为：
T_sndrHoldoff = 1*GRTT
T_sndrHoldoff = 1*GRTT
Recall that the receivers will also employ a "hold-off" timeout after generating a NACK message to allow time for the sender's response. Given a sender "<T_sndrAggregate>" plus "<T_sndrHoldoff>" time of "(K+1)*GRTT", the receivers should use hold-off timeouts of:
回想一下，在生成NACK消息后，接收方还将采用“暂停”超时，以便为发送方的响应留出时间。给定发送方“<T\u sndrAggregate>”加上“<T\u sndrHoldoff>”时间（K+1）*GRTT”，接收方应使用以下延迟超时：
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
This allows for a worst-case propagation time of the receiver's NACK to the sender, the sender's aggregation time, and propagation of the sender's response back to the receiver. Additionally, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) a representation of its aggregated NACK content to the group to allow for NACK suppression when there is not multicast connectivity among the receiver set.
这允许接收机的NACK向发送方的最坏情况传播时间、发送方的聚合时间以及发送方的响应向接收机的传播。另外，在来自接收器集的单播反馈的情况下，发送方将其聚集的NACK内容的表示转发（经由多播）到组以允许在接收器集之间不存在多播连接时抑制NACK是有用的。
At the expiration of the "<T_sndrAggregate>" timeout, the sender will begin transmitting repair messages according to the accumulated content of NACKs received. There are some guidelines with regards to FEC-based repair and the ordering of the repair response from the sender that can improve reliable multicast efficiency:
在“<T_sndrAggregate>”超时过期时，发送方将根据接收到的nack的累积内容开始发送修复消息。关于基于FEC的修复以及发送方修复响应的排序，有一些准则可以提高可靠的多播效率：
When FEC is used, it is beneficial that the sender transmit previously untransmitted parity content as repair messages whenever possible. This maximizes the receiving nodes' ability to reconstruct the entire transmitted content from their individual subsets of received messages.
当使用FEC时，发送方尽可能将先前未传输的奇偶校验内容作为修复消息传输是有益的。这最大限度地提高了接收节点从其接收消息的单个子集重构整个传输内容的能力。
The transmitted object and/or stream data and repair content should be indexed with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content (e.g., ordinally lowest FEC blocks) first, the receivers can use a strategy of withholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help keep repair cycles relatively synchronized without dependence upon strict time synchronization among the sender and receivers. This also helps minimize the buffering requirements of receivers and senders and reduces redundant transmission of data to the group at large.
传输的对象和/或流数据和修复内容应以单调递增的序列号（在相当大的顺序空间内）进行索引。如果发送方首先遵守发送对最早内容（例如，顺序最低的FEC块）的修复的规程，则接收方可以使用一种策略，在发送方再次返回到对象/流传输序列中的该点之前，扣留对随后内容的修复请求。这可以提高组之间的整体消息效率，并有助于保持修复周期相对同步，而不依赖发送方和接收方之间的严格时间同步。这也有助于最小化接收器和发送器的缓冲要求，并减少向整个组的冗余数据传输。
Inputs:
投入：
1. Receiver NACK messages.
1. 接收器NACK消息。
2. Group timing information.
2. 组定时信息。
Outputs:
产出：
1. Repair messages (FEC and/or Data content retransmission).
1. 修复消息（FEC和/或数据内容重传）。
2. Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
2. 当检测到单播接收器反馈时，播发当前挂起的修复传输。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies that limit the opportunities for receivers to begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
应考虑新接收器加入一个组（可能在可靠传输已经进行的情况下）并开始请求修复的政策和程序。如果接收器连接不受限制，组成员身份的动态可能会妨碍应用程序实现其数据传输向前推进目标的能力。限制接收者开始参与NACK过程的机会的策略可用于实现期望的行为。例如，接收机仅在对象或流的逻辑部分的第一FEC块中的数据的非修复传输时才尝试从新听到的发送方可靠接收可能是有益的。发送方还可以实现限制其将从中接受NACK请求的接收方的策略，但在某些情况下，由于可伸缩性的原因，这可能是禁止的。或者，可能希望具有更宽松的传输同步策略，并依赖会话管理机制来限制可能导致某些类型的批量传输应用程序（或潜在的交互式可靠多播应用程序）中性能不佳的组动态。
Inputs:
投入：
1. Current object/stream data/repair content and sequencing identifiers from sender transmissions.
1. 来自发送方传输的当前对象/流数据/修复内容和序列标识符。
Outputs:
产出：
1. Receiver yes/no decision to begin receiving and NACKing for reliable reception of data.
1. 接收器是/否决定开始接收和呼叫以可靠接收数据。
In a NACK-based reliable multicast protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers) within the group. Receivers that send NACK messages to the group will need to identify the sender to which the NACK is intended. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field SHOULD be present in packets transmitted by reliable multicast session members.
在可能存在多个数据源的基于NACK的可靠多播协议（或其他多播协议）中，有必要提供某种机制来唯一地标识组内的源（以及可能的一些或所有接收器）。向组发送NACK消息的接收者需要识别NACK的目标发送者。基于到达的数据包源地址的标识不充分，原因有几个。这些原因包括具有多个接口的主机的路由更改，这些更改会随着时间的推移导致给定主机的不同数据包源地址，网络地址转换（NAT）或防火墙设备，或其他传输/网络桥接方法。因此，可靠多播会话成员传输的数据包中应该存在某种类型的唯一源标识符<sourceId>字段。
The data and repair content transmitted by a NACK-based reliable multicast sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/ reassembly, caching, integrated forward error correction coding, etc.) rather than being required to provide their own mechanisms for these functions at the application layer.
由基于NACK的可靠多播发送方传输的数据和修复内容需要在协议头字段中进行某种形式的标识。这种识别是为了促进可靠的NACK导向维修过程。这些标识符也将用于生成的NACK消息中。此构建块文档假定两种非常通用的数据类型，它们可能包含批量传输会话内容。一种是有限大小的静态离散对象，另一种是连续的非有限流。给定的应用程序可能希望使用这些范例中的一种或两种来可靠地多播数据内容。虽然某些应用程序可能进一步推广此模型，并提供将静态对象封装为嵌入流中的内容的机制，但在许多应用程序中，在可靠多播会话的上下文中为静态批量对象和消息提供独特的支持具有优势。这些应用程序可能包括内容缓存服务器、文件传输或具有批量内容的协作工具。然后，对这些静态对象类型有需求的应用程序可以利用传输层机制（即分段/重组、缓存、集成前向纠错编码等），而不需要在应用层为这些功能提供自己的机制。
As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-real-time message broadcasts (e.g., stock ticker) or some content types that are part of collaborative tools or other applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g., files) into one or more streams within a multicast session.
如所注意到的，一些应用可替换地希望以一个或多个非有限大小的流的形式传输批量内容。示例流包括连续的准实时消息广播（例如股票行情）或作为协作工具或其他应用程序一部分的某些内容类型。并且，如上所述，一些应用程序可能希望将其他批量内容（例如，文件）封装到多播会话内的一个或多个流中。
The components described within this building block document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast session. To support this requirement, the normal data content identification should include a field to uniquely identify the object or stream (e.g., <objectId>) within some reasonable temporal or ordinal interval. Note that it is not expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
本构建块文档中描述的组件预计将适用于这两种模型，并可能在单个多播会话中混合使用这两种类型。为支持此要求，正常数据内容标识应包括一个字段，以在某个合理的时间或顺序间隔内唯一标识对象或流（例如，<objectId>）。请注意，预计此数据内容标识不会是全局唯一的。预期在可靠多播会话内以及在发送方支持该对象或流的特定传输实例期间，对象/流标识符相对于给定发送方将是唯一的。
Since "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream
由于“批量”对象/流内容通常需要分段，因此还必须提供某种形式的分段标识。此段标识符将与任何对象或流相关
identifier that has been provided. Thus, in some cases, NACK-based reliable multicast protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC, the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Basic Schemes building block [FECSchemes] and descriptions of additional FEC schemes that may be documented later provide a standard message format for identifying FEC transmission content. NACK-based reliable multicast protocol instantiations using FEC SHOULD follow such guidelines.
已提供的标识符。因此，在某些情况下，基于NACK的可靠多播协议实例化可以并行地接收多个流和一组或多组静态对象的传输并请求修复。对于采用FEC的协议实例化，数据内容标识符的段标识部分可以包括编码块标识符<sourceBlockNumber>和用于特定数据或码块的奇偶校验符号<encodingsymbol>的标识符的逻辑级联。FEC基本方案构建块[FECSchemes]和稍后可能记录的附加FEC方案的描述提供了用于识别FEC传输内容的标准消息格式。使用FEC的基于NACK的可靠多播协议实例化应该遵循这样的准则。
Additionally, flags to determine the usage of the content identifier fields (e.g., stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations.
此外，用于确定内容标识符字段（例如，流与对象）的使用的标志可能适用。标志还可以用于数据内容标识中的其他目的。预计定义的任何标志都将取决于各个协议实例。
In summary, the following data content identification fields may be required for NACK-based reliable multicast protocol data content messages:
总之，基于NACK的可靠多播协议数据内容消息可能需要以下数据内容标识字段：
1. Source node identifier (<sourceId>).
1. 源节点标识符（<sourceId>）。
2. Object/Stream identifier (<objectId>), if applicable.
2. 对象/流标识符（<objectId>），如果适用。
3. FEC Block identifier (<sourceBlockNumber>), if applicable.
3. FEC块标识符（<sourceBlockNumber>），如果适用。
4. FEC Symbol identifier (<encodingSymbolId>).
4. FEC符号标识符（<encodingSymbolId>）。
5. Flags to differentiate interpretation of identifier fields or identifier structure that implicitly indicates usage.
5. 用于区分隐式指示用法的标识符字段或标识符结构的解释的标志。
6. Additional FEC transmission content fields per FEC Building Block.
6. 每个FEC构建块的附加FEC传输内容字段。
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data.
这些字段已被标识，因为任何生成的NACK消息都将在请求修复或重新传输数据时使用这些标识符。
Multiple forward error correction (FEC) approaches using erasure coding techniques have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [FecBroadcast], [RmFec],
已经确定了使用擦除编码技术的多个前向纠错（FEC）方法，这些方法可以为面向NACK和其他可靠多播协议[FecBroadcast]、[RmFec]的修复过程提供极大的性能增强，
[RFC3453]. NACK-based reliable multicast protocols can reap additional benefits since FEC-based repair does not generally require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NACK-based reliable multicast, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [FecHybrid]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large "delay*bandwidth" product with some nominal level of expected packet loss. While the application of FEC is not unique to NACK-based reliable multicast, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
[RFC3453]。基于NACK的可靠多播协议可以获得额外的好处，因为基于FEC的修复通常不需要在其编码块大小（以符号为单位）的范围内明确了解修复内容。在基于NACK的可靠多播中，生成的奇偶校验修复包通常仅在响应接收节点的NACK修复请求时发送。然而，在一些网络环境中，传输与常规数据符号传输复用的一些预定数量的FEC修复分组[FecHybrid]是有益的。当组大小非常大或网络连接具有较大的“延迟*带宽”乘积且具有某种标称水平的预期分组丢失时，这可以在相对较小的开销成本的情况下减少产生的NACK通信量。虽然FEC的应用并不是基于NACK的可靠多播所独有的，但这些类型的需求可能决定了适用的算法和协议方法的类型。
A specific issue related to the use of FEC with NACK-based reliable multicast is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId:: sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [RFC5052] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
与FEC与基于NACK的可靠多播的使用相关的一个特定问题是用于识别特定FEC分组适用的传输数据内容的部分的机制。预计FEC算法将基于为相应的传输数据分组块生成一组奇偶校验修复分组。由于数据内容包在传输过程中通过连接<sourceId:：objectId:：sourceBlockNumber:：EncodingSymbolicId>进行唯一标识，因此预计FEC包将以类似的方式进行标识。FEC构建块文件[RFC5052]提供了有关FEC应用和相关可靠多播协议消息标准格式的详细建议。
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case of "one-to-many" transmission, it may be that only the sender requires RTT knowledge of the GRTT and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that each receiver in the group may need knowledge of its individual RTT. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender(s) and advertise them to the group or sender(s). Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for
需要测量组成员之间的分组传播往返时间（RTT），以支持基于计时器的NACK抑制算法、发送方命令的定时或某些修复功能以及拥塞控制操作。收集的往返信息的性质取决于小组成员之间的互动类型。在“一对多”传输的情况下，可能只有发送方需要GRTT的RTT知识和/或只需要组的一部分的RTT知识。在这里，GRTT信息可以以合理可伸缩的方式收集。对于拥塞控制操作，组中的每个接收机可能需要其各自RTT的知识。在这种情况下，可以使用替代RTT收集方案，其中接收机收集关于发送方的单个RTT测量值，并将其通告给组或发送方。如果可靠的多播数据很可能会在组之间以“多对多”的方式进行交换，则可以使用其他测量技术来进行测量
increased efficiency [DelayEstimation]. In some cases, there might be absolute time synchronization available among the participating hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various NACK timeouts used by receivers.
提高效率[延迟估计]。在某些情况下，参与主机之间可能存在绝对时间同步，这可能简化RTT测量。在指定RTT（或GRTT）测量的通用建议之前，需要进一步考虑多播拥塞控制设计中的权衡。无论如何收集有关拥塞控制或其他要求的RTT信息（更具体地说是GRTT），发送方都需要向集团公布其当前GRTT估计值，以供接收方使用各种NACK超时。
The goal of this form of RTT measurement is for the sender to estimate the GRTT among the receivers who are actively participating in NACK-based reliable multicast operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
这种形式的RTT测量的目的是让发送方在积极参与基于NACK的可靠多播操作的接收方中估计GRTT。参与该过程的接收器集可以是整个组或从协议实例化内的另一机制确定的组的某个子集。以下是收集GRTT信息的方法。
The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a "<sendTime>" timestamp relative to an internal clock at the sender. Upon reception of this message, the receivers will record this "<sendTime>" timestamp and the time (referenced to their own clocks) at which it was received "<recvTime>". When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantiation specification), it will construct a "response" using the formula:
发送方使用包含相对于发送方内部时钟的“<sendTime>”时间戳的消息（独立或“背驮”其他传输）定期轮询组。收到此消息后，接收者将记录此“<sendTime>”时间戳和接收该消息的时间（参考其自己的时钟）“<recvTime>”。当接收方向发送方提供反馈时（明确地或作为其他反馈消息的一部分，具体取决于协议实例化规范），它将使用以下公式构造“响应”：
grttResponse = sendTime + (currentTime - recvTime)
grttResponse = sendTime + (currentTime - recvTime)
where the "<sendTime>" is the timestamp from the last probe message received from the source and the ("<currentTime> - <recvTime>") is the amount of time differential since that request was received until the receiver generated the response.
其中，“<sendTime>”是从源接收到的最后一条探测消息的时间戳，“<currentTime>-<recvTime>”）是自接收到该请求到接收器生成响应的时间差量。
The sender processes each receiver response by calculating a current RTT measurement for the receiver from whom the response was received using the following formula:
发送方通过使用以下公式计算接收到响应的接收方的当前RTT测量值来处理每个接收方响应：
RTT_rcvr = currentTime - grttResponse
RTT_rcvr = currentTime - grttResponse
During each periodic "GRTT" probing interval, the source keeps the peak round-trip timing measurement ("RTT_peak") from the set of responses it has received. A conservative estimate of "GRTT" is kept
在每个周期性“GRTT”探测间隔期间，震源根据其接收到的响应集保持峰值往返时间测量（“RTT_峰值”）。保留对“GRTT”的保守估计
to maximize the efficiency of redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of "GRTT" is done observing the following rules:
最大限度地提高冗余NACK抑制和修复聚合的效率。信息来源对“GRTT”的持续估计的更新遵循以下规则：
1. If a receiver's response round-trip time ("RTT_rcvr") is greater than the current "GRTT" estimate, the "GRTT" is immediately updated to this new peak value:
1. 如果接收器的响应往返时间（“RTT_rcvr”）大于当前“GRTT”估计值，“GRTT”立即更新为该新峰值：
GRTT = RTT_rcvr
GRTT = RTT_rcvr
2. At the end of the response collection period (i.e., the GRTT probe interval), if the recorded "peak" response ("RTT_peak") is less than the current GRTT estimate, the GRTT is updated to:
2. 在响应收集期结束时（即GRTT探测间隔），如果记录的“峰值”响应（“RTT_峰值”）小于当前GRTT估计值，则GRTT更新为：
GRTT = MAX(0.9*GRTT, RTT_peak)
GRTT = MAX(0.9*GRTT, RTT_peak)
3. If no feedback is received, the sender "GRTT" estimate remains unchanged.
3. 如果没有收到反馈，发送方的“GRTT”估计值保持不变。
4. At the end of the response collection period, the peak tracking value ("RTT_peak") is reset to ZERO for subsequent peak detection.
4. 在响应收集周期结束时，峰值跟踪值（“RTT_峰值”）重置为零，以进行后续峰值检测。
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current estimate of GRTT (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. GRTT collection MAY also be coupled with collection of other information for congestion control purposes.
GRTT收集周期（即探测传输周期）可以固定在组成员资格和/或网络拓扑动态预期值的顺序上。为了稳健性，在协议启动时，在稳定到较不频繁的稳态间隔之前，可以使用更快速的探测。可选地，可以开发一种算法来响应于GRTT的当前估计（或其变化）和分组丢失的估计动态地调整GRTT收集周期。当GRTT估计值稳定且不变时，探测消息的开销可以减少，但可以调整以在GRTT收集周期相对较短的变化期间更动态地跟踪。出于拥塞控制目的，GRTT收集还可以与其他信息的收集相结合。
In summary, although NACK repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not depend upon highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NACK-based reliable multicast protocols have been deployed to date. The estimate provided by the given algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
总之，尽管NACK修复周期超时基于GRTT，但应注意，协议的收敛操作并不依赖于高精度GRTT估计。目前的机制已经在仿真和基于NACK的可靠多播协议已经部署的环境中被证明是足够的。给定算法提供的估计值跟踪实际GRTT的峰值包络（包括操作系统影响以及网络延迟），即使在相对较高的连接损失情况下也是如此。稳态探测/更新间隔可能会有所不同，以适应不同环境中不同级别的预期网络动态。
In this approach, receivers send messages with timestamps to the sender. To control the volume of these receiver-generated messages, a suppression mechanism similar to that described for NACK suppression my be used. The "age" of receivers' RTT measurement should be kept by receivers and used as a metric in competing for feedback opportunities in the suppression scheme. For example, receiver who have not made any RTT measurement or whose RTT measurement has aged most should have precedence over other receivers. In turn, the sender may have limited capacity to provide an "echo" of the receiver timestamps back to the group, and it could use this RTT "age" metric to determine which receivers get precedence. The sender can determine the "GRTT" as described in 3.7.1 if it provides sender timestamps to the group. Alternatively, receivers who note their RTT is greater than the sender GRTT can compete in the feedback opportunity/suppression scheme to provide the sender and group with this information.
在这种方法中，接收者向发送者发送带有时间戳的消息。为了控制这些接收器生成的消息的数量，可以使用与NACK抑制类似的抑制机制。接收机RTT测量的“年龄”应由接收机保持，并用作在抑制方案中竞争反馈机会的度量。例如，未进行任何RTT测量或RTT测量老化最严重的接收器应优先于其他接收器。反过来，发送方可能有有限的能力向组提供接收方时间戳的“回声”，并且它可以使用该RTT“年龄”度量来确定哪些接收方获得优先权。如果发送方向组提供发送方时间戳，则发送方可确定3.7.1中所述的“GRTT”。或者，注意到其RTT大于发送方GRTT的接收方可以在反馈机会/抑制方案中竞争，以向发送方和组提供此信息。
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and senders "b" and "c", it is likely that:
对于涉及多个发送方的可靠多播会话，在真正的“多对多”基础上进行RTT测量可能有用，而不是让每个发送方独立跟踪RTT。当接收者可以基于他们在另一个发送者上拥有的RTT信息以及该另一个发送者关于感兴趣的新发送者的RTT推断出他们相对于发送者的RTT的近似值时，可以获得一些协议效率。例如，对于接收方“a”和发送方“b”和“c”，很可能：
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT with respect to a small subset of other group members and if information concerning RTT among those other group members is learned by the node during protocol operation.
如果节点可以获得关于其自身相对于其他组成员的小子集的RTT的RTT信息，并且如果节点在协议操作期间学习到关于这些其他组成员中的RTT的信息，则可以进一步细化该估计。
To facilitate deterministic protocol operation, the sender should robustly advertise its current estimation of "GRTT" to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate
为了便于确定性协议操作，发送方应向接收方集可靠地公布其当前对“GRTT”的估计。对于发送方当前运行的GRTT估计值，集团内部的共同、可靠的知识将使协议以最有效的方式进行。发送方的GRTT估计值可以通过简单地将估计值嵌入发送方发送的所有相关消息中而可靠地通告给组。通过量化（压缩）GRTT估计值，可以使其开销非常小
to a single byte of information. The following C-language functions allow this to be done over a wide range ("RTT_MIN" through "RTT_MAX") of GRTT values while maintaining a greater range of precision for small values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for "RTT_MIN" and "RTT_MAX" respectively. NACK-based reliable multicast applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
一个字节的信息。以下C语言函数允许在GRTT值的大范围（“RTT_MIN”到“RTT_MAX”）上执行此操作，同时保持较小值的较大精度范围和较大值的较小精度范围。建议“RTT_最小值”和“RTT_最大值”分别为1.0e-06秒和1000秒。基于NACK的可靠多播应用程序可能希望对发送方公布的GRTT设置一个附加的、较小的上限，以满足应用程序数据交付延迟限制，同时在某些网络环境中牺牲更大的反馈量。
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0 -
(13.0 * log(RTT_MAX/grtt)))));
}
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0 -
(13.0 * log(RTT_MAX/grtt)))));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NACK-based reliable multicast protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
请注意，此功能可用于量化1微秒至1000秒范围内的GRTT时间。当然，出于实际原因，基于NACK的可靠多播协议实现可能希望进一步限制公布的GRTT估计（例如，限制最大值）。
When NACK-based reliable multicast protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of any group size determination
当基于NACK的可靠多播协议操作包括激发来自整个组的反馈的机制（例如，拥塞控制）时，可以基于接收到的关于所使用的概率抑制机制的分布的反馈消息的数量粗略估计组大小。注意：本文档中描述的基于计时器的抑制机制不需要非常准确的组大小估计来充分执行。因此，一个粗略的估计，特别是如果保守的管理，可能就足够了。组大小也可以通过管理来确定。在没有任何集团规模确定的情况下
mechanism, a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. This conservative estimate (over-estimate) of group size in the algorithms described above will result in some added latency to the NACK repair process if the actual group size is smaller but with a guarantee of feedback implosion protection. The study of the timer-based feedback suppression mechanism described in [McastFeedback] and [NormFeedback] showed that the group size estimate need only be with an order-of-magnitude to provide effective suppression performance.
机制，考虑到预期的基于NACK的可靠多播使用的可伸缩性，建议使用默认组大小值10000来合理管理反馈。如果实际组大小较小，但有反馈内爆保护的保证，则上述算法中对组大小的保守估计（高估）将导致NACK修复过程增加一些延迟。[McastFeedback]和[NormalFeedback]中描述的基于定时器的反馈抑制机制的研究表明，组大小估计只需一个数量级即可提供有效的抑制性能。
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] or Pragmatic General Multicast Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to NACK-based reliable multicast operation to meet this requirement. The former technique has been further documented in [RFC4654] and has been successfully applied in the NACK-Oriented Reliable Multicast Protocol (NORM) [RFC3940].
一般的Internet操作需要拥塞控制，它与其他可靠的多播和TCP实例公平地共享可用的网络容量。TCP友好多播拥塞控制（TFMCC）[TfmccPaper]或实用通用多播拥塞控制（PGMCC）[PgmccPaper]技术可以应用于基于NACK的可靠多播操作，以满足这一要求。前一种技术已在[RFC4654]中进一步记录，并已成功应用于面向NACK的可靠多播协议（NORM）[RFC3940]。
NACK-based multicast protocols may benefit from general purpose intermediate system assistance. In particular, additional NACK suppression where intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NACK-based reliable multicast protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Similarly, intermediate systems could monitor receiver NACKs and provide repair transmissions on-demand in response if sufficient state on the content being transmitted was being maintained. This can reduce the latency and volume of repair transmissions when the intermediate system is associated with a network link that is particularly problematic with respect to packet loss. These types of assist functions would require intermediate system interpretation of transport data unit content identifiers and flags. NACK-based protocol designs should consider the potential for intermediate system assistance in the specification of protocol messages and operations. It is likely that intermediate systems assistance will be more pragmatic if message parsing requirements are modest and if the amount of state an intermediate system is required to maintain is relatively small.
基于NACK的多播协议可能受益于通用中间系统协助。特别是，中间系统可以在向发送方中继时聚合来自接收器的NACK内容（或过滤重复的NACK内容）的附加NACK抑制可以增强标准组大小的可伸缩性。对于使用FEC的基于NACK的可靠多播协议，中间系统可能能够过滤FEC修复消息，以根据从先前接收器NACK学习到的修复需求，向多播拓扑的不同分支提供修复内容的智能“子类别”。类似地，中间系统可以监视接收机nack，并在所传输内容保持足够状态的情况下根据需要提供修复传输。当中间系统与在分组丢失方面特别有问题的网络链路相关联时，这可以减少修复传输的延迟和容量。这些类型的辅助功能需要传输数据单元内容标识符和标志的中间系统解释。基于NACK的协议设计应考虑协议消息和操作规范中中间系统辅助的潜力。如果消息解析需求不大，并且中间系统需要维护的状态量相对较小，那么中间系统的帮助可能会更加实用。
The Multicast NACK building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed NACK-based reliable multicast protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the multicast scalability property of NACK-based protocols [RmComparison], [RmClasses] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NACK-based reliable multicast protocols can make use of reciprocal (among senders and receivers) multicast communication under the any-source multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable of scalable operation in asymmetric topologies, such as source-specific multicast (SSM) [RFC4607], where there may only be unicast routing service from the receivers to the sender(s).
多播NACK构建块适用于希望采用否定确认来实现可靠数据传输的协议。正确设计的基于NACK的可靠多播协议为应用和/或网络拓扑提供了可扩展性优势，其中，由于各种原因，禁止在基本第3层IP多播服务（例如，单播或混合单播/多播数据分发树）之上构建高阶交付基础设施。此外，基于NACK的协议[RmComparison]、[RmClasses]的多播可伸缩性属性适用于单个网络跳（例如，有线电视数据传输、卫星或其他广播通信服务）的广泛“扇出”。此外，基于“扁平”组范围多播分布的协议的简单性可为广泛的分布式服务或动态网络和应用提供优势。基于NACK的可靠多播协议可以在RFC 1112[RFC1112]中定义的任意源多播（ASM）模型下使用对等（发送方和接收方之间）多播通信，并且能够在非对称拓扑中进行可伸缩操作，例如源特定多播（SSM）[RFC4607]，其中可能只有从接收器到发送器的单播路由服务。
NACK-based reliable multicast protocol operation is compatible with transport layer forward error correction coding techniques as described in [RFC3453] and congestion control mechanisms such as those described in [TfmccPaper] and [PgmccPaper]. A principal limitation of NACK-based reliable multicast operation involves group size scalability when network capacity for receiver feedback is very limited. It is possible that, with proper protocol design, the intermediate system assistance techniques mentioned in Section 2.4 and described further in Section 3.10 can allow NACK-based approaches to scale to larger group sizes. NACK-based reliable multicast operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
基于NACK的可靠多播协议操作与[RFC3453]中描述的传输层前向纠错编码技术以及[TfmccPaper]和[PgmccPaper]中描述的拥塞控制机制兼容。基于NACK的可靠多播操作的一个主要限制是当接收反馈的网络容量非常有限时，组大小的可伸缩性。通过适当的协议设计，第2.4节中提到并在第3.10节中进一步描述的中间系统辅助技术可能允许基于NACK的方法扩展到更大的组大小。基于NACK的可靠多播操作也受实现缓冲约束的控制。建议使用大于典型点到点可靠传输（如TCP）所需的缓冲，以允许接收器组连接中存在差异，并允许实现组大小可伸缩性所需的反馈延迟。
Prior experimental work included various protocol instantiations that implemented some of the concepts described in this building block document. This includes the Pragmatic General Multicast (PGM) protocol described in [RFC3208] as well as others that were documented or deployed outside of IETF activities. While the PGM protocol specification and some other approaches encompassed many of the goals of bulk data delivery as described here, this NACK-based building block provides a more generalized framework so that different application needs can be met by different protocol
先前的实验工作包括实现本构建块文档中描述的一些概念的各种协议实例。这包括[RFC3208]中描述的实用通用多播（PGM）协议以及在IETF活动之外记录或部署的其他协议。虽然PGM协议规范和一些其他方法包含了本文所述的批量数据交付的许多目标，但这种基于NACK的构建块提供了一个更通用的框架，以便不同的协议可以满足不同的应用需求
instantiation variants. The NACK-based building block approach described here includes compatibility with the other protocol mechanisms including FEC and congestion control that are described in other IETF reliable multicast building block documents. The NACK repair process described in this document can provide performance advantages compared to PGM when both are deployed on a pure end-to-end basis without intermediate system assistance. The round-trip timing estimation described here and its use in the NACK repair process allow protocol operation to more automatically adapt to different network environments or operate within environments where connectivity is dynamic. Use of the FEC payload identification techniques described in the FEC building block [RFC5052] and specific FEC instantiations allow protocol instantiations more flexibility as FEC techniques evolve than the specific sequence number data identification scheme described in the PGM specification. Similar flexibility is expected if protocol instantiations are designed to modularly invoke (at design time, if not run-time) the appropriate congestion control building block for different application or deployment purposes.
实例化变量。这里描述的基于NACK的构建块方法包括与其他协议机制的兼容性，包括在其他IETF可靠多播构建块文档中描述的FEC和拥塞控制。与PGM相比，本文档中描述的NACK修复过程可以提供性能优势，因为两者都是在纯端到端的基础上部署的，无需中间系统协助。这里描述的往返时间估计及其在NACK修复过程中的使用允许协议操作更自动地适应不同的网络环境或在连接动态的环境中操作。使用FEC构建块[RFC5052]中描述的FEC有效载荷识别技术和特定FEC实例化，随着FEC技术的发展，协议实例化比PGM规范中描述的特定序列号数据识别方案更具灵活性。如果协议实例化设计为模块化调用（在设计时，如果不是在运行时）适当的拥塞控制构建块以用于不同的应用程序或部署目的，则可以预期类似的灵活性。
NACK-based reliable multicast protocols are expected to be subject to the same security vulnerabilities as other IP and IP multicast protocols. However, unlike point-to-point (unicast) transport protocols, it is possible that one badly behaving participant can impact the transport service experience of others in the group. For example, a malicious receiver node could intentionally transmit NACK messages to cause the sender(s) to unnecessarily transmit repairs instead of making forward progress with reliable transfer. Also, group-wise messaging to support congestion control or other aspects of protocol operation may be subject to similar vulnerabilities. Thus, it is highly RECOMMENDED that security techniques such as authentication and data integrity checks be applied for NACK-based reliable multicast deployments. Protocol instantiations using this building block MUST identify approaches to security that can be used to address these and other security considerations.
基于NACK的可靠多播协议预计会受到与其他IP和IP多播协议相同的安全漏洞的影响。但是，与点对点（单播）传输协议不同，一个行为不良的参与者可能会影响组中其他人的传输服务体验。例如，恶意接收方节点可能故意传输NACK消息，以导致发送方不必要地传输修复，而不是通过可靠传输向前推进。此外，支持拥塞控制或协议操作的其他方面的分组消息传递可能会受到类似漏洞的影响。因此，强烈建议将身份验证和数据完整性检查等安全技术应用于基于NACK的可靠多播部署。使用此构建块的协议实例化必须确定可用于解决这些和其他安全问题的安全方法。
NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK-based protocols is that of NACK replay attacks, which could prevent a multicast sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. The IETF Multicast Security (MSEC) Working Group has developed a set of recommendations in its "Multicast Extensions to the Security Architecture for the Internet Protocol" [IpsecExtensions] that can be
基于NACK的可靠多播与IP安全（IPsec）身份验证机制[RFC4301]兼容，该机制建议用于防止会话入侵和拒绝服务攻击。基于NACK的协议的一个特殊威胁是NACK重播攻击，这可能会阻止多播发送方在传输过程中向前推进。建议使用任何可针对此类重播攻击提供保护的标准IPsec机制。IETF多播安全（MSEC）工作组在其“互联网协议安全架构的多播扩展”[IpsecExtensions]中制定了一套建议，可以
applied to appropriately extend IPsec mechanisms to multicast operation. An appendix of this document specifically addresses the NACK-Oriented Reliable Multicast protocol service model. As complete support for IPsec multicast operation may potentially follow reliable multicast deployment, NACK-based reliable multicast protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. This MAY be necessary when IPsec implementations are used that do not provide multicast replay attack protection when multiple sources are present.
用于将IPsec机制适当扩展到多播操作。本文档的附录专门介绍了面向NACK的可靠多播协议服务模型。由于对IPSec多播操作的完全支持可能遵循可靠的多播部署，NACK的可靠多播协议实例化应考虑在网络层机制不可用时为其自己的NACK重放攻击保护提供支持。当使用的IPsec实现在存在多个源时不提供多播重播攻击保护时，这可能是必要的。
For NACK-based multicast deployments with large receiver groups using IPsec, approaches might be developed that use shared, common keys for receiver-originated protocol messages to maintain a practical number of IPsec Security Associations (SAs). However, such group-based authentication may not be sufficient unless the receiver population can be completely trusted. Additionally, this can make identification of badly behaving (although authenticated) receiver nodes problematic as such nodes could potentially masquerade as other receivers in the group. In deployments such as this, one SHOULD consider use of source-specific multicast (SSM) instead of any-source multicast (ASM) models of multicast operation. SSM operation can simplify security challenges in a couple of ways:
对于使用IPsec的具有大型接收方组的基于NACK的多播部署，可能会开发一些方法，使用源于接收方的协议消息的共享公共密钥来维护实际数量的IPsec安全关联（SA）。然而，除非可以完全信任接收方群体，否则这种基于组的认证可能是不够的。此外，这会使识别行为不良（尽管经过身份验证）的接收方节点成为问题，因为此类节点可能伪装为组中的其他接收方。在这样的部署中，应该考虑使用源特定组播（SSM）而不是任何组播操作的源组播（ASM）模型。SSM操作可以通过以下两种方式简化安全挑战：
1. A NACK-based protocol supporting SSM operation can eliminate direct receiver-to-receiver signaling. This dramatically reduces the number of security associations that need to be established.
1. 支持SSM操作的基于NACK的协议可以消除直接的接收机到接收机信令。这大大减少了需要建立的安全关联的数量。
2. The SSM sender(s) can provide a centralized management point for secure group operation for its respective data flow as the sender alone is required to conduct individual host authentication for each receiver when group-based authentication does not suffice or is not pragmatic to deploy.
2. SSM发送方可以为其各自的数据流提供安全组操作的集中管理点，因为当基于组的身份验证不足以或不适合部署时，需要发送方单独为每个接收方执行单独的主机身份验证。
When individual host authentication is required, then it is possible receivers could use a digital signature on the IPsec Encapsulating Security Protocol (ESP) payload as described in [RFC4359]. Either an identity-based signature system or a group-specific public key infrastructure could avoid per-receiver state at the sender(s). Additionally, implementations MUST also support policies to limit the impact of extremely or exceptionally poor-performing (due to bad behavior or otherwise) receivers upon overall group operation if this is acceptable for the relevant application.
当需要单独的主机身份验证时，接收方可以在IPsec封装安全协议（ESP）有效负载上使用数字签名，如[RFC4359]所述。基于身份的签名系统或特定于组的公钥基础结构都可以避免发送方的每个接收方状态。此外，如果相关应用程序可以接受，则实施还必须支持策略，以限制性能极差或异常差（由于不良行为或其他原因）的接收器对整个组操作的影响。
As described in Section 3.4, deployment of NACK-based reliable multicast in some network environments may require identification of group members beyond that of IP addressing. If protocol-specific security mechanisms are developed, then it is RECOMMENDED that
如第3.4节所述，在某些网络环境中部署基于NACK的可靠多播可能需要识别IP寻址以外的组成员。如果开发了特定于协议的安全机制，则建议
protocol group member identifiers are used as selectors (as defined in [RFC4301]) for the applicable security associations. When IPsec is used, it is RECOMMENDED that the protocol implementation verify that the source IP addresses of received packets are valid for the given protocol source identifier in addition to usual IPsec authentication. This would prevent a badly behaving (although authorized) member from spoofing messages from other legitimate members, provided that individual host authentication is supported.
协议组成员标识符用作适用安全关联的选择器（定义见[RFC4301]）。当使用IPsec时，建议协议实现验证除了通常的IPsec身份验证之外，所接收数据包的源IP地址对于给定的协议源标识符也是有效的。这将防止行为恶劣（尽管已授权）的成员欺骗来自其他合法成员的消息，前提是支持单个主机身份验证。
The MSEC Working Group has also developed automated group keying solutions that are applicable to NACK-based reliable multicast security. For example, to support IPsec or other security mechanisms, the Group Secure Association Key Management Protocol [RFC4535] MAY be used for automated group key management. The technique it identifies for "Group Establishment for Receive-Only Members" may be application NACK-based reliable multicast SSM operation.
MSEC工作组还开发了适用于基于NACK的可靠多播安全的自动组键控解决方案。例如，为了支持IPsec或其他安全机制，组安全关联密钥管理协议[RFC4535]可用于自动组密钥管理。它为“仅接收成员的组建立”标识的技术可以是基于应用NACK的可靠多播SSM操作。
This section lists the changes between the Experimental version of this specification, [RFC3941], and this version:
本节列出了本规范试验版本[RFC3941]与本版本之间的变化：
1. Change of title to avoid confusion with NORM Protocol specification,
1. 更改标题以避免与规范协议规范混淆，
2. Updated references to related, updated RMT Building Block documents, and
2. 更新相关参考文献，更新RMT构建块文件，以及
3. More detailed security considerations.
3. 更详细的安全考虑。
(and these are not Negative)
（这些都不是负面的）
The authors would like to thank George Gross, Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
作者要感谢George Gross、Rick Jones和Joerg Widmer对本文件的宝贵评论。作者还要感谢RMT工作组主席Roger Kermode和Lorenzo Vicisano对本规范开发的支持，以及Sally Floyd对本文件的早期投入。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[ArchConsiderations] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proc. ACM SIGCOMM, pp. 201-208, September 1990.
[主要考虑]Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”，Proc。ACM SIGCOMM，第201-208页，1990年9月。
[DelayEstimation] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[DelayEstimation]Ozdemir，V.，Muthukrishnan，S.，和I.Rhee，“可扩展的低开销网络延迟估计”，NCSU/AT&T白皮书，1999年2月。
[FECSchemes] Watson, M., "Basic Forward Error Correction (FEC) Schemes", Work in Progress, July 2008.
[FEC方案]沃森，M.，“基本前向纠错（FEC）方案”，正在进行的工作，2008年7月。
[FecBroadcast] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications Vol. Com-32, No. 6, June 1984.
[FecBroadcast]Metzner，J.，“改进的广播重传协议”，IEEE通信交易卷Com-32，第6期，1984年6月。
[FecHybrid] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE Globecomm 1998, 1998.
[FecHybrid]Gossink，D.和J.Macker，“具有信道估计的可靠多播和集成奇偶重传”，IEEE GlobeCom，1998年。
[FecSchemes] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", Work in Progress, November 2007.
[FEC方案]Lacan，J.，Roca，V.，Peltotalo，J.，和S.Peltotalo，“里德-所罗门前向纠错（FEC）方案”，正在进行的工作，2007年11月。
[IpsecExtensions] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", Work in Progress, June 2008.
[IpsecExtensions]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，正在进行的工作，2008年6月。
[McastFeedback] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", IEEE Infocom p. 964, March/April 1998.
[McastFeedback]Nonnenmacher，J.和E.Biersack，“最佳多播反馈”，IEEE Infocom p。1998年3月/4月，第964页。
[NormFeedback] Adamson, B. and J. Macker, "Quantitative Prediction of NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE MILCOM 2002, October 2002.
[NormFeedback]Adamson，B.和J.Macker，“面向NACK的可靠多播（NORM）反馈的定量预测”，IEEE MILCOM 2002，2002年10月。
[PgmccPaper] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", ACM SIGCOMM 2000, August 2000.
[PgmccPaper]Rizzo，L.，“pgmcc：一种TCP友好的单速率多播拥塞控制方案”，ACM SIGCOMM 2000，2000年8月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]Speakman，T.，Crowcroft，J.，Gemmell，J.，Farinaci，D.，Lin，S.，Leshchiner，D.，Luby，M.，Montgomery，T.，Rizzo，L.，Tweedy，A.，Bhaskar，N.，Edmonstone，R.，Sumanasekera，R.，和L.Vicisano，“PGM可靠传输协议规范”，RFC 32082001年12月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）协议”，RFC 39402004年11月。
[RFC3941] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[RFC3941]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）构建块”，RFC 39412004年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654]Widmer，J.和M.Handley，“TCP友好多播拥塞控制（TFMCC）：协议规范”，RFC 4654，2006年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RmClasses] Levine, B. and J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96) Columbus, OH, October 1996.
[RmClasses]Levine，B.和J.Garcia Luna Aceves，“可靠多播协议已知类别的比较”，Proc。网络协议国际会议（ICNP-96），俄亥俄州哥伦布，1996年10月。
[RmComparison] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", Proc. INFOCOMM San Francisco, CA, October 1993.
[RmComparison]Pingali，S.，Towsley，D.，和J.Kurose，“发送方发起和接收方发起的可靠多播协议的比较”，Proc。旧金山，CA，1993年10月。
[RmFec] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", IEEE MILCOM 1997, October 1997.
[RmFec]Macker，J.“可靠的多播传输和基于综合擦除的前向纠错”，IEEE MILCOM 1997，1997年10月。
[SrmFramework] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[SrmFramework]Floyd，S.，Jacobson，V.，McCanne，S.，Liu，C.，和L.Zhang，“用于轻量级会话和应用程序级帧的可靠多播框架”，Proc。ACM SIGCOMM，1995年8月。
[TfmccPaper] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", ACM SIGCOMM 2001, August 2001.
[TfMcPaper]Widmer，J.和M.Handley，“将基于方程的拥塞控制扩展到多播应用”，ACM SIGCOMM 2001，2001年8月。
Authors' Addresses
作者地址
Brian Adamson Naval Research Laboratory Washington, DC 20375
布莱恩·亚当森海军研究实验室华盛顿特区20375
EMail: adamson@itd.nrl.navy.mil
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
EMail: cabo@tzi.org
EMail: cabo@tzi.org
Mark Handley University College London Gower Street London, WC1E 6BT UK
马克·汉德利大学学院伦敦高尔街伦敦，WC1E 6BT英国
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
乔·麦克尔海军研究实验室华盛顿特区20375
EMail: macker@itd.nrl.navy.mil
EMail: macker@itd.nrl.navy.mil