Network Working Group B. Adamson
Request for Comments: 3940 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Network Working Group B. Adamson
Request for Comments: 3940 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
面向否定确认（NACK）的可靠多播（NORM）协议
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design.
本文档描述面向否定确认（NACK）的可靠多播（NORM）协议的消息和过程。该协议旨在通过通用IP多播路由和转发服务提供批量数据对象或流的端到端可靠传输。NORM使用选择性的、否定的确认机制来提高传输可靠性，并提供额外的协议机制，以允许在发送方和接收方之间以最小的“先验”协调进行操作。指定了一种拥塞控制方案，以允许NORM协议与传输控制协议（TCP）等其他传输协议公平共享可用网络带宽。它能够在发送方和接收方之间使用互惠多播路由，并在发送方和接收方之间使用非对称连接（可能是单播返回路径）。该协议提供了许多功能，允许不同类型的应用程序或可能的其他更高级别的传输协议以不同的方式利用其服务。该协议在设计中利用了基于FEC的修复和其他IETF可靠多播传输（RMT）构建块。
Table of Contents
目录
1. Introduction and Applicability. . . . . . . . . . . . . . . . 3
1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . 4
1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . 6
1.3. Environmental Requirements and Considerations. . . . . . 7
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7
2.1. Protocol Operation Overview. . . . . . . . . . . . . . . 9
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . 10
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . 11
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. NORM Common Message Header and Extensions. . . . . . . . 14
4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . 16
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . 16
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . 24
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . 26
4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . 43
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . 43
4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . 50
4.4. General Purpose Messages . . . . . . . . . . . . . . . . 52
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . 52
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 52
5.1. Sender Initialization and Transmission . . . . . . . . . 54
5.1.1. Object Segmentation Algorithm . . . . . . . . . . 55
5.2. Receiver Initialization and Reception. . . . . . . . . . 57
5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . 57
5.4. Sender NACK Processing and Response. . . . . . . . . . . 59
5.4.1. Sender Repair State Aggregation . . . . . . . . . 60
5.4.2. Sender FEC Repair Transmission Strategy . . . . . 61
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . 62
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . 62
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . 63
5.5.1. Greatest Round-trip Time Collection . . . . . . . 63
5.5.2. NORM Congestion Control Operation . . . . . . . . 64
5.5.3. NORM Positive Acknowledgment Procedure. . . . . . 72
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . 74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 75
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1. Normative References. . . . . . . . . . . . . . . . . . 76
10.2. Informative References. . . . . . . . . . . . . . . . . 77
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 79
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 80
1. Introduction and Applicability. . . . . . . . . . . . . . . . 3
1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . 4
1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . 6
1.3. Environmental Requirements and Considerations. . . . . . 7
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7
2.1. Protocol Operation Overview. . . . . . . . . . . . . . . 9
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . 10
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . 11
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. NORM Common Message Header and Extensions. . . . . . . . 14
4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . 16
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . 16
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . 24
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . 26
4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . 43
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . 43
4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . 50
4.4. General Purpose Messages . . . . . . . . . . . . . . . . 52
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . 52
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 52
5.1. Sender Initialization and Transmission . . . . . . . . . 54
5.1.1. Object Segmentation Algorithm . . . . . . . . . . 55
5.2. Receiver Initialization and Reception. . . . . . . . . . 57
5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . 57
5.4. Sender NACK Processing and Response. . . . . . . . . . . 59
5.4.1. Sender Repair State Aggregation . . . . . . . . . 60
5.4.2. Sender FEC Repair Transmission Strategy . . . . . 61
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . 62
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . 62
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . 63
5.5.1. Greatest Round-trip Time Collection . . . . . . . 63
5.5.2. NORM Congestion Control Operation . . . . . . . . 64
5.5.3. NORM Positive Acknowledgment Procedure. . . . . . 72
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . 74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 75
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1. Normative References. . . . . . . . . . . . . . . . . . 76
10.2. Informative References. . . . . . . . . . . . . . . . . 77
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 79
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 80
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol is designed to provide reliable transport of data from one or more sender(s) to a group of receivers over an IP multicast network. The primary design goals of NORM are to provide efficient, scalable, and robust bulk data (e.g., computer files, transmission of persistent data) transfer across possibly heterogeneous IP networks and topologies. The NORM protocol design provides support for distributed multicast session participation with minimal coordination among senders and receivers. NORM allows senders and receivers to dynamically join and leave multicast sessions at will with minimal overhead for control information and timing synchronization among participants. To accommodate this capability, NORM protocol message headers contain some common information allowing receivers to easily synchronize to senders throughout the lifetime of a reliable multicast session. NORM is designed to be self-adapting to a wide range of dynamic network conditions with little or no pre-configuration. The protocol is purposely designed to be tolerant of inaccurate timing estimations or lossy conditions that may occur in many networks including mobile and wireless. The protocol is also designed to exhibit convergence and efficient operation even in situations of heavy packet loss and large queuing or transmission delays.
面向否定确认（NACK）的可靠多播（NORM）协议旨在通过IP多播网络将数据从一个或多个发送方可靠传输到一组接收方。NORM的主要设计目标是在可能的异构IP网络和拓扑上提供高效、可扩展和健壮的批量数据（例如，计算机文件、持久数据传输）传输。NORM协议设计支持分布式多播会话参与，发送方和接收方之间的协调最小。NORM允许发送者和接收者随意动态地加入和离开多播会话，而参与者之间的控制信息和定时同步开销最小。为了适应这种能力，NORM协议消息头包含一些公共信息，允许接收方在可靠多播会话的整个生命周期内轻松地与发送方同步。NORM设计用于自适应各种动态网络条件，几乎不需要或不需要预先配置。该协议旨在容忍在许多网络（包括移动和无线网络）中可能出现的不准确的定时估计或有损情况。该协议还设计为即使在严重丢包和大排队或传输延迟的情况下也能表现出收敛性和高效运行。
This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [1]. 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 BCP 14, RFC 2119 [2].
本文件是IETF RMT工作组的产品，遵循RFC 3269[1]中提供的指南。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC 2357完全指定可靠多播传输协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
在等待此类方案可用或现有方案被证明足够时，可靠多播传输工作组（RMT）在“实验性”类别中发布此评论请求。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT的目的是，一旦满足上述条件，立即将本规范作为IETF建议的标准重新提交。
A NORM protocol instance (NormSession) is defined within the context of participants communicating connectionless (e.g., Internet Protocol (IP) or User Datagram Protocol (UDP)) packets over a network using pre-determined addresses and host port numbers. Generally, the participants exchange packets using an IP multicast group address, but unicast transport may also be established or applied as an adjunct to multicast delivery. In the case of multicast, the participating NormNodes will communicate using a common IP multicast group address and port number that has been chosen via means outside the context of the given NormSession. Other IETF data format and protocol standards exist that may be applied to describe and convey the required "a priori" information for a specific NormSession (e.g., Session Description Protocol (SDP) [7], Session Announcement Protocol (SAP) [8], etc.).
NORM协议实例（NormSession）是在参与者使用预先确定的地址和主机端口号通过网络进行无连接（例如，因特网协议（IP）或用户数据报协议（UDP））分组通信的上下文中定义的。通常，参与者使用IP多播组地址交换分组，但是单播传输也可以被建立或应用为多播传送的附件。在多播的情况下，参与多播的节点将使用公共IP多播组地址和端口号进行通信，该地址和端口号是通过给定多播会话上下文之外的方式选择的。存在其他IETF数据格式和协议标准，可用于描述和传递特定会话所需的“先验”信息（例如，会话描述协议（SDP）[7]、会话公告协议（SAP）[8]等）。
The NORM protocol design is principally driven by the assumption of a single sender transmitting bulk data content to a group of receivers. However, the protocol MAY operate with multiple senders within the context of a single NormSession. In initial implementations of this protocol, it is anticipated that multiple senders will transmit independent of one another and receivers will maintain state as necessary for each sender. However, in future versions of NORM, it is possible that some aspects of protocol operation (e.g., round-trip time collection) may provide for alternate modes allowing more efficient performance for applications requiring multiple senders.
NORM协议的设计主要是由单个发送方向一组接收方发送大量数据内容的假设驱动的。然而，该协议可以在单个会话的上下文中与多个发送者一起操作。在该协议的初始实现中，预计多个发送方将相互独立地进行传输，并且接收方将根据需要为每个发送方保持状态。然而，在NORM的未来版本中，协议操作的某些方面（例如，往返时间收集）可能会提供替代模式，以便为需要多个发送方的应用程序提供更高效的性能。
NORM provides for three types of bulk data content objects (NormObjects) to be reliably transported. These types include:
NORM提供了三种类型的批量数据内容对象（NormObjects）以可靠地传输。这些类型包括：
1) static computer memory data content (NORM_OBJECT_DATA type),
1) 静态计算机内存数据内容（标准对象数据类型），
2) computer storage files (NORM_OBJECT_FILE type), and
2) 计算机存储文件（标准对象文件类型），以及
3) non-finite streams of continuous data content (NORM_OBJECT_STREAM type).
3) 连续数据内容的非有限流（NORM_OBJECT_STREAM type）。
The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is simply to provide a "hint" to receivers in NormSessions serving multiple types of content as to what type of storage should be allocated for received content (i.e., memory or file storage). Other than that distinction, the two are identical, providing for reliable transport of finite (but potentially very large) units of content. These static data and file services are anticipated to be useful for multicast-based cache applications with the ability to reliably provide transmission of large quantities of static data. Other types of static data/file delivery services might make use of these
NORM_OBJECT_数据和NORM_OBJECT_文件之间的区别只是向服务于多种类型内容的NORM会话中的接收者提供一个“提示”，说明应为接收的内容分配何种类型的存储（即内存或文件存储）。除此之外，两者是相同的，提供了有限（但可能非常大）内容单元的可靠传输。这些静态数据和文件服务对于基于多播的缓存应用程序非常有用，能够可靠地提供大量静态数据的传输。其他类型的静态数据/文件传递服务可能会使用这些服务
transport object types, too. The use of the NORM_OBJECT_STREAM type is at the application's discretion and could be used to carry static data or file content also. The NORM reliable stream service opens up additional possibilities such as serialized reliable messaging or other unbounded, perhaps dynamically produced content. The NORM_OBJECT_STREAM provides for reliable transport analogous to that of the Transmission Control Protocol (TCP), although NORM receivers will be able to begin receiving stream content at any point in time. The applicability of this feature will depend upon the application.
传输对象类型也是如此。NORM_OBJECT_STREAM类型的使用由应用程序自行决定，也可用于传输静态数据或文件内容。NORM-reliable-stream服务提供了额外的可能性，例如序列化可靠消息传递或其他无限的、可能是动态生成的内容。NORM_OBJECT_流提供了类似于传输控制协议（TCP）的可靠传输，尽管NORM接收器能够在任何时间点开始接收流内容。此功能的适用性取决于应用程序。
The NORM protocol also allows for a small amount of "out-of-band" data (sent as NORM_INFO messages) to be attached to the data content objects transmitted by the sender. This readily-available "out-of-band" data allows multicast receivers to quickly and efficiently determine the nature of the corresponding data, file, or stream bulk content being transmitted. This allows application-level control of the receiver node's participation in the current transport activity. This also allows the protocol to be flexible with minimal pre-coordination among senders and receivers. The NORM_INFO content is designed to be atomic in that its size MUST fit into the payload portion of a single NORM message.
NORM协议还允许将少量“带外”数据（作为NORM_信息消息发送）附加到发送方发送的数据内容对象。这种随时可用的“带外”数据允许多播接收器快速有效地确定正在传输的相应数据、文件或流批量内容的性质。这允许应用程序级控制接收方节点参与当前传输活动。这也使得协议具有灵活性，发送方和接收方之间的预协调最少。NORM_INFO内容被设计为原子内容，因为它的大小必须适合单个NORM消息的有效负载部分。
NORM does _not_ provide for global or application-level identification of data content within in its message headers. Note the NORM_INFO out-of-band data mechanism could be leveraged by the application for this purpose if desired, or identification could alternatively be embedded within the data content. NORM does identify transmitted content (NormObjects) with transport identifiers that are applicable only while the sender is transmitting and/or repairing the given object. These transport data content identifiers (NormTransportIds) are assigned in a monotonically increasing fashion by each NORM sender during the course of a NormSession. Each sender maintains its NormTransportId assignments independently so that individual NormObjects may be uniquely identified during transport with the concatenation of the sender session-unique identifier (NormNodeId) and the assigned NormTransportId. The NormTransportIds are assigned from a large, but fixed, numeric space in increasing order and may be reassigned during long-lived sessions. The NORM protocol provides mechanisms so that the sender application may terminate transmission of data content and inform the group of this in an efficient manner. Other similar protocol control mechanisms (e.g., session termination, receiver synchronization, etc.) are specified so that reliable multicast application variants may construct different, complete bulk transfer communication models to meet their goals.
NORM不提供消息头中数据内容的全局或应用程序级标识。注：如果需要，应用程序可以利用NORM_INFO带外数据机制实现此目的，或者也可以在数据内容中嵌入标识。NORM使用传输标识符标识传输内容（NormObjects），传输标识符仅在发送方传输和/或修复给定对象时适用。这些传输数据内容标识符（NormTransportIds）由每个NORM发送方在NORM会话过程中以单调递增的方式分配。每个发送方独立维护其NormTransportId分配，以便在传输过程中，通过发送方会话唯一标识符（NormNodeId）和分配的NormTransportId的串联，可以唯一标识各个NormObjects。NORMTransportID是从一个较大但固定的数字空间按递增顺序分配的，并且可以在长期会话期间重新分配。NORM协议提供了一些机制，使得发送方应用程序可以终止数据内容的传输，并以有效的方式通知组。规定了其他类似的协议控制机制（例如，会话终止、接收器同步等），以便可靠的多播应用程序变体可以构造不同的、完整的批量传输通信模型以满足其目标。
To summarize, the NORM protocol provides reliable transport of different types of data content (including potentially mixed types). The senders enqueue and transmit bulk content in the form of static data or files and/or non-finite, ongoing stream types. NORM senders provide for repair transmission of data and/or FEC content in response to NACK messages received from the receiver group. Mechanisms for "out-of-band" information and other transport control mechanisms are specified for use by applications to form complete reliable multicast solutions for different purposes.
总之，NORM协议提供了不同类型数据内容（包括潜在的混合类型）的可靠传输。发送方以静态数据或文件和/或非有限的持续流类型的形式排队并传输批量内容。NORM发送方响应于从接收方组接收的NACK消息，提供数据和/或FEC内容的修复传输。指定了“带外”信息机制和其他传输控制机制，供应用程序用于形成用于不同目的的完整可靠多播解决方案。
Group communication scalability requirements lead to adaptation of negative acknowledgment (NACK) based protocol schemes when feedback for reliability is required [9]. NORM is a protocol centered around the use of selective NACKs to request repairs of missing data. NORM provides for the use of packet-level forward error correction (FEC) techniques for efficient multicast repair and optional proactive transmission robustness [10]. FEC-based repair can be used to greatly reduce the quantity of reliable multicast repair requests and repair transmissions [11] in a NACK-oriented protocol. The principal factor in NORM scalability is the volume of feedback traffic generated by the receiver set to facilitate reliability and congestion control. NORM uses probabilistic suppression of redundant feedback based on exponentially distributed random backoff timers. The performance of this type of suppression relative to other techniques is described in [12]. NORM dynamically measures the group's roundtrip timing status to set its suppression and other protocol timers. This allows NORM to scale well while maintaining reliable data delivery transport with low latency relative to the network topology over which it is operating.
当需要可靠性反馈时，组通信可伸缩性要求导致基于否定确认（NACK）的协议方案的自适应[9]。NORM是一个以使用选择性NACK请求修复丢失数据为中心的协议。NORM规定使用数据包级前向纠错（FEC）技术进行有效的多播修复和可选的主动传输鲁棒性[10]。在面向NACK的协议中，基于FEC的修复可用于大大减少可靠多播修复请求的数量和修复传输[11]。范数可伸缩性的主要因素是接收器集产生的反馈通信量，以促进可靠性和拥塞控制。NORM使用基于指数分布随机退避定时器的冗余反馈的概率抑制。[12]中描述了这种类型的抑制相对于其他技术的性能。NORM动态测量组的往返计时状态，以设置其抑制和其他协议计时器。这使得NORM能够很好地扩展，同时保持可靠的数据传输，相对于其运行的网络拓扑，延迟较低。
Feedback messages can be either multicast to the group at large or sent via unicast routing to the sender. In the case of unicast feedback, the sender "advertises" the feedback state to the group to facilitate feedback suppression. In typical Internet environments, it is expected that the NORM protocol will readily scale to group sizes on the order of tens of thousands of receivers. A study of the quantity of feedback for this type of protocol is described in [13]. NORM is able to operate with a smaller amount of feedback than a single TCP connection, even with relatively large numbers of receivers. Thus, depending upon the network topology, it is possible that NORM may scale to larger group sizes. With respect to computer resource usage, the NORM protocol does _not_ require that state be kept on all receivers in the group. NORM senders maintain state only for receivers providing explicit congestion control feedback. NORM receivers must maintain state for each active sender. This may constrain the number of simultaneous senders in some uses of NORM.
反馈消息可以多播到整个组，也可以通过单播路由发送到发送方。在单播反馈的情况下，发送者向组“播发”反馈状态以促进反馈抑制。在典型的Internet环境中，预计NORM协议将很容易扩展到数万个接收器的组大小。[13]中描述了对此类协议反馈量的研究。NORM能够以比单个TCP连接更少的反馈量运行，即使有相对较多的接收器。因此，根据网络拓扑，NORM可能扩展到更大的组大小。关于计算机资源使用，NORM协议不要求组中所有接收器保持状态。标准发送方仅为提供显式拥塞控制反馈的接收方维护状态。NORM接收方必须维护每个活动发送方的状态。这可能会限制NORM某些用途中同时发送的数量。
All of the environmental requirements and considerations that apply to the RMT NORM Building Block [4] and the RMT FEC Building Block [5] also apply to the NORM protocol.
适用于RMT规范构建块[4]和RMT FEC构建块[5]的所有环境要求和注意事项也适用于规范协议。
The NORM protocol SHALL be capable of operating in an end-to-end fashion with no assistance from intermediate systems beyond basic IP multicast group management, routing, and forwarding services. While the techniques utilized in NORM are principally applicable to "flat" end-to-end IP multicast topologies, they could also be applied in the sub-levels of hierarchical (e.g., tree-based) multicast distribution if so desired. NORM can make use of reciprocal (among senders and receivers) multicast communication under the Any-Source Multicast (ASM) model defined in RFC 1112 [3], but SHALL also be capable of scalable operation in asymmetric topologies such as Source Specific Multicast (SSM) [14] where there may only be unicast routing service from the receivers to the sender(s).
除了基本的IP多播组管理、路由和转发服务外，NORM协议应能够以端到端的方式运行，而无需中间系统的协助。虽然NORM中使用的技术主要适用于“扁平”端到端IP多播拓扑，但如果需要，它们也可以应用于分层（例如，基于树的）多播分布的子级别。NORM可在RFC 1112[3]中定义的任何源多播（ASM）模型下使用互惠（发送方和接收方之间）多播通信，但也应能够在非对称拓扑中进行可伸缩操作，如源特定多播（SSM）[14]其中可能只有从接收器到发送器的单播路由服务。
NORM is compatible with IPv4 and IPv6. Additionally, NORM may be used with networks employing Network Address Translation (NAT) providing the NAT device supports IP multicast and/or can cache UDP traffic source port numbers for remapping feedback traffic from receivers to the sender(s).
NORM与IPv4和IPv6兼容。此外，NORM可用于采用网络地址转换（NAT）的网络，前提是NAT设备支持IP多播和/或可以缓存UDP通信源端口号，以便将来自接收器的反馈通信重新映射到发送器。
A NormSession is comprised of participants (NormNodes) acting as senders and/or receivers. NORM senders transmit data content in the form of NormObjects to the session destination address and the NORM receivers attempt to reliably receive the transmitted content using negative acknowledgments to request repair. Each NormNode within a NormSession is assumed to have a preselected unique 32-bit identifier (NormNodeId). NormNodes MUST have uniquely assigned identifiers within a single NormSession to distinguish between possible multiple senders and to distinguish feedback information from different receivers. There are two reserved NormNodeId values. A value of 0x00000000 is considered an invalid NormNodeId value and a value of 0xffffffff is a "wildcard" NormNodeId. While the protocol does not preclude multiple sender nodes concurrently transmitting within the context of a single NORM session (i.e., many-to-many operation), any type of interactive coordination among NORM senders is assumed to be controlled by the application or higher protocol layer. There are some optional mechanisms specified in this document that can be leveraged for such application layer coordination.
NormSession由作为发送方和/或接收方的参与者（NormNodes）组成。NORM发送方以NormObjects的形式将数据内容发送到会话目标地址，NORM接收方尝试使用否定确认来可靠地接收发送的内容，以请求修复。假设NormSession中的每个NormNode都有一个预选的唯一32位标识符（NormNodeId）。NormNodes必须在单个NormSession中具有唯一分配的标识符，以区分可能的多个发送方，并区分来自不同接收方的反馈信息。有两个保留的NormNodeId值。0x00000000的值被视为无效的NormNodeId值，0xFFFFFF的值是“通配符”NormNodeId。虽然协议不排除在单个NORM会话（即，多对多操作）的上下文中同时传输多个发送方节点，但是NORM发送方之间的任何类型的交互协调被假定为由应用程序或更高的协议层控制。本文档中指定的一些可选机制可用于此类应用程序层协调。
As previously noted, NORM allows for reliable transmission of three different basic types of data content. The first type is NORM_OBJECT_DATA, which is used for static, persistent blocks of data content maintained in the sender's application memory storage. The second type is NORM_OBJECT_FILE, which corresponds to data stored in the sender's non-volatile file system. The NORM_OBJECT_DATA and NORM_OBJECT_FILE types both represent "NormObjects" of finite but potentially very large size. The third type of data content is NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of undefined length. This is analogous to the reliable stream service provide by TCP for unicast data transport. The format of the stream content is application-defined and may be byte or message oriented. The NORM protocol provides for "flushing" of the stream to expedite delivery or possibly enforce application message boundaries. NORM protocol implementations may offer either (or both) in-order delivery of the stream data to the receive application or out-of-order (more immediate) delivery of received segments of the stream to the receiver application. In either case, NORM sender and receiver implementations provide buffering to facilitate repair of the stream as it is transported.
如前所述，NORM允许可靠传输三种不同的基本类型的数据内容。第一种类型是NORM_OBJECT_DATA，用于在发送方的应用程序内存存储中维护静态、持久的数据内容块。第二种类型是NORM_OBJECT_FILE，它对应于存储在发送方的非易失性文件系统中的数据。NORM_OBJECT_数据和NORM_OBJECT_文件类型都表示有限但可能非常大的“NormObjects”。第三种类型的数据内容是NORM_OBJECT_STREAM，它对应于未定义长度的正在进行的传输。这类似于TCP为单播数据传输提供的可靠流服务。流内容的格式由应用程序定义，可以是字节或面向消息的。NORM协议提供流的“刷新”，以加快交付或可能强制应用程序消息边界。NORM协议实现可以向接收应用程序提供流数据的有序传递（或两者都提供），或者向接收应用程序提供流的接收段的无序（更直接）传递。在这两种情况下，NORM发送方和接收方实现都提供了缓冲，以便于在传输流时对其进行修复。
All NormObjects are logically segmented into FEC coding blocks and symbols for transmission by the sender. In NORM, an FEC encoding symbol directly corresponds to the payload of NORM_DATA messages or "segment". Note that when systematic FEC codes are used, the payload of NORM_DATA messages sent for the first portion of a FEC encoding block are source symbols (actual segments of original user data), while the remaining symbols for the block consist of parity symbols generated by FEC encoding. These parity symbols are generally sent in response to repair requests, but some number may be sent proactively at the end each encoding block to increase the robustness of transmission. When non-systematic FEC codes are used, all symbols sent consist of FEC encoding parity content. In this case, the receiver must receive a sufficient number of symbols to reconstruct (via FEC decoding) the original user data for the given block. In this document, the terms "symbol" and "segment" are used interchangeably.
所有对象在逻辑上被分割为FEC编码块和符号，以供发送方传输。在NORM中，FEC编码符号直接对应于NORM_数据消息或“段”的有效载荷。注意，当使用系统FEC码时，为FEC编码块的第一部分发送的NORM_数据消息的有效载荷是源符号（原始用户数据的实际段），而块的其余符号包括由FEC编码生成的奇偶校验符号。这些奇偶校验符号通常是响应修复请求而发送的，但是可以在每个编码块的末尾主动发送一些数字，以增加传输的健壮性。当使用非系统FEC码时，发送的所有符号都由FEC编码奇偶校验内容组成。在这种情况下，接收器必须接收足够数量的符号以（通过FEC解码）重构给定块的原始用户数据。在本文件中，术语“符号”和“段”可互换使用。
Transmitted NormObjects are temporarily yet uniquely identified within the NormSession context using the given sender's NormNodeId, NormInstanceId, and a temporary NormObjectTransportId. Depending upon the implementation, individual NORM senders may manage their NormInstanceIds independently, or a common NormInstanceId may be agreed upon for all participating nodes within a session if needed as a session identifier. NORM NormObjectTransportId data content identifiers are sender-assigned and applicable and valid only during a NormObject's actual _transport_ (i.e., for as long as the sender is transmitting and providing repair of the indicated NormObject). For
使用给定发送方的NormNodeId、NormInstanceId和临时NormObjectTransportId，在NormSession上下文中临时但唯一地标识传输的NORMObject。取决于实现，单个NORM发送者可以独立地管理其NormInstanceId，或者如果需要将公共NormInstanceId作为会话标识符，则可以为会话中的所有参与节点商定一个公共NormInstanceId。NORM NormObjectTransportId数据内容标识符是发送方指定的，仅在NormObject的实际传输期间（即，只要发送方正在传输并提供所指示NormObject的修复）才适用和有效。对于
a long-lived session, the NormObjectTransportId field can wrap and previously-used identifiers may be re-used. Note that globally unique identification of transported data content is not provided by NORM and, if required, must be managed by the NORM application. The individual segments or symbols of the NormObject are further identified with FEC payload identifiers which include coding block and symbol identifiers. These are discussed in detail later in this document.
对于一个长期会话，NormObjectTransportId字段可以包装，以前使用的标识符可以重复使用。请注意，NORM不提供传输数据内容的全局唯一标识，如果需要，必须由NORM应用程序管理。所述对象的各个段或符号进一步用FEC有效载荷标识符标识，所述FEC有效载荷标识符包括编码块和符号标识符。本文件后面将详细讨论这些问题。
A NORM sender primarily generates messages of type NORM_DATA. These messages carry original data segments or FEC symbols and repair segments/symbols for the bulk data/file or stream NormObjects being transferred. By default, redundant FEC symbols are sent only in response to receiver repair requests (NACKs) and thus normally little or no additional transmission overhead is imposed due to FEC encoding. However, the NORM implementation MAY be optionally configured to proactively transmit some amount of redundant FEC symbols along with the original content to potentially enhance performance (e.g., improved delay) at the cost of additional transmission overhead. This option may be sensible for certain network conditions and can allow for robust, asymmetric multicast (e.g., unidirectional routing, satellite, cable) [15] with reduced receiver feedback, or, in some cases, no feedback.
NORM发送方主要生成NORM_DATA类型的消息。这些消息携带原始数据段或FEC符号，以及正在传输的批量数据/文件或流对象的修复段/符号。默认情况下，冗余FEC符号仅在响应接收器修复请求（NACK）时发送，因此，由于FEC编码，通常很少或没有额外的传输开销。然而，NORM实现可以可选地被配置为主动地发送一些冗余FEC符号以及原始内容，以潜在地提高性能（例如，改进的延迟），而代价是额外的传输开销。对于某些网络条件，此选项可能是合理的，并且可以允许稳健的非对称多播（例如，单向路由、卫星、电缆）[15]，减少接收器反馈，或者在某些情况下，无反馈。
A sender message of type NORM_INFO is also defined and is used to carry OPTIONAL "out-of-band" context information for a given transport object. A single NORM_INFO message can be associated with a NormObject. Because of its atomic nature, missing NORM_INFO messages can be NACKed and repaired with a slightly lower delay process than NORM's general FEC-encoded data content. NORM_INFO may serve special purposes for some bulk transfer, reliable multicast applications where receivers join the group mid-stream and need to ascertain contextual information on the current content being transmitted. The NACK process for NORM_INFO will be described later. When the NORM_INFO message type is used, its transmission should precede transmission of any NORM_DATA message for the associated NormObject.
还定义了NORM_INFO类型的发送方消息，用于为给定传输对象提供可选的“带外”上下文信息。单个NORM_INFO消息可以与NormObject关联。由于其原子性质，丢失的NORM_INFO消息可以用比NORM的一般FEC编码数据内容稍低的延迟过程进行nacke和修复。NORM_INFO可用于某些批量传输、可靠多播应用的特殊用途，其中接收机加入组中流，并需要确定当前传输内容的上下文信息。NORM_INFO的NACK过程将在后面描述。使用NORM_信息消息类型时，其传输应先于关联NormObject的任何NORM_数据消息的传输。
The sender also generates messages of type NORM_CMD to assist in certain protocol operations such as congestion control, end-of-transmission flushing, round trip time estimation, receiver synchronization, and optional positive acknowledgment requests or application defined commands. The transmission of NORM_CMD messages from the sender is accomplished by one of three different procedures. These procedures are: single, best effort unreliable transmission of the command; repeated redundant transmissions of the command; and
发送方还生成NORM_CMD类型的消息，以协助某些协议操作，如拥塞控制、传输结束刷新、往返时间估计、接收器同步以及可选的肯定确认请求或应用程序定义的命令。来自发送方的NORM_CMD消息的传输由三个不同的过程之一完成。这些程序是：单次、尽力不可靠地传递命令；命令的重复冗余传输；和
positively-acknowledged commands. The transmission technique used for a given command depends upon the function of the command. Several core commands are defined for basic protocol operation. Additionally, implementations MAY wish to consider providing the OPTIONAL application-defined commands that can take advantage of the transmission methodologies available for commands. This allows for application-level session management mechanisms that can make use of information available to the underlying NORM protocol engine (e.g., round-trip timing, transmission rate, etc.).
肯定的命令。用于给定命令的传输技术取决于命令的功能。为基本协议操作定义了几个核心命令。此外，实现可能希望考虑提供可选的应用程序定义的命令，这些命令可以利用可用于命令的传输方法。这允许应用程序级会话管理机制，可以利用底层NORM协议引擎可用的信息（例如，往返时间、传输速率等）。
NORM receivers generate messages of type NORM_NACK or NORM_ACK in response to transmissions of data and commands from a sender. The NORM_NACK messages are generated to request repair of detected data transmission losses. Receivers generally detect losses by tracking the sequence of transmission from a sender. Sequencing information is embedded in the transmitted data packets and end-of-transmission commands from the sender. NORM_ACK messages are generated in response to certain commands transmitted by the sender. In the general (and most scalable) protocol mode, NORM_ACK messages are sent only in response to congestion control commands from the sender. The feedback volume of these congestion control NORM_ACK messages is controlled using the same timer-based probabilistic suppression techniques as for NORM_NACK messages to avoid feedback implosion. In order to meet potential application requirements for positive acknowledgment from receivers, other NORM_ACK messages are defined and available for use. All sender and receiver transmissions are subject to rate control governed by a peak transmission rate set for each participant by the application. This can be used to limit the quantity of multicast data transmitted by the group. When NORM's congestion control algorithm is enabled the rate for senders is automatically adjusted. In some networks, it may be desirable to establish minimum and maximum bounds for the rate adjustment depending upon the application even when dynamic congestion control is enabled. However, in the case of the general Internet, congestion control policy SHALL be observed that is compatible with coexistent TCP flows.
NORM接收器生成NORM_NACK或NORM_ACK类型的消息，以响应来自发送方的数据和命令传输。生成NORM_NACK消息以请求修复检测到的数据传输丢失。接收机通常通过跟踪发送方的传输序列来检测丢失。序列信息嵌入在发送的数据包和来自发送方的发送结束命令中。NORM_ACK消息是响应发送方发送的某些命令而生成的。在通用（且最具可扩展性）协议模式下，NORM_ACK消息仅在响应发送方发出的拥塞控制命令时发送。使用与NORM_NACK消息相同的基于定时器的概率抑制技术来控制这些拥塞控制NORM_ACK消息的反馈量，以避免反馈内爆。为了满足来自接收器的肯定确认的潜在应用要求，定义了其他规范确认消息并可供使用。所有发送方和接收方传输都受到由应用程序为每个参与者设置的峰值传输速率控制的速率控制。这可用于限制组传输的多播数据量。当NORM的拥塞控制算法启用时，发送方的速率将自动调整。在一些网络中，即使启用了动态拥塞控制，也可能需要根据应用为速率调整建立最小和最大界限。但是，对于通用互联网，应遵守与共存TCP流兼容的拥塞控制策略。
The operation of the NORM protocol is based primarily upon the concepts presented in the Nack-Oriented Reliable Multicast (NORM) Building Block document [4]. This includes the basic NORM architecture and the data transmission, repair, and feedback strategies discussed in that document. Additional reliable multicast building blocks are applied in creating the full NORM protocol instantiation [16]. NORM also makes use of Forward Error Correction encoding techniques for repair messaging and optional transmission robustness as described in [10]. NORM uses the FEC Payload ID as
NORM协议的操作主要基于面向Nack的可靠多播（NORM）构建块文档[4]中提出的概念。这包括该文档中讨论的基本规范体系结构和数据传输、修复和反馈策略。在创建完整的NORM协议实例化时，应用了其他可靠的多播构建块[16]。NORM还使用前向纠错编码技术来修复消息传递和可选传输健壮性，如[10]所述。NORM将FEC有效负载ID用作
specified by the FEC Building Block Document [5]. Additionally, for congestion control, this document includes a baseline congestion control mechanism (NORM-CC) based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme described in [19].
由FEC构建块文件[5]指定。此外，对于拥塞控制，本文档包括一个基于[19]中描述的TCP友好多播拥塞控制（TFMCC）方案的基线拥塞控制机制（NORM-CC）。
While the various features of NORM are designed to provide some measure of general purpose utility, it is important to emphasize the understanding that "no one size fits all" in the reliable multicast transport arena. There are numerous engineering tradeoffs involved in reliable multicast transport design and this requires an increased awareness of application and network architecture considerations. Performance requirements affecting design can include: group size, heterogeneity (e.g., capacity and/or delay), asymmetric delivery, data ordering, delivery delay, group dynamics, mobility, congestion control, and transport across low capacity connections. NORM contains various parameters to accommodate many of these differing requirements. The NORM protocol and its mechanisms MAY be applied in multicast applications outside of bulk data transfer, but there is an assumed model of bulk transfer transport service that drives the trade-offs that determine the scalability and performance described in this document.
虽然NORM的各种特性旨在提供一些通用实用性的度量，但重要的是要强调，在可靠的多播传输领域，“没有一刀切”的理解。可靠的多播传输设计涉及许多工程权衡，这需要提高对应用程序和网络体系结构考虑因素的认识。影响设计的性能要求可能包括：组大小、异构性（例如，容量和/或延迟）、不对称交付、数据订购、交付延迟、组动态、移动性、拥塞控制以及跨低容量连接的传输。NORM包含各种参数，以适应许多不同的需求。NORM协议及其机制可应用于批量数据传输之外的多播应用中，但存在一个假定的批量传输传输服务模型，该模型决定了本文档中描述的可伸缩性和性能。
The ability of NORM to provide reliable data delivery is also governed by any buffer constraints of the sender and receiver applications. NORM protocol implementations SHOULD be designed to operate with the greatest efficiency and robustness possible within application-defined buffer constraints. Buffer requirements for reliability, as always, are a function of the delay-bandwidth product of the network topology. NORM performs best when allowed more buffering resources than typical point-to-point transport protocols. This is because NORM feedback suppression is based upon randomly-delayed transmissions from the receiver set, rather than immediately transmitted feedback. There are definitive tradeoffs between buffer utilization, group size scalability, and efficiency of performance. Large buffer sizes allow the NORM protocol to perform most efficiently in large delay-bandwidth topologies and allow for longer feedback suppression backoff timeouts. This yields improved group size scalability. NORM can operate with reduced buffering but at a cost of decreased efficiency (lower relative goodput) and reduced group size scalability.
NORM提供可靠数据传输的能力也受到发送方和接收方应用程序的任何缓冲区约束的制约。NORM协议的实现应该设计为在应用程序定义的缓冲区约束内以最大的效率和健壮性运行。一如既往，对可靠性的缓冲要求是网络拓扑的延迟带宽乘积的函数。与典型的点到点传输协议相比，当允许更多的缓冲资源时，NORM的性能最佳。这是因为范数反馈抑制基于来自接收器集的随机延迟传输，而不是立即传输的反馈。缓冲区利用率、组大小可伸缩性和性能效率之间存在明确的权衡。大的缓冲区大小允许NORM协议在大延迟带宽拓扑中最有效地执行，并允许更长的反馈抑制回退超时。这提高了组大小的可伸缩性。NORM可以在减少缓冲的情况下运行，但其代价是效率降低（相对吞吐量降低）和组大小可伸缩性降低。
This Protocol Instantiation document, in conjunction with the RMT Building Block documents of [4] and [5], completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357 [17].
本协议实例化文件与[4]和[5]中的RMT构建块文件一起，完全指定了一个工作可靠的多播传输协议，该协议符合RFC 2357[17]中描述的要求。
This document specifies the following message types and mechanisms which are REQUIRED in complying NORM protocol implementations:
本文件规定了遵守规范协议实施所需的以下消息类型和机制：
+--------------------+-----------------------------------------------+
| Message Type | Purpose |
+--------------------+-----------------------------------------------+
|NORM_DATA | Sender message for application data |
| | transmission. Implementations must support |
| | at least one of the NORM_OBJECT_DATA, |
| | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM |
| | delivery services. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_DATA |
| | messages. |
+--------------------+-----------------------------------------------+
|NORM_CMD(FLUSH) | Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM_DATA |
| | transmissions. Note the use of the |
| | NORM_CMD(FLUSH) for positive acknowledgment |
| | of data receipt is OPTIONAL. |
+--------------------+-----------------------------------------------+
|NORM_CMD(SQUELCH) | Sender command to advertise its current valid |
| | repair window in response to invalid requests |
| | for repair. |
+--------------------+-----------------------------------------------+
|NORM_CMD(REPAIR_ADV)| Sender command to advertise current repair |
| | (and congestion control state) to group when |
| | unicast feedback messages are detected. Used |
| | to control/suppress excessive receiver |
| | feedback in asymmetric multicast topologies. |
+--------------------+-----------------------------------------------+
|NORM_CMD(CC) | Sender command used in collection of round |
| | trip timing and congestion control status |
| | from group (this may be OPTIONAL if |
| | alternative congestion control mechanism and |
| | round trip timing collection is used). |
+--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
+--------------------+-----------------------------------------------+
+--------------------+-----------------------------------------------+
| Message Type | Purpose |
+--------------------+-----------------------------------------------+
|NORM_DATA | Sender message for application data |
| | transmission. Implementations must support |
| | at least one of the NORM_OBJECT_DATA, |
| | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM |
| | delivery services. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_DATA |
| | messages. |
+--------------------+-----------------------------------------------+
|NORM_CMD(FLUSH) | Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM_DATA |
| | transmissions. Note the use of the |
| | NORM_CMD(FLUSH) for positive acknowledgment |
| | of data receipt is OPTIONAL. |
+--------------------+-----------------------------------------------+
|NORM_CMD(SQUELCH) | Sender command to advertise its current valid |
| | repair window in response to invalid requests |
| | for repair. |
+--------------------+-----------------------------------------------+
|NORM_CMD(REPAIR_ADV)| Sender command to advertise current repair |
| | (and congestion control state) to group when |
| | unicast feedback messages are detected. Used |
| | to control/suppress excessive receiver |
| | feedback in asymmetric multicast topologies. |
+--------------------+-----------------------------------------------+
|NORM_CMD(CC) | Sender command used in collection of round |
| | trip timing and congestion control status |
| | from group (this may be OPTIONAL if |
| | alternative congestion control mechanism and |
| | round trip timing collection is used). |
+--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
+--------------------+-----------------------------------------------+
+--------------------+-----------------------------------------------+
|NORM_ACK | Receiver message used to proactively provide |
| | feedback for congestion control purposes. |
| | Also used with the OPTIONAL NORM Positive |
| | Acknowledgment Process. |
+--------------------+-----------------------------------------------+
+--------------------+-----------------------------------------------+
|NORM_ACK | Receiver message used to proactively provide |
| | feedback for congestion control purposes. |
| | Also used with the OPTIONAL NORM Positive |
| | Acknowledgment Process. |
+--------------------+-----------------------------------------------+
This document also describes the following message types and associated mechanisms which are OPTIONAL for complying NORM protocol implementations:
本文档还描述了以下消息类型和相关机制，这些消息类型和机制对于符合规范协议的实现是可选的：
+----------------------+----------------------------------------------+
| Message Type | Purpose |
+----------------------+----------------------------------------------+
|NORM_INFO | Sender message for providing ancillary |
| | context information associated with NORM |
| | transport objects. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_INFO |
| | messages. |
+----------------------+----------------------------------------------+
|NORM_CMD(EOT) | Sender command to indicate it has reached |
| | end-of-transmission and will no longer |
| | respond to repair requests. |
+----------------------+----------------------------------------------+
|NORM_CMD(ACK_REQ) | Sender command to support application- |
| | defined, positively acknowledged commands |
| | sent outside of the context of the bulk data |
| | content being transmitted. The NORM Positive|
| | Acknowledgment Procedure associated with this|
| | message type is OPTIONAL. |
+----------------------+----------------------------------------------+
|NORM_CMD(APPLICATION) | Sender command containing application-defined|
| | commands sent outside of the context of the |
| | bulk data content being transmitted. |
+----------------------+----------------------------------------------+
|NORM_REPORT | Optional message type reserved for |
| | experimental implementations of the NORM |
| | protocol. |
+----------------------+----------------------------------------------+
+----------------------+----------------------------------------------+
| Message Type | Purpose |
+----------------------+----------------------------------------------+
|NORM_INFO | Sender message for providing ancillary |
| | context information associated with NORM |
| | transport objects. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_INFO |
| | messages. |
+----------------------+----------------------------------------------+
|NORM_CMD(EOT) | Sender command to indicate it has reached |
| | end-of-transmission and will no longer |
| | respond to repair requests. |
+----------------------+----------------------------------------------+
|NORM_CMD(ACK_REQ) | Sender command to support application- |
| | defined, positively acknowledged commands |
| | sent outside of the context of the bulk data |
| | content being transmitted. The NORM Positive|
| | Acknowledgment Procedure associated with this|
| | message type is OPTIONAL. |
+----------------------+----------------------------------------------+
|NORM_CMD(APPLICATION) | Sender command containing application-defined|
| | commands sent outside of the context of the |
| | bulk data content being transmitted. |
+----------------------+----------------------------------------------+
|NORM_REPORT | Optional message type reserved for |
| | experimental implementations of the NORM |
| | protocol. |
+----------------------+----------------------------------------------+
As mentioned in Section 2.1, there are two primary classes of NORM messages: sender messages and receiver messages. NORM_CMD, NORM_INFO, and NORM_DATA message types are generated by senders of data content, and NORM_NACK and NORM_ACK messages generated by receivers within a NormSession. An auxiliary message type of
如第2.1节所述，NORM消息有两个主要类别：发送方消息和接收方消息。NORM_CMD、NORM_INFO和NORM_数据消息类型由数据内容的发送方生成，NORM_NACK和NORM_ACK消息由NORM会话中的接收方生成。的辅助消息类型
NORM_REPORT is also provided for experimental purposes. This section describes the message formats used by the NORM protocol. These messages and their fields are referenced in the detailed functional description of the NORM protocol given in Section 5. Individual NORM messages are designed to be compatible with the MTU limitations of encapsulating Internet protocols including IPv4, IPv6, and UDP. The current NORM protocol specification assumes UDP encapsulation and leverages the transport features of UDP. The NORM messages are independent of network addresses and can be used in IPv4 and IPv6 networks.
还提供了NORM_报告用于实验目的。本节介绍NORM协议使用的消息格式。第5节中给出的NORM协议的详细功能描述中引用了这些消息及其字段。单个NORM消息设计为与封装Internet协议（包括IPv4、IPv6和UDP）的MTU限制兼容。当前的NORM协议规范采用UDP封装，并利用UDP的传输特性。NORM消息独立于网络地址，可用于IPv4和IPv6网络。
There are some common message fields contained in all NORM message types. Additionally, a header extension mechanism is defined to expand the functionality of the NORM protocol without revision to this document. All NORM protocol messages begin with a common header with information fields as follows:
所有NORM消息类型中都包含一些通用消息字段。此外，定义了一种标头扩展机制，以扩展NORM协议的功能，而无需修改本文档。所有NORM协议消息都以一个公共标头开头，其信息字段如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type | hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type | hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Common Message Header Format
标准通用消息头格式
The "version" field is a 4-bit value indicating the protocol version number. NORM implementations SHOULD ignore received messages with version numbers different from their own. This number is intended to indicate and distinguish upgrades of the protocol which may be non-interoperable. The NORM version number for this specification is 1.
“版本”字段是一个4位值，表示协议版本号。NORM实现应该忽略接收到的版本号与其自身版本号不同的消息。此编号用于指示和区分可能不可互操作的协议升级。本规范的标准版本号为1。
The message "type" field is a 4-bit value indicating the NORM protocol message type. These types are defined as follows:
消息“类型”字段是一个4位值，指示NORM协议消息类型。这些类型的定义如下：
Message Value
消息值
NORM_INFO 1 NORM_DATA 2 NORM_CMD 3 NORM_NACK 4 NORM_ACK 5 NORM_REPORT 6
定额信息1定额数据2定额指令3定额确认4定额确认5定额报告6
The 8-bit "hdr_len" field indicates the number of 32-bit words that comprise the given message's header portion. This is used to facilitate header extensions that may be applied. The presence of header extensions are implied when the "hdr_len" value is greater than the base value for the given message "type".
8位“hdr_len”字段表示组成给定消息头部分的32位字的数量。这用于促进可能应用的标题扩展。当“hdr_len”值大于给定消息“type”的基值时，表示存在标头扩展。
The "sequence" field is a 16-bit value that is set by the message originator as a monotonically increasing number incremented with each NORM message transmitted to a given destination address. A "sequence" field number space SHOULD be maintained for messages sent to the NormSession group address. This value can be monitored by receiving nodes to detect packet losses in the transmission from a sender and used in estimating raw packet loss for congestion control purposes. Note that this value is NOT used in the NORM protocol to detect missing reliable data content and does NOT identify the application data or FEC payload that may be attached. With message authentication, the "sequence" field may also be leveraged for protection from message "replay" attacks, particularly of NORM_NACK or other feedback messages. In this case, the receiver node should maintain a monotonically increasing "sequence" field space for each destination to which it transmits (this may be multiple destinations when unicast feedback is used). The size of this field is intended to be sufficient to allow detection of a reasonable range of packet loss within the delay-bandwidth product of expected network connections.
“序列”字段是一个16位的值，由消息发起者设置为一个单调递增的数字，随着发送到给定目标地址的每个NORM消息而递增。应为发送到NormSession组地址的消息保留“序列”字段编号空间。该值可由接收节点监控，以检测来自发送方的传输中的分组丢失，并用于出于拥塞控制目的估计原始分组丢失。注意，该值在NORM协议中不用于检测丢失的可靠数据内容，并且不识别可能附加的应用数据或FEC有效载荷。对于消息身份验证，“序列”字段还可用于防止消息“重播”攻击，特别是针对NORM_NACK或其他反馈消息的攻击。在这种情况下，接收器节点应为其发送到的每个目的地（当使用单播反馈时，这可能是多个目的地）保持单调递增的“序列”字段空间。该字段的大小旨在足以允许在预期网络连接的延迟带宽乘积内检测合理范围的分组丢失。
The "source_id" field is a 32-bit value identifying the node that sent the message. A participant's NORM node identifier (NormNodeId) can be set according to application needs but unique identifiers must be assigned within a single NormSession. In some cases, use of the host IP address or a hash of it can suffice, but alternative methodologies for assignment and potential collision resolution of node identifiers within a multicast session need to be considered. For example, the "source identifier" mechanism defined in the Real-Time Protocol (RTP) specification [18] may be applicable to use for NORM node identifiers. At this point in time, the protocol makes no assumptions about how these unique identifiers are actually assigned.
“source_id”字段是一个32位的值，用于标识发送消息的节点。参与者的NORM节点标识符（NormNodeId）可以根据应用程序需要设置，但必须在单个NormSession内分配唯一标识符。在某些情况下，使用主机IP地址或其散列就足够了，但是需要考虑在多播会话中分配和潜在冲突解决节点标识符的替代方法。例如，实时协议（RTP）规范[18]中定义的“源标识符”机制可适用于用于规范节点标识符。此时，协议对这些唯一标识符的实际分配方式不作任何假设。
NORM Header Extensions
范数头扩展
When header extensions are applied, they follow the message type's base header and precede any payload portion. There are two formats for header extensions, both of which begin with an 8-bit "het" (header extension type) field. One format is provided for variable-length extensions with "het" values in the range from 0 through 127. The other format is for fixed length (one 32-bit word) extensions with "het" values in the range from 128 through 255. These formats are given here:
应用头扩展时，它们位于消息类型的基本头之后，并位于任何有效负载部分之前。标头扩展有两种格式，均以8位“het”（标头扩展类型）字段开头。为“het”值在0到127范围内的可变长度扩展提供了一种格式。另一种格式用于固定长度（一个32位字）扩展名，其“het”值在128到255之间。这些格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het <=127 | hel | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Header Extension Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het <=127 | hel | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Header Extension Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Variable Length Header Extension Format
范数可变长度标题扩展格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het >=128 | reserved | Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Fixed Length (32-bit) Header Extension Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het >=128 | reserved | Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Fixed Length (32-bit) Header Extension Format
The "Header Extension Content" portion of these header extension format is defined for each header extension type defined for NORM messages. Some header extensions are defined within this document for NORM baseline FEC and congestion control operations.
这些标头扩展格式的“标头扩展内容”部分是为NORM消息定义的每个标头扩展类型定义的。本文档中定义了一些用于标准基线FEC和拥塞控制操作的报头扩展。
NORM sender messages include the NORM_DATA type, the NORM_INFO type, and the NORM_CMD type. NORM_DATA and NORM_INFO messages contain application data content while NORM_CMD messages are used for various protocol control functions.
NORM sender消息包括NORM_数据类型、NORM_信息类型和NORM_CMD类型。NORM_DATA和NORM_INFO消息包含应用程序数据内容，而NORM_CMD消息用于各种协议控制功能。
The NORM_DATA message is expected to be the predominant type transmitted by NORM senders. These messages are used to encapsulate segmented data content for objects of type NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. NORM_DATA messages may contain original or FEC-encoded application data content.
NORM_数据报文预计是NORM发送方传输的主要类型。这些消息用于封装NORM_OBJECT_data、NORM_OBJECT_FILE和NORM_OBJECT_STREAM类型的对象的分段数据内容。NORM_数据消息可能包含原始或FEC编码的应用程序数据内容。
The format of NORM_DATA messages is comprised of three logical portions: 1) a fixed-format NORM_DATA header portion, 2) a FEC Payload ID portion with a format dependent upon the FEC encoding used, and 3) a payload portion containing source or encoded application data content. Note for objects of type NORM_OBJECT_STREAM, the payload portion contains additional fields used to appropriately recover stream content. NORM implementations MAY also extend the NORM_DATA header to include a FEC Object
NORM_数据消息的格式由三个逻辑部分组成：1）固定格式NORM_数据报头部分，2）格式取决于所使用的FEC编码的FEC有效负载ID部分，以及3）包含源或编码的应用程序数据内容的有效负载部分。注意：对于NORM_OBJECT_STREAM类型的对象，有效负载部分包含用于适当恢复流内容的附加字段。NORM实现还可以扩展NORM_数据头以包括FEC对象
Transmission Information (EXT_FTI) header extension. This allows NORM receivers to automatically allocate resources and properly perform FEC decoding without the need for pre-configuration or out-of-band information.
传输信息（EXT_FTI）标题扩展。这允许NORM接收机自动分配资源并正确执行FEC解码，而无需预配置或带外信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=2| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_reserved* | payload_len* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=2| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_reserved* | payload_len* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_DATA Message Format
标准数据报文格式
*NOTE: The "payload_reserved", "payload_len" and "payload_offset" fields are present only for objects of type NORM_OBJECT_STREAM. The "payload_len" and "payload_offset" fields allow senders to arbitrarily vary the size of NORM_DATA payload segments for streams. This allows applications to flush transmitted streams as needed to meet unique streaming requirements. For objects of types NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary since the receiver can calculate the payload length and offset information from the "fec_payload_id" using the algorithm described in Section 5.1.1. The "payload_reserved" field is kept for anticipated future NORM stream control functions. When systematic FEC codes (e.g., "fec_id" = 129) are used, the "payload_len" and "payload_offset" fields contain actual length and offset values for the encapsulated application data segment for those NORM_DATA messages containing source data symbols. In NORM_DATA messages that contain parity information, these fields are not actual length or
*注意：“有效载荷\保留”、“有效载荷\长度”和“有效载荷\偏移量”字段仅适用于NORM\ U OBJECT\ U STREAM类型的对象。“有效负载长度”和“有效负载偏移”字段允许发送方任意改变流的正常数据有效负载段的大小。这允许应用程序根据需要刷新传输的流，以满足独特的流传输要求。对于NORM_OBJECT_FILE和NORM_OBJECT_DATA类型的对象，这些字段是不必要的，因为接收机可以使用第5.1.1节中描述的算法从“fec_payload_id”计算有效载荷长度和偏移信息。“payload_reserved”（有效载荷_保留）字段用于预期的未来规范流控制功能。当使用系统FEC代码（例如，“FEC_id”=129）时，“有效载荷长度”和“有效载荷偏移”字段包含包含包含源数据符号的那些标准数据消息的封装应用程序数据段的实际长度和偏移值。在包含奇偶校验信息的NORM_数据消息中，这些字段不是实际长度或长度
offset values, but instead are values computed from FEC encoding the "payload_len" and "payload_offset" fields of the _source_ data symbols of the corresponding applicable coding block.
偏移值，而是从FEC编码对应的适用编码块的源数据符号的“有效载荷长度”和“有效载荷偏移”字段计算的值。
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM Common Message Header as described in Section 4.1. The value of the NORM_DATA "type" field is 2. The NORM_DATA _base_ "hdr_len" value is 4 (32-bit words) plus the size of the "fec_payload_id" field. The "fec_payload_id" field size depends upon the FEC encoding used for the referenced NormObject. The "fec_id" field is used to indicate the FEC coding type. For example, when small block, systematic codes are used, a "fec_id" value of 129 is indicated and the size of the "fec_payload_id" is two 32-bit words. In this case the NORM_DATA base "hdr_len" value is 6. The cumulative size of any header extensions applied is added into the "hdr_len" field.
“版本”、“类型”、“hdr_len”、“序列”和“源id”字段构成第4.1节所述的标准公共消息头。NORM_数据“type”字段的值为2。NORM_DATA_base_“hdr_len”值为4（32位字）加上“fec_payload_id”字段的大小。“fec_payload_id”字段大小取决于引用对象使用的fec编码。“fec_id”字段用于指示fec编码类型。例如，当使用小块系统代码时，指示129的“fec_id”值，“fec_有效负载_id”的大小是两个32位字。在这种情况下，NORM_数据库“hdr_len”值为6。应用的任何标头扩展的累积大小将添加到“hdr_len”字段中。
The "instance_id" field contains a value generated by the sender to uniquely identify its current instance of participation in the NormSession. This allows receivers to detect when senders have perhaps left and rejoined a session in progress. When a sender (identified by its "source_id") is detected to have a new "instance_id", the NORM receivers SHOULD drop their previous state on the sender and begin reception anew.
“instance_id”字段包含发送方生成的值，用于唯一标识其当前参与会话的实例。这允许接收方检测发送方何时离开并重新加入正在进行的会话。当检测到发送方（由其“源_id”标识）具有新的“实例_id”时，NORM接收方应在发送方上放弃其先前状态并重新开始接收。
The "grtt" field contains a non-linear quantized representation of the sender's current estimate of group round-trip time (GRTT) (this is also referred to as R_max in [19]). This value is used to control timing of the NACK repair process and other aspects of protocol operation as described in this document. The algorithm for encoding and decoding this field is described in the RMT NORM Building Block document [4].
“grtt”字段包含发送方对组往返时间（grtt）的当前估计的非线性量化表示（在[19]中也称为R_max）。该值用于控制NACK修复过程的定时以及本文档中描述的协议操作的其他方面。RMT规范构建块文档[4]中描述了对该字段进行编码和解码的算法。
The "backoff" field value is used by receivers to determine the maximum backoff timer value used in the timer-based NORM NACK feedback suppression. This 4-bit field supports values from 0-15 which is multiplied by the sender GRTT to determine the maximum backoff timeout. The "backoff" field informs the receiver set of the sender's backoff factor parameter "Ksender". Recommended values and their use are described in the NORM receiver NACK procedure description in Section 5.3. The "gsize" field contains a representation of the sender's current estimate of group size. This 4-bit field can roughly represent values from ten to 500 million where the most significant bit value of 0 or 1 represents a mantissa of 1 or 5, respectively and the three least significant bits incremented by one represent a base 10 exponent (order of magnitude). For examples, a field value of "0x0" represents 1.0e+01 (10), a value of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02
接收机使用“退避”字段值来确定基于定时器的范数NACK反馈抑制中使用的最大退避定时器值。此4位字段支持0-15之间的值，该值乘以发送方GRTT以确定最大退避超时。“退避”字段通知接收方设置发送方的退避系数参数“Ksender”。第5.3节中的标准接收器NACK程序说明中描述了推荐值及其用途。“gsize”字段包含发件人当前估计的组大小的表示。这个4位字段可以大致表示1000万到5亿之间的值，其中最高有效位值0或1分别表示尾数1或5，三个最低有效位加1表示基数为10的指数（数量级）。例如，字段值“0x0”表示1.0e+01（10），“0x8”表示5.0e+01（50），“0x1”表示1.0e+02
(100), and a value of "0xf" represents 5.0e+08. For NORM feedback suppression purposes, the group size does not need to be represented with a high degree of precision. The group size may even be estimated somewhat conservatively (i.e., overestimated) to maintain low levels of feedback traffic. A default group size estimate of 10,000 ("gsize" = 0x4) is recommended for general purpose reliable multicast applications using the NORM protocol.
（100），值“0xf”表示5.0e+08。出于范数反馈抑制目的，不需要以高精度表示组大小。甚至可以稍微保守地估计组大小（即高估），以保持低水平的反馈流量。对于使用NORM协议的通用可靠多播应用程序，建议使用默认组大小估计值10000（“gsize”=0x4）。
The "flags" field contains a number of different binary flags providing information and hints regarding how the receiver should handle the identified object. Defined flags in this field include:
“flags”字段包含许多不同的二进制标志，提供有关接收方应如何处理已识别对象的信息和提示。此字段中定义的标志包括：
+--------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair |
| | | transmission |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to |
| | | meet a specific receiver erasure, as |
| | | compared to parity segments provided by |
| | | the sender for general purpose (with |
| | | respect to an FEC coding block) erasure |
| | | filling. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO for |
| | | object. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_UNRELIABLE| 0x08 | Indicates that repair transmissions for |
| | | the specified object will be unavailable|
| | | (One-shot, best effort transmission). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_FILE | 0x10 | Indicates object is "file-based" data |
| | | (hint to use disk storage for |
| | | reception). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_STREAM | 0x20 | Indicates object is of type |
| | | NORM_OBJECT_STREAM. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_MSG_START | 0x40 | Marks the first segment of application |
| | | messages embedded in |
| | | NORM_OBJECT_STREAMs. |
+--------------------+-------+-----------------------------------------+
+--------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair |
| | | transmission |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to |
| | | meet a specific receiver erasure, as |
| | | compared to parity segments provided by |
| | | the sender for general purpose (with |
| | | respect to an FEC coding block) erasure |
| | | filling. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO for |
| | | object. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_UNRELIABLE| 0x08 | Indicates that repair transmissions for |
| | | the specified object will be unavailable|
| | | (One-shot, best effort transmission). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_FILE | 0x10 | Indicates object is "file-based" data |
| | | (hint to use disk storage for |
| | | reception). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_STREAM | 0x20 | Indicates object is of type |
| | | NORM_OBJECT_STREAM. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_MSG_START | 0x40 | Marks the first segment of application |
| | | messages embedded in |
| | | NORM_OBJECT_STREAMs. |
+--------------------+-------+-----------------------------------------+
NORM_FLAG_REPAIR is set when the associated message is a repair transmission. This information can be used by receivers to help observe a join policy where it is desired that newly joining receivers only begin participating in the NACK process upon receipt
当相关信息为修复传输时，将设置NORM_FLAG_REPAIR。接收者可以使用此信息来帮助遵守加入策略，其中希望新加入的接收者仅在收到后才开始参与NACK过程
of new (non-repair) data content. NORM_FLAG_EXPLICIT is used to mark repair messages sent when the data sender has exhausted its ability to provide "fresh" (previously untransmitted) parity segments as repair. This flag could possibly be used by intermediate systems implementing functionality to control sub-casting of repair content to different legs of a reliable multicast topology with disparate repair needs. NORM_FLAG_INFO is set only when optional NORM_INFO content is actually available for the associated object. Thus, receivers will NACK for retransmission of NORM_INFO only when it is available for a given object. NORM_FLAG_UNRELIABLE is set when the sender wishes to transmit an object with only "best effort" delivery and will not supply repair transmissions for the object. NORM receivers SHOULD NOT execute repair requests for objects marked with the NORM_FLAG_UNRELIABLE flag. Note that receivers may inadvertently request repair of such objects when all segments (or info content) for those objects are not received (i.e., a gap in the "object_transport_id" sequence is noted). In this case, the sender should invoke the NORM_CMD(SQUELCH) process as described in Section 4.2.3. NORM_FLAG_FILE can be set as a "hint" from the sender that the associated object should be stored in non-volatile storage. NORM_FLAG_STREAM is set when the identified object is of type NORM_OBJECT_STREAM. When NORM_FLAG_STREAM is set, the NORM_FLAG_MSG_START can be optionally used to mark the first data segments of application-layer messages transported within the NORM stream. This allows NORM receiver applications to "synchronize" with NORM senders and to be able to properly interpret application layer data when joining a NORM session already in progress. In practice, the NORM implementation MAY set this flag for the segment transmitted following an explicit "flush" of the stream by the application.
新的（非修复的）数据内容。NORM_FLAG_EXPLICIT用于在数据发送方已将其提供“新鲜”（以前未传输的）奇偶校验段的能力耗尽时，将发送的修复消息标记为修复。该标志可能由实现功能的中间系统使用，以控制将修复内容分播到具有不同修复需求的可靠多播拓扑的不同分支。仅当可选的NORM_信息内容实际可用于关联对象时，才会设置NORM_FLAG_INFO。因此，只有当范数信息可用于给定对象时，接收机才会NACK用于范数信息的重传。当发送方希望仅以“尽力而为”的方式传输对象，并且不为对象提供修复传输时，将设置NORM_FLAG_UNRELIABLE。NORM接收者不应执行带有NORM_标志\u不可靠标志的对象的修复请求。注意，当未接收到这些对象的所有段（或信息内容）时，接收器可能会无意中请求修复这些对象（即，注意到“对象传输id”序列中的间隙）。在这种情况下，发送方应调用第4.2.3节所述的NORM_CMD（静噪）过程。可以将NORM_FLAG_文件设置为发送方的“提示”，即关联对象应存储在非易失性存储器中。当标识的对象类型为NORM\u object\u STREAM时，将设置NORM\u FLAG\u STREAM。当设置NORM_FLAG_STREAM时，NORM_FLAG_MSG_START可选择性地用于标记在NORM STREAM内传输的应用层消息的第一个数据段。这允许NORM接收方应用程序与NORM发送方“同步”，并能够在加入已在进行的NORM会话时正确解释应用程序层数据。实际上，NORM实现可以为在应用程序显式地“刷新”流之后传输的段设置该标志。
The "fec_id" field corresponds to the FEC Encoding Identifier described in the FEC Building Block document [5]. The "fec_id" value implies the format of the "fec_payload_id" field and, coupled with FEC Object Transmission Information, the procedures to decode FEC encoded content. Small block, systematic codes ("fec_id" = 129) are expected to be used for most NORM purposes and the NORM_OBJECT_STREAM requires systematic FEC codes for most efficient performance.
“fec_id”字段对应于fec构建块文档[5]中描述的fec编码标识符。“fec_id”值意味着“fec_有效负载_id”字段的格式，以及与fec对象传输信息相结合的解码fec编码内容的过程。小块系统代码（“fec_id”=129）预计将用于大多数规范目的，规范对象流需要系统fec代码以获得最有效的性能。
The "object_transport_id" field is a monotonically and incrementally increasing value assigned by the sender to NormObjects being transmitted. Transmissions and repair requests related to that object use the same "object_transport_id" value. For sessions of very long or indefinite duration, the "object_transport_id" field may be repeated, but it is presumed that the 16-bit field size provides an adequate enough sequence space to avoid object confusion amongst receivers and sources (i.e., receivers SHOULD re-synchronize with a server when receiving object sequence identifiers sufficiently out-of-range with the current state kept for a given source). During the
“object_transport_id”字段是发送方分配给正在传输的对象的单调递增的值。与该对象相关的传输和修复请求使用相同的“对象传输id”值。对于持续时间非常长或不确定的会话，“object_transport_id”字段可以重复，但假定16位字段大小提供足够的序列空间，以避免接收机和源之间的对象混淆（即，当接收到的对象序列标识符与给定源保持的当前状态完全超出范围时，接收器应与服务器重新同步）
course of its transmission within a NORM session, an object is uniquely identified by the concatenation of the sender "source_id" and the given "object_transport_id". Note that NORM_INFO messages associated with the identified object carry the same "object_transport_id" value.
在NORM会话中的传输过程中，对象通过发送方“源标识”和给定的“对象传输标识”的串联来唯一标识。请注意，与已识别对象关联的NORM_INFO消息具有相同的“object_transport_id”值。
The "fec_payload_id" identifies the attached NORM_DATA "payload" content. The size and format of the "fec_payload_id" field depends upon the FEC type indicated by the "fec_id" field. These formats are given in the FEC Building Block document [5] and any subsequent extensions of that document. As an example, the format of the "fec_payload_id" format small block, systematic codes ("fec_id" = 129) given here:
“fec_有效载荷_id”标识附加的规范数据“有效载荷”内容。“fec_有效负载_id”字段的大小和格式取决于“fec_id”字段指示的fec类型。这些格式在FEC构建块文档[5]和该文档的任何后续扩展中给出。作为一个示例，“fec_有效载荷_id”格式的小块系统代码（“fec_id”=129）的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_len | encoding_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_len | encoding_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Small Block, Systematic Code ("fec_id" = 129) "fec_payload_id" Format
小块系统代码（“fec\U id”=129）“fec\U有效负载\U id”格式
The FEC payload identifier "source_block_number", "source_block_len", and "encoding_symbol_id" fields correspond to the "Source Block Number", "Source Block Length, and "Encoding Symbol ID" fields of the FEC Payload ID format given by the IETF FEC Building Block document [5]. The "source_block_number" identifies the coding block's relative position with a NormObject. Note that, for NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may wrap for very long lived sessions. The "source_block_len" indicates the number of user data segments in the identified coding block. Given the "source_block_len" information of how many symbols of application data are contained in the block, the receiver can determine whether the attached segment is data or parity content and treat it appropriately. The "encoding_symbol_id" identifies which specific symbol (segment) within the coding block the attached payload conveys. Depending upon the value of the "encoding_symbol_id" and the associated "source_block_len" parameters for the block, the symbol (segment) referenced may be a user data or an FEC parity segment. For systematic codes, encoding symbols numbered less than the source_block_len contain original application data while segments greater than or equal to source_block_len contain parity symbols calculated for the block. The concatenation of
FEC有效负载标识符“源块号”、“源块号”和“编码符号号”字段对应于IETF FEC构建块文档[5]给出的FEC有效负载id格式的“源块号”、“源块长度”和“编码符号号”字段“标识编码块与对象的相对位置。请注意，对于NORM\u OBJECT\u STREAM类型的normObject，“源\u块\u编号”可能会换行很长时间的会话。“源块”表示所识别编码块中的用户数据段的数量。给定块中包含多少应用数据符号的“源块”信息，接收机可以确定所附段是数据还是奇偶校验内容，并对其进行适当处理。“encoding_symbol_id”标识所附有效负载传送的编码块内的特定符号（段）。根据块的“编码\符号\ id”的值和相关联的“源\块\ len”参数，所引用的符号（段）可以是用户数据或FEC奇偶校验段。对于系统代码，编号小于源块长度的编码符号包含原始应用程序数据，而大于或等于源块长度的段包含为该块计算的奇偶校验符号。串接
object_transport_id::fec_payload_id can be viewed as a unique transport protocol data unit identifier for the attached segment with respect to the NORM sender's instance within a session.
object_transport_id:：fec_payload_id可以被视为会话中连接的段相对于NORM发送方实例的唯一传输协议数据单元标识符。
Additional FEC Object Transmission Information (as described in the FEC Building Block document [5]) is required to properly receive and decode NORM transport objects. This information MAY be provided as out-of-band session information. However, in some cases, it may be useful for the sender to include this information "in band" to facilitate receiver operation with minimal preconfiguration. For this purpose, the NORM FEC Object Transmission Information Header Extension (EXT_FTI) is defined. This header extension MAY be applied to NORM_DATA and NORM_INFO messages to provide this necessary information. The exact format of the extension depends upon the FEC code in use, but in general it SHOULD contain any required details on the FEC code in use (e.g., FEC Instance ID, etc.) and the byte size of the associated NormObject (For the NORM_OBJECT_STREAM type, this size corresponds to the stream buffer size maintained by the NORM sender). As an example, the format of the EXT_FTI for small block systematic codes ("fec_id" = 129) is given here:
需要额外的FEC对象传输信息（如FEC构建块文档[5]中所述），以正确接收和解码NORM传输对象。该信息可以作为带外会话信息提供。然而，在某些情况下，发送方将该信息包括在“频带内”可能是有用的，以便以最小的预配置促进接收机操作。为此，定义了范数FEC对象传输信息报头扩展（EXT_FTI）。此标头扩展可应用于NORM_数据和NORM_信息消息，以提供此必要信息。扩展的确切格式取决于所使用的FEC代码，但一般来说，它应该包含所使用的FEC代码的任何必要细节（例如，FEC实例ID等）和相关NormObject的字节大小（对于NORM_对象_流类型，此大小对应于NORM发送方维护的流缓冲区大小）。作为示例，这里给出了小数据块系统代码的EXT_FTI格式（“fec_id”=129）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 64 | hel = 4 | object_length (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_length (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 64 | hel = 4 | object_length (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_length (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object Transmission Information Header Extension (EXT_FTI) for Small Block Systematic Codes ("fec_id" = 129)
用于小分组系统码的FEC对象传输信息头扩展（EXT_FTI）（“FEC_id”=129）
The header extension type "het" field value for this header extension is 64. The header extension length "hel" depends upon the format of the FTI for FEC code type identified by the "fec_id" field. In this example (for "fec_id" = 129), the "hel" field value is 4.
此标头扩展的标头扩展类型“het”字段值为64。标头扩展长度“hel”取决于“FEC_id”字段标识的FEC代码类型的FTI格式。在本例中（对于“fec_id”=129），“hel”字段值为4。
The 48-bit "object_length" field indicates the total size of the object (in bytes) for the static object types of NORM_OBJECT_FILE and NORM_OBJECT_DATA. This information is used by receivers to determine storage requirements and/or allocate storage for the received object. Receivers with insufficient storage capability may wish to forego reliable reception (i.e., not NACK for) of the indicated object. In the case of objects of type NORM_OBJECT_STREAM, the "object_length"
48位“object_length”字段表示NORM_object_文件和NORM_object_数据的静态对象类型的对象总大小（字节）。接收器使用该信息确定存储需求和/或为接收对象分配存储。存储能力不足的接收器可能希望放弃对所指示对象的可靠接收（即，非NACK）。对于NORM\u OBJECT\u STREAM类型的对象，“OBJECT\u length”
field is used by the sender to indicate the size of its stream buffer to the receiver group. In turn, the receivers SHOULD use this information to allocate a stream buffer for reception of corresponding size.
字段由发送方用于向接收方组指示其流缓冲区的大小。反过来，接收器应使用该信息来分配用于相应大小的接收的流缓冲器。
The "fec_instance_id" corresponds to the "FEC Instance ID" described in the FEC Building Block document [5]. In this case, the "fec_instance_id" SHALL be a value corresponding to the particular type of Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), Reed-Solomon GF(2^16), etc). The standardized assignment of FEC Instance ID values is described in [5]. The "segment_size" field indicates the sender's current setting for maximum message payload content (in bytes). This allows receivers to allocate appropriate buffering resources and to determine other information in order to properly process received data messaging.
“fec_实例_id”对应于fec构建块文档[5]中描述的“fec实例id”。在这种情况下，“fec_实例_id”应是与所使用的特定类型的小数据块系统代码（例如，里德所罗门GF（2^8）、里德所罗门GF（2^16）等）相对应的值。FEC实例ID值的标准化分配如[5]所述。“segment_size”字段表示发送方的最大消息有效负载内容的当前设置（以字节为单位）。这允许接收器分配适当的缓冲资源并确定其他信息，以便正确处理接收到的数据消息。
The "fec_max_block_len" indicates the current maximum number of user data segments per FEC coding block to be used by the sender during the session. This allows receivers to allocate appropriate buffer space for buffering blocks transmitted by the sender.
“fec_max_block_len”表示会话期间发送方要使用的每个fec编码块的当前最大用户数据段数。这允许接收机为发送方发送的缓冲块分配适当的缓冲空间。
The "fec_num_parity" corresponds to the "maximum number of encoding symbols that can be generated for any source block" as described in for FEC Object Transmission Information for Small Block Systematic Codes in the FEC Building Block document [5]. For example, Reed-Solomon codes may be arbitrarily shortened to create different code variations for a given block length. In the case of Reed-Solomon (GF(2^8) and GF(2^16)) codes, this value indicates the maximum number of parity segments available from the sender for the coding blocks. This field MAY be interpreted differently for other systematic codes as they are defined.
“fec_num_奇偶校验”对应于如fec构建块文档[5]中关于小块系统码的fec对象传输信息中所述的“可为任何源块生成的编码符号的最大数量”。例如，可以任意缩短里德-所罗门码以针对给定块长度创建不同的码变体。对于Reed-Solomon（GF（2^8）和GF（2^16））码，该值表示发送方可用于编码块的奇偶校验段的最大数量。对于定义的其他系统代码，此字段可能会有不同的解释。
The payload portion of NORM_DATA messages includes source data or FEC encoded application content.
NORM_数据消息的有效负载部分包括源数据或FEC编码的应用程序内容。
The "payload_reserved", "payload_len" and "payload_offset" fields are present ONLY for transport objects of type NORM_OBJECT_STREAM. These fields indicate the size and relative position (within the stream) of the application content represented by the message payload. For senders employing systematic FEC encoding, these fields contain _actual_ length and offset values (in bytes) for the payload of messages which contain original data source symbols. For NORM_DATA messages containing calculated parity content, these fields will actually contain values computed by FEC encoding of the "payload_len" and "payload_offset" values of the NORM_DATA data segments of the corresponding FEC coding block. Thus, the "payload_len" and "payload_offset" values of missing data content can be determined upon decoding a FEC coding block. Note that these fields do NOT
“payload_reserved”、“payload_len”和“payload_offset”字段仅用于NORM_OBJECT_STREAM类型的传输对象。这些字段指示由消息负载表示的应用程序内容的大小和相对位置（在流中）。对于采用系统FEC编码的发送方，这些字段包含包含原始数据源符号的消息有效载荷的_实际长度和偏移量值（以字节为单位）。对于包含计算出的奇偶校验内容的NORM_数据消息，这些字段实际上将包含由相应FEC编码块的NORM_数据段的“payload_len”和“payload_offset”值的FEC编码计算出的值。因此，可以在解码FEC编码块时确定丢失数据内容的“有效载荷长度”和“有效载荷偏移”值。请注意，这些字段不存在
contribute to the value of the NORM_DATA "hdr_len" field. These fields are NOT present when the "flags" portion of the NORM_DATA message indicate the transport object if of type NORM_OBJECT_FILE or NORM_OBJECT_DATA. In this case, the length and offset information can be calculated from the "fec_payload_id" using the methodology described in Section 5.1.1. Note that for long-lived streams, the "payload_offset" field can wrap.
对NORM_DATA“hdr_len”字段的值作出贡献。如果NORM_object_FILE或NORM_object_DATA类型，则当NORM_数据消息的“flags”部分指示传输对象时，这些字段不存在。在这种情况下，可以使用第5.1.1节中描述的方法从“fec_有效载荷_id”计算长度和偏移信息。请注意，对于长寿命流，“有效负载_偏移”字段可以换行。
The "payload_data" field contains the original application source or parity content for the symbol identified by the "fec_payload_id". The length of this field SHALL be limited to a maximum of the sender's NormSegmentSize bytes as given in the FTI for the object. Note the length of this field for messages containing parity content will always be of length NormSegmentSize. When encoding data segments of varying sizes, the FEC encoder SHALL assume ZERO value padding for data segments with length less than the NormSegmentSize. It is RECOMMENDED that a sender's NormSegmentSize generally be constant for the duration of a given sender's term of participation in the session, but may possibly vary on a per-object basis. The NormSegmentSize is expected to be configurable by the sender application prior to session participation as needed for network topology maximum transmission unit (MTU) considerations. For IPv6, MTU discovery may be possibly leveraged at session startup to perform this configuration. The "payload_data" content may be delivered directly to the application for source symbols (when systematic FEC encoding is used) or upon decoding of the FEC block. For NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment length and offset can be calculated using the algorithm described in Section 5.1.1. For NORM_OBJECT_STREAM objects, the length and offset is obtained from the segment's corresponding "payload_len" and "payload_offset" fields.
“有效负载数据”字段包含由“fec\U有效负载id”标识的符号的原始应用程序源或奇偶校验内容。该字段的长度应限制为对象FTI中给出的发送方NORMSECTIONSIZE字节的最大值。请注意，包含奇偶校验内容的消息的此字段长度始终为长度大小。当编码不同大小的数据段时，FEC编码器应对长度小于正常段大小的数据段采用零值填充。建议发送者的大小在给定发送者参与会话的期限内通常保持不变，但可能因每个对象而异。根据网络拓扑最大传输单元（MTU）的考虑，在会话参与之前，发送方应用程序可以配置该大小。对于IPv6，可能在会话启动时利用MTU发现来执行此配置。“有效载荷数据”内容可直接传送到源符号的应用程序（当使用系统FEC编码时）或在对FEC块进行解码时。对于NORM_OBJECT_FILE和NORM_OBJECT_STREAM对象，可以使用第5.1.1节中描述的算法计算数据段长度和偏移量。对于NORM_OBJECT_STREAM对象，长度和偏移量从段的相应“payload_len”和“payload_offset”字段中获取。
The NORM_INFO message is used to convey OPTIONAL, application-defined, "out-of-band" context information for transmitted NormObjects. An example NORM_INFO use for bulk file transfer is to place MIME type information for the associated file, data, or stream object into the NORM_INFO payload. Receivers may use the NORM_INFO content to make a decision as whether to participate in reliable reception of the associated object. Each NormObject can have an independent unit of NORM_INFO associated with it. NORM_DATA messages contain a flag to indicate the availability of NORM_INFO for a given NormObject. NORM receivers may NACK for retransmission of NORM_INFO when they have not received it for a given NormObject. The size of the NORM_INFO content is limited to that of a single NormSegmentSize
NORM_INFO消息用于为传输的NORM对象传递可选的、应用程序定义的“带外”上下文信息。大容量文件传输使用的一个示例NORM_INFO是将关联文件、数据或流对象的MIME类型信息放入NORM_INFO负载中。接收机可以使用NORM_信息内容来作出是否参与相关对象的可靠接收的决定。每个NormObject都可以有一个独立的NORM_信息单元与其关联。NORM_数据消息包含一个标志，用于指示给定NORM对象的NORM_信息的可用性。当规范接收者没有接收到给定规范对象的规范信息时，规范接收者可以NACK重新传输规范信息。NORM_信息内容的大小仅限于单个NORMSECTIONSIZE的大小
for the given sender. This atomic nature allows the NORM_INFO to be rapidly and efficiently repaired within the NORM reliable transmission process.
对于给定的发送者。这种原子性质允许NORM_信息在NORM可靠传输过程中快速有效地修复。
When NORM_INFO content is available for a NormObject, the NORM_FLAG_INFO flag SHALL be set in NORM_DATA messages for the corresponding "object_transport_id" and the NORM_INFO message shall be transmitted as the first message for the NormObject.
当NORM\u信息内容可用于NORM对象时，NORM\u FLAG\u INFO FLAG应在对应的“object\u transport\u id”的NORM\u数据消息中设置，NORM\u INFO消息应作为NORM对象的第一条消息传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=1| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=1| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_INFO Message Format
标准信息格式
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM Common Message Header as described in Section 4.1. The value of "hdr_len" field when no header extensions are present is 4.
“版本”、“类型”、“hdr_len”、“序列”和“源id”字段构成第4.1节所述的标准公共消息头。当不存在标头扩展名时，“hdr_len”字段的值为4。
The "instance_id", "grtt", "backoff", "gsize", "flags", "fec_id", and "object_transport_id" fields carry the same information and serve the same purpose as with NORM_DATA messages. These values allow the receiver to prepare appropriate buffering, etc, for further transmissions from the sender when NORM_INFO is the first message received.
“实例id”、“grtt”、“退避”、“gsize”、“标志”、“fec id”和“对象传输id”字段携带的信息和用途与NORM_数据消息相同。当NORM_INFO是接收到的第一条消息时，这些值允许接收方为来自发送方的进一步传输准备适当的缓冲等。
As with NORM_DATA messages, the NORM FTI Header Extension (EXT_FTI) may be optionally applied to NORM_INFO messages. To conserve protocol overhead, some NORM implementations may wish to apply the EXT_FTI when used to NORM_INFO messages only and not to NORM_DATA messages.
与NORM_数据消息一样，NORM FTI报头扩展（EXT_FTI）可选择性地应用于NORM_INFO消息。为了节省协议开销，一些NORM实现可能希望在仅用于NORM_信息消息而不用于NORM_数据消息时应用EXT_FTI。
The NORM_INFO "payload_data" field contains sender application-defined content which can be used by receiver applications for various purposes as described above.
NORM_INFO“payload_data”字段包含发送方应用程序定义的内容，接收方应用程序可将其用于上述各种目的。
NORM_CMD messages are transmitted by senders to perform a number of different protocol functions. This includes functions such as round-trip timing collection, congestion control functions, synchronization of sender/receiver repair "windows", and notification of sender status. A core set of NORM_CMD messages is enumerated. Additionally, a range of command types remain available for potential application-specific use. Some NORM_CMD types may have dynamic content attached. Any attached content will be limited to maximum length of the sender NormSegmentSize to retain the atomic nature of commands. All NORM_CMD messages begin with a common set of fields, after the usual NORM message common header. The standard NORM_CMD fields are:
NORM_CMD消息由发送方传输，以执行许多不同的协议功能。这包括往返定时收集、拥塞控制功能、发送方/接收方修复“窗口”的同步以及发送方状态通知等功能。枚举一组核心的NORM_CMD消息。此外，还有一系列命令类型可供特定于应用程序的潜在使用。某些NORM_CMD类型可能附加了动态内容。任何附加的内容都将被限制在发送方大小的最大长度内，以保留命令的原子性。所有NORM_CMD消息都以一组公共字段开头，位于普通NORM消息公共头之后。标准NORM_CMD字段包括：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD Standard Fields
NORM\u CMD标准字段
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM Common Message Header as described in Section 4.1. The value of the "hdr_len" field for NORM_CMD messages without header extensions present depends upon the "flavor" field.
“版本”、“类型”、“hdr_len”、“序列”和“源id”字段构成第4.1节所述的标准公共消息头。对于不存在标头扩展名的NORM_CMD消息，“hdr_len”字段的值取决于“flavor”字段。
The "instance_id", "grtt", "backoff", and "gsize" fields provide the same information and serve the same purpose as with NORM_DATA and NORM_INFO messages. The "flavor" field indicates the type of command to follow. The remainder of the NORM_CMD message is dependent upon the command type ("flavor"). NORM command flavors include:
“instance_id”、“grtt”、“backoff”和“gsize”字段提供与NORM_数据和NORM_信息消息相同的信息和用途。“flavor”字段指示要遵循的命令类型。NORM_CMD消息的其余部分取决于命令类型（“flavor”）。NORM命令的风格包括：
+----------------------+-------------+---------------------------------+
| Command |Flavor Value | Purpose |
+----------------------+-------------+---------------------------------+
|NORM_CMD(FLUSH) | 1 | Used to indicate sender |
| | | temporary end-of-transmission. |
| | | (Assists in robustly initiating |
| | | outstanding repair requests from|
| | | receivers). May also be |
| | | optionally used to collect |
| | | positive acknowledgment of |
| | | reliable reception from subset |
| | | of receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(SQUELCH) | 3 | Used to advertise sender's |
| | | current repair window in |
| | | response to out-of-range NACKs |
| | | from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(CC) | 4 | Used for GRTT measurement and |
| | | collection of congestion control|
| | | feedback. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender's |
| | | aggregated repair/feedback state|
| | | for suppression of unicast |
| | | feedback from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment |
| | | from a list of receivers |
| | | (OPTIONAL). |
+----------------------+-------------+---------------------------------+
|NORM_CMD(APPLICATION) | 7 | Used for application-defined |
| | | purposes which may need to |
| | | temporarily preempt data |
| | | transmission (OPTIONAL). |
+----------------------+-------------+---------------------------------+
+----------------------+-------------+---------------------------------+
| Command |Flavor Value | Purpose |
+----------------------+-------------+---------------------------------+
|NORM_CMD(FLUSH) | 1 | Used to indicate sender |
| | | temporary end-of-transmission. |
| | | (Assists in robustly initiating |
| | | outstanding repair requests from|
| | | receivers). May also be |
| | | optionally used to collect |
| | | positive acknowledgment of |
| | | reliable reception from subset |
| | | of receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(SQUELCH) | 3 | Used to advertise sender's |
| | | current repair window in |
| | | response to out-of-range NACKs |
| | | from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(CC) | 4 | Used for GRTT measurement and |
| | | collection of congestion control|
| | | feedback. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender's |
| | | aggregated repair/feedback state|
| | | for suppression of unicast |
| | | feedback from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment |
| | | from a list of receivers |
| | | (OPTIONAL). |
+----------------------+-------------+---------------------------------+
|NORM_CMD(APPLICATION) | 7 | Used for application-defined |
| | | purposes which may need to |
| | | temporarily preempt data |
| | | transmission (OPTIONAL). |
+----------------------+-------------+---------------------------------+
The NORM_CMD(FLUSH) command is sent when the sender reaches the end of all data content and pending repairs it has queued for transmission. This may indicate a temporary or permanent end of data transmission, but the sender is still willing to respond to repair requests. This command is repeated once per 2*GRTT to excite the
当发送方到达其排队等待传输的所有数据内容和未决修复的末尾时，将发送NORM_CMD（FLUSH）命令。这可能表示数据传输暂时或永久结束，但发送方仍愿意响应修复请求。该命令每2*GRTT重复一次，以激励
receiver set for any outstanding repair requests up to and including the transmission point indicated within the NORM_CMD(FLUSH) message. The number of repeats is equal to NORM_ROBUST_FACTOR unless a list of receivers from which explicit positive acknowledgment is expected ("acking_node_list") is given. In that case, the "acking_node_list" is updated as acknowledgments are received and the NORM_CMD(FLUSH) is repeated according to the mechanism described in Section 5.5.3. The greater the NORM_ROBUST_FACTOR, the greater the probability that all applicable receivers will be excited for acknowledgment or repair requests (NACKs) _and_ that the corresponding NACKs are delivered to the sender. If a NORM_NACK message interrupts the flush process, the sender will re-initiate the flush process after any resulting repair transmissions are completed.
在NORM_CMD（FLUSH）消息中指示的传输点之前（包括该传输点），为任何未完成的维修请求设置接收器。重复次数等于NORM_ROBUST_因子，除非给出了预期明确肯定确认的接收器列表（“确认节点列表”）。在这种情况下，“确认节点列表”随着收到确认而更新，并且根据第5.5.3节中描述的机制重复NORM_CMD（刷新）。范数鲁棒系数越大，所有适用的接收者将被激发接受确认或修复请求（nack）以及相应的nack被交付给发送者的概率就越大。如果NORM_NACK消息中断刷新过程，则发送方将在任何修复传输完成后重新启动刷新过程。
Note that receivers also employ a timeout mechanism to self-initiate NACKing (if there are outstanding repair needs) when no messages of any type are received from a sender. This inactivity timeout is related to 2*GRTT*NORM_ROBUST_FACTOR and will be discussed more later. With a sufficient NORM_ROBUST_FACTOR value, data content is delivered with a high assurance of reliability. The penalty of a large NORM_ROBUST_FACTOR value is potentially excess sender NORM_CMD(FLUSH) transmissions and a longer timeout for receivers to self-initiate the terminal NACK process.
请注意，当没有从发送方接收到任何类型的消息时，接收方还使用超时机制来自启动NACKing（如果有未完成的修复需求）。此非活动超时与2*GRTT*NORM\u ROBUST\u因子有关，稍后将进一步讨论。有了足够的范数_稳健_因子值，数据内容的交付具有高度的可靠性保证。较大的NORM_ROBUST_FACTOR值的代价可能是发送方NORM_CMD（FLUSH）传输量过大，并且接收机自启动终端NACK进程的超时时间更长。
For finite-size transport objects such as NORM_OBJECT_DATA and NORM_OBJECT_FILE, the flush process (if there are no further pending objects) occurs at the end of these objects. Thus, FEC repair information is always available for repairs in response to repair requests elicited by the flush command. However, for NORM_OBJECT_STREAM, the flush may occur at any time, including in the middle of an FEC coding block if systematic FEC codes are employed. In this case, the sender will not yet be able to provide FEC parity content as repair for the concurrent coding block and will be limited to explicitly repairing stream data content for that block. Applications that anticipate frequent flushing of stream content SHOULD be judicious in the selection of the FEC coding block size (i.e., do not use a very large coding block size if frequent flushing occurs). For example, a reliable multicast application transmitting an on-going series of intermittent, relatively small messaging content will need to trade-off using the NORM_OBJECT_DATA paradigm versus the NORM_OBJECT_STREAM paradigm with an appropriate FEC coding block size. This is analogous to application trade-offs for other transport protocols such as the selection of different TCP modes of operation such as "no delay", etc.
对于有限大小的传输对象，如NORM_OBJECT_DATA和NORM_OBJECT_FILE，刷新过程（如果没有其他挂起的对象）发生在这些对象的末尾。因此，FEC修复信息始终可用于响应flush命令引发的修复请求的修复。然而，对于NoMalObjista流，如果采用系统FEC码，刷新可能在任何时间发生，包括在FEC编码块的中间。在这种情况下，发送方将不能提供FEC奇偶校验内容作为对并发编码块的修复，并且将被限制为显式地修复该块的流数据内容。预期流内容频繁刷新的应用程序在选择FEC编码块大小时应明智（即，如果频繁刷新，则不要使用非常大的编码块大小）。例如，可靠的多播应用程序传输正在进行的一系列间歇的、相对较小的消息传递内容，将需要使用NORM_OBJECT_数据范式与具有适当FEC编码块大小的NORM_OBJECT_流范式进行权衡。这类似于其他传输协议的应用程序权衡，如选择不同的TCP操作模式，如“无延迟”等。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(FLUSH) Message Format
NORM_CMD（FLUSH）消息格式
In addition to the NORM common message header and standard NORM_CMD fields, the NORM_CMD(FLUSH) message contains fields to identify the current status and logical transmit position of the sender.
除了NORM common message header和标准NORM_CMD字段外，NORM_CMD（FLUSH）消息还包含用于标识发送方当前状态和逻辑传输位置的字段。
The "fec_id" field indicates the FEC type used for the flushing "object_transport_id" and implies the size and format of the "fec_payload_id" field. Note the "hdr_len" value for the NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id" field when no header extensions are present.
“fec_id”字段表示用于刷新“object_transport_id”的fec类型，并表示“fec_payload_id”字段的大小和格式。注意：当不存在头扩展时，NORM_CMD（FLUSH）消息的“hdr_len”值为4加上“fec_payload_id”字段的大小。
The "object_transport_id" and "fec_payload_id" fields indicate the sender's current logical "transmit position". These fields are interpreted in the same manner as in the NORM_DATA message type. Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check their completion state _through_ (including) this transmission position. If receivers have outstanding repair needs in this range, they SHALL initiate the NORM NACK Repair Process as described in Section 5.3. If receivers have no outstanding repair needs, no response to the NORM_CMD(FLUSH) is generated.
“object_transport_id”和“fec_payload_id”字段表示发送方当前的逻辑“传输位置”。这些字段的解释方式与NORM_数据消息类型中的解释方式相同。在收到NORM_CMD（FLUSH）后，接收机应通过（包括）该传输位置检查其完成状态。如果接收器在此范围内有未完成的维修需求，则应按照第5.3节所述启动NORM NACK维修流程。如果接收器没有未完成的维修需求，则不会生成对NORM_CMD（冲洗）的响应。
For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers MUST request "explicit-only" repair of the identified "source_block_number" if the given "encoding_symbol_id" is less than the "source_block_len". This condition indicates the sender has not yet completed encoding the corresponding FEC block and parity content is not yet available. An "explicit-only" repair request consists of NACK content for the applicable "source_block_number" which does not include any requests for parity-based repair. This allows NORM
对于使用系统FEC代码的NORM_对象_流对象，如果给定的“编码符号_id”小于“源块_len”，则接收器必须请求“仅显式”修复已识别的“源块_编号”。此条件表示发送方尚未完成对相应FEC块的编码，奇偶校验内容尚不可用。“仅显式”修复请求包含适用“源块号”的NACK内容，其中不包括任何基于奇偶校验的修复请求。这允许规范
sender applications to "flush" an ongoing stream of transmission when needed, even if in the middle of an FEC block. Once the sender resumes stream transmission and passes the end of the pending coding block, subsequent NACKs from receivers SHALL request parity-based repair as usual. Note that the use of a systematic FEC code is assumed here. Normal receiver NACK initiation and construction is discussed in detail in Section 5.3. The OPTIONAL "acking_node_list" field contains a list of NormNodeIds for receivers from which the sender is requesting explicit positive acknowledgment of reception up through the transmission point identified by the "object_transport_id" and "fec_payload_id" fields. The length of the list can be inferred from the length of the received NORM_CMD(FLUSH) message. When the "acking_node_list" is present, the lightweight positive acknowledgment process described in Section 5.5.3 SHALL be observed.
当需要时，发送器应用程序“刷新”正在进行的传输流，即使在FEC块的中间。一旦发送方恢复流传输并通过挂起的编码块的末尾，来自接收方的后续nack应像往常一样请求基于奇偶校验的修复。注意，此处假设使用系统FEC代码。第5.3节详细讨论了正常接收器NACK的启动和构造。可选的“acking_node_list”（确认节点列表）字段包含用于发送方通过“object_transport_id”和“fec_payload_id”字段标识的传输点请求接收明确肯定确认的接收器的NORMNODEID列表。列表的长度可以从收到的NORM_CMD（FLUSH）消息的长度推断出来。当出现“确认节点列表”时，应遵守第5.5.3节所述的轻量级肯定确认过程。
The NORM_CMD(EOT) command is sent when the sender reaches permanent end-of-transmission with respect to the NormSession and will not respond to further repair requests. This allows receivers to gracefully reach closure of operation with this sender (without requiring any timeout) and free any resources that are no longer needed. The NORM_CMD(EOT) command SHOULD be sent with the same robust mechanism as used for NORM_CMD(FLUSH) commands to provide a high assurance of reception by the receiver set.
当发送方到达NormSession的永久传输结束时，将发送NORM_CMD（EOT）命令，并且不会响应进一步的修复请求。这允许接收者优雅地结束与该发送者的操作（无需任何超时），并释放不再需要的任何资源。NORM_CMD（EOT）命令应使用与NORM_CMD（FLUSH）命令相同的健壮机制发送，以提供接收器集接收的高保证。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(EOT) Message Format
NORM_CMD（EOT）消息格式
The value of the "hdr_len" field for NORM_CMD(EOT) messages without header extensions present is 4. The "reserved" field is reserved for future use and MUST be set to an all ZERO value. Receivers MUST ignore the "reserved" field.
不存在标头扩展名的NORM_CMD（EOT）消息的“hdr_len”字段的值为4。“保留”字段保留供将来使用，必须设置为全零值。接收者必须忽略“保留”字段。
The NORM_CMD(SQUELCH) command is transmitted in response to outdated or invalid NORM_NACK content received by the sender. Invalid NORM_NACK content consists of repair requests for NormObjects for which the sender is unable or unwilling to provide repair. This includes repair requests for outdated objects, aborted objects, or those objects which the sender previously transmitted marked with the NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what content is available for repair, thus serving as a description of the sender's current "repair window". Receivers SHALL not generate repair requests for content identified as invalid by a NORM_CMD(SQUELCH).
发送NORM_CMD（SQUELCH）命令是为了响应发送方接收到的过期或无效的NORM_NACK内容。无效的NORM_NACK内容由发送方无法或不愿意提供修复的NormObjects的修复请求组成。这包括对过时对象、中止对象或发送方先前传输的对象（标记为NORM_FLAG_UNRELIABLE FLAG）的修复请求。此命令向接收者指示哪些内容可用于修复，从而作为发送者当前“修复窗口”的描述。接收者不得对NORM_CMD（静噪）标识为无效的内容生成修复请求。
The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most. The NORM_CMD(SQUELCH) advertises the current "repair window" of the sender by identifying the earliest (lowest) transmission point for which it will provide repair, along with an encoded list of objects from that point forward that are no longer valid for repair. This mechanism allows the sender application to cancel or abort transmission and/or repair of specific previously enqueued objects. The list also contains the identifiers for any objects within the repair window that were sent with the NORM_FLAG_UNRELIABLE flag set. In normal conditions, it is expected the NORM_CMD(SQUELCH) will be needed infrequently, and generally only to provide a reference repair window for receivers who have fallen "out-of-sync" with the sender due to extremely poor network conditions.
NORM_CMD（SQUELCH）命令最多每2*GRTT发送一次。NORM_CMD（SQUELCH）通过识别其将提供修复的最早（最低）传输点，以及从该点开始不再有效的修复对象的编码列表，通告发送方的当前“修复窗口”。此机制允许发送方应用程序取消或中止传输和/或修复以前排队的特定对象。该列表还包含修复窗口中与NORM_FLAG_UNRELIABLE FLAG set一起发送的任何对象的标识符。在正常情况下，预计不经常需要NORM_CMD（静噪），通常仅为由于极端恶劣的网络条件而与发送方“不同步”的接收方提供参考修复窗口。
The starting point of the invalid NormObject list begins with the lowest invalid NormTransportId greater than the current "repair window" start from the invalid NACK(s) that prompted the generation of the squelch. The length of the list is limited by the sender's NormSegmentSize. This allows the receivers to learn the status of the sender's applicable object repair window with minimal transmission of NORM_CMD(SQUELCH) commands. The format of the NORM_CMD(SQUELCH) message is:
无效NormObject列表的起始点是从提示生成静噪的无效NACK开始的大于当前“修复窗口”的最低无效NormTransportId。列表的长度受发件人的大小限制。这允许接收者通过最少的NORM_CMD（静噪）命令传输来了解发送者适用对象修复窗口的状态。NORM_CMD（静噪）消息的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type = 3 | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type = 3 | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(SQUELCH) Message Format
NORM_CMD（静噪）消息格式
In addition to the NORM common message header and standard NORM_CMD fields, the NORM_CMD(SQUELCH) message contains fields to identify the earliest logical transmit position of the sender's current repair window and an "invalid object list" beginning with the index of the logically earliest invalid repair request from the offending NACK message which initiated the squelch transmission.
除了NORM common message header和标准NORM_CMD字段外，NORM_CMD（SQUELCH）消息还包含用于标识发送方当前修复窗口的最早逻辑传输位置的字段和“无效对象列表”从发起静噪传输的违规NACK消息中逻辑上最早的无效修复请求的索引开始。
The "object_transport_id" and "fec_payload_id" fields are concatenated to indicate the beginning of the sender's current repair window (i.e., the logically earliest point in its transmission history for which the sender can provide repair). The "fec_id" field implies the size and format of the "fec_payload_id" field. This serves as an advertisement of a "synchronization point" for receivers to request repair. Note, that while an "encoding_symbol_id" may be included in the "fec_payload_id" field, the sender's repair window SHOULD be aligned on FEC coding block boundaries and thus the "encoding_symbol_id" SHOULD be zero.
“object_transport_id”和“fec_payload_id”字段被连接起来，以指示发送方当前修复窗口的开始（即，发送方可以提供修复的传输历史中逻辑上最早的点）。“fec_id”字段表示“fec_有效负载_id”字段的大小和格式。这作为“同步点”的广告，供接收器请求修复。注意，虽然“fec_有效载荷_id”字段中可以包括“编码符号_id”，但是发送方的修复窗口应当在fec编码块边界上对齐，因此“编码符号_id”应当为零。
The "invalid_object_list" is a list of 16-bit NormTransportIds that, although they are within the range of the sender's current repair window, are no longer available for repair from the sender. For example, a sender application may dequeue an out-of-date object even though it is still within the repair window. The total size of the "invalid_object_list" content is can be determined from the packet's payload length and is limited to a maximum of the NormSegmentSize of the sender. Thus, for very large repair windows, it is possible that a single NORM_CMD(SQUELCH) message may not be capable of listing the entire set of invalid objects in the repair window. In this case,
“无效\u对象\u列表”是一个16位NORMTransportID的列表，尽管它们在发送方当前修复窗口的范围内，但发送方不再可以对其进行修复。例如，即使过期对象仍在修复窗口内，发送方应用程序也可能将其出列。“无效对象列表”内容的总大小可根据数据包的有效负载长度确定，并限制为发送方的最大大小。因此，对于非常大的修复窗口，单个NORM_CMD（SQUELCH）消息可能无法在修复窗口中列出整个无效对象集。在这种情况下,，
the sender SHALL ensure that the list begins with a NormObjectId that is greater than or equal to the lowest ordinal invalid NormObjectId from the NACK message(s) that prompted the NORM_CMD(SQUELCH) generation. The NormObjectIds in the "invalid_object_list" MUST be greater than the "object_transport_id" marking the beginning of the sender's repair window. This insures convergence of the squelch process, even if multiple invalid NACK/ squelch iterations are required. This explicit description of invalid content within the sender's current window allows the sender application (most notably for discrete "object" based transport) to arbitrarily invalidate (i.e., dequeue) portions of enqueued content (e.g., certain objects) for which it no longer wishes to provide reliable transport.
发送方应确保列表以NormObjectId开头，该NormObjectId大于或等于NACK消息中提示NORM_CMD（静噪）生成的最低顺序无效NormObjectId。“无效对象列表”中的NORMOBJECTID必须大于标记发件人修复窗口开始的“对象传输id”。这确保了静噪过程的收敛，即使需要多个无效的NACK/静噪迭代。发送方当前窗口内对无效内容的这种明确描述允许发送方应用程序（最明显的是基于离散“对象”的传输）任意使其不再希望提供可靠传输的已排队内容（例如，某些对象）的部分无效（即，出列）。
The NORM_CMD(CC) messages contains fields to enable sender-to-receiver group greatest round-trip time (GRTT) measurement and to excite the group for congestion control feedback. A baseline NORM congestion control scheme (NORM-CC), based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme of [19] is described in Section 5.5.2 of this document. The NORM_CMD(CC) message is usually transmitted as part of NORM-CC congestion control operation. A NORM header extension is defined below to be used with the NORM_CMD(CC) message to support NORM-CC operation. Different header extensions may be defined for the NORM_CMD(CC) (and/or other NORM messages as needed) to support alternative congestion control schemes in the future. If NORM is operated in a private network with congestion control operation disabled, the NORM_CMD(CC) message is then used for GRTT measurement only and may optionally be sent less frequently than with congestion control operation.
NORM_CMD（CC）消息包含用于启用发送方到接收方组最大往返时间（GRTT）测量并激励组进行拥塞控制反馈的字段。本文件第5.5.2节描述了基于[19]的TCP友好多播拥塞控制（TFMCC）方案的基线NORM拥塞控制方案（NORM-CC）。NORM_CMD（CC）消息通常作为NORM-CC拥塞控制操作的一部分进行传输。下面定义了一个NORM头扩展，它与NORM_CMD（CC）消息一起使用，以支持NORM-CC操作。可以为NORM_CMD（CC）（和/或其他需要的NORM消息）定义不同的报头扩展，以支持将来的替代拥塞控制方案。如果NORM在禁用拥塞控制操作的专用网络中运行，则NORM_CMD（CC）消息将仅用于GRTT测量，并且可以选择发送的频率低于拥塞控制操作。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 4 | reserved | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 4 | reserved | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(CC) Message Format
NORM_CMD（CC）消息格式
The NORM common message header and standard NORM_CMD fields serve their usual purposes.
NORM common message header和标准NORM_CMD字段用于其通常用途。
The "reserved" field is for potential future use and should be set to ZERO in this version of the NORM protocol.
“保留”字段用于将来的潜在用途，在此版本的NORM协议中应设置为零。
The "cc_sequence" field is a sequence number applied by the sender. For NORM-CC operation, it is used to provide functionality equivalent to the "feedback round number" (fb_nr)described in [19]. The most recently received "cc_sequence" value is recorded by receivers and can be fed back to the sender in congestion control feedback generated by the receivers for that sender. The "cc_sequence" number can also be used in NORM implementations to assess how recently a receiver has received NORM_CMD(CC) probes from the sender. This can be useful instrumentation for complex or experimental multicast routing environments.
“cc_序列”字段是发送方应用的序列号。对于NORM-CC操作，它用于提供与[19]中所述的“反馈轮数”（fb_nr）等效的功能。最近接收到的“cc_序列”值由接收方记录，并可在接收方为该发送方生成的拥塞控制反馈中反馈给发送方。“cc_序列”编号也可用于NORM实现中，以评估接收器最近从发送方接收NORM_CMD（cc）探测的情况。对于复杂的或实验性的多播路由环境，这可能是有用的工具。
The "send_time" field is a timestamp indicating the time that the NORM_CMD(CC) message was transmitted. This consists of a 64-bit field containing 32-bits with the time in seconds ("send_time_sec") and 32-bits with the time in microseconds ("send_time_usec") since some reference time the source maintains (usually 00:00:00, 1 January 1970). The byte ordering of the fields is "Big Endian" network order. Receivers use this timestamp adjusted by the amount of delay
“发送时间”字段是一个时间戳，指示NORM_CMD（CC）消息的传输时间。这包括一个64位字段，其中包含32位，时间以秒为单位（“发送时间”秒），以及32位，时间以微秒为单位（“发送时间”秒），因为源保持一些参考时间（通常是1970年1月1日00:00:00）。字段的字节顺序为“大端”网络顺序。接收器使用此时间戳，该时间戳由延迟量调整
from the time they received the NORM_CMD(CC) message to the time of their response as the "grtt_response" portion of NORM_ACK and NORM_NACK messages generated. This allows the sender to evaluate round-trip times to different receivers for congestion control and other (e.g., GRTT determination) purposes.
从收到NORM_CMD（CC）消息到作为生成的NORM_ACK和NORM_NACK消息的“grtt_response”部分进行响应的时间。这允许发送方评估到不同接收方的往返时间，以用于拥塞控制和其他（例如，GRTT确定）目的。
To facilitate the baseline NORM-CC scheme described in Section 5.5.2, a NORM-CC Rate header extension (EXT_RATE) is defined to inform the group of the sender's current transmission rate. This is used along with the loss detection "sequence" field of all NORM sender messages and the NORM_CMD(CC) GRTT collection process to support NORM-CC congestion control operation. The format of this header extension is as follows:
为了促进第5.5.2节中所述的基准NORM-CC方案，定义了NORM-CC速率报头扩展（EXT_Rate），以通知组发送方的当前传输速率。这与所有NORM发送方消息的丢失检测“序列”字段以及NORM_CMD（CC）GRTT收集过程一起使用，以支持NORM-CC拥塞控制操作。此标头扩展的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Rate Header Extension Format (EXT_RATE)
NORM-CC速率头扩展格式（扩展速率）
The "send_rate" field indicates the sender's current transmission rate in bytes per second. The 16-bit "send_rate" field consists of 12 bits of mantissa in the most significant portion and 4 bits of base 10 exponent (order of magnitude) information in the least significant portion. The 12-bit mantissa portion of the field is scaled such that a floating point value of 0.0 corresponds to 0 and a floating point value of 10.0 corresponds to 4096. Thus:
“发送速率”字段表示发送方的当前传输速率（字节/秒）。16位“发送速率”字段包括最高有效部分的12位尾数和最低有效部分的4位10进制指数（数量级）信息。字段的12位尾数部分被缩放，使得0.0的浮点值对应于0，10.0的浮点值对应于4096。因此：
send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) |
Value_exponent;
send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) |
Value_exponent;
For example, to represent a transmission rate of 256kbps (3.2e+04 bytes per second), the lower 4 bits of the 16-bit field contain a value of 0x04 to represent the exponent while the upper 12 bits contain a value of 0x51f as determined from the equation given above:
例如，为了表示256kbps（3.2e+04字节/秒）的传输速率，16位字段的低4位包含表示指数的值0x04，而高12位包含根据上述等式确定的值0x51f：
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4
= (0x51f << 4) | 0x4
= 0x51f4
=0x51f4
To decode the "send_rate" field, the following equation can be used:
要解码“发送速率”字段，可使用以下等式：
value = (send_rate >> 4) * 10.0 / 4096.0 *
power(10.0, (send_rate & x000f))
value = (send_rate >> 4) * 10.0 / 4096.0 *
power(10.0, (send_rate & x000f))
Note the maximum transmission rate that can be represented by this scheme is approximately 9.99e+15 bytes per second.
请注意，此方案可表示的最大传输速率约为每秒9.99e+15字节。
When this extension is present, a "cc_node_list" may be attached as the payload of the NORM_CMD(CC) message. The presence of this header extension also implies that NORM receivers should respond according to the procedures described in Section 5.5.2. The "cc_node_list" consists of a list of NormNodeIds and their associated congestion control status. This includes the current limiting receiver (CLR) node, any potential limiting receiver (PLR) nodes that have been identified, and some number of receivers for which congestion control status is being provided, most notably including the receivers' current RTT measurement. The maximum length of the "cc_node_list" provides for at least the CLR and one other receiver, but may be configurable for more timely feedback to the group. The list length can be inferred from the length of the NORM_CMD(CC) message.
当存在此扩展时，可以附加“cc_node_list”作为NORM_CMD（cc）消息的有效负载。该报头扩展的存在还意味着标准接收机应根据第5.5.2节中描述的程序进行响应。“cc_节点_列表”由normNodeId及其相关拥塞控制状态的列表组成。这包括限流接收器（CLR）节点、已识别的任何潜在限流接收器（PLR）节点，以及为其提供拥塞控制状态的一些接收器，最显著的是包括接收器的当前RTT测量。“cc_节点_列表”的最大长度至少提供CLR和一个其他接收器，但可配置为更及时地反馈给组。列表长度可以从NORM_CMD（CC）消息的长度推断出来。
Each item in the "cc_node_list" is in the following format:
“cc_节点_列表”中的每个项目的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Control Node List Item Format
拥塞控制节点列表项格式
The "cc_node_id" is the NormNodeId of the receiver which the item represents.
“cc_node_id”是该项表示的接收方的NormNodeId。
The "cc_flags" field contains flags indicating the congestion control status of the indicated receiver. The following flags are defined:
“cc_标志”字段包含指示所指示接收器的拥塞控制状态的标志。定义了以下标志：
+------------------+-------+------------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_CLR | 0x01 | Receiver is the current limiting |
| | | receiver (CLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect |
| | | to sender. |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_START| 0x08 | Sender/receiver is in "slow start" phase |
| | | of congestion control operation (i.e., |
| | | The receiver has not yet detected any |
| | | packet loss and the "cc_rate" field is |
| | | the receiver's actual measured receive |
| | | rate). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_LEAVE| 0x10 | Receiver is imminently leaving the |
| | | session and its feedback should not be |
| | | considered in congestion control |
| | | operation. |
+------------------+-------+------------------------------------------+
+------------------+-------+------------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_CLR | 0x01 | Receiver is the current limiting |
| | | receiver (CLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect |
| | | to sender. |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_START| 0x08 | Sender/receiver is in "slow start" phase |
| | | of congestion control operation (i.e., |
| | | The receiver has not yet detected any |
| | | packet loss and the "cc_rate" field is |
| | | the receiver's actual measured receive |
| | | rate). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_LEAVE| 0x10 | Receiver is imminently leaving the |
| | | session and its feedback should not be |
| | | considered in congestion control |
| | | operation. |
+------------------+-------+------------------------------------------+
The "cc_rtt" contains a quantized representation of the RTT as measured by the sender with respect to the indicated receiver. This field is valid only if the NORM_FLAG_CC_RTT flag is set in the "cc_flags" field. This one byte field is a quantized representation of the RTT using the algorithm described in the NORM Building Block document [4]. The "cc_rate" field contains a representation of the receiver's current calculated (during steady-state congestion control operation) or twice its measured (during the "slow start" phase) congestion control rate. This field is encoded and decoded using the same technique as described for the NORM_CMD(CC) "send_rate" field.
“cc_rtt”包含由发送方相对于所指示的接收机测量的rtt的量化表示。只有在“CC_标志”字段中设置了NORM_标志\u CC_RTT标志时，此字段才有效。该单字节字段是RTT的量化表示，使用NORM构建块文档[4]中描述的算法。“cc_速率”字段包含接收机当前计算（在稳态拥塞控制操作期间）或其测量（在“慢启动”阶段）拥塞控制速率两倍的表示。使用与NORM_CMD（CC）“send_rate”字段相同的技术对该字段进行编码和解码。
The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise" its aggregated repair state from NORM_NACK messages accumulated during a repair cycle and/or congestion control feedback received. This message is sent only when the sender has received NORM_NACK and/or NORM_ACK(CC) (when congestion control is enabled) messages via unicast transmission instead of multicast. By "echoing" this information to the receiver set, suppression of feedback can be achieved even when receivers are unicasting that feedback instead of multicasting it among the group [13].
发送方使用NORM_CMD（REPAIR_ADV）消息从修复周期和/或接收到的拥塞控制反馈期间累积的NORM_NACK消息“公布”其聚合修复状态。仅当发送方通过单播传输而不是多播接收到NORM_NACK和/或NORM_ACK（CC）（启用拥塞控制时）消息时，才会发送此消息。通过将该信息“回传”到接收器集，即使接收器单播该反馈而不是在组中多播该反馈，也可以实现反馈抑制[13]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 5 | flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_adv_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 5 | flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_adv_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(REPAIR_ADV) Message Format
NORM\U CMD（修复高级）消息格式
The "instance_id", "grtt", "backoff", "gsize", and "flavor" fields serve the same purpose as in other NORM_CMD messages. The value of the "hdr_len" field when no extensions are present is 4.
“instance_id”、“grtt”、“backoff”、“gsize”和“flavor”字段的用途与其他NORM_CMD消息中的相同。当不存在扩展名时，“hdr_len”字段的值为4。
The "flags" field provide information on the NORM_CMD(REPAIR_ADV) content. There is currently one NORM_CMD(REPAIR_ADV) flag defined:
“标志”字段提供有关NORM_CMD（REPAIR_ADV）内容的信息。当前定义了一个NORM\u CMD（REPAIR\u ADV）标志：
NORM_REPAIR_ADV_FLAG_LIMIT = 0x01
NORM_REPAIR_ADV_FLAG_LIMIT = 0x01
This flag is set by the sender when it is unable to fit its full current repair state into a single NormSegmentSize. If this flag is set, receivers should limit their NACK response to generating NACK content only up through the maximum ordinal transmission position (objectId::fecPayloadId) included in the "repair_adv_content".
当发送方无法将其完整的当前修复状态适应单个大小时，该标志由发送方设置。如果设置了此标志，接收器应将其NACK响应限制为仅在“修复adv_内容”中包含的最大顺序传输位置（objectId:：fecPayloadId）上生成NACK内容。
When congestion control operation is enabled, a header extension may be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting (in terms of congestion control feedback suppression) congestion control response. This allows the NORM_CMD(REPAIR_ADV) message to suppress receiver congestion control responses as well as NACK feedback messages. The field is defined as a header extension so that alternative congestion control schemes may be used with NORM without revision to this document. A NORM-CC Feedback Header Extension (EXT_CC) is defined to encapsulate congestion control feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV) messages. If another congestion control technique (e.g., Pragmatic General Multicast Congestion Control (PGMCC) [20]) is used within a
当启用拥塞控制操作时，可以将标头扩展应用于表示最大限制（就拥塞控制反馈抑制而言）拥塞控制响应的NORM_CMD（REPAIR_ADV）。这允许NORM_CMD（REPAIR_ADV）消息抑制接收器拥塞控制响应以及NACK反馈消息。该字段被定义为标头扩展，因此替代拥塞控制方案可与NORM一起使用，而无需对本文档进行修订。定义了一个NORM-CC反馈头扩展（EXT_-CC），用于将拥塞控制反馈封装在NORM_NACK、NORM_ACK和NORM_CMD（REPAIR_ADV）消息中。如果在网络中使用另一种拥塞控制技术（例如，实用通用多播拥塞控制（PGMCC）[20]）
NORM implementation, an additional header extension MAY need to be defined to encapsulate any required feedback content. The NORM-CC Feedback Header Extension format is:
在规范实现中，可能需要定义额外的头扩展来封装任何所需的反馈内容。NORM-CC反馈标头扩展格式为：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Feedback Header Extension (EXT_CC) Format
NORM-CC反馈标头扩展（EXT_CC）格式
The "cc_sequence" field contains the current greatest "cc_sequence" value receivers have received in NORM_CMD(CC) messages from the sender. This information assists the sender in congestion control operation by providing an indicator of how current ("fresh") the receiver's round-trip measurement reference time is and whether the receiver has been successfully receiving recent congestion control probes. For example, if it is apparent the receiver has not been receiving recent congestion control probes (and thus possibly other messages from the sender), the sender may choose to take congestion avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_sequence" field value to the value set in the last NORM_CMD(CC) message sent.
“cc_sequence”字段包含接收方从发送方收到的NORM_CMD（cc）消息中当前最大的“cc_sequence”值。此信息通过提供接收器往返测量参考时间的当前（“新鲜”）程度以及接收器是否已成功接收最近的拥塞控制探测的指示器，帮助发送方进行拥塞控制操作。例如，如果接收方显然没有收到最近的拥塞控制探测（因此可能没有收到来自发送方的其他消息），发送方可以选择采取拥塞避免措施。对于NORM_CMD（REPAIR_ADV）消息，发送方应将“cc_sequence”字段值设置为上次发送的NORM_CMD（cc）消息中设置的值。
The "cc_flags" field contains bits representing the receiver's state with respect to congestion control operation. The possible values for the "cc_flags" field are those specified for the NORM_CMD(CC) message node list item flags. These fields are used by receivers in controlling (suppressing as necessary) their congestion control feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT should be set only when all feedback messages received by the sender have the flag set. Similarly, the NORM_FLAG_CC_CLR or NORM_FLAG_CC_PLR should be set only when no feedback has been received from non-CLR or non-PLR receivers. And the NORM_FLAG_CC_LEAVE should be set only when all feedback messages the sender has received have this flag set. These heuristics for setting the flags in NORM_CMD(REPAIR_ADV) ensure the most effective suppression of receivers providing unicast feedback messages.
“cc_flags”字段包含表示接收器关于拥塞控制操作的状态的位。“cc_flags”字段的可能值是为NORM_CMD（cc）消息节点列表项标志指定的值。接收机使用这些字段来控制（必要时抑制）其拥塞控制反馈。对于NORM_CMD（REPAIR_ADV）消息，只有当发送方收到的所有反馈消息都设置了该标志时，才应设置NORM_FLAG_CC_RTT。类似地，仅当未收到来自非CLR或非PLR接收器的反馈时，才应设置NORM_FLAG_CC_CLR或NORM_FLAG_CC_PLR。只有当发送方收到的所有反馈消息都设置了此标志时，才应设置NORM_FLAG_CC_LEAVE。这些用于在NORM_CMD（REPAIR_ADV）中设置标志的启发式方法确保最有效地抑制提供单播反馈消息的接收器。
The "cc_rtt" field SHALL be set to a default maximum value and the NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet received RTT measurement information. When a receiver has received RTT measurement information, it shall set the "cc_rtt" value accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags" field.
“cc_rtt”字段应设置为默认的最大值，当没有接收机接收到rtt测量信息时，应清除NORM_FLAG_cc_rtt标志。当接收器接收到RTT测量信息时，应相应地设置“cc_RTT”值，并在“cc_标志”字段中设置NORM_标志\u cc_RTT标志。
For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has measured from receivers for the current feedback round.
对于NORM_CMD（REPAIR_ADV）消息，发送方应将“cc_rtt”字段值设置为其在当前反馈回合中从接收方测得的最大非CLR/非PLR rtt。
The "cc_loss" field represents the receiver's current packet loss fraction estimate for the indicated source. The loss fraction is a value from 0.0 to 1.0 corresponding to a range of zero to 100 percent packet loss. The 16-bit "cc_loss" value is calculated by the following formula:
“cc_loss”字段表示指定源的接收器当前分组丢失分数估计值。丢失分数是0.0到1.0之间的值，对应于0到100%的分组丢失范围。16位“cc_损耗”值通过以下公式计算：
"cc_loss" = decimal_loss_fraction * 65535.0
“cc_损失”=十进制_损失分数*65535.0
For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" field value to the largest non-CLR/non-PLR loss estimate it has received from receivers for the current feedback round.
对于NORM_CMD（REPAIR_ADV）消息，发送方应将“cc_loss”字段值设置为其在当前反馈回合中从接收方收到的最大非CLR/非PLR损失估计值。
The "cc_rate" field represents the receivers current local congestion control rate. During "slow start", when the receiver has detected no loss, this value is set to twice the actual rate it has measured from the corresponding sender and the NORM_FLAG_CC_START is set in the "cc_flags' field. Otherwise, the receiver calculates a congestion control rate based on its loss measurement and RTT measurement information (even if default) for the "cc_rate" field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" field value to the lowest non-CLR/non-PLR "cc_rate" report it has received from receivers for the current feedback round.
“cc_速率”字段表示接收器当前的本地拥塞控制速率。在“慢速启动”期间，当接收器未检测到任何丢失时，该值被设置为其从相应发送方测得的实际速率的两倍，并且在“CC_标志”字段中设置NORM_FLAG_CC_start。否则，接收器根据其丢失测量和RTT测量信息计算拥塞控制速率（即使是默认值）对于“抄送率”字段。对于NORM_CMD（REPAIR_ADV）消息，发送方应将“抄送率丢失”字段值设置为其在当前反馈回合中从接收方收到的最低非CLR/非PLR“抄送率”报告。
The "cc_reserved" field is reserved for future NORM protocol use. Currently, senders SHALL set this field to ZERO, and receivers SHALL ignore the content of this field.
“cc_reserved”（cc_reserved）字段保留供将来的NORM协议使用。目前，发送方应将此字段设置为零，接收方应忽略此字段的内容。
The "repair_adv_payload" is in exactly the same form as the "nack_content" of NORM_NACK messages and can be processed by receivers for suppression purposes in the same manner, with the exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is set.
“repair_adv_payload”的形式与NORM_nack消息的“nack_内容”完全相同，并且可以由接收机以相同的方式处理以用于抑制目的，但设置NORM_repair_adv_FLAG_LIMIT时的情况除外。
The NORM_CMD(ACK_REQ) message is used by the sender to request acknowledgment from a specified list of receivers. This message is used in providing a lightweight positive acknowledgment mechanism that is OPTIONAL for use by the reliable multicast application. A range of acknowledgment request types is provided for use at the application's discretion. Provision for application-defined, positively-acknowledged commands allows the application to automatically take advantage of transmission and round-trip timing information available to the NORM protocol. The details of the NORM
发送方使用NORM_CMD（ACK_REQ）消息从指定的接收方列表请求确认。此消息用于提供轻量级肯定确认机制，该机制可供可靠多播应用程序选择使用。提供了一系列确认请求类型，供应用程序自行决定使用。提供应用程序定义的肯定确认命令，允许应用程序自动利用NORM协议可用的传输和往返定时信息。规范的细节
positive acknowledgment process including transmission of the NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ) message is:
第5.5.3节描述了包括发送NORM_CMD（ACK_REQ）消息和接收器响应（NORM_ACK）在内的肯定确认过程。NORM_CMD（ACK_REQ）消息的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(ACK_REQ) Message Format
NORM\U CMD（确认请求）消息格式
The NORM common message header and standard NORM_CMD fields serve their usual purposes. The value of the "hdr_len" field for NORM_CMD(ACK_REQ) messages with no header extension present is 4.
NORM common message header和标准NORM_CMD字段用于其通常用途。不存在头扩展名的NORM_CMD（ACK_REQ）消息的“hdr_len”字段的值为4。
The "ack_type" field indicates the type of acknowledgment being requested and thus implies rules for how the receiver will treat this request. The following "ack_type" values are defined and are also used in NORM_ACK messages described later:
“ack_type”（确认类型）字段表示所请求的确认类型，因此暗示了接收方将如何处理该请求的规则。定义了以下“确认类型”值，并在下文描述的正常确认消息中使用这些值：
+---------------------+--------+---------------------------------+
| ACK Type | Value | Purpose |
+---------------------+--------+---------------------------------+
|NORM_ACK_CC | 1 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(CC) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(FLUSH) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_RESERVED | 3-15 | Reserved for possible future |
| | | NORM protocol use. |
+---------------------+--------+---------------------------------+
|NORM_ACK_APPLICATION | 16-255 | Used at application's |
| | | discretion. |
+---------------------+--------+---------------------------------+
+---------------------+--------+---------------------------------+
| ACK Type | Value | Purpose |
+---------------------+--------+---------------------------------+
|NORM_ACK_CC | 1 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(CC) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(FLUSH) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_RESERVED | 3-15 | Reserved for possible future |
| | | NORM protocol use. |
+---------------------+--------+---------------------------------+
|NORM_ACK_APPLICATION | 16-255 | Used at application's |
| | | discretion. |
+---------------------+--------+---------------------------------+
The NORM_ACK_CC value is provided for use only in NORM_ACKs generated in response to the NORM_CMD(CC) messages used in congestion control operation. Similarly, the NORM_ACK_FLUSH is provided for use only in NORM_ACKs generated in response to applicable NORM_CMD(FLUSH) messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC or NORM_ACK_FLUSH SHALL NOT be generated by the sender.
NORM_ACK_CC值仅用于响应拥塞控制操作中使用的NORM_CMD（CC）消息而生成的NORM_ACK。类似地，NORM_ACK_FLUSH仅用于响应适用NORM_CMD（FLUSH）消息而生成的NORM_ACKs。发送方不得生成“确认类型”为NORM_ACK_CC或NORM_ACK_FLUSH的NORM_CMD（ACK_REQ）消息。
The NORM_ACK_RESERVED range of "ack_type" values is provided for possible future NORM protocol use.
“确认类型”值的NORM_ACK_保留范围是为将来可能的NORM协议使用而提供的。
The NORM_ACK_APPLICATION range of "ack_type" values is provided so that NORM applications may implement application-defined, positively-acknowledged commands that are able to leverage internal transmission and round-trip timing information available to the NORM protocol implementation.
提供“ACK类型”值的NORM_ACK_应用范围，以便NORM应用程序可以实现应用程序定义的、肯定确认的命令，这些命令能够利用NORM协议实现可用的内部传输和往返定时信息。
The "ack_id" provides a sequenced identifier for the given NORM_CMD(ACK_REQ) message. This "ack_id" is returned in NORM_ACK messages generated by the receivers so that the sender may associate the response with its corresponding request.
“ack_id”为给定的NORM_CMD（ack_REQ）消息提供顺序标识符。该“ack_id”在接收方生成的NORM_ack消息中返回，以便发送方可以将响应与其相应的请求相关联。
The "reserved" field is reserved for possible future protocol use and SHALL be set to ZERO by senders and ignored by receivers.
“保留”字段是为将来可能的协议使用而保留的，发送方应将其设置为零，接收方应忽略该字段。
The "acking_node_list" field contains the NormNodeIds of the current NORM receivers that are desired to provide positive acknowledge (NORM_ACK) to this request. The packet payload length implies the length of the "acking_node_list" and its length is limited to the sender NormSegmentSize. The individual NormNodeId items are listed in network (Big Endian) byte order. If a receiver's NormNodeId is included in the "acking_node_list", it SHALL schedule transmission of a NORM_ACK message as described in Section 5.5.3.
“确认节点列表”字段包含当前NORM接收器的NORMNODEID，这些NORMNODEID需要向该请求提供肯定确认（NORM确认）。数据包有效负载长度表示“确认节点列表”的长度，其长度限制为发送方大小。各个NormNodeId项以网络（大端）字节顺序列出。如果接收器的NormNodeId包含在“确认节点列表”中，则其应按照第5.5.3节所述计划发送NormNodeId消息。
This command allows the NORM application to robustly transmit application-defined commands. The command message preempts any ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR times at a rate of once per 2*GRTT. This rate of repetition allows the application to observe any response (if that is the application's purpose for the command) before it is repeated. Possible responses may include initiation of data transmission, other NORM_CMD(APPLICATION) messages, or even application-defined, positively-acknowledge commands from other NormSession participants. The transmission of these commands will preempt data transmission when they are scheduled and may be multiplexed with ongoing data transmission. This type of robustly transmitted command allows NORM applications to define a complete set of session control mechanisms
此命令允许NORM应用程序可靠地传输应用程序定义的命令。命令消息抢占任何正在进行的数据传输，并以每2*GRTT一次的速率重复至正常稳健因子次数。此重复率允许应用程序在重复之前观察任何响应（如果这是应用程序执行命令的目的）。可能的响应可能包括启动数据传输、其他NORM_CMD（应用程序）消息，甚至是应用程序定义的，肯定地确认来自其他NormSession参与者的命令。这些命令的传输将在调度时抢占数据传输，并可与正在进行的数据传输进行多路复用。这种类型的健壮传输命令允许NORM应用程序定义一套完整的会话控制机制
with less state than the transfer of FEC encoded reliable content requires while taking advantage of NORM transmission and round-trip timing information.
使用比FEC编码的可靠内容传输所需的状态更少的状态，同时利用范数传输和往返定时信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 7 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-Defined Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 7 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-Defined Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(APPLICATION) Message Format
NORM_CMD（应用程序）消息格式
The NORM common message header and NORM_CMD fields are interpreted as previously described. The value of the NORM_CMD(APPLICATION) "hdr_len" field when no header extensions are present is 4.
NORM common message header和NORM_CMD字段的解释如上所述。当不存在标头扩展名时，NORM_CMD（APPLICATION）“hdr_len”字段的值为4。
The "Application-Defined Content" area contains information in a format at the discretion of the application. The size of this payload SHALL be limited to a maximum of the sender's NormSegmentSize setting.
“应用程序定义的内容”区域包含应用程序自行决定格式的信息。该有效载荷的大小应限制在发送器的最大尺寸设置范围内。
The NORM message types generated by participating receivers consist of NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent to request repair of missing data content from sender transmission and NORM_ACK messages are generated in response to certain sender commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).
参与接收方生成的NORM消息类型包括NORM_NACK和NORM_ACK消息类型。发送NORM_NACK消息以请求修复发送方传输中丢失的数据内容，并生成NORM_ACK消息以响应特定发送方命令，包括NORM_CMD（CC）和NORM_CMD（ACK_REQ）。
The principal purpose of NORM_NACK messages is for receivers to request repair of sender content via selective, negative acknowledgment upon detection of incomplete data. NORM_NACK messages will be transmitted according to the rules of NORM_NACK generation and suppression described in Section 5.3. NORM_NACK messages also contain additional fields to provide feedback to the sender(s) for purposes of round-trip timing collection and congestion control.
NORM_NACK消息的主要目的是，接收方在检测到不完整数据时，通过选择性的否定确认请求修复发送方内容。NORM_NACK消息将根据第5.3节中描述的NORM_NACK生成和抑制规则进行传输。NORM_NACK消息还包含其他字段，用于向发送方提供反馈，以实现往返定时收集和拥塞控制。
The payload of NORM_NACK messages contains one or more repair requests for different objects or portions of those objects. The NORM_NACK message format is as follows:
NORM_NACK消息的有效负载包含针对不同对象或这些对象的部分的一个或多个修复请求。NORM_NACK消息格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=4| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nack_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=4| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nack_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_NACK Message Format
标准NACK消息格式
The NORM common message header fields serve their usual purposes. The value of the "hdr_len" field for NORM_NACK messages without header extensions present is 6.
NORM common message header字段用于其通常用途。对于不存在头扩展名的NORM_NACK消息，“hdr_len”字段的值为6。
The "server_id" field identifies the NORM sender to which the NORM_NACK message is destined.
“server_id”字段标识NORM_NACK消息发送到的NORM发送方。
The "instance_id" field contains the current session identifier given by the sender identified by the "server_id" field in its sender messages. The sender SHOULD ignore feedback messages which contain an invalid "instance_id" value.
“instance_id”字段包含由发送方消息中的“server_id”字段标识的发送方提供的当前会话标识符。发件人应忽略包含无效“实例id”值的反馈消息。
The "grtt_response" fields contain an adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender. The format of the "grtt_response" is the same as the "send_time" field of the NORM_CMD(CC). The "grtt_response" value is _relative_ to the "send_time" the source provided with a corresponding NORM_CMD(CC) command. The receiver adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the time differential from when the receiver received the NORM_CMD(CC)
“grtt_response”（grtt_response）字段包含所指示的NORM发送方最近收到的NORM_CMD（CC）消息的时间戳的调整版本。“grtt_响应”的格式与NORM_CMD（CC）的“发送_时间”字段相同。“grtt_response”值与“send_time”相对，源提供了相应的NORM_CMD（CC）命令。接收机通过添加接收机接收到NORM_CMD（CC）时的时间差来调整源的NORM_CMD（CC）“send_time”时间戳
to when the NORM_NACK is transmitted to calculate the value in the "grtt_response" field. This is the "receive_to_response_differential" value used in the following formula:
当传输NORM_NACK以计算“grtt_响应”字段中的值时。这是以下公式中使用的“接收\响应\微分”值：
"grtt_response" = NORM_CMD(CC) "send_time" + receive_to_response_differential
“grtt\U响应”=标准命令（CC）“发送时间”+接收到响应
The receiver SHALL set the "grtt_response" to a ZERO value, to indicate that it has not yet received a NORM_CMD(CC) message from the indicated sender and that the sender should ignore the "grtt_response" in this message.
接收方应将“grtt_响应”设置为零值，以表明其尚未收到来自指定发送方的NORM_CMD（CC）消息，且发送方应忽略该消息中的“grtt_响应”。
For NORM-CC operation, the NORM-CC Feedback Header Extension, as described in the NORM_CMD(REPAIR_ADV} message description, is added to NORM_NACK messages to provide feedback on the receivers current state with respect to congestion control operation. Note that alternative header extensions for congestion control feedback may be defined for alternative congestion control schemes for NORM use in the future.
对于NORM-CC操作，NORM-CC反馈标头扩展，如NORM_CMD中所述（REPAIR_ADV}消息描述添加到NORM_NACK消息中，以提供有关拥塞控制操作的接收器当前状态的反馈。请注意，拥塞控制反馈的可选报头扩展可能会为将来使用NORM的可选拥塞控制方案定义。
The "reserved" field is for potential future NORM use and SHALL be set to ZERO for this version of the protocol.
“保留”字段用于未来可能的规范使用，对于本版本的协议，应设置为零。
The "nack_content" of the NORM_NACK message specifies the repair needs of the receiver with respect to the NORM sender indicated by the "server_id" field. The receiver constructs repair requests based on the NORM_DATA and/or NORM_INFO segments it requires from the sender in order to complete reliable reception up to the sender's transmission position at the moment the receiver initiates the NACK Procedure as described in Section 5.3. A single NORM Repair Request consists of a list of items, ranges, and/or FEC coding block erasure counts for needed NORM_DATA and/or NORM_INFO content. Multiple repair requests may be concatenated within the "nack_payload" field of a NORM_NACK message. Note that a single NORM Repair Request can possibly include multiple "items", "ranges", or "erasure_counts". In turn, the "nack_payload" field may contain multiple repair requests. A single NORM Repair Request has the following format:
NORM_nack消息的“nack_内容”指定了接收者相对于“server_id”字段指示的NORM发送者的修复需求。接收方根据其要求的发送方的NORM_数据和/或NORM_信息段构造修复请求，以便在接收方启动第5.3节所述NACK程序时，完成可靠接收，直至发送方的传输位置。单个定额修复请求由所需定额数据和/或定额信息内容的项目、范围和/或FEC编码块擦除计数列表组成。多个修复请求可以在NORM_nack消息的“nack_有效载荷”字段内串联。请注意，单个标准修复请求可能包括多个“项目”、“范围”或“擦除计数”。反过来，“nack_有效载荷”字段可能包含多个修复请求。单个标准维修请求具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form | flags | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_request_items |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form | flags | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_request_items |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Repair Request Format
标准维修请求格式
The "form" field indicates the type of repair request items given in the "repair_request_items" list. Possible values for the "form" field include:
“表格”字段表示“维修申请项目”列表中给出的维修申请项目类型。“表单”字段的可能值包括：
Form Value NORM_NACK_ITEMS 1 NORM_NACK_RANGES 2 NORM_NACK_ERASURES 3
表值NORM\u NACK\u项目1 NORM\u NACK\u范围2 NORM\u NACK\u擦除3
A "form" value of NORM_NACK_ITEMS indicates each repair request item in the "repair_request_items" list is to be treated as an individual request. A value of NORM_NACK_RANGES indicates that the "repair_request_items" list consists of pairs of repair request items that correspond to inclusive ranges of repair needs. And the NORM_NACK_ERASURES "form" indicates that the repair request items are to be treated individually and that the "encoding_symbol_id" portion of the "fec_payload_id" field of the repair request item (see below) is to be interpreted as an "erasure count" for the FEC coding block identified by the repair request item's "source_block_number".
NORM_NACK_项目的“form”值表示“repair_request_ITEMS”列表中的每个修理请求项目将被视为一个单独的请求。NORM_NACK_RANGES的值表示“修理请求项目”列表由修理请求项目对组成，这些项目对应于修理需求的包含范围。并且，NORM_NACK_擦除“形式”指示要单独处理修复请求项，并且修复请求项的“fec_有效载荷_id”字段（参见下文）的“编码符号_id”部分将被解释为由修复请求项的“源_块编号”标识的fec编码块的“擦除计数”。
The "flags" field is currently used to indicate the level of data content for which the repair request items apply (i.e., an individual segment, entire FEC coding block, or entire transport object). Possible flag values include:
“标志”字段当前用于指示维修请求项适用的数据内容级别（即，单个段、整个FEC编码块或整个传输对象）。可能的标志值包括：
+------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+-----------------------------------------+
|NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range|
| | | of segments are required as repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range |
| | | of blocks in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_INFO | 0x04 | Indicates that NORM_INFO is required as |
| | | repair for the listed object(s). |
+------------------+-------+-----------------------------------------+
|NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or range |
| | | of objects in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
+------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+-----------------------------------------+
|NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range|
| | | of segments are required as repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range |
| | | of blocks in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_INFO | 0x04 | Indicates that NORM_INFO is required as |
| | | repair for the listed object(s). |
+------------------+-------+-----------------------------------------+
|NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or range |
| | | of objects in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and "fec_payload_id" fields are used to determine which sets or ranges of individual NORM_DATA segments are needed to repair content at the
当设置NORM_NACK_段标志时，“object_transport_id”和“fec_payload_id”字段用于确定需要哪些集合或范围的单个NORM_数据段来修复当前位置的内容
receiver. When the NORM_NACK_BLOCK flag is set, this indicates the receiver is completely missing the indicated coding block(s) and requires transmissions sufficient to repair the indicated block(s) in their entirety. When the NORM_NACK_INFO flag is set, this indicates the receiver is missing the NORM_INFO segment for the indicated "object_transport_id". Note the NORM_NACK_INFO may be set in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or may be set alone. When the NORM_NACK_OBJECT flag is set, this indicates the receiver is missing the entire NormTransportObject referenced by the "object_transport_id". This also implicitly requests any available NORM_INFO for the NormObject, if applicable. The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT is set.
接受者当设置NORM_NACK_块标志时，这表示接收器完全丢失所指示的编码块，并且需要足够的传输来修复全部所指示的块。当设置了NORM_NACK_INFO标志时，这表示接收器缺少指示的“对象传输id”的NORM_INFO段。注：NORM_-NACK_信息可以与NORM_-NACK_块或NORM_-NACK_段标志一起设置，也可以单独设置。当设置NORM_NACK_OBJECT标志时，这表示接收器缺少“OBJECT_transport_id”引用的整个NormTransportObject。这还隐式地请求NormObject的任何可用NORM_信息（如果适用）。当设置标志NORM_NACK_对象时，“fec_有效负载_id”字段被忽略。
The "length" field value is the length in bytes of the "repair_request_items" field.
“长度”字段值是“修复请求项目”字段的长度（字节）。
The "repair_request_items" field consists of a list of individual or range pairs of transport data unit identifiers in the following format.
“修复请求项目”字段由以下格式的单个或范围对传输数据单元标识符列表组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Repair Request Item Format
标准维修请求项目格式
The "fec_id" indicates the FEC type and can be used to determine the format of the "fec_payload_id" field. The "reserved" field is kept for possible future use and SHALL be set to a ZERO value and ignored by NORM nodes processing NACK content.
“fec_id”表示fec类型，可用于确定“fec_有效负载_id”字段的格式。保留“保留”字段以备将来可能使用，并应设置为零值，由处理NACK内容的NORM节点忽略。
The "object_transport_id" corresponds to the NormObject for which repair is being requested and the "fec_payload_id" identifies the specific FEC coding block and/or segment being requested. When the NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code block identifier portion of the "fec_payload_id" is to be interpreted.
“object_transport_id”对应于正在请求修复的对象，“fec_payload_id”标识正在请求的特定fec编码块和/或段。当设置NORM_NACK_OBJECT标志时，“fec_payload_id”字段的值被忽略。当设置NORM_NACK_块标志时，仅解释“FEC_有效负载_id”的FEC码块标识符部分。
The format of the "fec_payload_id" field depends upon the "fec_id" field value.
“fec_有效负载_id”字段的格式取决于“fec_id”字段值。
When the receiver's repair needs dictate that different forms (mixed ranges and/or individual items) or types (mixed specific segments and/or blocks or objects in entirety) are required to complete reliable transmission, multiple NORM Repair Requests with different "form" and or "flags" values can be concatenated within a single NORM_NACK message. Additionally, NORM receivers SHALL construct NORM_NACK messages with their repair requests in ordinal order with respect to "object_transport_id" and "fec_payload_id" values. The "nack_payload" size SHALL NOT exceed the NormSegmentSize for the sender to which the NORM_NACK is destined.
当接收机的维修需求要求不同的形式（混合范围和/或单个项目）或类型（混合特定段和/或块或对象整体）来完成可靠传输时，具有不同“形式”和/或“标志”的多个定额维修请求值可以在单个NORM_NACK消息中串联。此外，NORM接收器应按照“对象传输id”和“fec有效负载id”值的顺序构造NORM_NACK消息及其修复请求。“nack_有效载荷”大小不得超过NORM_nack目的地发送方的NORMSECTIONSIZE。
NORM_NACK Content Examples:
NORM_NACK内容示例：
In these examples, a small block, systematic FEC code ("fec_id" = 129) is assumed with a user data block length of 32 segments. In Example 1, a list of individual NORM_NACK_ITEMS repair requests is given. In Example 2, a list of NORM_NACK_RANGES requests _and_ a single NORM_NACK_ITEMS request are concatenated to illustrate the possible content of a NORM_NACK message. Note that FEC coding block erasure counts could also be provided in each case. However, the erasure counts are not really necessary since the sender can easily determine the erasure count while processing the NACK content. However, the erasure count option may be useful for operation with other FEC codes or for intermediate system purposes.
在这些示例中，假设用户数据块长度为32段的小块系统FEC代码（“FEC_id”=129）。在示例1中，给出了单个NORM_NACK_项目修复请求的列表。在示例2中，将NORM_NACK_范围请求列表和单个NORM_NACK_项请求连接起来，以说明NORM_NACK消息的可能内容。注意，在每种情况下也可以提供FEC编码块擦除计数。然而，由于发送方在处理NACK内容时可以容易地确定擦除计数，因此擦除计数实际上不是必需的。然而，擦除计数选项可用于与其他FEC代码的操作或用于中间系统目的。
Example 1: NORM_NACK "nack_payload" for: Object 12, Coding Block 3, Segments 2,5,8
示例1:NORM_NACK“NACK_payload”用于：对象12，编码块3，段2,5,8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x01 | length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x01 | length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 2: NORM_NACK "nack_payload" for: Object 18 Coding Block 6, Segments 5, 6, 7, 8, 9, 10; and Object 19 NORM_INFO and Coding Block 1, segment 3
示例2:NORM_NACK“NACK_payload”用于：对象18编码块6，段5、6、7、8、9、10；以及对象19 NORM_信息和编码块1，段3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 2 | flags = 0x01 | length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x05 | length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 2 | flags = 0x01 | length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x05 | length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NORM_ACK message is intended to be used primarily as part of NORM congestion control operation and round-trip timing measurement. As mentioned in the NORM_CMD(ACK_REQ) message description, the acknowledgment type NORM_ACK_CC is provided for this purpose. The generation of NORM_ACK(CC) messages for round-trip timing estimation and congestion-control operation is described in Sections 5.5.1 and 5.5.2, respectively. However, some multicast applications may benefit from some limited form of positive acknowledgment for certain functions. A simple, scalable positive acknowledgment scheme is defined in Section 5.5.3 that can be leveraged by protocol implementations when appropriate. The NORM_CMD(FLUSH) may be used for OPTIONAL collection of positive acknowledgment of reliable reception to a certain "watermark" transmission point from specific receivers using this mechanism. The NORM_ACK type NORM_ACK_FLUSH is provided for this purpose and the format of the "nack_payload" for this acknowledgment type is given below. Beyond that, a range of
NORM_ACK消息主要用作NORM拥塞控制操作和往返计时测量的一部分。如NORM_CMD（ACK_REQ）消息描述中所述，为此目的提供了确认类型NORM_ACK_CC。第5.5.1节和第5.5.2节分别描述了用于往返时间估计和拥塞控制操作的NORM_ACK（CC）消息的生成。然而，对于某些功能，某些多播应用程序可能受益于某种有限形式的肯定确认。第5.5.3节定义了一个简单、可扩展的肯定确认方案，协议实现可在适当时利用该方案。NORM_CMD（FLUSH）可用于使用该机制从特定接收器向特定“水印”传输点选择性收集可靠接收的肯定确认。为此提供了NORM_ACK类型NORM_ACK_FLUSH，下面给出了该确认类型的“nack_有效载荷”格式。除此之外，还有一系列
application-defined "ack_type" values is provided for use at the NORM application's discretion. Implementations making use of application-defined positive acknowledgments may also make use the "nack_payload" as needed, observing the constraint that the "nack_payload" field size be limited to a maximum of the NormSegmentSize for the sender to which the NORM_ACK is destined.
应用程序定义的“确认类型”值由标准应用程序自行决定使用。使用应用程序定义的肯定确认的实现也可以根据需要使用“nack_有效载荷”，注意“nack_有效载荷”字段大小被限制为NORM_ACK目的地的发送方normsecgmentsize的最大值的约束。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=5| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ack_payload (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=5| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ack_payload (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_ACK Message Format
标准确认报文格式
The NORM common message header fields serve their usual purposes.
NORM common message header字段用于其通常用途。
The "server_id", "instance_id", and "grtt_response" fields serve the same purpose as the corresponding fields in NORM_NACK messages. And header extensions may be applied to support congestion control feedback or other functions in the same manner.
“服务器id”、“实例id”和“grtt_响应”字段的用途与NORM_NACK消息中的相应字段相同。报头扩展可以以相同的方式应用于支持拥塞控制反馈或其他功能。
The "ack_type" field indicates the nature of the NORM_ACK message. This directly corresponds to the "ack_type" field of the NORM_CMD(ACK_REQ) message to which this acknowledgment applies.
“确认类型”字段表示正常确认消息的性质。这直接对应于此确认适用的NORM_CMD（ack_REQ）消息的“ack_type”字段。
The "ack_id" field serves as a sequence number so that the sender can verify that a NORM_ACK message received actually applies to a current acknowledgment request. The "ack_id" field is not used in the case of the NORM_ACK_CC and NORM_ACK_FLUSH acknowledgment types.
“ack_id”字段用作序列号，以便发送方可以验证收到的NORM_ack消息是否实际应用于当前确认请求。“确认id”字段不用于NORM_ack_CC和NORM_ack_FLUSH确认类型。
The "ack_payload" format is a function of the "ack_type". The NORM_ACK_CC message has no attached content. Only the NORM_ACK header applies. In the case of NORM_ACK_FLUSH, a specific "ack_payload" format is defined:
“确认有效载荷”格式是“确认类型”的函数。NORM_ACK_CC消息没有附加内容。只有NORM_ACK头适用。在NORM_ACK_FLUSH的情况下，定义了特定的“ACK_payload”格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_ACK_FLUSH "ack_payload" Format
正常确认刷新“确认有效载荷”格式
The "object_transport_id" and "fec_payload_id" are used by the receiver to acknowledge applicable NORM_CMD(FLUSH) messages transmitted by the sender identified by the "server_id" field.
接收方使用“对象\传输\ id”和“fec\ U有效负载\ id”确认由“服务器\ id”字段标识的发送方发送的适用NORM\ U CMD（FLUSH）消息。
The "ack_payload" of NORM_ACK messages for application-defined "ack_type" values is specific to the application but is limited in size to a maximum the NormSegmentSize of the sender referenced by the "server_id".
应用程序定义的“确认类型”值的NORM_ack消息的“确认有效负载”特定于应用程序，但其大小限制为“服务器id”引用的发送方NORMSECTIONSIZE的最大大小。
Some additional message formats are defined for general purpose in NORM multicast sessions whether the participant is acting as a sender and/or receiver within the group.
在NORM多播会话中定义了一些附加的消息格式，以供通用，无论参与者是作为组内的发送者和/或接收者。
This is an optional message generated by NORM participants. This message could be used for periodic performance reports from receivers in experimental NORM implementations. The format of this message is currently undefined. Experimental NORM implementations may define NORM_REPORT formats as needed for test purposes. These report messages SHOULD be disabled for interoperability testing between different NORM implementations.
这是NORM参与者生成的可选消息。此消息可用于实验性规范实现中接收器的定期性能报告。此邮件的格式当前未定义。实验性的NORM实现可以根据测试需要定义NORM_报告格式。对于不同NORM实现之间的互操作性测试，应禁用这些报告消息。
This section describes the detailed interactions of senders and receivers participating in a NORM session. A simple synopsis of protocol operation is given here:
本节描述参与NORM会话的发送方和接收方之间的详细交互。此处给出了协议操作的简单概要：
1) The sender periodically transmits NORM_CMD(CC) messages as needed to initialize and collect roundtrip timing and congestion control feedback from the receiver set.
1) 发送方根据需要定期发送NORM_CMD（CC）消息，以初始化并从接收方收集往返时间和拥塞控制反馈。
2) The sender transmits an ordinal set of NormObjects segmented in the form of NORM_DATA messages labeled with NormTransportIds and logically identified with FEC encoding block numbers and symbol identifiers. NORM_INFO messages may optionally precede the transmission of data content for NORM transport objects.
2) 发送方发送一组有序的NormObjects，这些NormObjects以NormTransportIds标记的NORM_数据消息的形式分段，并用FEC编码块号和符号标识符进行逻辑标识。NORM_INFO消息可以选择性地先于NORM传输对象的数据内容的传输。
3) As receivers detect missing content from the sender, they initiate repair requests with NORM_NACK messages. Note the receivers track the sender's most recent objectId::fecPayloadId transmit position and NACK _only_ for content ordinally prior to that transmit position. The receivers schedule random backoff timeouts before generating NORM_NACK messages and wait an appropriate amount of time before repeating the NORM_NACK if their repair request is not satisfied.
3) 当接收者检测到发送者丢失的内容时，他们会使用NORM_NACK消息发起修复请求。注意：接收者跟踪发送者最新的objectId:：fecPayloadId传输位置，然后依次跟踪该传输位置之前内容的NACK u。接收机在生成NORM_-NACK消息之前安排随机退避超时，如果不满足其修复请求，则在重复NORM_-NACK之前等待适当的时间。
4) The sender aggregates repair requests from the receivers and logically "rewinds" its transmit position to send appropriate repair messages. The sender sends repairs for the earliest ordinal transmit position first and maintains this ordinal repair transmission sequence. Previously untransmitted FEC parity content for the applicable FEC coding block is used for repair transmissions to the greatest extent possible. If the sender exhausts its available FEC parity content on multiple repair cycles for the same coding block, it resorts to an explicit repair strategy (possibly using parity content) to complete repairs. (The use of explicit repair is expected to be an exception in general protocol operation, but the possibility does exist for extreme conditions). The sender immediately assumes transmission of new content once it has sent pending repairs.
4) 发送方聚合来自接收方的修复请求，并在逻辑上“倒带”其发送位置，以发送适当的修复消息。发送方首先发送对最早顺序传输位置的修复，并保持该顺序修复传输顺序。适用FEC编码块的先前未传送的FEC奇偶校验内容用于尽可能大的修复传输。如果发送方在同一编码块的多个修复周期中耗尽其可用的FEC奇偶校验内容，则它求助于显式修复策略（可能使用奇偶校验内容）来完成修复。（在一般协议操作中，使用显式修复预计是一个例外，但在极端条件下确实存在这种可能性）。一旦发送了待修复的内容，发送方立即承担新内容的传输。
5) The sender transmits NORM_CMD(FLUSH) messages when it reaches the end of enqueued transmit content and pending repairs. Receivers respond to the NORM_CMD(FLUSH) messages with NORM_NACK transmissions (following the same suppression backoff timeout strategy as for data) if they require further repair.
5) 当发送方到达排队传输内容和待修复的末尾时，发送方传输NORM_CMD（FLUSH）消息。如果接收器需要进一步修复，则使用NORM_NACK传输（遵循与数据相同的抑制退避超时策略）响应NORM_CMD（FLUSH）消息。
6) The sender transmissions are subject to rate control limits determined by congestion control mechanisms. In the baseline NORM-CC operation, each sender in a NormSession maintains its own independent congestion control state. Receivers provide congestion control feedback in NORM_NACK and NORM_ACK messages. NORM_ACK feedback for congestion control purposes is governed using a suppression mechanism similar to that for NORM_NACK messages.
6) 发送方传输受拥塞控制机制确定的速率控制限制的约束。在基线NORM-CC操作中，NormSession中的每个发送方都保持自己独立的拥塞控制状态。接收机在NORM_NACK和NORM_ACK消息中提供拥塞控制反馈。用于拥塞控制目的的NORM_ACK反馈使用与NORM_NACK消息类似的抑制机制进行控制。
While this overall concept is relatively simple, there are details to each of these aspects that need to be addressed for successful, efficient, robust, and scalable NORM protocol operation.
虽然这一总体概念相对简单，但为了成功、高效、健壮和可扩展的NORM协议操作，需要解决这些方面的细节。
Upon startup, the NORM sender immediately begins sending NORM_CMD(CC) messages to collect round trip timing and other information from the potential group. If NORM-CC congestion control operation is enabled, the NORM-CC Rate header extension MUST be included in these messages. Congestion control operation SHALL be observed at all times when operating in the general Internet. Even if congestion control operation is disabled at the sender, it may be desirable to use the NORM_CMD(CC) messaging to collect feedback from the group using the baseline NORM-CC feedback mechanisms. This proactive feedback collection can be used to establish a GRTT estimate prior to data transmission and potential NACK operation.
启动后，NORM发送方立即开始发送NORM_CMD（CC）消息，以从潜在组收集往返时间和其他信息。如果启用了NORM-CC拥塞控制操作，则这些消息中必须包含NORM-CC速率头扩展。在通用互联网上运行时，应始终遵守拥塞控制操作。即使在发送方禁用了拥塞控制操作，也可能需要使用NORM_CMD（CC）消息来使用基准NORM-CC反馈机制从组收集反馈。这种主动反馈收集可用于在数据传输和潜在NACK操作之前建立GRTT估计。
In some cases, applications may wish for the sender to also proceed with data transmission immediately. In other cases, the sender may wish to defer data transmission until it has received some feedback or request from the receiver set indicating that receivers are indeed present. Note, in some applications (e.g., web push), this indication may come out-of-band with respect to the multicast session via other means. As noted, the periodic transmission of NORM_CMD(CC) messages may precede actual data transmission in order to have an initial GRTT estimate.
在某些情况下，应用程序可能希望发送方也立即进行数据传输。在其他情况下，发送方可能希望延迟数据传输，直到它已经从接收机集合接收到指示接收机确实存在的一些反馈或请求为止。注意，在一些应用程序（例如，web推送）中，该指示可能通过其他方式出现在关于多播会话的带外。如前所述，NORM_CMD（CC）消息的周期性传输可能先于实际数据传输，以便获得初始GRTT估计。
With inclusion of the OPTIONAL NORM FEC Object Transmission Information Header Extension, the NORM protocol sender message headers can contain all information necessary to prepare receivers for subsequent reliable reception. This includes FEC coding parameters, the sender NormSegmentSize, and other information. If this header extension is not used, it is presumed that receivers have received the FEC Object Transmission Information via other means. Additionally, applications may leverage the use of NORM_INFO messages associated with the session data objects in the session to provide application-specific context information for the session and data being transmitted. These mechanisms allow for operation with minimal pre-coordination among the senders and receivers.
通过包含可选的NORM FEC对象传输信息报头扩展，NORM协议发送方消息报头可以包含为后续可靠接收准备接收方所需的所有信息。这包括FEC编码参数、发送方大小和其他信息。如果未使用该报头扩展，则假定接收机已经通过其他方式接收到FEC对象传输信息。此外，应用程序可以利用与会话中的会话数据对象相关联的NORM_INFO消息的使用，为会话和正在传输的数据提供特定于应用程序的上下文信息。这些机制允许在发送方和接收方之间进行最小程度的预协调操作。
The NORM sender begins segmenting application-enqueued data into NORM_DATA segments and transmitting it to the group. The segmentation algorithm is described in Section 5.1.1. The rate of transmission is controlled via congestion control mechanisms or is a fixed rate if desired for closed network operations. The receivers participating in the multicast group provide feedback to the sender as needed. When the sender reaches the end of data it has enqueued
NORM发送方开始将应用程序排队的数据分割为NORM_数据段，并将其传输给组。第5.1.1节描述了分割算法。传输速率通过拥塞控制机制进行控制，如果封闭网络操作需要，则为固定速率。参与多播组的接收者根据需要向发送者提供反馈。当发送方到达其已排队的数据末尾时
for transmission or any pending repairs, it transmits a series of NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT. Receivers may respond to these NORM_CMD(FLUSH) messages with additional repair requests. A protocol parameter "NORM_ROBUST_FACTOR" determines the number of flush messages sent. If receivers request repair, the repair is provided and flushing occurs again at the end of repair transmission. The sender may attach an OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing the NormNodeIds for receivers from which it expects explicit positive acknowledgment of reception. The NORM_CMD(FLUSH) message may be also used for this optional function any time prior to the end of data enqueued for transmission with the NORM_CMD(FLUSH) messages multiplexed with ongoing data transmissions. The OPTIONAL NORM positive acknowledgment procedure is described in Section 5.5.3.
对于传输或任何未决维修，它以每2*GRTT一条的速率传输一系列NORM_CMD（FLUSH）消息。接收者可能会对这些NORM_CMD（FLUSH）消息做出额外的修复请求。协议参数“NORM\u ROBUST\u FACTOR”确定发送的刷新消息数。如果接收器请求维修，则提供维修，并在维修结束时再次进行冲洗。发送方可以在NORM_CMD（FLUSH）上附加一个可选的“确认节点列表”，其中包含它期望接收到明确肯定确认的接收方的normnodeid。NORM_CMD（FLUSH）消息也可在排队等待传输的数据结束之前的任何时间用于此可选功能，其中NORM_CMD（FLUSH）消息与正在进行的数据传输复用。第5.5.3节描述了可选规范肯定确认程序。
NORM senders and receivers must use a common algorithm for logically segmenting transport data into FEC encoding blocks and symbols so that appropriate NACKs can be constructed to request repair of missing data. NORM FEC coding blocks are comprised of multi-byte symbols which are transmitted in the payload of NORM_DATA messages. Each NORM_DATA message contains one source or encoding symbol and the NormSegmentSize sender parameter defines the maximum symbol size in bytes. The FEC encoding type and associated parameters govern the source block size (number of source symbols per coding block). NORM senders and receivers use these FEC parameters, along with the NormSegmentSize and transport object size to compute the source block structure for transport objects. These parameters are provided in the FEC Transmission Information for each object. The algorithm given below is used to compute a source block structure such that all source blocks are as close to being equal length as possible. This helps avoid the performance disadvantages of "short" FEC blocks. Note this algorithm applies only to the statically-sized NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where the object size is fixed and predetermined. For NORM_OBJECT_STREAM objects, the object is segmented according to the maximum source block length given in the FEC Transmission Information, unless the FEC Payload ID indicates an alternative size for a given block.
规范发送方和接收方必须使用通用算法将传输数据逻辑分割为FEC编码块和符号，以便可以构造适当的NACK以请求修复丢失的数据。NORM FEC编码块由在NORM_数据消息的有效载荷中传输的多字节符号组成。每个NORM_数据消息包含一个源或编码符号，NormSegmentSize sender参数以字节为单位定义最大符号大小。FEC编码类型和相关参数控制源块大小（每个编码块的源符号数）。NORM发送方和接收方使用这些FEC参数以及NORMSECTIONSIZE和传输对象大小来计算传输对象的源块结构。这些参数在每个对象的FEC传输信息中提供。下面给出的算法用于计算源块结构，使所有源块的长度尽可能接近相等。这有助于避免“短”FEC块的性能缺点。注意：此算法仅适用于静态大小的NORM_OBJECT_数据和NORM_OBJECT_文件传输对象类型，其中对象大小是固定的和预先确定的。对于NORM_OBJECT_STREAM对象，根据FEC传输信息中给定的最大源块长度分割对象，除非FEC有效负载ID指示给定块的替代大小。
The NORM block segmentation algorithm is defined as follows. For a transport object of a given length (L_obj) in bytes, a first number of FEC source blocks (N_large) is delineated of a larger block size (B_large), and a second number of source blocks (N_small) is delineated of a smaller block size (B_small). Given the maximum FEC source block size (B_max) and the sender's NormSegmentSize, the block segmentation for a given NORM transport object is determined as follows:
范数块分割算法定义如下。对于以字节为单位的给定长度（L_obj）的传输对象，以较大的块大小（B_large）描绘第一数量的FEC源块（N_large），以较小的块大小（B_small）描绘第二数量的源块（N_small）。给定最大FEC源块大小（B_max）和发送方的NormSegmentSize，给定NORM传输对象的块分割确定如下：
Inputs:
投入：
B_max = Maximum source block length (i.e., maximum number of source symbols per source block)
B_max=最大源块长度（即每个源块的最大源符号数）
L_sym = Encoding symbol length in bytes (i.e., NormSegmentSize)
L_sym=编码符号长度（字节）（即NORMSECTIONSIZE）
L_obj = Object length in bytes
L_obj = Object length in bytes
Outputs:
产出：
N_total = The total number of source blocks into which the transport object is partitioned.
N_total=传输对象被划分到的源块总数。
N_large = Number of larger source blocks (first set of blocks)
N_large=较大源块的数量（第一组块）
B_large = Size (in encoding symbols) of the larger source blocks
B_large=较大源块的大小（编码符号）
N_small = Number of smaller source blocks (second set of blocks)
N_small=较小源块的数量（第二组块）
B_small = Size (in encoding symbols) of the smaller source blocks
B_small=较小源块的大小（在编码符号中）
L_final = Length (in bytes) of the last source symbol of the last source block (All other symbols are of length L_sym).
L_final=最后一个源块的最后一个源符号的长度（字节）（所有其他符号的长度为L_sym）。
Algorithm:
算法：
1) The total number of source symbols in the transport object is computed as: S_total = L_obj/L_sym [rounded up to the nearest integer]
1) 传输对象中源符号的总数计算为：S_total=L_obj/L_sym[四舍五入到最接近的整数]
2) The transport object is partitioned into N_total source blocks, where: N_total = S_total/B_max [rounded up to the nearest integer]
2) 传输对象被划分为N个total源块，其中：N_total=S_total/B_max[四舍五入到最接近的整数]
3) The average length of a source block is computed as: B_ave = S_total/N_total (this may be non-integer)
3) 源块的平均长度计算为：B_ave=S_total/N_total（这可能是非整数）
4) The size of the first set of larger blocks is computed as: B_large = B_ave [rounded up to the nearest integer] (Note it will always be the case that B_large <= B_max)
4) 第一组较大块的大小计算为：B_large=B_ave[四舍五入到最接近的整数]（注意，B_large<=B_max的情况始终如此）
5) The size of the second set of smaller blocks is computed as:
B_small = B_ave [rounded down to the nearest integer] (Note if
B_ave is an integer B_small = B_large; otherwise B_small = B_large
- 1)
5) The size of the second set of smaller blocks is computed as:
B_small = B_ave [rounded down to the nearest integer] (Note if
B_ave is an integer B_small = B_large; otherwise B_small = B_large
- 1)
6) The fractional part of B_ave is computed as: B_fraction = B_ave - B_small
6) B_ave的分数部分计算为：B_分数=B_ave-B_小
7) The number of larger source blocks is computed as: N_large = B_fraction * N_total (Note N_large is an integer in the range 0 through N_total - 1)
7) 较大源块的数量计算为：N_large=B_分数*N_total（注意N_large是0到N_total-1范围内的整数）
8) The number of smaller source blocks is computed as: N_small = N_total - N_large
8) 较小源块的数量计算为：N_small=N_total-N_large
9) Each of the first N_large source blocks consists of B_large source
symbols. Each of the remaining N_small source blocks consists of
B_small source symbols. All symbols are L_sym bytes in length
except for the final source symbol of the final source block which
is of length (in bytes):
L_final = L_obj - (N_large*B_large + N_small*B_small - 1) * L_sym
9) Each of the first N_large source blocks consists of B_large source
symbols. Each of the remaining N_small source blocks consists of
B_small source symbols. All symbols are L_sym bytes in length
except for the final source symbol of the final source block which
is of length (in bytes):
L_final = L_obj - (N_large*B_large + N_small*B_small - 1) * L_sym
The NORM protocol is designed such that receivers may join and leave the group at will. However, some applications may be constrained such that receivers need to be members of the group prior to start of data transmission. NORM applications may use different policies to constrain the impact of new receivers joining the group in the middle of a session. For example, a useful implementation policy is for new receivers joining the group to limit or avoid repair requests for transport objects already in progress. The NORM sender implementation may wish to impose additional constraints to limit the ability of receivers to disrupt reliable multicast performance by joining, leaving, and rejoining the group often. Different receiver "join policies" may be appropriate for different applications and/or scenarios. For general purpose operation, default policy where receivers are allowed to request repair only for coding blocks with a NormTransportId and FEC coding block number greater than or equal to the first non-repair NORM_DATA or NORM_INFO message received upon joining the group is RECOMMENDED. For objects of type NORM_OBJECT_STREAM it is RECOMMENDED that the join policy constrain receivers to start reliable reception at the current FEC coding block for which non-repair content is received.
NORM协议的设计使得接收方可以随意加入和离开组。然而，一些应用可能受到限制，使得接收器在开始数据传输之前需要是组的成员。规范应用程序可以使用不同的策略来约束新的接收者在会话中间加入组的影响。例如，一个有用的实施策略是让新加入组的接收者限制或避免对已在进行的传输对象的修复请求。NORM发送方实现可能希望施加附加约束，以限制接收方通过经常加入、离开和重新加入组来中断可靠多播性能的能力。不同的接收方“加入策略”可能适用于不同的应用程序和/或场景。对于通用操作，建议使用默认策略，即只允许接收机对NormTransportId和FEC编码块编号大于或等于加入组时接收到的第一个非修复NORM_数据或NORM_信息的编码块请求修复。对于NORM_OBJECT_STREAM类型的对象，建议联接策略约束接收器在接收非修复内容的当前FEC编码块处开始可靠接收。
When the receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACKing procedure. The NACKing procedure SHALL be initiated _only_ at FEC coding block boundaries, NormObject boundaries, and upon receipt of a NORM_CMD(FLUSH) message.
当接收器检测到它丢失了来自发送方NORM传输的数据时，它启动其NACKing过程。NACKing程序应仅在FEC编码块边界、NormObject边界和收到NORM CMD（FLUSH）消息时启动。
The NACKing procedure begins with a random backoff timeout. The duration of the backoff timeout is chosen using the "RandomBackoff" algorithm described in the NORM Building Block document [4] using (Ksender*GRTTsender) for the "maxTime" parameter and the sender advertised group size (GSIZEsender) as the "groupSize" parameter. NORM senders provide values for GRTTsender, Ksender and GSIZEsender via the "grtt", "backoff", and "gsize" fields of transmitted messages. The GRTTsender value is determined by the sender based on feedback it has received from the group while the Ksender and GSIZEsender values may determined by application requirements and expectations or ancillary information. The backoff factor "Ksender" MUST be greater than one to provide for effective feedback suppression. A value of K = 4 is RECOMMENDED for the Any Source Multicast (ASM) model while a value of K = 6 is RECOMMENDED for Single Source Multicast (SSM) operation.
NACKing过程以随机回退超时开始。退避超时的持续时间是使用NORM构建块文档[4]中描述的“随机退避”算法选择的，使用（Ksender*GRTTsender）作为“maxTime”参数，使用发送方公布的组大小（GSIZEsender）作为“groupSize”参数。标准发送方通过传输消息的“grtt”、“退避”和“gsize”字段为GRTTsender、Ksender和GSIZEsender提供值。GRTTsender值由发送方根据其从集团收到的反馈确定，而Ksender和GSIZEsender值可由应用要求和期望或辅助信息确定。退避系数“Ksender”必须大于1，以提供有效的反馈抑制。对于任意源多播（ASM）模型，建议使用K=4的值，而对于单源多播（SSM）操作，建议使用K=6的值。
Thus:
因此：
T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
To avoid the possibility of NACK implosion in the case of sender or network failure during SSM operation, the receiver SHALL automatically suppress its NACK and immediately enter the "holdoff" period described below when T_backoff is greater than (Ksender-1)*GRTTsender. Otherwise, the backoff period is entered and the receiver MUST accumulate external pending repair state from NORM_NACK messages and NORM_CMD(REPAIR_ADV) messages received. At the end of the backoff time, the receiver SHALL generate a NORM_NACK message only if the following conditions are met:
为避免在SSM运行期间发送方或网络故障的情况下NACK内爆的可能性，当T_回退大于（Ksender-1）*GRTTsender时，接收方应自动抑制其NACK并立即进入下文所述的“延迟”期。否则，将进入退避期，接收方必须从收到的NORM_NACK消息和NORM_CMD（repair_ADV）消息中累积外部挂起修复状态。在退避时间结束时，仅当满足以下条件时，接收器才应生成NORM_NACK消息：
1) The sender's current transmit position (in terms of objectId::fecPayloadId) exceeds the earliest repair position of the receiver.
1) 发送方的当前发送位置（就objectId:：fecPayloadId而言）超过了接收方的最早修复位置。
2) The repair state accumulated from NORM_NACK and NORM_CMD(REPAIR_ADV) messages do not equal or supersede the receiver's repair needs up to the sender transmission position at the time the NACK procedure (backoff timeout) was initiated.
2) 从NORM_NACK和NORM_CMD（repair_ADV）消息中累积的修复状态不等于或取代NACK过程（退避超时）启动时接收器到发送方传输位置的修复需求。
If these conditions are met, the receiver immediately generates a NORM_NACK message when the backoff timeout expires. Otherwise, the receiver's NACK is considered to be "suppressed" and the message is not sent. At this time, the receiver begins a "holdoff" period during which it constrains itself to not reinitiate the NACKing process. The purpose of this timeout is to allow the sender worst-case time to respond to the repair needs before the receiver requests repair again. The value of this "holdoff" timeout (T_rcvrHoldoff) as described in [4] is:
如果满足这些条件，当退避超时过期时，接收器立即生成NORM_NACK消息。否则，接收器的NACK被认为是“被抑制的”，并且消息不被发送。此时，接收器开始一个“延迟”期，在此期间，它约束自己不重新初始化NACKing过程。此超时的目的是在接收方再次请求修复之前，允许发送方在最坏情况下响应修复需求。[4]中所述的“延迟”超时（T_rcvrHoldoff）的值为：
T_rcvrHoldoff =(Ksender+2)*GRTTsender
T_rcvrHoldoff =(Ksender+2)*GRTTsender
The NORM_NACK message contains repair request content beginning with lowest ordinal repair position of the receiver up through the coding block prior to the most recently heard ordinal transmission position for the sender. If the size of the NORM_NACK content exceeds the sender's NormSegmentSize, the NACK content is truncated so that the receiver only generates a single NORM_NACK message per NACK cycle for a given sender. In summary, a single NACK message is generated containing the receiver's lowest ordinal repair needs.
NORM_NACK消息包含维修请求内容，从接收机的最低顺序维修位置开始，一直到发送方最近听到的顺序传输位置之前的编码块。如果NORM_NACK内容的大小超过发送方的NormSegmentSize，则NACK内容将被截断，以便接收方仅为给定发送方的每个NACK周期生成一条NORM_NACK消息。总之，生成一条包含接收方最低顺序修复需求的NACK消息。
For each partially-received FEC coding block requiring repair, the receiver SHALL, on its _first_ repair attempt for the block, request the parity portion of the FEC coding block beginning with the lowest ordinal _parity_ "encoding_symbol_id" (i.e., "encoding_symbol_id" = "source_block_len") and request the number of FEC symbols corresponding to its data segment erasure count for the block. On _subsequent_ repair cycles for the same coding block, the receiver SHALL request only those repair symbols from the first set it has not yet received up to the remaining erasure count for that applicable coding block. Note that the sender may have provided other different, additional parity segments for other receivers that could also be used to satisfy the local receiver's erasure-filling needs. In the case where the erasure count for a partially-received FEC coding block exceeds the maximum number of parity symbols available from the sender for the block (as indicated by the NORM_DATA "fec_num_parity" field), the receiver SHALL request all available parity segments plus the ordinally highest missing data segments required to satisfy its total erasure needs for the block. The goal of this strategy is for the overall receiver set to request a lowest common denominator set of repair symbols for a given FEC coding block. This allows the sender to construct the most efficient repair transmission segment set and enables effective NACK suppression among the receivers even with uncorrelated packet loss. This approach also requires no synchronization among the receiver set in their repair requests for the sender.
对于需要修复的每个部分接收的FEC编码块，接收器应在其对该块的“第一次”修复尝试时，请求FEC编码块的奇偶校验部分，该奇偶校验部分从最低顺序的“编码符号id”（即，“编码符号id”=“源代码块长度”）开始以及请求与其块的数据段擦除计数相对应的FEC符号的数目。在同一编码块的后续修复周期中，接收器应仅从其尚未接收到的第一组中请求修复符号，直至该适用编码块的剩余擦除计数。注意，发送方可能已经为其他接收机提供了其他不同的附加奇偶校验段，这些奇偶校验段也可用于满足本地接收机的擦除填充需求。在部分接收的FEC编码块的擦除计数超过该块的发送方可用奇偶校验符号的最大数目的情况下（如NORM_DATA“FEC_num_奇偶校验”字段所示），接收器应请求所有可用奇偶校验段加上满足其块的总擦除需求所需的顺序最高缺失数据段。该策略的目标是使整个接收机集合请求给定FEC编码块的最小公分母修复符号集合。这允许发送方构造最有效的修复传输段集，并且即使在不相关分组丢失的情况下，也能够在接收机之间实现有效的NACK抑制。这种方法也不需要在发送方的修复请求中设置接收方之间进行同步。
For FEC coding blocks or NormObjects missed in their entirety, the NORM receiver constructs repair requests with NORM_NACK_BLOCK or NORM_NACK_OBJECT flags set as appropriate. The request for retransmission of NORM_INFO is accomplished by setting the NORM_NACK_INFO flag in a corresponding repair request.
对于全部丢失的FEC编码块或NormObjects，NORM接收器使用NORM_NACK_块或NORM_NACK_对象标志（视情况而定）构造修复请求。通过在相应的修复请求中设置NORM_NACK_INFO标志来完成NORM_INFO的重新传输请求。
The principle goal of the sender is to make forward progress in the transmission of data its application has enqueued. However, the sender must occasionally "rewind" its logical transmission point to
发送方的主要目标是在其应用程序排队的数据传输方面取得进展。但是，发送方必须偶尔将其逻辑传输点“倒带”到
satisfy the repair needs of receivers who have NACKed. Aggregation of multiple NACKs is used to determine an optimal repair strategy when a NACK event occurs. Since receivers initiate the NACK process on coding block or object boundaries, there is some loose degree of synchronization of the repair process even when receivers experience uncorrelated data loss.
满足已损坏接收器的维修需求。当NACK事件发生时，多个NACK的聚合用于确定最佳修复策略。由于接收机在编码块或对象边界上启动NACK过程，因此即使在接收机经历不相关的数据丢失时，修复过程也存在某种程度的松散同步。
When a sender is in its normal state of transmitting new data and receives a NACK, it begins a procedure to accumulate NACK repair state from NORM_NACK messages before beginning repair transmissions. Note that this period of aggregating repair state does _not_ interfere with its ongoing transmission of new data.
当发送方处于发送新数据的正常状态并接收到NACK时，它开始在开始修复传输之前从NORM_NACK消息中累积NACK修复状态的过程。请注意，聚合修复状态的这段时间不会干扰新数据的持续传输。
As described in [4], the period of time during which the sender aggregates NORM_NACK messages is equal to:
如[4]所述，发送方聚合NORM_NACK消息的时间段等于：
T_sndrAggregate = (Ksender+1)*GRTT
T_sndrAggregate = (Ksender+1)*GRTT
where "Ksender" is the same backoff scaling value used by the receivers, and "GRTT" is the sender's current estimate of the group's greatest round-trip time.
其中，“Ksender”是接收方使用的相同退避比例值，“GRTT”是发送方对组的最大往返时间的当前估计。
When this period ends, the sender "rewinds" by incorporating the accumulated repair state into its pending transmission state and begins transmitting repair messages. After pending repair transmissions are completed, the sender continues with new transmissions of any enqueued data. Also, at this point in time, the sender begins a "holdoff" timeout during which time the sender constrains itself from initiating a new repair aggregation cycle, even if NORM_NACK messages arrive. As described in [4], the value of this sender "holdoff" period is:
When this period ends, the sender "rewinds" by incorporating the accumulated repair state into its pending transmission state and begins transmitting repair messages. After pending repair transmissions are completed, the sender continues with new transmissions of any enqueued data. Also, at this point in time, the sender begins a "holdoff" timeout during which time the sender constrains itself from initiating a new repair aggregation cycle, even if NORM_NACK messages arrive. As described in [4], the value of this sender "holdoff" period is:translate error, please retry
T_sndrHoldoff = (1*GRTT)
T_sndrHoldoff = (1*GRTT)
If additional NORM_NACK messages are received during this sender "holdoff" period, the sender will immediately incorporate these "late messages" into its pending transmission state ONLY if the NACK content is ordinally greater than the sender's current transmission position. This "holdoff" time allows worst case time for the sender to propagate its current transmission sequence position to the group, thus avoiding redundant repair transmissions. After the holdoff timeout expires, a new NACK accumulation period can be begun (upon arrival of a NACK) in concert with the pending repair and new data transmission. Recall that receivers are not to initiate the NACK repair process until the sender's logical transmission position exceeds the lowest ordinal position of their repair needs. With the
如果在此发送方“延迟”期间收到其他NORM_NACK消息，则仅当NACK内容通常大于发送方的当前传输位置时，发送方才会立即将这些“延迟消息”合并到其挂起传输状态。此“延迟”时间允许发送方在最坏情况下将其当前传输序列位置传播到组，从而避免冗余修复传输。延迟超时到期后，新的NACK累积期可以开始（在NACK到达时）与待修复和新数据传输相一致。回想一下，在发送方的逻辑传输位置超过其维修需求的最低顺序位置之前，接收方不得启动NACK维修过程。和
new NACK aggregation period, the sender repeats the same process of incorporating accumulated repair state into its transmission plan and subsequently "rewinding" to transmit the lowest ordinal repair data when the aggregation period expires. Again, this is conducted in concert with ongoing new data and/or pending repair transmissions.
在新的NACK聚合周期中，发送方重复相同的过程，将累积的修复状态合并到其传输计划中，然后在聚合周期到期时“倒带”以传输最低顺序的修复数据。同样，这是与正在进行的新数据和/或待修复传输同步进行的。
The NORM sender should leverage transmission of FEC parity content for repair to the greatest extent possible. Recall that the receivers use a strategy to request a lowest common denominator of explicit repair (including parity content) in the formation of their NORM_NACK messages. Before falling back to explicitly satisfying different receivers' repair needs, the sender can make use of the general erasure-filling capability of FEC-generated parity segments. The sender can determine the maximum erasure filling needs for individual FEC coding blocks from the NORM_NACK messages received during the repair aggregation period. Then, if the sender has a sufficient number (less than or equal to the maximum erasure count) of previously unsent parity segments available for the applicable coding blocks, the sender can transmit these in lieu of the specific packets the receiver set has requested. Only after exhausting its supply of "fresh" (unsent) parity segments for a given coding block should the sender resort to explicit transmission of the receiver set's repair needs. In general, if a sufficiently powerful FEC code is used, the need for explicit repair will be an exception, and the fulfillment of reliable multicast can be accomplished quite efficiently. However, the ability to resort to explicit repair allows the protocol to be reliable under even very extreme circumstances.
规范发送方应尽可能利用FEC奇偶校验内容的传输进行修复。回想一下，接收方在形成其NORM_NACK消息时使用一种策略来请求显式修复（包括奇偶校验内容）的最低公分母。在返回到显式满足不同接收方的修复需求之前，发送方可以利用FEC生成的奇偶校验段的一般擦除填充能力。发送方可以根据修复聚合期间接收的NORM_NACK消息确定单个FEC编码块的最大擦除填充需求。然后，如果发送方具有足够数量（小于或等于最大擦除计数）的先前未发送的奇偶校验段可用于适用的编码块，则发送方可以发送这些奇偶校验段来代替接收方集合请求的特定分组。只有在耗尽其对给定编码块的“新鲜”（未发送）奇偶校验段的供应之后，发送方才应求助于明确传输接收方集合的修复需求。一般来说，如果使用功能足够强大的FEC代码，则显式修复的需要将是一个例外，并且可以非常有效地实现可靠的多播。然而，借助于显式修复的能力，即使在非常极端的情况下，协议也是可靠的。
NORM_DATA messages sent as repair transmissions SHALL be flagged with the NORM_FLAG_REPAIR flag. This allows receivers to obey any policies that limit new receivers from joining the reliable transmission when only repair transmissions have been received. Additionally, the sender SHOULD additionally flag NORM_DATA transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT flag.
作为维修传输发送的NORM_数据信息应标有NORM_FLAG_维修标志。这允许接收机遵守任何限制新接收机在仅接收到修复传输时加入可靠传输的策略。此外，发送方还应使用NORM_flag_explicit标志将发送为显式修复的NORM_数据传输附加标记。
Although NORM end system receivers do not make use of the NORM_FLAG_EXPLICIT flag, this message transmission status could be leveraged by intermediate systems wishing to "assist" NORM protocol performance. If such systems are properly positioned with respect to reciprocal reverse-path multicast routing, they need to sub-cast only a sufficient count of non-explicit parity repairs to satisfy a multicast routing sub-tree's erasure filling needs for a given FEC coding block. When the sender has resorted to explicit repair, then the intermediate systems should sub-cast all of the explicit repair
尽管NORM终端系统接收器不使用NORM_FLAG_EXPLICIT标志，但希望“帮助”NORM协议性能的中间系统可以利用此消息传输状态。如果这样的系统相对于互惠反向路径多播路由被正确定位，那么它们只需要子广播足够数量的非显式奇偶校验修复，以满足多播路由子树对给定FEC编码块的擦除填充需求。当发送方求助于显式修复时，中间系统应将所有显式修复进行分型
packets to those portions of the routing tree still requiring repair for a given coding block. Note the intermediate systems will be required to conduct repair state accumulation for sub-routes in a manner similar to the sender's repair state accumulation in order to have sufficient information to perform the sub-casting. Additionally, the intermediate systems could perform additional NORM_NACK suppression/aggregation as it conducts this repair state accumulation for NORM repair cycles. The detail of this type of operation are beyond the scope of this document, but this information is provided for possible future consideration.
对于给定的编码块，发送到路由树中仍需要修复的部分的数据包。注：中间系统需要以类似于发送方维修状态累加的方式对子路由进行维修状态累加，以便有足够的信息来执行分播。此外，中间系统可以执行额外的NORM_NACK抑制/聚集，因为它为NORM修复周期执行该修复状态累积。此类操作的详细信息超出了本文件的范围，但提供此信息供将来可能考虑。
If the sender receives a NORM_NACK message for repair of data it is no longer supporting, the sender generates a NORM_CMD(SQUELCH) message to advertise its repair window and squelch any receivers from additional NACKing of invalid data. The transmission rate of NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT. The "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) message SHALL begin with the lowest "object_transport_id" from the invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) transmission. Lower ordinal invalid "object_transport_ids" should be included only while the NORM_CMD(SQUELCH) payload is less than the sender's NormSegmentSize parameter.
如果发送方收到用于修复其不再支持的数据的NORM_NACK消息，发送方将生成NORM_CMD（SQUELCH）消息以公布其修复窗口，并禁止任何接收方接收其他无效数据。NORM_CMD（静噪）消息的传输速率限制为每2*GRTT一次。NORM_CMD（SQUELCH）消息的“无效对象_列表”（如果适用）应以自上次NORM_CMD（SQUELCH）传输以来接收到的无效NORM_NACK消息的最低“对象_传输_id”开始。只有当NORM_CMD（静噪）有效负载小于发送方的NormSegmentSize参数时，才应包括低序数无效的“object_transport_id”。
When a NORM sender receives NORM_NACK messages from receivers via unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to advertise its accumulated repair state to the receiver set since the receiver set is not directly sharing their repair needs via multicast communication. The NORM_CMD(REPAIR_ADV) message is multicast to the receiver set by the sender. The payload portion of this message has content in the same format as the NORM_NACK receiver message payload. Receivers are then able to perform feedback suppression in the same manner as with NORM_NACK messages directly received from other receivers. Note the sender does not merely retransmit NACK content it receives, but instead transmits a representation of its aggregated repair state. The transmission of NORM_CMD(REPAIR_ADV) messages are subject to the sender transmit rate limit and NormSegmentSize limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum size, receivers SHALL consider the maximum ordinal transmission position value embedded in the message as the senders "current" transmission position and implicitly suppress requests for ordinally higher repair. For congestion control operation, the sender may also need to provide information so that dynamic congestion control feedback can be suppressed as needed among receivers. This document specifies the NORM-CC Feedback Header Extension that is applied for
当NORM发送方通过单播传输从接收方接收NORM_NACK消息时，它使用NORM_CMD（REPAIR_ADV）消息将其累积的修复状态通告给接收方集，因为接收方集未通过多播通信直接共享其修复需求。NORM_CMD（REPAIR_ADV）消息多播到发送方设置的接收方。此消息的有效负载部分具有与NORM_NACK接收器消息有效负载相同格式的内容。然后，接收机能够以与直接从其他接收机接收的NORM_NACK消息相同的方式执行反馈抑制。注意，发送方不仅重新传输它接收到的NACK内容，而是传输其聚合修复状态的表示。NORM_CMD（REPAIR_ADV）消息的传输受发送方传输速率限制和NormSegmentSize限制。当NoMr.CMD（ReaPixADV）消息具有最大大小时，接收方应考虑嵌入在消息中的最大序号传输位置值作为发送者“当前”传输位置，并隐式地抑制通常更高修复的请求。对于拥塞控制操作，发送方可能还需要提供信息，以便可以根据需要在接收方之间抑制动态拥塞控制反馈。本文档指定了应用于的NORM-CC反馈标头扩展
baseline NORM-CC operation. If other congestion control mechanisms are used within a NORM implementation, other header extensions may be defined. Whatever content format is used for this purpose should ensure that maximum possible suppression state is conveyed to the receiver set.
基线NORM-CC操作。如果在NORM实现中使用其他拥塞控制机制，则可以定义其他报头扩展。用于此目的的任何内容格式都应确保将最大可能的抑制状态传送到接收器集。
In addition to the principal function of data content transmission and repair, there are some other protocol mechanisms that help NORM to adapt to network conditions and play fairly with other coexistent protocols.
除了数据内容传输和修复的主要功能外，还有一些其他协议机制可以帮助NORM适应网络条件并公平地使用其他共存协议。
For NORM receivers to appropriately scale backoff timeouts and the senders to use proper corresponding timeouts, the participants must agree on a common timeout basis. Each NORM sender monitors the round-trip time of active receivers and determines the group greatest round-trip time (GRTT). The sender advertises this GRTT estimate in every message it transmits so that receivers have this value available for scaling their timers. To measure the current GRTT, the sender periodically sends NORM_CMD(CC) messages that contain a locally generated timestamp. Receivers are expected to record this timestamp along with the time the NORM_CMD(CC) message is received. Then, when the receivers generate feedback messages to the sender, an adjusted version of the sender timestamp is embedded in the feedback message (NORM_NACK or NORM_ACK). The adjustment adds the amount of time the receiver held the timestamp before generating its response. Upon receipt of this adjusted timestamp, the sender is able to calculate the round-trip time to that receiver.
为了规范接收者适当调整退避超时，发送者使用适当的相应超时，参与者必须在共同超时的基础上达成一致。每个NORM发送器监控活动接收器的往返时间，并确定组最大往返时间（GRTT）。发送方在其发送的每一条消息中公布此GRTT估计值，以便接收方可将此值用于调整其计时器。为了测量当前GRTT，发送方定期发送包含本地生成的时间戳的NORM_CMD（CC）消息。接收方应记录此时间戳以及收到NORM_CMD（CC）消息的时间。然后，当接收器生成反馈消息给发送者时，发送者时间戳的调整版本被嵌入反馈消息中（NORM_NACK或NORM_ACK）。调整增加了接收器在生成响应之前保持时间戳的时间量。收到该调整后的时间戳后，发送方能够计算到该接收方的往返时间。
The round-trip time for each receiver is fed into an algorithm that weights and smoothes the values for a conservative estimate of the GRTT. The algorithm and methodology are described in the NORM Building Block document [4] in the section entitled "One-to-Many Sender GRTT Measurement". A conservative estimate helps feedback suppression at a small cost in overall protocol repair delay. The sender's current estimate of GRTT is advertised in the "grtt" field found in all NORM sender messages. The advertised GRTT is also limited to a minimum of the nominal inter-packet transmission time given the sender's current transmission rate and system clock granularity. The reason for this additional limit is to keep the receiver somewhat "event driven" by making sure the sender has had adequate time to generate any response to repair requests from receivers given transmit rate limitations due to congestion control or configuration.
每个接收器的往返时间被输入一个算法，该算法对GRTT保守估计值进行加权和平滑。该算法和方法在题为“一对多发送方GRTT测量”一节的规范构建块文件[4]中进行了描述。保守估计有助于以较小的总体协议修复延迟成本抑制反馈。发送方当前对GRTT的估计在所有NORM发送方消息中的“GRTT”字段中公布。给定发送方的当前传输速率和系统时钟粒度，公布的GRTT也被限制为标称分组间传输时间的最小值。此附加限制的原因是，通过确保发送方有足够的时间生成对来自接收方的修复请求的响应（给定由于拥塞控制或配置导致的传输速率限制），使接收方在某种程度上保持“事件驱动”。
When the NORM-CC Rate header extension is present in NORM_CMD(CC) messages, the receivers respond to NORM_CMD(CC) messages as described in Section 5.5.2, "NORM Congestion Control Operation". The NORM_CMD(CC) messages are periodically generated by the sender as described for congestion control operation. This provides for proactive, but controlled, feedback from the group in the form of NORM_ACK messages. This provides for GRTT feedback even if no NORM_NACK messages are being sent. If operating without congestion control in a closed network, the NORM_CMD(CC) messages may be sent periodically without the NORM-CC Rate header extension. In this case, receivers will only provide GRTT measurement feedback when NORM_NACK messages are generated since no NORM_ACK messages are generated. In this case, the NORM_CMD(CC) messages may be sent less frequently, perhaps as little as once per minute, to conserve network capacity. Note that the NORM-CC Rate header extension may also be used proactively solicit RTT feedback from the receiver group per congestion control operation even though the sender may not be conducting congestion control rate adjustment. NORM operation without congestion control should be considered only in closed networks.
当NORM_CMD（CC）消息中存在NORM-CC速率报头扩展时，接收方响应第5.5.2节“NORM拥塞控制操作”中所述的NORM_CMD（CC）消息。如拥塞控制操作所述，发送方定期生成NORM_CMD（CC）消息。这提供了来自团队的主动但受控的反馈，反馈形式为NORM_确认消息。即使没有发送NORM_NACK消息，也会提供GRTT反馈。如果在封闭网络中运行时没有拥塞控制，则可以定期发送NORM_CMD（CC）消息，而无需NORM-CC速率头扩展。在这种情况下，由于没有生成NORM_ACK消息，因此只有在生成NORM_NACK消息时，接收机才会提供GRTT测量反馈。在这种情况下，NORM_CMD（CC）消息的发送频率可能会降低，可能只有每分钟一次，以节省网络容量。注意，NORM-CC速率报头扩展还可以用于在每次拥塞控制操作中主动请求来自接收方组的RTT反馈，即使发送方可能没有进行拥塞控制速率调整。只有在封闭网络中才应考虑无拥塞控制的正常运行。
This section describes baseline congestion control operation for the NORM protocol (NORM-CC). The supporting NORM message formats and approach described here are an adaptation of the equation-based TCP-Friendly Multicast Congestion Control (TFMCC) approach described in [19]. This congestion control scheme is REQUIRED for operation within the general Internet unless the NORM implementation is adapted to use another IETF-sanctioned reliable multicast congestion control mechanism (e.g., PGMCC [20]). With this TFMCC-based approach, the transmissions of NORM senders are controlled in a rate-based manner as opposed to window-based congestion control algorithms as in TCP. However, it is possible that the NORM protocol message set may alternatively be used to support a window-based multicast congestion control scheme such as PGMCC. The details of that alternative may be described separately or in a future revision of this document. In either case (rate-based TFMCC or window-based PGMCC), successful control of sender transmission depends upon collection of sender-to-receiver packet loss estimates and RTTs to identify the congestion control bottleneck path(s) within the multicast topology and adjust the sender rate accordingly. The receiver with loss and RTT estimates that correspond to the lowest result transmission rate is identified as the "current limiting receiver" (CLR).
本节介绍NORM协议（NORM-CC）的基线拥塞控制操作。此处描述的支持规范消息格式和方法是对[19]中描述的基于等式的TCP友好多播拥塞控制（TFMCC）方法的改编。这种拥塞控制方案是在通用互联网内运行所必需的，除非NORM实现适合使用另一种IETF认可的可靠多播拥塞控制机制（例如PGMCC[20]）。通过这种基于TFMCC的方法，与TCP中基于窗口的拥塞控制算法相反，以基于速率的方式控制范数发送方的传输。然而，NORM协议消息集可以替代地用于支持基于窗口的多播拥塞控制方案，例如PGMCC。该替代方案的细节可单独描述，或在本文件的未来版本中描述。在这两种情况下（基于速率的TFMCC或基于窗口的PGMCC），发送方传输的成功控制取决于发送方到接收方分组丢失估计和RTT的收集，以识别多播拓扑内的拥塞控制瓶颈路径并相应地调整发送方速率。具有与最低结果传输速率相对应的损耗和RTT估计的接收机被识别为“限流接收机”（CLR）。
As described in [21], a steady-state sender transmission rate, to be "friendly" with competing TCP flows can be calculated as:
如[21]所述，与竞争TCP流“友好”的稳态发送方传输速率可计算为：
S
Rsender = --------------------------------------------------------------
tRTT * (sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p *
(1 + 32*(p^2)))
S
Rsender = --------------------------------------------------------------
tRTT * (sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p *
(1 + 32*(p^2)))
where
哪里
S = Nominal transmitted packet size. (In NORM, the "nominal" packet size can be determined by the sender as an exponentially weighted moving average (EWMA) of transmitted packet sizes to account for variable message sizes).
S=标称传输数据包大小。（在标准中，“标称”分组大小可由发送方确定为传输分组大小的指数加权移动平均（EWMA），以考虑可变消息大小）。
tRTT = The RTT estimate of the current "current limiting receiver" (CLR).
tRTT=电流“限流接收器”（CLR）的RTT估计值。
p = The loss event fraction of the CLR.
p=CLR的损失事件分数。
To support congestion control feedback collection and operation, the NORM sender periodically transmits NORM_CMD(CC) command messages. NORM_CMD(CC) messages are multiplexed with NORM data and repair transmissions and serve several purposes:
为了支持拥塞控制反馈收集和操作，NORM发送方定期发送NORM_CMD（CC）命令消息。NORM_CMD（CC）消息与NORM数据多路传输，并修复传输，用于多种用途：
1) Stimulate explicit feedback from the general receiver set to collect congestion control information.
1) 刺激来自通用接收器集的明确反馈，以收集拥塞控制信息。
2) Communicate state to the receiver set on the sender's current congestion control status including details of the CLR.
2) 将状态设置为发送方当前的拥塞控制状态，包括CLR的详细信息传达给接收方。
3) Initiate rapid (immediate) feedback from the CLR in order to closely track the dynamics of congestion control for that current "worst path" in the group multicast topology.
3) 启动CLR的快速（立即）反馈，以便密切跟踪组多播拓扑中当前“最差路径”的拥塞控制动态。
The format of the NORM_CMD(CC) message is describe in Section 4.2.3 of this document. The NORM_CMD(CC) message contains information to allow measurement of RTTs, to inform the group of the congestion control CLR, and to provide feedback of individual RTT measurements to the receivers in the group. The NORM_CMD(CC) also provides for exciting feedback from OPTIONAL "potential limiting receiver" (PLR) nodes that may be determined administratively or possibly algorithmically based on congestion control feedback. PLR nodes are receivers that have been identified to have potential for (perhaps soon) becoming the CLR and thus immediate, up-to-date feedback is beneficial for congestion control performance. The details of PLR selection are not discussed in this document.
本文件第4.2.3节描述了NORM_CMD（CC）信息的格式。NORM_CMD（CC）消息包含允许测量RTT、通知组拥塞控制CLR以及向组中的接收器提供单个RTT测量反馈的信息。NORM_CMD（CC）还提供来自可选的“潜在限制接收器”（PLR）节点的激励反馈，该反馈可基于拥塞控制反馈以管理方式或可能的算法方式确定。PLR节点是已经确定有可能（可能很快）成为CLR的接收器，因此即时、最新的反馈有利于拥塞控制性能。本文件不讨论PLR选择的细节。
The NORM_CMD(CC) message is transmitted periodically by the sender along with its normal data transmission. Note that the repeated transmission of NORM_CMD(CC) messages may be initiated some time before transmission of user data content at session startup. This may be done to collect some estimation of the current state of the multicast topology with respect to group and individual RTT and congestion control state.
NORM_CMD（CC）消息由发送方在正常数据传输的同时定期传输。请注意，重复传输NORM_CMD（CC）消息可能在会话启动时传输用户数据内容之前的一段时间启动。这可以用于收集关于组和个体RTT和拥塞控制状态的多播拓扑的当前状态的一些估计。
A NORM_CMD(CC) message is immediately transmitted at sender startup. The interval of subsequent NORM_CMD(CC) message transmission is determined as follows:
在发送方启动时，会立即发送NORM_CMD（CC）消息。后续NORM_CMD（CC）消息传输的间隔确定如下：
1) By default, the interval is set according to the current sender GRTT estimate. A startup GRTT of 0.5 seconds is recommended when no feedback has yet been received from the group.
1) 默认情况下，间隔是根据当前发送方GRTT估计值设置的。当尚未收到团队反馈时，建议启动GRTT为0.5秒。
2) If a CLR has been identified (based on previous receiver feedback), the interval is the RTT between the sender and CLR.
2) 如果已识别CLR（基于之前的接收器反馈），则间隔为发送方和CLR之间的RTT。
3) Additionally, if the interval of nominal data message transmission is greater than the GRTT or RTT_clr interval, the NORM_CMD(CC) interval is set to this greater value. This ensures that the transmission of this control message is not done to the exclusion of user data transmission.
3) 此外，如果标称数据消息传输的间隔大于GRTT或RTT_clr间隔，则NORM_CMD（CC）间隔设置为该较大值。这可确保此控制消息的传输不会排除用户数据传输。
The NORM_CMD(CC) "cc_sequence" field is incremented with each transmission of a NORM_CMD(CC) command. The greatest "cc_sequence" recently received by receivers is included in their feedback to the sender. This allows the sender to determine the "age" of feedback to assist in congestion avoidance.
NORM_CMD（CC）“CC_sequence”字段随NORM_CMD（CC）命令的每次传输而递增。接收者最近收到的最大“cc_序列”包含在他们对发送者的反馈中。这允许发送方确定反馈的“时间”，以帮助避免拥塞。
The NORM-CC Rate Header Extension is applied to the NORM_CMD(CC) message and the sender advertises its current transmission rate in the "send_rate" field. The rate information is used by receivers to initialize loss estimation during congestion control startup or restart.
NORM-CC Rate头扩展应用于NORM_CMD（CC）消息，发送方在“send_Rate”字段中公布其当前传输速率。在拥塞控制启动或重启期间，接收机使用速率信息初始化损失估计。
The "cc_node_list" contains a list of entries identifying receivers and their current congestion control state (status "flags", "rtt" and "loss" estimates). The list may be empty if the sender has not yet received any feedback from the group. If the sender has received feedback, the list will minimally contain an entry identifying the CLR. A NORM_FLAG_CC_CLR flag value is provided for the "cc_flags" field to identify the CLR entry. It is RECOMMENDED that the CLR entry be the first in the list for implementation efficiency. Additional entries in the list are used to provide sender-measured
“cc_节点_列表”包含一个条目列表，用于标识接收器及其当前拥塞控制状态（状态“标志”、“rtt”和“丢失”估计）。如果发件人尚未收到组的任何反馈，则列表可能为空。如果发送者收到反馈，列表将至少包含一个标识CLR的条目。为“CC_标志”字段提供了NORM_FLAG_CC_CLR标志值，以标识CLR条目。为了提高实施效率，建议将CLR条目放在列表的第一位。列表中的其他条目用于提供发送方度量值
individual RTT estimates to receivers in the group. The number of additional entries in this list is dependent upon the percentage of control traffic the sender application is willing to send with respect to user data message transmissions. More entries in the list may allow the sender to be more responsive to congestion control dynamics. The length of the list may be dynamically determined according to the current transmission rate and scheduling of NORM_CMD(CC) messages. The maximum length of the list corresponds to the sender's NormSegmentSize parameter for the session. The inclusion of additional entries in the list based on receiver feedback are prioritized with following rules:
对组中接收器的单个RTT估计。此列表中附加条目的数量取决于发送方应用程序愿意发送的关于用户数据消息传输的控制通信量的百分比。列表中的更多条目可能允许发送方对拥塞控制动态做出更大的响应。列表的长度可以根据当前传输速率和NORM_CMD（CC）消息的调度动态地确定。列表的最大长度对应于会话的发送方NORMSECTIONSIZE参数。根据接收者反馈在列表中包含其他条目的优先顺序如下：
1) Receivers that have not yet been provided RTT feedback get first priority. Of these, those with the greatest loss fraction receive precedence for list inclusion.
1) 尚未提供RTT反馈的接收器获得第一优先级。其中，损失率最高的优先列入名单。
2) Secondly, receivers that have previously been provided RTT are included with receivers yielding the lowest calculated congestion rate getting precedence.
2) 第二，先前已提供RTT的接收器包括产生获得优先权的最低计算拥塞率的接收器。
There are "cc_flag" values in addition to NORM_FLAG_CC_CLR that are used for other congestion control functions. The NORM_FLAG_CC_PLR flag value is used to mark additional receivers from that the sender would like to have immediate, non-suppressed feedback. These may be receivers that the sender algorithmically identified as potential future CLRs or that have been pre-configured as potential congestion control points in the network. The NORM_FLAG_CC_RTT indicates the validity of the "cc_rtt" field for the associated receiver node. Normally, this flag will be set since the receivers in the list will typically be receivers from which the sender has received feedback. However, in the case that the NORM sender has been pre-configured with a set of PLR nodes, feedback from those receivers may not yet have been collected and thus the "cc_rtt" and "cc_rate" fields do not contain valid values when this flag is not set.
除了用于其他拥塞控制功能的NORM_flag_cc_CLR之外，还有“cc_flag”值。NORM_FLAG_CC_PLR FLAG值用于标记发送方希望立即获得非抑制反馈的其他接收器。这些可以是发送方算法上识别为潜在未来CLR的接收器，或者已经预先配置为网络中的潜在拥塞控制点的接收器。NORM_FLAG_CC_RTT指示关联接收器节点的“CC_RTT”字段的有效性。通常，将设置此标志，因为列表中的接收者通常是发送者从中接收反馈的接收者。然而，在NORM发送器已经预先配置了一组PLR节点的情况下，来自这些接收器的反馈可能还没有被收集，因此当未设置该标志时，“cc_rtt”和“cc_rate”字段不包含有效值。
Receivers explicitly respond to NORM_CMD(CC) messages in the form of a NORM_ACK(RTT) message. The goal of the congestion control feedback is to determine the receivers with the lowest congestion control rates. Receivers that are marked as CLR or PLR nodes in the NORM_CMD(CC) "cc_node_list" immediately provide feedback in the form of a NORM_ACK to this message. When a NORM_CMD(CC) is received, non-CLR or non-PLR nodes initiate random feedback backoff timeouts similar to that used when the receiver initiates a repair cycle (see Section 5.3) in response to detection of data loss. The backoff timeout for the congestion control response is generated as follows:
接收方以NORM_ACK（RTT）消息的形式显式响应NORM_CMD（CC）消息。拥塞控制反馈的目标是确定具有最低拥塞控制速率的接收机。在NORM_CMD（CC）“CC_node_list”中标记为CLR或PLR节点的接收器立即以NORM_ACK的形式对此消息提供反馈。当接收到NORM_CMD（CC）时，非CLR或非PLR节点启动随机反馈回退超时，类似于接收器启动修复周期（见第5.3节）以响应数据丢失检测时使用的超时。拥塞控制响应的退避超时生成如下：
T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender)
T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender)
The "RandomBackoff()" algorithm provides a truncated exponentially distributed random number and is described in the NORM Building Block document [4]. The same backoff factor K = Ksender MAY be used as with NORM_NACK suppression. However, in cases where the application purposefully specifies a very small Ksender backoff factor to minimize the NACK repair process latency (trading off group size scalability), it may still be desirable to maintain a larger backoff factor for congestion control feedback, since there may often be a larger volume of congestion control feedback than NACKs in many cases and congestion control feedback latency may be tolerable where reliable delivery latency is not. As previously noted, a backoff factor value of K = 4 is generally recommended for ASM operation and K = 6 for SSM operation. A receiver SHALL cancel the backoff timeout and thus its pending transmission of a NORM_ACK(RTT) message under the following conditions:
“RandomBackoff（）”算法提供了一个截断的指数分布随机数，在NORM构建块文档[4]中进行了描述。同一退避系数K=K可与NORM_NACK抑制一起使用。然而，在应用程序有意指定非常小的Ksender退避因子以最小化NACK修复过程延迟（权衡组大小可伸缩性）的情况下，可能仍然希望为拥塞控制反馈保持更大的退避因子，因为在许多情况下，拥塞控制反馈的容量通常比NACK的容量大，并且在没有可靠的传递延迟的情况下，拥塞控制反馈延迟是可以容忍的。如前所述，通常建议ASM操作的退避系数值为K=4，SSM操作的退避系数值为K=6。在以下条件下，接收器应取消退避超时，从而取消其等待传输的NORM_ACK（RTT）消息：
1) The receiver generates another feedback message (NORM_NACK or other NORM_ACK) before the congestion control feedback timeout expires,
1) 在拥塞控制反馈超时到期之前，接收器生成另一反馈消息（NORM_NACK或其他NORM_ACK），
2) A NORM_CMD(CC) or other receiver feedback with an ordinally greater "cc_sequence" field value is received before the congestion control feedback timeout expires (this is similar to the TFMCC feedback round number),
2) 在拥塞控制反馈超时到期之前，接收到NORM_CMD（CC）或其他具有顺序更大“CC_序列”字段值的接收器反馈（这类似于TFMCC反馈轮数），
3) When the T_backoff is greater than 1*GRTT. This prevents NACK implosion in the event of sender or network failure,
3) 当T_后退大于1*GRTT时。这可防止在发送方或网络发生故障时NACK内爆，
4) "Suppressing" congestion control feedback is heard from another receiver (in a NORM_ACK or NORM_NACK) or via a NORM_CMD(REPAIR_ADV) message from the sender. The local receiver's feedback is "suppressed" if the rate of the competing feedback (Rfb) is sufficiently close to or less than the local receiver's calculated rate (Rcalc). The local receiver's feedback is canceled when:
4) “抑制”拥塞控制反馈从另一个接收器（在NORM_ACK或NORM_NACK中）或通过来自发送方的NORM_CMD（REPAIR_ADV）消息听到。如果竞争反馈（Rfb）的速率足够接近或小于本地接收机的计算速率（Rcalc），则本地接收机的反馈被“抑制”。在以下情况下，取消本地接收器的反馈：
Rcalc > (0.9 * Rfb)
Rcalc>（0.9*Rfb）
Also note receivers that have not yet received an RTT measurement from the sender are suppressed only by other receivers that have not yet measured RTT. Additionally, receivers whose RTT estimate has "aged" considerably (i.e., they haven't been included in the NORM_CMD(CC) "cc_node_list" in a long time) may wish to compete as a receiver with no prior RTT measurement after some expiration period.
另请注意，尚未从发送方接收RTT测量的接收器仅被尚未测量RTT的其他接收器抑制。此外，其RTT估计值已明显“老化”的接收机（即，它们在很长时间内未被包括在NORM_CMD（CC）“CC_节点_列表”中）可能希望在某个到期期后作为事先未进行RTT测量的接收机进行竞争。
When the backoff timer expires, the receiver SHALL generate a NORM_ACK(RTT) message to provide feedback to the sender and group. This message may be multicast to the group for most effective suppression in ASM topologies or unicast to the sender depending upon how the NORM protocol is deployed and configured.
当退避计时器到期时，接收方应生成一条NORM_ACK（RTT）消息，以向发送方和组提供反馈。根据NORM协议的部署和配置方式，该消息可以多播到组以获得ASM拓扑中最有效的抑制，也可以单播到发送方。
Whenever any feedback is generated (including this NORM_ACK(RTT) message), receivers include an adjusted version of the sender timestamp from the most recently received NORM_CMD(CC) message and the "cc_sequence" value from that command in the applicable NORM_ACK or NORM_NACK message fields. For NORM-CC operation, any generated feedback message SHALL also contain the NORM-CC Feedback header extension. The receiver provides its current "cc_rate" estimate, "cc_loss" estimate, "cc_rtt" if known, and any applicable "cc_flags" via this header extension.
无论何时生成任何反馈（包括此NORM_ACK（RTT）消息），接收方都会在适用的NORM_ACK或NORM_NACK消息字段中包含来自最近接收的NORM_CMD（CC）消息的发送方时间戳的调整版本以及来自该命令的“CC_序列”值。对于NORM-CC操作，任何生成的反馈消息也应包含NORM-CC反馈头扩展。接收机通过该报头扩展提供其当前“cc_速率”估计、“cc_损失”估计、“cc_rtt”（如果已知）和任何适用的“cc_标志”。
During slow start (when the receiver has not yet detected loss from the sender), the receiver uses a value equal to two times its measured rate from the sender in the "cc_rate" field. For steady-state congestion control operation, the receiver "cc_rate" value is from the equation-based value using its current loss event estimate and sender<->receiver RTT information. (The GRTT is used when the receiver has not yet measured its individual RTT).
在慢速启动期间（当接收器尚未检测到来自发送方的丢失时），接收器在“cc_速率”字段中使用一个等于其来自发送方的测量速率两倍的值。对于稳态拥塞控制操作，接收器“cc_rate”值来自基于方程的值，使用其当前损失事件估计值和发送方<->接收器RTT信息。（当接收器尚未测量其单个RTT时，使用GRTT）。
The "cc_loss" field value reflects the receiver's current loss event estimate with respect to the sender in question.
“cc_损失”字段值反映了接收方对相关发送方的当前损失事件估计。
When the receiver has a valid individual RTT measurement, it SHALL include this value in the "cc_rtt" field. The NORM_FLAG_CC_RTT MUST be set when the "cc_rtt" field is valid.
当接收器具有有效的单个RTT测量值时，应将该值包含在“cc_RTT”字段中。当“CC\u RTT”字段有效时，必须设置NORM\u FLAG\u CC\u RTT。
After a congestion control feedback message is generated or when the feedback is suppressed, a non-CLR receiver begins a "holdoff" timeout period during which it will restrain itself from providing congestion control feedback, even if NORM_CMD(CC) messages are received from the sender (unless the receive becomes marked as a CLR or PLR node). The value of this holdoff timeout (T_ccHoldoff) period is:
生成拥塞控制反馈消息后或反馈被抑制时，非CLR接收器将开始一个“延迟”超时期，在此期间，即使从发送方接收到NORM_CMD（CC）消息（除非接收被标记为CLR或PLR节点），它也会限制自己提供拥塞控制反馈。此延迟超时（T_ccHoldoff）时间段的值为：
T_ccHoldoff = (K*GRTT)
T_ccHoldoff = (K*GRTT)
Thus, non-CLR receivers are constrained to providing explicit congestion control feedback once per K*GRTT intervals. Note, however, that as the session progresses, different receivers will be responding to different NORM_CMD(CC) messages and there will be relatively continuous feedback of congestion control information while the sender is active.
因此，非CLR接收机被限制为每K*GRTT间隔提供一次显式拥塞控制反馈。但是，请注意，随着会话的进行，不同的接收方将响应不同的NORM_CMD（CC）消息，并且在发送方处于活动状态时，将有相对连续的拥塞控制信息反馈。
During steady-state operation, the sender will directly adjust its transmission rate to the rate indicated by the feedback from its currently selected CLR. As noted in [19], the estimation of parameters (loss and RTT) for the CLR will generally constrain the rate changes possible within acceptable bounds. For rate increases, the sender SHALL observe a maximum rate of increase of one packet per RTT at all times during steady-state operation.
在稳态运行期间，发送器将直接将其传输速率调整为当前所选CLR反馈指示的速率。如[19]所述，CLR参数（损耗和RTT）的估计通常将速率变化限制在可接受的范围内。对于速率增加，发送方应在稳态运行期间始终观察每RTT一个数据包的最大增加速率。
The sender processes congestion control feedback from the receivers and selects the CLR based on the lowest rate receiver. Receiver rates are either determined directly from the slow start "cc_rate" provided by the receiver in the NORM-CC Feedback header extension or by performing the equation-based calculation using individual RTT and loss estimates ("cc_loss") as feedback is received.
发送方处理来自接收方的拥塞控制反馈，并基于最低速率的接收方选择CLR。接收机速率直接由接收机在NORM-cc反馈报头扩展中提供的慢启动“cc_速率”确定，或者在接收反馈时使用单个RTT和损耗估计（“cc_损耗”）执行基于方程的计算。
The sender can calculate a current RTT for a receiver (RTT_rcvrNew) using the "grtt_response" timestamp included in feedback messages. When the "cc_rtt" value in a response is not valid, the sender simply uses this RTT_rcvrNew value as the receiver's current RTT (RTT_rcvr). For non-CLR and non-PLR receivers, the sender can use the "cc_rtt" value provided in the NORM-CC Feedback header extension as the receiver's previous RTT measurement (RTT_rcvrPrev) to smooth according to:
发送方可以使用反馈消息中包含的“grtt_响应”时间戳计算接收方的当前RTT（RTT_rcvrNew）。当响应中的“cc_rtt”值无效时，发送方仅使用此rtt_rcvr新值作为接收方的当前rtt（rtt_rcvr）。对于非CLR和非PLR接收机，发送方可使用NORM-cc反馈报头扩展中提供的“cc_rtt”值作为接收机先前的rtt测量（rtt_rcvrPrev），以根据以下要求进行平滑：
RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew
RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew
For CLR receivers where feedback is received more regularly, the sender SHOULD maintain a more smoothed RTT estimate upon new feedback from the CLR where:
对于更定期收到反馈的CLR接收器，发送方应在收到来自CLR的新反馈时保持更平滑的RTT估计，其中：
RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew
RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew
"RTT_clrNew" is the new RTT calculated from the timestamp in the feedback message received from the CLR. The RTT_clr is initialized to RTT_clrNew on the first feedback message received. Note that the same procedure is observed by the sender for PLR receivers and that if a PLR is "promoted" to CLR status, the smoothed estimate can be continued.
“RTT_clrNew”是根据从CLR接收的反馈消息中的时间戳计算的新RTT。在收到第一条反馈消息时，RTT_clr被初始化为RTT_clrNew。请注意，发送方对PLR接收机遵循相同的程序，如果PLR“升级”到CLR状态，则平滑估计可以继续。
There are some additional periods besides steady-state operation that need to be considered in NORM-CC operation. These periods are:
除稳态运行外，NORM-CC运行中还需要考虑一些额外的周期。这些时期是：
1) during session startup,
1) 在会话启动期间，
2) when no feedback is received from the CLR, and
2) 当没有收到来自CLR的反馈时，以及
3) when the sender has a break in data transmission.
3) 当发送方的数据传输中断时。
During session startup, the congestion control operation SHALL observe a "slow start" procedure to quickly approach its fair bandwidth share. An initial sender startup rate is assumed where:
在会话启动期间，拥塞控制操作应遵守“慢启动”程序，以快速接近其公平带宽共享。假设初始发送方启动速率，其中：
Rinitial = MIN(NormSegmentSize / GRTT, NormSegmentSize) bytes/second.
Rinitial=MIN（NormSegmentSize/GRTT，NormSegmentSize）字节/秒。
The rate is increased only when feedback is received from the receiver set. The "slow start" phase proceeds until any receiver provides feedback indicating that loss has occurred. Rate increase during slow start is applied as:
仅当接收到来自接收器集的反馈时，速率才会增加。“慢启动”阶段继续进行，直到任何接收器提供反馈，表明发生了丢失。慢启动期间的速率增加适用于：
Rnew = Rrecv_min
Rnew = Rrecv_min
where "Rrecv_min" is the minimum reported receiver rate in the "cc_rate" field of congestion control feedback messages received from the group. Note that during "slow start", receivers use two times their measured rate from the sender in the "cc_rate" field of their feedback. Rate increase adjustment is limited to once per GRTT during slow start.
其中，“Rrecv_min”是从组接收的拥塞控制反馈消息的“cc_rate”字段中报告的最小接收速率。请注意，在“慢启动”期间，接收器在其反馈的“cc_rate”字段中使用来自发送器的两倍于其测量速率的速率。在缓慢启动期间，每个GRTT的速率增加调整限制为一次。
If the CLR or any receiver intends to leave the group, it will set the NORM_FLAG_CC_LEAVE in its congestion control feedback message as an indication that the sender should not select it as the CLR. When the CLR changes to a lower rate receiver, the sender should immediately adjust to the new lower rate. The sender is limited to increasing its rate at one additional packet per RTT towards any new, higher CLR rate.
如果CLR或任何接收者打算离开该组，它将在其拥塞控制反馈消息中设置NORM_FLAG_CC_leave，作为发送者不应选择它作为CLR的指示。当CLR更改为较低速率接收器时，发送方应立即调整为新的较低速率。发送方被限制为以每RTT一个额外数据包的速率向任何新的、更高的CLR速率增加速率。
The sender should also track the "age" of the feedback it has received from the CLR by comparing its current "cc_sequence" value (Seq_sender) to the last "cc_sequence" value received from the CLR (Seq_clr). As the "age" of the CLR feedback increases with no new feedback, the sender SHALL begin reducing its rate once per RTT_clr as a congestion avoidance measure.
发送方还应通过将其当前“cc_序列”值（Seq_发送方）与从CLR（Seq_CLR）收到的上一个“cc_序列”值进行比较，跟踪其从CLR收到的反馈的“期限”。由于CLR反馈的“期限”增加，且没有新的反馈，发送方应开始在每个RTT_CLR中降低其速率一次，作为拥塞避免措施。
The following algorithm is used to determine the decrease in sender rate (Rsender bytes/sec) as the CLR feedback, unexpectedly, excessively ages:
以下算法用于确定CLR反馈意外过度老化时发送方速率（Rsender字节/秒）的降低：
Age = Seq_sender - Seq_clr;
if (Age > 4) Rsender = Rsender * 0.5;
Age = Seq_sender - Seq_clr;
if (Age > 4) Rsender = Rsender * 0.5;
This rate reduction is limited to the lower bound on NORM transmission rate. After NORM_ROBUST_FACTOR consecutive NORM_CMD(CC) rounds without any feedback from the CLR, the sender SHOULD assume the CLR has left the group and pick the receiver with the next lowest
这种速率降低仅限于标准传输速率的下限。在NORM_ROBUST_FACTOR连续NORM_CMD（CC）轮没有来自CLR的任何反馈后，发送方应假设CLR已离开该组，并选择下一个最低的接收方
rate as the new CLR. Note this assumes that the sender does not have explicit knowledge that the CLR intentionally left the group. If no receiver feedback is received, the sender MAY wish to withhold further transmissions of NORM_DATA segments and maintain NORM_CMD(CC) transmissions only until feedback is detected. After such a CLR timeout, the sender will be transmitting with a minimal rate and should return to slow start as described here for a break in data transmission.
作为新的CLR进行评级。注意：这假设发送方不明确知道CLR有意离开组。如果没有接收到接收机反馈，发送方可能希望保留NORM_数据段的进一步传输，并仅在检测到反馈之前保持NORM_CMD（CC）传输。在CLR超时后，发送方将以最小速率进行传输，并应返回到慢速启动，如此处所述，以中断数据传输。
When the sender has a break in its data transmission, it can continue to probe the group with NORM_CMD(CC) messages to maintain RTT collection from the group. This will enable the sender to quickly determine an appropriate CLR upon data transmission restart. However, the sender should exponentially reduce its target rate to be used for transmission restart as time since the break elapses. The target rate SHOULD be recalculated once per RTT_clr as:
当发送方的数据传输中断时，它可以继续使用NORM_CMD（CC）消息探测组，以维护来自组的RTT收集。这将使发送方能够在数据传输重新启动时快速确定适当的CLR。但是，发送方应随着中断时间的推移，以指数方式降低其用于传输重启的目标速率。每个RTT_clr应重新计算一次目标费率，如下所示：
Rsender = Rsender * 0.5;
Rsender = Rsender * 0.5;
If the minimum NORM rate is reached, the sender should set the NORM_FLAG_START flag in its NORM_CMD(CC) messages upon restart and the group should observer "slow start" congestion control procedures until any receiver experiences a new loss event.
如果达到最低正常速率，发送方应在重启时在其NORM_CMD（CC）消息中设置NORM_FLAG_START FLAG，并且组应观察“慢速启动”拥塞控制程序，直到任何接收方经历新的丢失事件。
NORM provides options for the source application to request positive acknowledgment (ACK) of NORM_CMD(FLUSH) and NORM_CMD(ACK_REQ) messages from members of the group. There are some specific acknowledgment requests defined for the NORM protocol and a range of acknowledgment request types that are left to be defined by the application. One predefined acknowledgment type is the NORM_ACK_FLUSH type. This acknowledgment is used to determine if receivers have achieved completion of reliable reception up through a specific logical transmission point with respect to the sender's sequence of transmission. The NORM_ACK_FLUSH acknowledgment may be used to assist in application flow control when the sender has information on a portion of the receiver set. Another predefined acknowledgment type is NORM_ACK(CC), which is used to explicitly provide congestion control feedback in response to NORM_CMD(CC) messages transmitted by the sender for NORM-CC operation. Note the NORM_ACK(CC) response does NOT follow the positive acknowledgment procedure described here. The NORM_CMD(ACK_REQ) and NORM_ACK messages contain an "ack_type" field to identify the type of acknowledgment requested and provided. A range of "ack_type" values is provided for application-defined use. While the application is responsible for initiating the acknowledgment request and interprets application-defined "ack_type" values, the acknowledgment procedure
NORM为源应用程序提供选项，以请求组成员对NORM_CMD（FLUSH）和NORM_CMD（ACK_REQ）消息的肯定确认（ACK）。有一些为NORM协议定义的特定确认请求和一系列由应用程序定义的确认请求类型。一种预定义的确认类型是NORM_ACK_FLUSH类型。该确认用于确定接收机是否已通过特定逻辑传输点完成了与发送方传输序列相关的可靠接收。当发送方具有关于接收器集的一部分的信息时，NORM_ACK_FLUSH确认可用于协助应用程序流控制。另一种预定义的确认类型是NORM_ACK（CC），用于显式提供拥塞控制反馈，以响应发送方为NORM-CC操作发送的NORM_CMD（CC）消息。注：正常确认（CC）响应不遵循此处描述的肯定确认过程。NORM_CMD（ACK_REQ）和NORM_ACK消息包含一个“ACK_type”字段，用于标识请求和提供的确认类型。为应用程序定义的使用提供了一系列“确认类型”值。当应用程序负责启动确认请求并解释应用程序定义的“确认类型”值时，确认过程
SHOULD be conducted within the protocol implementation to take advantage of timing and transmission scheduling information available to the NORM transport.
应在协议实现内进行，以利用NORM传输可用的定时和传输调度信息。
The NORM positive acknowledgment procedure uses polling by the sender to query the receiver group for response. Note this polling procedure is not intended to scale to very large receiver groups, but could be used in large group setting to query a critical subset of the group. Either the NORM_CMD(ACK_REQ), or when applicable, the NORM_CMD(FLUSH) message is used for polling and contains a list of NormNodeIds for receivers that should respond to the command. The list of receivers providing acknowledgment is determined by the source application with "a priori" knowledge of participating nodes or via some other application-level mechanism.
NORM肯定确认过程使用发送方的轮询来查询接收方组的响应。注意：此轮询过程不打算扩展到非常大的接收方组，但可以在大型组设置中使用，以查询组的关键子集。NORM_CMD（ACK_REQ）或适用时，NORM_CMD（FLUSH）消息用于轮询，并包含应响应命令的接收器的normnodeid列表。提供确认的接收器的列表由具有参与节点的“先验”知识的源应用程序或通过一些其他应用程序级机制确定。
The ACK process is initiated by the sender that generates NORM_CMD(FLUSH) or NORM_CMD(ACK_REQ) messages in periodic "rounds". For NORM_ACK_FLUSH requests, the NORM_CMD(FLUSH) contain a "object_transport_id" and "fec_payload_id" denoting the watermark transmission point for which acknowledgment is requested. This watermark transmission point is "echoed" in the corresponding fields of the NORM_ACK(FLUSH) message sent by the receiver in response. NORM_CMD(ACK_REQ) messages contain an "ack_id" field which is similarly "echoed" in response so that the sender may match the response to the appropriate request.
确认过程由发送方启动，发送方在周期性的“轮次”中生成NORM_CMD（FLUSH）或NORM_CMD（ACK_REQ）消息。对于NORM_ACK_FLUSH请求，NORM_CMD（FLUSH）包含“object_transport_id”和“fec_payload_id”，表示请求确认的水印传输点。此水印传输点在接收器响应发送的NORM_ACK（FLUSH）消息的相应字段中“回声”。NORM_CMD（ACK_REQ）消息包含一个“ACK_id”字段，该字段在响应中类似地“回声”，以便发送方可以将响应与适当的请求相匹配。
In response to the NORM_CMD(ACK_REQ), the listed receivers randomly spread NORM_ACK messages uniformly in time over a window of (1*GRTT). These NORM_ACK messages are typically unicast to the sender. (Note that NORM_ACK(CC) messages SHALL be multicast or unicast in the same manner as NORM_NACK messages).
作为对NORM_CMD（ACK_REQ）的响应，列出的接收机在（1*GRTT）的时间窗口内随机均匀地传播NORM_ACK消息。这些标准确认消息通常单播给发送方。（注意，NORM_ACK（CC）消息应采用与NORM_NACK消息相同的方式进行多播或单播）。
The ACK process is self-limiting and avoids ACK implosion in that:
ACK过程具有自限性，可避免ACK内爆，因为：
1) Only a single NORM_CMD(ACK_REQ) message is generated once per (2*GRTT), and,
1) 每个（2*GRTT）仅生成一条NORM_CMD（ACK_REQ）消息，并且，
2) The size of the "acking_node_list" of NormNodeIds from which acknowledgment is requested is limited to a maximum of the sender NormSegmentSize setting per round of the positive acknowledgment process.
2) 请求确认的NORMNODEID的“确认节点列表”的大小限制为每轮肯定确认过程中发送方NORMSECTIONSIZE设置的最大值。
Because the size of the included list is limited to the sender's NormSegmentSize setting, multiple NORM_CMD(ACK_REQ) rounds may be required to achieve responses from all receivers specified. The content of the attached NormNodeId list will be dynamically updated as this process progresses and NORM_ACK responses are received from the specified receiver set. As the sender receives valid responses
由于包含列表的大小仅限于发送方的NORMSECTIONSIZE设置，因此可能需要多轮NORM_CMD（ACK_REQ）以获得所有指定接收方的响应。随此过程的进行，所附NormNodeId列表的内容将动态更新，并从指定的接收器集接收NORM_ACK响应。当发送方收到有效响应时
(i.e., matching watermark point or "ack_id") from receivers, it SHALL eliminate those receivers from the subsequent NORM_CMD(ACK_REQ) message "acking_node_list" and add in any pending receiver NormNodeIds while keeping within the NormSegmentSize limitation of the list size. Each receiver is queried a maximum number of times (NORM_ROBUST_FACTOR, by default). Receivers not responding within this number of repeated requests are removed from the payload list to make room for other potential receivers pending acknowledgment. The transmission of the NORM_CMD(ACK_REQ) is repeated until no further responses are required or until the repeat threshold is exceeded for all pending receivers. The transmission of NORM_CMD(ACK_REQ) or NORM_CMD(FLUSH) messages to conduct the positive acknowledgment process is multiplexed with ongoing sender data transmissions. However, the NORM_CMD(FLUSH) positive acknowledgment process may be interrupted in response to negative acknowledgment repair requests (NACKs) received from receivers during the acknowledgment period. The NORM_CMD(FLUSH) positive acknowledgment process is restarted for receivers pending acknowledgment once any the repairs have been transmitted.
（即，匹配来自接收者的水印点或“确认id”），应将这些接收者从随后的NORM_CMD（确认请求）消息“确认节点列表”中删除，并添加任何待处理的接收者NORMNODEID，同时保持在列表大小的NORMSECTIONSIZE限制内。每个接收器被查询的次数最多（默认情况下为NORM\u ROBUST\u FACTOR）。在这个重复请求数内没有响应的接收器将从有效负载列表中删除，以便为等待确认的其他潜在接收器腾出空间。重复传输NORM_CMD（ACK_REQ），直到不需要进一步的响应，或者直到所有待处理的接收器超过重复阈值。用于执行肯定确认过程的NORM_CMD（ACK_REQ）或NORM_CMD（FLUSH）消息的传输与正在进行的发送方数据传输进行多路复用。然而，NORM_CMD（FLUSH）肯定确认过程可能会被中断，以响应在确认期间从接收机接收到的否定确认修复请求（nack）。一旦发送了任何修复，等待确认的接收器将重新启动NORM_CMD（FLUSH）肯定确认过程。
In the case of NORM_CMD(FLUSH) commands with an attached "acking_node_list", receivers will not ACK until they have received complete transmission of all data up to and including the given watermark transmission point. All receivers SHALL interpret the watermark point provided in the request NACK for repairs if needed as for NORM_CMD(FLUSH) commands with no attached "acking_node_list".
如果NORM_CMD（FLUSH）命令带有附加的“acking_node_list”（确认节点列表），则接收器将不会确认，直到它们接收到所有数据的完整传输（包括给定水印传输点）。如果需要，所有接收者应将NACK维修请求中提供的水印点解释为NORM_CMD（FLUSH）命令，无附加的“确认节点列表”。
NORM sender messages contain a "gsize" field that is a representation of the group size and is used in scaling random backoff timer ranges. The use of the group size estimate within the NORM protocol does not require a precise estimation and works reasonably well if the estimate is within an order of magnitude of the actual group size. By default, the NORM sender group size estimate may be administratively configured. Also, given the expected scalability of the NORM protocol for general use, a default value of 10,000 is recommended for use as the group size estimate.
NORM sender消息包含一个“gsize”字段，该字段表示组大小，用于缩放随机退避计时器范围。在NORM协议中使用组大小估计值不需要精确的估计值，如果估计值在实际组大小的数量级范围内，则效果相当好。默认情况下，可以通过管理方式配置标准发送方组大小估计。此外，考虑到一般使用的NORM协议的预期可伸缩性，建议使用默认值10000作为组大小估计值。
It is possible that group size may be algorithmically approximated from the volume of congestion control feedback messages which follow the exponentially weighted random backoff. However, the specification of such an algorithm is currently beyond the scope of this document.
组大小可能通过算法从指数加权随机退避之后的拥塞控制反馈消息的量来近似。然而，这种算法的规范目前超出了本文件的范围。
The same security considerations that apply to the NORM, and FEC Building Blocks also apply to the NORM protocol. In addition to vulnerabilities that any IP and IP multicast protocol implementation may be generally subject to, the NACK-based feedback of NORM may be exploited by replay attacks which force the NORM sender to unnecessarily transmit repair information. This MAY be addressed by network layer IP security implementations that guard against this potential security exploitation. It is RECOMMENDED that such IP security mechanisms be used when available. Another possible approach is for NORM senders to use the "sequence" field from the NORM Common Message Header to detect replay attacks. This can be accomplished if the NORM packets are cryptographically protected and the sender is willing to maintain state on receivers which are NACKing. A cache of receiver state may provide some protection against replay attacks. Note that the "sequence" field of NORM messages should be incremented with independent values for different destinations (e.g., group-addressed versus unicast-addressed messages versus "receiver" messages). Thus, the congestion control loss estimation function of the "sequence" field can be preserved for sender messages when receiver messages are unicast to the sender. The NORM protocol is compatible with the use of the IP security (IPsec) architecture described in [22]. It is important to note that while NORM does leverage FEC-based repair for scalability, this does not alone guarantee integrity of received data. Application-level integrity-checking of data content is highly RECOMMENDED.
适用于NORM和FEC构建块的安全注意事项同样适用于NORM协议。除了任何IP和IP多播协议实现通常会遇到的漏洞外，基于NACK的NORM反馈可能会被重播攻击利用，从而迫使NORM发送方不必要地传输修复信息。这可以通过网络层IP安全实现来解决，这些实现可以防止这种潜在的安全攻击。建议在可用时使用此类IP安全机制。另一种可能的方法是，NORM发送者使用NORM Common消息头中的“sequence”字段来检测重播攻击。如果NORM数据包受到加密保护，并且发送方愿意在正在发送的接收方上保持状态，则可以实现这一点。接收器状态的缓存可以提供一些防止重放攻击的保护。请注意，NORM消息的“序列”字段应增加不同目的地的独立值（例如，组寻址消息与单播寻址消息与“接收方”消息）。因此，当接收方消息单播到发送方时，可以为发送方消息保留“序列”字段的拥塞控制损失估计功能。NORM协议与[22]中描述的IP安全（IPsec）体系结构的使用兼容。需要注意的是，尽管NORM确实利用基于FEC的修复来实现可伸缩性，但这并不能单独保证接收数据的完整性。强烈建议对数据内容进行应用程序级完整性检查。
No information in this specification is currently subject to IANA registration. However, several Header Extensions are defined within this document. If/when additional Header Extensions are developed, the first RFC MUST establish an IANA registry for them, with a "Specification Required" policy [6] and all Header Extensions, including those in the present document, MUST be registered thereafter. Additionally, building blocks components used by NORM may introduce additional IANA considerations. In particular, the FEC Building Block used by NORM does require IANA registration of the FEC codecs used. The registration instructions for FEC codecs are provided in [5].
本规范中的任何信息目前都不需要IANA注册。但是，本文档中定义了几个标题扩展。如果/当开发额外的标题扩展时，第一个RFC必须为其建立IANA注册中心，带有“需要规范”策略[6]，并且所有标题扩展，包括本文档中的标题扩展，必须在此后注册。此外，NORM使用的构建块组件可能会引入额外的IANA注意事项。特别是，NORM使用的FEC构建块确实需要对所使用的FEC编解码器进行IANA注册。[5]中提供了FEC编解码器的注册说明。
The present NORM protocol is seen as useful tool for the reliable data transfer over generic IP multicast services. It is not the intention of the authors to suggest it is suitable for supporting all envisioned multicast reliability requirements. NORM provides a
目前的NORM协议被认为是在通用IP多播服务上进行可靠数据传输的有用工具。作者无意建议它适用于支持所有预想的多播可靠性需求。NORM提供了一个
simple and flexible framework for multicast applications with a degree of concern for network traffic implosion and protocol overhead efficiency. NORM-like protocols have been successfully demonstrated within the MBone for bulk data dissemination applications, including weather satellite compressed imagery updates servicing a large group of receivers and a generic web content reliable "push" application.
简单灵活的多播应用框架，关注网络流量内爆和协议开销效率。类似规范的协议已在MBone中成功演示，用于批量数据发布应用，包括气象卫星压缩图像更新服务于大量接收器和通用web内容可靠的“推送”应用。
In addition, this framework approach has some design features making it attractive for bulk transfer in asymmetric and wireless internetwork applications. NORM is capable of successfully operating independent of network structure and in environments with high packet loss, delay, and misordering. Hybrid proactive/reactive FEC-based repairing improve protocol performance in some multicast scenarios. A sender-only repair approach often makes additional engineering sense in asymmetric networks. NORM's unicast feedback capability may be suitable for use in asymmetric networks or in networks where only unidirectional multicast routing/delivery service exists. Asymmetric architectures supporting multicast delivery are likely to make up an important portion of the future Internet structure (e.g., DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer will be an important capability for servicing large groups of subscribed receivers.
此外，该框架方法还具有一些设计特点，使其在非对称和无线互联网应用中具有大容量传输的吸引力。NORM能够独立于网络结构并在高数据包丢失、延迟和误序的环境中成功运行。在某些多播场景中，基于混合主动/被动FEC的修复可以提高协议性能。在非对称网络中，仅发送方的修复方法通常具有额外的工程意义。NORM的单播反馈能力可能适用于非对称网络或仅存在单向多播路由/传送服务的网络。支持多播传输的非对称体系结构可能构成未来互联网结构的重要组成部分（例如，DBS/cable/PSTN混合网络），高效、可靠的批量数据传输将是服务于大量订阅接收器的重要能力。
The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh, Toni Paila, Michael Luby, and Joerg Widmer for their valuable input and 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 input into this document.
作者要感谢Rick Jones、Vincent Roca、Rod Walsh、Toni Paila、Michael Luby和Joerg Widmer对本文件的宝贵投入和评论。作者还要感谢RMT工作组主席Roger Kermode和Lorenzo Vicisano对本规范开发的支持，以及Sally Floyd对本文件的早期投入。
[1] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[1] Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[4] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[4] Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）构建块”，RFC 39412004年11月。
[5] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[5] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[8] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[9] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", In Proc. INFOCOM, San Francisco CA, October 1993.
[9] S.Pingali，D.Towsley，J.Kurose，“发送方发起和接收方发起的可靠多播协议的比较”，在Proc。信息通信公司，旧金山CA，1993年10月。
[10] 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.
[10] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[11] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol (MDP) Toolkit", Proc. IEEE MILCOM 99, October 1999.
[11] Macker，J.和B.Adamson，“多播传播协议（MDP）工具包”，Proc。IEEE MILCOM 99，1999年10月。
[12] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", Proc. IEEE INFOCOMM, p. 964, March/April 1998.
[12] Nonnenmacher，J.和E.Biersack，“最佳多播反馈”，Proc。IEEE信息通信，p。1998年3月/4月，第964页。
[13] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002.
[13] J.Macker，B.Adamson，“面向Nack的可靠多播（NORM）反馈的定量预测”，Proc。IEEE MILCOM 2002，2002年10月。
[14] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[14] H.W.Holbrook，“多播的信道模型”，博士。斯坦福大学计算机科学系博士论文，斯坦福，加利福尼亚，2001年8月。
[15] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOMM 98', September 1998.
[15] D.Gossink，J.Macker，“具有信道估计的可靠多播和集成奇偶重传”，IEEE GlobeCom 98，1998年9月。
[16] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[16] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[17] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[17] Mankin，A.，Romanow，A.，Bradner，S.，和V.Paxson，“评估可靠多播传输和应用协议的IETF标准”，RFC 2357，1998年6月。
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[18] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[19] J. Widmer and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, August 2001.
[19] J.Widmer和M.Handley，“将基于方程的拥塞控制扩展到多播应用”，Proc ACM SIGCOMM 2001，圣地亚哥，2001年8月。
[20] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[20] L.Rizzo，“pgmcc：一种TCP友好的单速率多播拥塞控制方案”，Proc ACM SIGCOMM 2000，斯德哥尔摩，2000年8月。
[21] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
[21] J.Padhye，V.Firoiu，D.Towsley和J.Kurose，“TCP吞吐量建模：一个简单模型及其经验验证”，Proc ACM SIGCOMM 1998。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Brian Adamson Naval Research Laboratory Washington, DC, USA, 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 Department of Computer Science 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, USA, 20375
乔·麦克尔海军研究实验室，华盛顿特区，美国，20375
EMail: macker@itd.nrl.navy.mil
EMail: macker@itd.nrl.navy.mil
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。