Network Working Group B. Adamson
Request for Comments: 5740 Naval Research Laboratory
Obsoletes: 3940 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2009
Network Working Group B. Adamson
Request for Comments: 5740 Naval Research Laboratory
Obsoletes: 3940 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2009
NACK-Oriented Reliable Multicast (NORM) Transport Protocol
面向NACK的可靠多播（NORM）传输协议
Abstract
摘要
This document describes the messages and procedures of the Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can 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 (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940.
本文档描述面向否定确认（NACK）的可靠多播（NORM）协议的消息和过程。该协议可以通过通用IP多播路由和转发服务提供批量数据对象或流的端到端可靠传输。NORM使用选择性的、否定的确认机制来提高传输可靠性，并提供额外的协议机制，以允许在发送方和接收方之间以最小的先验协调进行操作。指定了一种拥塞控制方案，以允许NORM协议与传输控制协议（TCP）等其他传输协议公平共享可用网络带宽。它能够在发送方和接收方之间使用互惠多播路由，并在发送方和接收方之间使用非对称连接（可能是单播返回路径）。该协议提供了许多功能，以允许不同类型的应用程序或可能的其他更高级别的传输协议以不同的方式利用其服务。该协议在设计中利用了基于FEC（前向纠错）的修复和其他IETF可靠多播传输（RMT）构建块。本文件淘汰了RFC 3940。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction and Applicability . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 5
1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 7
1.4. Environmental Requirements and Considerations . . . . . . 8
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 8
2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 10
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 12
2.3. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. NORM Common Message Header and Extensions . . . . . . . . 15
4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 18
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 28
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 29
4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 47
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . 47
4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 53
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 55
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 55
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 55
5.1. Sender Initialization and Transmission . . . . . . . . . . 57
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 58
1. Introduction and Applicability . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 5
1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 7
1.4. Environmental Requirements and Considerations . . . . . . 8
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 8
2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 10
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 12
2.3. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. NORM Common Message Header and Extensions . . . . . . . . 15
4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 18
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 28
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 29
4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 47
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . 47
4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 53
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 55
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 55
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 55
5.1. Sender Initialization and Transmission . . . . . . . . . . 57
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 58
5.2. Receiver Initialization and Reception . . . . . . . . . . 59
5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 59
5.4. Sender NACK Processing and Response . . . . . . . . . . . 62
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 62
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 63
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 64
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 65
5.5.1. Group Round-Trip Time (GRTT) Collection . . . . . . . 65
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77
6. Configurable Elements . . . . . . . . . . . . . . . . . . . . 77
7. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 82
7.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 83
7.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
8.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 87
8.1.1. NORM Header Extension Types . . . . . . . . . . . . . 87
8.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 88
8.1.3. NORM_CMD Message Sub-Types . . . . . . . . . . . . . . 88
9. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 89
10. Changes from RFC 3940 . . . . . . . . . . . . . . . . . . . . 90
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12.1. Normative References . . . . . . . . . . . . . . . . . . . 91
12.2. Informative References . . . . . . . . . . . . . . . . . . 92
5.2. Receiver Initialization and Reception . . . . . . . . . . 59
5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 59
5.4. Sender NACK Processing and Response . . . . . . . . . . . 62
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 62
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 63
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 64
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 65
5.5.1. Group Round-Trip Time (GRTT) Collection . . . . . . . 65
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77
6. Configurable Elements . . . . . . . . . . . . . . . . . . . . 77
7. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 82
7.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 83
7.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
8.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 87
8.1.1. NORM Header Extension Types . . . . . . . . . . . . . 87
8.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 88
8.1.3. NORM_CMD Message Sub-Types . . . . . . . . . . . . . . 88
9. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 89
10. Changes from RFC 3940 . . . . . . . . . . . . . . . . . . . . 90
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12.1. Normative References . . . . . . . . . . . . . . . . . . . 91
12.2. Informative References . . . . . . . . . . . . . . . . . . 92
The Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol can provide reliable transport of data from one or more senders 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 self-adapting to a wide range of dynamic network conditions with little or no pre-configuration. The protocol is tolerant of inaccurate timing estimations or lossy conditions that can occur in many networks including mobile and wireless. The protocol can also converge and maintain efficient operation even in situations of heavy packet loss and large queuing or transmission delays. This document obsoletes the Experimental RFC 3940 specification.
面向否定确认（NACK）的可靠多播（NORM）协议可以通过IP多播网络将数据从一个或多个发送方可靠地传输到一组接收方。NORM的主要设计目标是在可能的异构IP网络和拓扑上提供高效、可扩展和健壮的批量数据（例如，计算机文件、持久数据传输）传输。NORM协议设计支持分布式多播会话参与，发送方和接收方之间的协调最小。NORM允许发送者和接收者随意动态地加入和离开多播会话，而参与者之间的控制信息和定时同步开销最小。为了适应这种能力，NORM协议消息头包含一些公共信息，允许接收方在可靠多播会话的整个生命周期内轻松地与发送方同步。NORM可以自适应于各种动态网络条件，并且几乎不需要预先配置。该协议能够容忍许多网络（包括移动和无线网络）中可能出现的不准确定时估计或有损情况。即使在严重的数据包丢失和较大的排队或传输延迟的情况下，该协议也可以收敛并保持有效的运行。本文件废除了实验性RFC 3940规范。
This document is a product of the IETF RMT working group and follows the guidelines provided in the Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents [RFC3269].
本文件是IETF RMT工作组的产品，遵循可靠多播传输（RMT）构建块和协议实例化文件[RFC3269]作者指南中提供的指南。
Statement of Intent
意向书
This memo contains the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with the criteria of IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols [RFC2357]. The NORM specification described in this document was previously published in the Experimental Category [RFC3940]. It was the stated intent of the RMT working group to re-submit this specifications as an IETF Proposed Standard in due course. This Proposed Standard specification is thus based on RFC 3940 and has been updated according to accumulated experience and growing protocol maturity since the publication of RFC 3940. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification. The differences between RFC 3940 and this document are listed in Section 10.
本备忘录包含根据IETF评估可靠多播传输和应用协议标准[RFC2357]完全指定可靠多播传输协议所需的定义。本文件中描述的规范规范先前已在实验类别[RFC3940]中发布。RMT工作组声明的目的是在适当的时候将本规范作为IETF建议的标准重新提交。因此，本拟议标准规范基于RFC 3940，并根据RFC 3940发布以来积累的经验和不断增长的协议成熟度进行了更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。第10节列出了RFC 3940和本文件之间的差异。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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 chosen via means outside the context of the given NormSession. Other existing IETF data format and protocol standards MAY be applied to describe and convey the necessary a priori information for a specific NormSession (e.g., Session Description Protocol (SDP) [RFC4566], Session Announcement Protocol (SAP) [RFC2974], etc.).
NORM协议实例（NormSession）是在参与者使用预先确定的地址和主机端口号通过网络进行无连接（例如，因特网协议（IP）或用户数据报协议（UDP））分组通信的上下文中定义的。通常，参与者使用IP多播组地址交换分组，但是单播传输也可以被建立或应用为多播传送的附件。在多播的情况下，参与多播的节点将使用公共IP多播组地址和端口号进行通信，该地址和端口号是通过给定多播会话上下文之外的方式选择的。其他现有IETF数据格式和协议标准可用于描述和传递特定会话的必要先验信息（例如，会话描述协议（SDP）[RFC4566]、会话公告协议（SAP）[RFC2974]等）。
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 independently of one another and receivers will maintain state as necessary for each sender. In future versions of NORM, it is possible some aspects of protocol operation (e.g., round-trip time collection) will 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 to allocate for received content (i.e., memory or file storage). Other than that
NORM_OBJECT_数据和NORM_OBJECT_文件之间的区别只是向服务于多种类型内容的NORM会话中的接收者提供一个提示，提示为接收到的内容分配何种类型的存储（即内存或文件存储）。除此之外
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 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 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 its message headers. Note the NORM_INFO out-of-band data mechanism can be leveraged by the application for this purpose if desired, or identification can 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. Participants, including senders, in NORM protocol sessions are also identified with unique identifiers (NormNodeIds). Each sender maintains its NormTransportId assignments independently and thus individual NormObjects can be uniquely identified during transport by concatenation of the session-unique sender identifier (NormNodeId) and the assigned NormTransportId. The NormTransportIds are assigned from a large, but fixed, numeric space in increasing order and will be reassigned during long-lived sessions. The NORM protocol provides mechanisms so the sender application can terminate transmission of data content and inform the group of this in an efficient manner. Other similar protocol control
NORM不提供消息头中数据内容的全局或应用程序级标识。注：如果需要，应用程序可以为此目的利用NORM_INFO带外数据机制，或者也可以在数据内容中嵌入标识。NORM使用传输标识符标识传输内容（NormObjects），传输标识符仅在发送方传输和/或修复给定对象时适用。这些传输数据内容标识符（NormTransportIds）由每个NORM发送方在NORM会话过程中以单调递增的方式分配。NORM协议会话中的参与者（包括发送者）也使用唯一标识符（NORMNODEID）进行标识。每个发送方独立维护其NormTransportId分配，因此在传输过程中，通过连接会话唯一发送方标识符（NormNodeId）和分配的NormTransportId，可以唯一标识各个NormObjects。NORMTransportID是从一个较大但固定的数字空间按递增顺序分配的，并将在长期会话期间重新分配。NORM协议提供了一些机制，使发送方应用程序能够终止数据内容的传输，并以有效的方式通知组。其他类似协议控制
mechanisms (e.g., session termination, receiver synchronization, etc.) are specified so reliable multicast application variants can realize different, complete bulk transfer communication models to meet their goals.
指定了机制（例如，会话终止、接收器同步等），因此可靠的多播应用程序变体可以实现不同、完整的批量传输通信模型，以满足其目标。
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 NACK-based protocol schemes when feedback for reliability is needed [RmComparison]. 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 [RFC3453]. FEC-based repair can be used to greatly reduce the quantity of reliable multicast repair requests and repair transmissions [MdpToolkit] 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 [McastFeedback]. NORM dynamically measures the group's round-trip 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的协议方案的自适应[RmComparison]。NORM是一个以使用选择性NACK请求修复丢失数据为中心的协议。NORM规定使用包级前向纠错（FEC）技术进行有效的多播修复和可选的主动传输鲁棒性[RFC3453]。在面向NACK的协议中，基于FEC的修复可用于大大减少可靠多播修复请求和修复传输[MdpToolkit]的数量。范数可伸缩性的主要因素是接收器集产生的反馈通信量，以促进可靠性和拥塞控制。NORM使用基于指数分布随机退避定时器的冗余反馈的概率抑制。与其他技术相比，此类抑制的性能在[McastFeedback]中进行了描述。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 relays the feedback state to the group to facilitate feedback suppression. In typical Internet environments, 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 [NormFeedback]. 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 for NORM to scale to larger group sizes. With respect to computer resource usage, the
反馈消息可以多播到整个组，也可以通过单播路由发送到发送方。在单播反馈的情况下，发送方将反馈状态转发给组以便于反馈抑制。在典型的Internet环境中，NORM协议将很容易扩展到数万个接收器的组大小。[NormFeedback]中对此类协议的反馈量进行了研究。NORM能够以比单个TCP连接更少的反馈量运行，即使有相对较多的接收器。因此，根据网络拓扑，NORM可以扩展到更大的组大小。在计算机资源使用方面
NORM protocol does not need state to be kept on all receivers in the group. NORM senders maintain state only for receivers providing explicit congestion control feedback. However, NORM receivers need to maintain state for each active sender. This can constrain the number of simultaneous senders in some uses of NORM.
NORM协议不需要在组中的所有接收器上保持状态。标准发送方仅为提供显式拥塞控制反馈的接收方维护状态。然而，NORM接收方需要维护每个活动发送方的状态。这可以限制NORM的某些用法中同时发送的数量。
All of the environmental requirements and considerations that apply to the "Multicast Negative-Acknowledgment (NACK) Building Blocks" [RFC5401], "Forward Error Correction (FEC) Building Block" [RFC5052], and "TCP-Friendly Multicast Congestion Control (TFMCC) Protocol Specification" [RFC4654] also apply to the NORM protocol.
适用于“多播否定确认（NACK）构建块”[RFC5401]、“前向纠错（FEC）构建块”[RFC5052]和“TCP友好多播拥塞控制（TFMCC）协议规范”[RFC4654]的所有环境要求和注意事项也适用于NORM协议。
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 "Host Extensions for IP Multicasting" [RFC1112], but it SHALL also be capable of scalable operation in asymmetric topologies such as Source-Specific Multicast (SSM) [RFC4607] where only unicast routing service is available from the receivers to the sender(s).
除了基本的IP多播组管理、路由和转发服务外，NORM协议应能够以端到端的方式运行，而无需中间系统的协助。虽然NORM中使用的技术主要适用于平坦的端到端IP多播拓扑，但如果需要，它们也可以应用于分层（例如，基于树的）多播分布的子级别。NORM可以在“IP多播的主机扩展”[RFC1112]中定义的任何源多播（ASM）模型下使用互惠（发送方和接收方之间）多播通信，但它还应能够在非对称拓扑中进行可伸缩操作，如源特定多播（SSM）[RFC4607]其中，从接收方到发送方仅提供单播路由服务。
NORM is compatible with IPv4 and IPv6. Additionally, NORM can be used with networks employing Network Address Translation (NAT) provided that 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 multiple possible senders and to distinguish feedback information from different receivers. There are two reserved NormNodeId values. A value of 0x00000000 is considered an invalid NormNodeId (NORM_NODE_NONE), and a value of 0xffffffff is a "wild card" NormNodeId (NORM_NODE_ANY).
NormSession由作为发送方和/或接收方的参与者（NormNodes）组成。NORM发送方以NormObjects的形式将数据内容发送到会话目标地址，NORM接收方尝试使用否定确认来可靠地接收发送的内容，以请求修复。假设NormSession中的每个NormNode都有一个预选的唯一32位标识符（NormNodeId）。NormNodes必须在单个NormSession中具有唯一分配的标识符，以区分多个可能的发送者，并区分来自不同接收者的反馈信息。有两个保留的NormNodeId值。0x00000000的值被视为无效的NormNodeId（NORM_NODE_NONE），0xFFFFFF的值是“通配符”NormNodeId（NORM_NODE_ANY）。
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.
虽然该协议不排除在单个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 provided by TCP for unicast data transport. The format of the stream content is application-defined and can 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_文件类型都表示大小有限但可能非常大的NORM对象。第三种类型的数据内容是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, a 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 of 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 needs to receive a sufficient number of symbols to reconstruct (via FEC decoding) the original user data for the given block.
所有对象在逻辑上被分割为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 NormTransportId. Depending upon the
使用给定发送方的NormNodeId、NormInstanceId和临时NormTransportId，在NormSession上下文中临时但唯一地标识传输的NORMObject。视乎
implementation, individual NORM senders can manage their NormInstanceIds independently, or a common NormInstanceId could be agreed upon for all participating nodes within a session, if needed, as a session identifier. NORM NormTransportId 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 a long-lived session, the NormTransportId field can wrap and previously used identifiers will be re-used. Note that globally unique identification of transported data content is not provided by NORM and, if necessary, is expected to be managed by the NORM application. The individual segments or symbols of the NormObject are further identified with FEC payload identifiers that include coding block and symbol identifiers. These are discussed in detail later in this document.
实现时，单个NORM发送方可以独立地管理其NormInstanceId，或者如果需要，可以为会话中的所有参与节点商定一个公共NormInstanceId作为会话标识符。NORM NormTransportId数据内容标识符是发送方指定的，仅在NormObject的实际传输期间（即，只要发送方正在传输和提供所指示NormObject的修复），才适用和有效。对于长期会话，NormTransportId字段可以包装，以前使用的标识符将被重新使用。请注意，NORM不提供传输数据内容的全局唯一标识，如有必要，应通过NORM应用程序进行管理。使用包括编码块和符号标识符的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 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 configuration is sensible for certain network conditions and can allow for robust, asymmetric multicast (e.g., unidirectional routing, satellite, cable) [FecHybrid] with reduced receiver feedback, or, in some cases, no feedback.
NORM发送方主要生成NORM_DATA类型的消息。这些消息携带原始数据段或FEC符号，以及正在传输的批量数据/文件或流对象的修复段/符号。默认情况下，冗余FEC符号仅在响应接收器修复请求（NACK）时发送，因此，由于FEC编码，通常很少或没有额外的传输开销。然而，NORM实现可以被配置为主动地发送一些数量的冗余FEC符号以及原始内容，以潜在地提高性能（例如，改进的延迟），代价是额外的传输开销。这种配置对于某些网络条件是合理的，并且可以允许健壮的非对称多播（例如，单向路由、卫星、电缆）[FecHybrid]，减少接收机反馈，或者在某些情况下，不提供反馈。
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. The NORM_INFO message can 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
发送方还生成NORM_CMD类型的消息，以帮助
certain protocol operations such as congestion control, end-of-transmission flushing, group round-trip time (GRTT) 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: single, best-effort unreliable transmission of the command; repeated redundant transmissions of the command; and 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.). A notable distinction between NORM_DATA message and some NORM_CMD message transmissions is that typically a receiver will need to allocate resources to manage reliable reception when NORM_DATA messages are received. However, some NORM_CMD messages are completely atomic and no specific reliability (buffering) state needs to be kept. Thus, for session management or other purposes, it is possible that even participants acting principally as data receivers MAY transmit NORM_CMD messages. However, it is RECOMMENDED that this is not done within the context of the NORM multicast session unless congestion control is addressed. For example, many receiver nodes transmitting NORM_CMD messages simultaneously can cause congestion for the destination(s).
某些协议操作，如拥塞控制、传输结束刷新、组往返时间（GRTT）估计、接收器同步和可选的肯定确认请求或应用程序定义的命令。来自发送方的NORM_CMD消息的传输由三个不同的过程之一完成：命令的单次、最大努力、不可靠传输；命令的重复冗余传输；并积极承认命令。用于给定命令的传输技术取决于命令的功能。为基本协议操作定义了几个核心命令。此外，实现可能希望考虑提供可选的应用程序定义的命令，这些命令可以利用可用于命令的传输方法。这允许应用程序级会话管理机制，可以利用底层NORM协议引擎可用的信息（例如，往返时间、传输速率等）。NORM_数据消息和一些NORM_CMD消息传输之间的一个显著区别是，当接收到NORM_数据消息时，接收器通常需要分配资源来管理可靠的接收。然而，一些NORM_CMD消息是完全原子的，不需要保持特定的可靠性（缓冲）状态。因此，出于会话管理或其他目的，即使主要充当数据接收器的参与者也可能发送NORM_CMD消息。但是，建议不要在NORM多播会话的上下文中执行此操作，除非解决了拥塞控制问题。例如，许多同时传输NORM_CMD消息的接收器节点可能会导致目的地拥塞。
All sender 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 is 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的拥塞控制算法启用时，发送方的速率将自动调整。在一些网络中，即使启用了动态拥塞控制，也希望根据应用程序为速率调整建立最小和最大界限。但是，对于通用互联网，应遵守与共存TCP流兼容的拥塞控制策略。
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
NORM接收器生成NORM_NACK或NORM_ACK类型的消息，以响应来自发送方的数据和命令传输。生成NORM_NACK消息以请求修复检测到的数据传输丢失。接收机通常通过跟踪发送方的传输序列来检测丢失。序列信息嵌入在发送的数据包和来自发送方的发送结束命令中。NORM_ACK消息是响应发送方发送的某些命令而生成的。在通用（且最具可扩展性）协议模式下，发送NORM_ACK消息
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 are available for use.
仅响应发送方发出的拥塞控制命令。使用与NORM_NACK消息相同的基于定时器的概率抑制技术来控制这些拥塞控制NORM_ACK消息的反馈量，以避免反馈内爆。为了满足来自接收器的肯定确认的潜在应用要求，定义了其他规范确认消息并可供使用。
The operation of the NORM protocol is based primarily upon the concepts presented in the Multicast NACK Building Block [RFC5401] document. This includes the basic NORM architecture and the data transmission, repair, and feedback strategies discussed in that document. The reliable multicast building block approach, as described in "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer" [RFC3048], is applied in creating the full NORM protocol instantiation. NORM also makes use of the parity-based encoding techniques for repair messaging and added transmission robustness as described in "The Use of Forward Error Correction (FEC) in Reliable Multicast" [RFC3453]. NORM uses the FEC Payload ID as specified by the FEC Building Block document [RFC5052]. Additionally, for congestion control, this document fully specifies a baseline congestion control mechanism (NORM-CC) based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme [TfmccPaper], [RFC4654].
NORM协议的操作主要基于多播NACK构建块[RFC5401]文档中提出的概念。这包括该文档中讨论的基本规范体系结构和数据传输、修复和反馈策略。如“一对多批量数据传输的可靠多播传输构建块”[RFC3048]中所述，可靠多播构建块方法用于创建完整规范协议实例化。NORM还使用基于奇偶校验的编码技术来修复消息传递，并增加了传输健壮性，如“可靠多播中前向纠错（FEC）的使用”[RFC3453]所述。NORM使用FEC构建块文档[RFC5052]指定的FEC有效负载ID。此外，对于拥塞控制，本文档完全指定了基于TCP友好多播拥塞控制（TFMCC）方案[TfmccPaper]，[RFC4654]的基线拥塞控制机制（NORM-CC）。
While the various features of NORM 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 trade-offs involved in reliable multicast transport design and this necessitates 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
NORM提供可靠数据传输的能力也受发送方和接收方的任何缓冲区约束的制约
applications. NORM protocol implementations SHOULD 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 trade-offs 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可以在减少缓冲的情况下运行，但其代价是效率降低（相对吞吐量降低）和组大小可伸缩性降低。
This RMT Protocol Instantiation document, in conjunction with the "Multicast Negative-Acknowledgment (NACK) Building Blocks" [RFC5401] and "Forward Error Correction (FEC) Building Block" [RFC5052] Building Blocks, completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357.
本RMT协议实例化文件与“多播否定确认（NACK）构建块”[RFC5401]和“前向纠错（FEC）构建块”[RFC5052]构建块一起，完全指定了一个工作可靠的多播传输协议，该协议符合RFC 2357中描述的要求。
This document specifies the following message types and mechanisms that 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. |
+----------------------+--------------------------------------------+
| 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 is 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_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 is 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. |
+----------------------+--------------------------------------------+
This document also describes the following message types and associated mechanisms that 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. |
+-----------------------+-------------------------------------------+
| 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. |
+-----------------------+-------------------------------------------+
| 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. |
+-----------------------+-------------------------------------------+
There are two primary classes of NORM messages (see Section 2.1): 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. Sender messages SHALL be governed by congestion control for Internet use. For session management or other purposes, receivers can also employ NORM_CMD message transmissions. The principal rationale for distinguishing sender and receiver messages is that receivers will typically need to allocate resources to support reliable reception from sender(s) and NORM sender messages are subject to congestion control. NORM receivers MAY employ the NORM_CMD message type for application-defined purposes, but it is RECOMMENDED that congestion control and feedback implosion issues be addressed. Additionally, an auxiliary message type of 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 compatible with the Maximum Transmission Unit (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消息有两大类（见第2.1节）：发送方消息和接收方消息。NORM_CMD、NORM_INFO和NORM_数据消息类型由数据内容的发送方生成，NORM_NACK和NORM_ACK消息由NORM会话中的接收方生成。发送方消息应受到互联网使用拥塞控制的管辖。出于会话管理或其他目的，接收器还可以使用NORM_CMD消息传输。区分发送方和接收方消息的主要理由是，接收方通常需要分配资源以支持来自发送方的可靠接收，并且发送方消息受到拥塞控制。NORM接收者可能出于应用程序定义的目的使用NORM_CMD消息类型，但建议解决拥塞控制和反馈内爆问题。此外，还为实验目的提供了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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NORM Common Message Header Format
图1:NORM通用消息头格式
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 that are 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 |
+------------------+------------------+
+------------------+------------------+
| Message | Value |
+------------------+------------------+
| NORM_INFO | 1 |
| NORM_DATA | 2 |
| NORM_CMD | 3 |
| NORM_NACK | 4 |
| NORM_ACK | 5 |
| NORM_REPORT | 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 the addition of header extensions. The presence of header extensions is 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. The "sequence" field serves two separate purposes, depending upon the message type:
“序列”字段是由消息发起人设置的16位值。“序列”字段有两个不同的用途，具体取决于消息类型：
1. NORM senders MUST set the "sequence" field of sender messages (NORM_INFO, NORM_DATA, and NORM_CMD) so that receivers can monitor the "sequence" value to maintain an estimate of packet loss that can be used for congestion control purposes (see Section 5.5.2 for a detailed description of NORM Congestion Control operation). A monotonically increasing sequence number space MUST be maintained to mark NORM sender messages in this way. Note that this "sequence" number is explicitly NOT used in
1. NORM发送方必须设置发送方消息（NORM_信息、NORM_数据和NORM_CMD）的“序列”字段，以便接收方可以监控“序列”值，以保持可用于拥塞控制目的的数据包丢失估计值（有关NORM拥塞控制操作的详细说明，请参见第5.5.2节）。必须保持单调递增的序列号空间，以便以这种方式标记标准发送方消息。请注意，此“序列”号在中未明确使用
NORM as part of its reliability procedures. The NORM object and FEC payload identifiers are used to detect missing content for reliable transfer purposes.
规范作为其可靠性程序的一部分。NORM对象和FEC有效负载标识符用于检测丢失的内容，以实现可靠传输。
2. NORM receivers SHOULD set the "sequence" field to support protection from message replay attacks of NORM_NACK or NORM_NACK messages. Note that, depending upon configuration, NORM feedback messages are sent to the session multicast address or the unicast address(es) of the active NORM sender(s). Thus, a separate, monotonically increasing sequence number space MUST be maintained for each destination address to which the NORM receiver is transmitting feedback messages.
2. NORM接收方应设置“序列”字段，以支持对NORM_NACK或NORM_NACK消息的消息重播攻击的保护。注意，根据配置，NORM反馈消息被发送到活动NORM发送方的会话多播地址或单播地址。因此，对于范数接收器向其发送反馈消息的每个目的地地址，必须保持单独的、单调递增的序列号空间。
Note that these two separate purposes necessitate the maintenance of separate sequence spaces to support the functions described here. And, in the case of NORM receivers, additional sequence spaces are needed when feedback messages are sent to the sender unicast address(es) instead of the session address.
注意，这两个单独的目的需要维护单独的序列空间，以支持此处描述的功能。并且，在NORM接收机的情况下，当反馈消息被发送到发送方单播地址（es）而不是会话地址时，需要额外的序列空间。
The "source_id" field is a 32-bit value that uniquely identifies the node that sent the message within the context of a single NormSession. This value is termed the NORM node identifier (NormNodeId) and unique NormNodeIds MUST be assigned within a single NormSession. In some cases, use of the host IPv4 address or a hash of an address can suffice, but alternative methodologies for assignment and potential collision resolution of node identifiers within a multicast session SHOULD be considered. For example, the techniques for managing the 32-bit "synchronization source" (SSRC) identifiers defined in the Real-Time Protocol (RTP) specification [RFC3550] are applicable for use with NORM node identifiers when an ASM traffic model is observed. In most deployments of the NORM protocol to date, the NormNodeId assignments are administratively configured, and this form of NormNodeId assignment is RECOMMENDED for most purposes. NORM sender NormNodeId values MUST be unique within an ASM session so that NORM receiver feedback can be properly demultiplexed by senders, and NORM receiver NormNodeId values MUST also be unique for congestion control operation or when the OPTIONAL positive acknowledgment mechanism is used.
“source_id”字段是一个32位的值，用于唯一标识在单个会话上下文中发送消息的节点。该值称为NORM节点标识符（NormNodeId），必须在单个NormSession内分配唯一的NormNodeId。在某些情况下，使用主机IPv4地址或地址哈希就足够了，但应考虑在多播会话中分配和解决节点标识符潜在冲突的替代方法。例如，用于管理实时协议（RTP）规范[RFC3550]中定义的32位“同步源”（SSRC）标识符的技术适用于在观察ASM业务模型时与标准节点标识符一起使用。迄今为止，在大多数NORM协议部署中，NormNodeId分配是通过管理方式配置的，在大多数情况下建议使用这种形式的NormNodeId分配。ASM会话中的NORM发送方NormNodeId值必须是唯一的，以便发送方可以正确地将NORM接收方反馈解复用，并且NORM接收方NormNodeId值对于拥塞控制操作或使用可选的肯定确认机制时也必须是唯一的。
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.
应用头扩展时，它们位于消息类型的基本头之后，并位于任何有效负载部分之前。标头扩展有两种格式，均以8位“het”（标头扩展类型）字段开头。为“het”值在0到127范围内的可变长度扩展提供了一种格式。另一种格式用于固定长度（一个32位字）扩展名，其“het”值在128到255之间。
For variable-length extensions, the value of the "hel" (header extension length) field is the length of the entire header extension, expressed in multiples of 32-bit words. The "hel" field MUST be present for variable-length extensions ("het" between 0 and 127) and MUST NOT be present for fixed-length extensions ("het" between 128 and 255).
对于可变长度扩展，“hel”（标头扩展长度）字段的值是整个标头扩展的长度，以32位字的倍数表示。对于可变长度扩展（“het”介于0和127之间），必须存在“hel”字段；对于固定长度扩展（“het”介于128和255之间），必须不存在“het”字段。
The formats of the variable-length and fixed-length header extensions
are given, respectively, here:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The formats of the variable-length and fixed-length header extensions
are given, respectively, here:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NORM Variable-Length Header Extension Format
图2: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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het >=128 | reserved | 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 >=128 | reserved | Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NORM Fixed-Length (32-bit) Header Extension Format
图3：标准固定长度（32位）标头扩展格式
The "Header Extension Content" portion of the header extension is defined for each extension type. Some header extensions are defined within this document for NORM baseline FEC and congestion control operations.
标题扩展的“标题扩展内容”部分是为每种扩展类型定义的。本文档中定义了一些用于标准基线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 generally 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 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
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.
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_len* | payload_msg_start* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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_len* | payload_msg_start* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NORM_DATA Message Format
图4:NORM_数据消息格式
*IMPORTANT NOTE: The "payload_len", "payload_msg_start" and "payload_offset" fields are present only for objects of type NORM_OBJECT_STREAM. These fields, as with the entire payload, are subject to any FEC encoding used. Thus, when systematic FEC codes are used, these values can be directly interpreted only for packets containing source symbols while packets containing FEC parity content need decoding before these fields can be interpreted.
*重要提示：“有效负载长度”、“有效负载消息开始”和“有效负载偏移量”字段仅适用于NORM\u OBJECT\u STREAM类型的对象。与整个有效负载一样，这些字段受所使用的任何FEC编码的约束。因此，当使用系统FEC码时，这些值只能直接解释为包含源符号的分组，而包含FEC奇偶校验内容的分组需要解码才能解释这些字段。
The "version", "type", "hdr_len", "sequence", and "source_id" fields
“版本”、“类型”、“hdr\u len”、“序列”和“源id”字段
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 (i.e., four 32-bit words) plus the size of the "fec_payload_id" field. The "fec_payload_id" field size depends upon the FEC encoding type referenced by the "fec_id" field. 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.
形成第4.1节所述的标准通用消息头。NORM_数据“type”字段的值为2。NORM_数据库“hdr_len”值为4（即四个32位字）加上“fec_有效负载_id”字段的大小。“fec_有效负载_id”字段大小取决于“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, or at least treat this "instance" as a new, separate sender.
“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_sender) (this is also referred to as R_max in [TfmccPaper]). This value is used to control timing of the NACK repair process and other aspects of protocol operation as described in this document. Normally, the advertised "grtt" value will correspond to what the sender has measured based on feedback from the group, but, at low transmission rates, the advertised "grtt" SHALL be set to MAX(grttMeasured, NormSegmentSize/senderRate) where the NormSegmentSize is the sender's segment size in bytes and the senderRate is the sender's current transmission rate in bytes per second. The algorithm for encoding and decoding this field is described in the Multicast NACK Building Block [RFC5401] document.
“grtt”字段包含发送方对组往返时间（grtt_发送方）的当前估计的非线性量化表示（在[TfMcPaper]中也称为R_max]）。该值用于控制NACK修复过程的定时以及本文档中描述的协议操作的其他方面。通常情况下，公布的“grtt”值将与发送方根据组的反馈测量的值相对应，但在低传输速率下，公布的“grtt”应设置为最大值（grtt测量值，NORMSECTIONSIZE/senderRate）其中NormSegmentSize是发送方的段大小（以字节为单位），senderRate是发送方的当前传输速率（以字节/秒为单位）。多播NACK构建块[RFC5401]文档中描述了对该字段进行编码和解码的算法。
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 that are multiplied by GRTT_sender to determine the maximum backoff timeout. The "backoff" field informs the receivers of the sender's backoff factor parameter (K_sender). Recommended values and their uses are described in the NORM receiver NACK procedure description in Section 5.3.
接收机使用“退避”字段值来确定基于定时器的范数NACK反馈抑制中使用的最大退避定时器值。此4位字段支持0-15之间的值，这些值乘以GRTT_sender以确定最大退避超时。“退避”字段通知接收方发送方的退避系数参数（K_发送方）。推荐值及其用途见第5.3节中的标准接收器NACK程序说明。
The "gsize" field contains a representation of the sender's current estimate of group size (GSIZE_sender). 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
“gsize”字段包含发送方当前估计的组大小（gsize\u发送方）的表示。这个4位字段可以大致表示1000万到5亿之间的值，其中最高有效位值0或1分别表示尾数1或5，最低有效位加1表示尾数
base-10 exponent (order of magnitude). For example, 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 (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" = 0x3) is RECOMMENDED for general purpose reliable multicast applications using the NORM protocol.
以10为基数的指数（数量级）。例如，字段值“0x0”表示1.0e+01（10），“0x8”表示5.0e+01（50），“0x1”表示1.0e+02（100），“0xf”表示5.0e+08。出于范数反馈抑制目的，不需要以高精度表示组大小。甚至可以稍微保守地估计组大小（即高估），以保持低水平的反馈流量。对于使用NORM协议的通用可靠多播应用程序，建议使用默认组大小估计值10000（“gsize”=0x3）。
The "flags" field contains a number of different binary flags providing information and hints for the receiver to appropriately handle the identified object. Defined flags in this field include:
“标志”字段包含许多不同的二进制标志，为接收者提供信息和提示，以正确处理识别的对象。此字段中定义的标志包括：
+----------------------+-------+------------------------------------+
| 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 a 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. |
+----------------------+-------+------------------------------------+
+----------------------+-------+------------------------------------+
| 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 a 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_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 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" (not previously transmitted) parity segments as
当相关信息为修复传输时，将设置NORM_FLAG_REPAIR。接收方可使用此信息来帮助遵守加入策略，其中希望新加入的接收方仅在接收到新（非修复）数据内容后才开始参与NACK过程。NORM_FLAG_EXPLICIT用于在数据发送方已用尽其提供“新鲜”（以前未传输）奇偶校验段的能力时，将发送的修复消息标记为
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. There are cases where receivers can 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 SHALL invoke the NORM_CMD(SQUELCH) process as described in Section 4.2.3.
修理该标志可能由实现功能的中间系统使用，以控制将修复内容分播到具有不同修复需求的可靠多播拓扑的不同分支。仅当可选的NORM_信息内容实际可用于关联对象时，才会设置NORM_FLAG_INFO。因此，只有当范数信息可用于给定对象时，接收机才会NACK用于范数信息的重传。当发送方希望仅以“尽力而为”的方式传输对象，并且不为对象提供修复传输时，将设置NORM_FLAG_UNRELIABLE。NORM接收者不应执行带有NORM_标志\u不可靠标志的对象的修复请求。在某些情况下，当未接收到这些对象的所有段（或信息内容）时，接收器可能会无意中请求修复这些对象（即，注意到“对象传输id”序列中的间隙）。在这种情况下，发送方应调用第4.2.3节所述的NORM_CMD（静噪）过程。
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. The presence of NORM_FLAG_STREAM overrides that of NORM_FLAG_FILE with respect to interpretation of object size and the format of NORM_DATA messages.
可以将NORM_FLAG_文件设置为发送方发出的提示，即关联对象应存储在非易失性存储器中。当标识的对象类型为NORM\u object\u STREAM时，将设置NORM\u FLAG\u STREAM。NORM_FLAG_STREAM的存在会覆盖NORM_FLAG_文件对对象大小和NORM_数据消息格式的解释。
The "fec_id" field corresponds to the FEC Encoding Identifier described in the FEC Building Block document [RFC5052]. 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 systematic FEC codes are RECOMMENDED for the most efficient performance of NORM_OBJECT_STREAM transport.
“fec_id”字段对应于fec构建块文档[RFC5052]中描述的fec编码标识符。“fec_id”值意味着“fec_有效负载_id”字段的格式，以及与fec对象传输信息相结合的解码fec编码内容的过程。小块系统代码（“fec_id”=129）预计将用于大多数NORM目的，系统fec代码建议用于NORM_对象流传输的最有效性能。
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 will wrap and be repeated, but it is presumed that the 16-bit field size provides a sufficient 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 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.
“object_transport_id”字段是发送方分配给正在传输的对象的单调递增的值。与该对象相关的传输和修复请求使用相同的“对象传输id”值。对于持续时间非常长或不确定的会话，“object_transport_id”字段将换行并重复，但假定16位字段大小提供了足够的序列空间，以避免接收器和源之间的对象混淆（即，当接收到的对象序列标识符与给定源的当前状态完全超出范围时，接收方应与服务器重新同步）。在NORM会话中传输对象的过程中，通过发送方“源\u id”和给定“对象\u传输\u id”的串联来唯一标识对象。请注意，与已识别对象关联的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 descriptions of specific FEC schemes such as those
described in the FEC Basic Schemes [RFC5445] specification or in
other FEC Schemes. As an example, the format of the "fec_payload_id"
format for Small Block, Systematic codes ("fec_id" = 129) from the
FEC Basic Schemes [RFC5445] specification is given here:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 descriptions of specific FEC schemes such as those
described in the FEC Basic Schemes [RFC5445] specification or in
other FEC Schemes. As an example, the format of the "fec_payload_id"
format for Small Block, Systematic codes ("fec_id" = 129) from the
FEC Basic Schemes [RFC5445] specification is given here:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example: FEC Payload Id Format for 'fec_id' = 129
Figure 5: Example: FEC Payload Id Format for 'fec_id' = 129
In this example, FEC payload identifier, the "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 for Small Block Systematic FEC Schemes identified by a "fec_id" value of 129 as specified by the FEC Basic Schemes [RFC5445] specification. 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" will 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. Applications MAY dynamically "shorten" code blocks when the pending information content is not predictable (e.g., real-time message streams). In that case, the "source_block_len" value given for an "encoding_symbol_id" that contains FEC parity content SHALL take precedence over the "source_block_len" value provided for any packets containing source symbols. Also, the "source_block_len" value given for an ordinally higher "encoding_symbol_id" SHALL take precedence over the "source_block_len" given for prior encoding symbols. The reason for this is that the sender will only know the maximum source block length at the time it is transmitting source symbols, but then subsequently "shorten" the code and then provide that last source symbol and/or encoding symbols with FEC parity content. 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)
在该示例中，FEC有效负载标识符、“源块号”、“源块号”和“编码符号号”字段对应于由“FEC\u id”标识的小块系统FEC方案的FEC有效负载id格式的“源块号”、“源块长度”和“编码符号id”字段FEC基本方案[RFC5445]规范规定的129值。“源块编号”标识编码块与对象的相对位置。请注意，对于NORM\u OBJECT\u STREAM类型的normObject，“source\u block\u number”将在非常长的会话中换行。“源块”表示所识别编码块中的用户数据段的数量。给定块中包含多少应用数据符号的“源块”信息，接收机可以确定所附段是数据还是奇偶校验内容，并对其进行适当处理。当挂起的信息内容不可预测时（例如，实时消息流），应用程序可以动态地“缩短”代码块。在这种情况下，为包含FEC奇偶校验内容的“编码符号”id给定的“源块”值应优先于为包含源符号的任何数据包提供的“源块”值。此外，为顺序较高的“编码符号”id给出的“源块长度”值应优先于为先前编码符号给出的“源块长度”。原因是发送方在发送源符号时只知道最大源块长度，但随后“缩短”代码，然后提供最后一个源符号和/或具有FEC奇偶校验内容的编码符号。“encoding_symbol_id”标识所附有效负载传送的编码块内的特定符号（段）。根据块的“编码\u符号\u id”和相关“源\u块\u长度”参数的值，符号（段）
referenced will be a user data or a 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 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.
引用的将是用户数据或FEC奇偶校验段。对于系统代码，编号小于源块长度的编码符号包含原始应用程序数据，而大于或等于源块长度的段包含为该块计算的奇偶校验符号。对象_transport _id:：fec _payload _id的串联可以被视为连接段相对于会话中NORM发送方实例的唯一传输协议数据单元标识符。
Additional FEC Object Transmission Information (FTI) (as described in the FEC Building Block [RFC5052]) document is needed to properly receive and decode NORM transport objects. This information MAY be provided as out-of-band session information. In some cases, it will be useful for the sender to include this information "in-band" to facilitate receiver operation with minimal pre-configuration. 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 format of the EXT_FTI consists of two parts, a general part that contains the size of the associated transport object and a portion that depends upon the FEC scheme being used. The "fec_id" field in NORM_DATA and NORM_INFO messages identifies the FEC scheme. The format of the EXT_FTI general part is given here.
需要额外的FEC对象传输信息（FTI）（如FEC构建块[RFC5052]中所述）文档来正确接收和解码标准传输对象。该信息可以作为带外会话信息提供。在某些情况下，发送方将此信息包括在“带内”将是有用的，以便于接收机操作，且预配置最少。为此，定义了范数FEC对象传输信息报头扩展（EXT_FTI）。此标头扩展可应用于NORM_数据和NORM_信息消息，以提供此必要信息。EXT_FTI的格式由两部分组成，一部分是包含相关传输对象大小的通用部分，另一部分取决于所使用的FEC方案。NORM_数据和NORM_信息消息中的“fec_id”字段标识fec方案。这里给出了EXT_FTI通用部分的格式。
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_size (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC scheme-specific 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 = 64 | hel = 4 | object_size (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC scheme-specific content ... |
Figure 6: EXT_FTI Header Extension General Portion Format
图6:EXT_FTI标题扩展通用部分格式
The header extension type "het" field value for the EXT_FTI header extension is 64. The header extension length "hel" value depends upon the format of the FTI for encoding type identified by the "fec_id" field.
EXT_FTI标头扩展的标头扩展类型“het”字段值为64。标题扩展长度“hel”值取决于“fec_id”字段标识的编码类型的FTI格式。
The 48-bit "object_size" field indicates the total length 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 might 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_size" field is used by the sender to advertise the size of its stream
48位“object_size”字段表示NORM_object_文件和NORM_object_数据的静态对象类型的对象总长度（字节）。接收器使用该信息确定存储需求和/或为接收对象分配存储。存储能力不足的接收器可能希望放弃对指示对象的可靠接收（即，非NACK）。对于NORM_OBJECT_STREAM类型的对象，发送方使用“OBJECT_size”字段公布其流的大小
buffer to the receiver group. In turn, the receivers SHOULD use this information to allocate a stream buffer for reception of corresponding size.
缓冲区到接收器组。反过来，接收器应使用该信息来分配用于相应大小的接收的流缓冲器。
As noted, the format of the extension depends upon the FEC code in
use, but in general, it contains any necessary details on the code in
use (e.g., FEC Instance ID, etc.). As an example, the format of the
EXT_FTI for small block systematic codes ("fec_id" = 129) is given
here:
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_size (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As noted, the format of the extension depends upon the FEC code in
use, but in general, it contains any necessary details on the code in
use (e.g., FEC Instance ID, etc.). As an example, the format of the
EXT_FTI for small block systematic codes ("fec_id" = 129) is given
here:
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_size (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example: EXT_FTI Header Extension Format for 'fec_id' = 129
Figure 7: Example: EXT_FTI Header Extension Format for 'fec_id' = 129
In this example (for "fec_id" = 129), the "hel" field value is 4. The size of the EXT_FTI header extension will possibly be different for other FEC schemes.
在本例中（对于“fec_id”=129），“hel”字段值为4。对于其他FEC方案，EXT_FTI报头扩展的大小可能不同。
The 48-bit "object_size" serves the purpose described previously.
48位“对象大小”用于上述目的。
The "fec_instance_id" corresponds to the "FEC Instance ID" described in the FEC Building Block [RFC5052] document. In this case, the "fec_instance_id" is 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 RFC 5052.
“fec_实例_id”对应于fec构建块[RFC5052]文档中描述的“fec实例id”。在这种情况下，“fec_实例_id”是与正在使用的特定类型的小块系统代码（例如，里德所罗门GF（2^8）、里德所罗门GF（2^16）等）相对应的值。RFC 5052中描述了FEC实例ID值的标准化分配。
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. Typically, FEC parity symbol segments will be of this size.
“segment_size”字段表示发送方的最大消息有效负载内容的当前设置（以字节为单位）。这允许接收器分配适当的缓冲资源并确定其他信息，以便正确处理接收到的数据消息。通常，FEC奇偶校验符号段将具有此大小。
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
“fec_num_奇偶校验”对应于“最大编码数”
symbols that can be generated for any source block" as described in FEC Object Transmission Information for Small Block Systematic Codes as described in the FEC Building Block [RFC5052] document. For example, Reed-Solomon codes can 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构建块[RFC5052]文档中所述的小块系统代码的FEC对象传输信息中所述，可为任何源块生成的符号。例如，可以任意缩短里德-所罗门代码，以针对给定的块长度创建不同的代码变体。在里德-所罗门代码的情况下（GF（2^8）和GF（2^16））代码，此值表示发送方可用于编码块的奇偶校验段的最大数量。对于定义的其他系统代码，此字段的解释可能不同。
The payload portion of NORM_DATA messages includes source data or FEC-encoded application content. The content of this payload depends upon the FEC scheme being employed, and support for streaming using the NORM_OBJECT_STREAM type, when applicable, necessitates some additional content in the payload.
NORM_数据消息的有效负载部分包括源数据或FEC编码的应用程序内容。该有效载荷的内容取决于所采用的FEC方案，并且在适用时，支持使用NORM_OBJECT_流类型的流传输需要有效载荷中的一些附加内容。
The "payload_len", "payload_msg_start", and "payload_offset" fields are present only for transport objects of type NORM_OBJECT_STREAM. These REQUIRED 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 REQUIRED block partitioning algorithm described in the FEC Building Block [RFC5052] document. When systematic FEC codes (e.g., "fec_id" = 129) are used, the "payload_len", "payload_msg_start", and "payload_offset" fields contain actual payload_data length, message start index (or stream control code), and byte offset values for the associated application stream data segment (the remainder of the "payload_data" field content) for those NORM_DATA messages containing source data symbols. In NORM_DATA messages that contain FEC parity content, these fields do not contain values that can be directly interpreted, but instead are values computed from FEC encoding the "payload_len", "payload_msg_start", and "payload_offset" fields for the source data segments of the corresponding coding block. The actual "payload_msg_start", "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 contribute to the value of the NORM_DATA "hdr_len" field. These fields are present only when the "flags" portion of the NORM_DATA message indicate the transport object is of type NORM_OBJECT_STREAM.
“有效负载长度”、“有效负载消息开始”和“有效负载偏移”字段仅适用于NORM\u OBJECT\u STREAM类型的传输对象。这些必填字段允许发送方任意改变流的NORM_数据有效负载段的大小。这允许应用程序根据需要刷新传输的流，以满足独特的流传输要求。对于NORM_OBJECT_FILE和NORM_OBJECT_DATA类型的对象，这些字段是不必要的，因为接收器可以使用fec构建块[RFC5052]文档中描述的所需块划分算法，从“fec_有效负载_id”计算有效负载长度和偏移信息。当使用系统FEC代码（例如，“FEC_id”=129）时，“有效负载_len”、“有效负载_msg_start”和“有效负载_offset”字段包含相关应用程序流数据段（剩余的“有效负载_data”字段内容）的实际有效负载_数据长度、消息开始索引（或流控制代码）和字节偏移值对于那些包含源数据符号的NORM_数据消息。在包含FEC奇偶校验内容的NORM_数据消息中，这些字段不包含可直接解释的值，而是根据FEC编码对应编码块的源数据段的“payload_len”、“payload_msg_start”和“payload_offset”字段计算出的值。在解码FEC编码块时，可以确定丢失数据内容的实际“有效载荷msg开始”、“有效载荷len”和“有效载荷偏移”值。请注意，这些字段不构成NORM_DATA“hdr_len”字段的值。只有当NORM_数据消息的“flags”部分指示传输对象为NORM_object_STREAM类型时，这些字段才会出现。
The "payload_len" value, when non-zero, indicates the length (in bytes) of the source content contained in the associated "payload_data" field. However, when the "payload_len" value is equal to ZERO, this indicates that the "payload_msg_start" field be
“payload_len”值在非零时表示相关“payload_data”字段中包含的源内容的长度（字节）。但是，当“有效载荷长度”值等于零时，这表示“有效载荷消息开始”字段为空
alternatively interpreted as a "stream_control_code". The only "stream_control_code" value defined is NORM_STREAM_END = 0. The NORM_STREAM_END code indicates that the sender is terminating the transmission of stream content at the corresponding position in the stream and the receiver MUST NOT expect content (or request repair for any content) following that position in the stream. Additional specifications MAY extend the functionality of the NORM stream transport mode by defining additional stream control codes. These control codes are delivered to the recipient application reliably, in-order with respect to the streamed application data content.
或者解释为“流控制代码”。唯一定义的“流控制代码”值为NORM\u stream\u END=0。NORM_STREAM_END code表示发送方在流中的相应位置终止流内容的传输，接收方不得期望流中该位置之后出现内容（或请求修复任何内容）。附加规范可通过定义附加流控制码来扩展NORM流传输模式的功能。这些控制代码根据流式应用程序数据内容的顺序可靠地传递给接收方应用程序。
The "payload_msg_start" field serves one of two exclusive purposes. When the "payload_len" value is non-zero, the "payload_msg_start" field, when also set to a non-zero value, indicates that the associated "payload_data" content contains an application-defined message boundary (start-of-message). When such a message boundary is indicated, the first byte of an application-defined message, with respect to the "payload_data" field, will be found at an offset of "payload_msg_start - 1" bytes. Thus, if a NORM_DATA payload for a NORM_OBJECT_STREAM contains the start of an application message at the first byte of the "payload_data" field, the value of the "payload_msg_start" field will be '1'. NORM implementations SHOULD provide sender stream applications with a capability to mark message boundaries in this manner. Similarly, the NORM receiver implementation SHOULD enable the application to recover such message boundary information. This enables NORM receivers to "synchronize" reliable reception of transmitted message stream content in a meaningful way (i.e., meaningful to the application) at any time, whether joining a session already in progress, or departing the session and returning. Note that if the value of the "payload_msg_start" field is ZERO, no message boundary is present. The "payload_msg_start" value will always be less than or equal to the "payload_len" value except for the special case of "payload_len = 0", which indicates the "payload_msg_start" field be instead interpreted as a "stream_control_code"
“payload_msg_start”字段用于两个专用目的之一。当“payload_len”值为非零时，“payload_msg_start”字段也设置为非零值时，表示关联的“payload_data”内容包含应用程序定义的消息边界（消息开始）。当指示这样的消息边界时，应用程序定义的消息的第一个字节（关于“payload_data”字段）将位于“payload_msg_start-1”字节的偏移量处。因此，如果NORM_对象_流的NORM_数据有效载荷在“payload_DATA”字段的第一个字节处包含应用程序消息的开始，则“payload_msg_start”字段的值将为“1”。NORM实现应该为发送方流应用程序提供以这种方式标记消息边界的能力。类似地，NORM接收器实现应使应用程序能够恢复此类消息边界信息。这使得NORM接收机能够在任何时候以有意义的方式（即，对应用程序有意义的方式）对发送的消息流内容进行“同步”可靠接收，无论是加入已经在进行的会话，还是离开会话并返回。请注意，如果“payload_msg_start”字段的值为零，则不存在消息边界。“payload_msg_start”值将始终小于或等于“payload_len”值，但“payload_len=0”的特殊情况除外，这表示“payload_msg_start”字段将被解释为“流控制代码”
The "payload_offset" field indicates the relative byte position (from the sender stream transmission start) of the source content contained in the "payload_data" field. Note that for long-lived streams, the "payload_offset" field will wrap.
“payload_offset”字段表示“payload_data”字段中包含的源内容的相对字节位置（从发送方流传输开始）。请注意，对于长寿命的流，“payload_offset”字段将换行。
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
“有效负载数据”字段包含由“fec\U有效负载id”标识的符号的原始应用程序源或奇偶校验内容。该字段的长度应限制为对象FTI中给出的发送方NORMSECTIONSIZE字节的最大值。请注意，包含奇偶校验内容的消息的此字段长度始终为长度大小。当编码不同大小的数据段时，FEC编码器应假定为零值
padding for data segments with a 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 can possibly vary on a per-object basis. The NormSegmentSize SHOULD be configurable by the sender application prior to session participation as needed for network topology 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 block partitioning algorithm described in the FEC Building Block [RFC5052] document. For NORM_OBJECT_STREAM objects, the length and offset is obtained from the segment's corresponding embedded "payload_len" and "payload_offset" fields.
长度小于NORMSECTIONSIZE的数据段的填充。建议发送者的大小在给定发送者参与会话的期限内通常保持不变，但可能因每个对象而异。根据网络拓扑MTU的考虑，在会话参与之前，发送方应用程序应该可以配置该大小。对于IPv6，可能在会话启动时利用MTU发现来执行此配置。“有效载荷数据”内容可直接传送到源符号的应用程序（当使用系统FEC编码时）或在对FEC块进行解码时。对于NORM_OBJECT_FILE和NORM_OBJECT_STREAM对象，可以使用FEC构建块[RFC5052]文档中描述的块划分算法计算数据段长度和偏移量。对于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 could then use the NORM_INFO content to make a decision as to whether to participate in reliable reception of the associated object. Each NormObject can have an independent unit of NORM_INFO with which it is associated. NORM_DATA messages contain a flag to indicate the availability of NORM_INFO for a given NormObject. NORM receivers will 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 for the given sender. This atomic nature allows the NORM_INFO to be rapidly and efficiently repaired within the NORM reliable transmission process.
NORM_INFO消息用于传递传输对象的可选、应用程序定义的带外上下文信息。大容量文件传输使用的一个示例NORM_INFO是将关联文件、数据或流对象的MIME类型信息放入NORM_INFO负载中。然后，接收器可以使用NORM_信息内容来决定是否参与相关对象的可靠接收。每个NormObject都可以有一个独立的NORM_信息单元，与之关联。NORM_数据消息包含一个标志，用于指示给定NORM对象的NORM_信息的可用性。当规范接收者没有收到给定规范对象的规范信息时，规范接收者将NACK重新传输规范信息。NORM_信息内容的大小仅限于给定发件人的单个NORMSECTIONSIZE大小。这种原子性质允许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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: NORM_INFO Message Format
图8:NORM_信息消息格式
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 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 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.
“实例标识”、“grtt”、“退避”、“gsize”、“标志”、“fec标识”和“对象传输标识”字段携带的信息和用途与标准数据消息相同。当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, NORM implementations MAY 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 that 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
NORM_CMD消息由发送方传输，以执行许多不同的协议功能。这包括往返定时收集、拥塞控制功能、发送方/接收方修复“窗口”的同步以及发送方状态通知等功能。枚举一组核心的NORM_CMD消息。此外，还有一系列命令类型可供潜在用户使用
application-specific use. Some NORM_CMD types can have dynamic
content attached. Any attached content will be limited to the
maximum length of the sender NormSegmentSize to retain the atomic
nature of the 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
application-specific use. Some NORM_CMD types can have dynamic
content attached. Any attached content will be limited to the
maximum length of the sender NormSegmentSize to retain the atomic
nature of the 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: NORM_CMD Standard Fields
图9: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 "sub-type" field.
“版本”、“类型”、“hdr_len”、“序列”和“源id”字段构成第4.1节所述的标准公共消息头。对于不存在标头扩展名的NORM_CMD消息，“hdr_len”字段的值取决于“sub type”字段。
The "instance_id", "grtt", "backoff", and "gsize" fields provide the same information and serve the same purpose as NORM_DATA and NORM_INFO messages. The "sub-type" field indicates the type of command to follow. The remainder of the NORM_CMD message is dependent upon the command sub-type. NORM command sub-types include:
“instance_id”、“grtt”、“backoff”和“gsize”字段提供与NORM_数据和NORM_信息消息相同的信息和用途。“子类型”字段指示要遵循的命令类型。NORM_CMD消息的其余部分取决于命令子类型。NORM命令子类型包括：
+-----------------------+----------+--------------------------------+
| Command | Sub-type | 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 a subset of |
| | | receivers. |
| NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+-----------------------+----------+--------------------------------+
| Command | Sub-type | 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 a 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 that need to |
| | | temporarily preempt or |
| | | supplement data transmission |
| | | (OPTIONAL). |
+-----------------------+----------+--------------------------------+
| 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 that need to |
| | | temporarily preempt or |
| | | supplement 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 can indicate either a temporary or permanent end-of-data transmission, but that the sender is still willing to respond to repair requests. This command is repeated once per 2*GRTT_sender to excite the 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. A default value of NORM_ROBUST_FACTOR equal to 20 is RECOMMENDED. If a NORM_NACK message interrupts the flush process, the sender SHALL re-initiate the flush process after any resulting repair transmissions are completed.
当发送方到达其排队等待传输的所有数据内容和未决修复的末尾时，将发送NORM_CMD（FLUSH）命令。这可以表示数据传输的临时或永久结束，但发送方仍愿意响应修复请求。该命令每2*GRTT_发送方重复一次，以激励接收方设置任何未完成的维修请求，直到并包括NORM_CMD（FLUSH）消息中指示的传输点。重复次数等于NORM_ROBUST_因子，除非给出了预期明确肯定确认的接收器列表（“确认节点列表”）。在这种情况下，“确认节点列表”随着收到确认而更新，并且根据第5.5.3节中描述的机制重复NORM_CMD（刷新）。NORM_ROBUST_因子越大，所有适用的接收器将被激发接受确认或修复请求（nack）以及相应的nack被交付给发送方的概率就越大。建议将NORM_ROBUST_FACTOR的默认值设置为20。如果NORM_NACK消息中断刷新过程，则发送方应在任何修复传输完成后重新启动刷新过程。
Note that receivers also employ a timeout mechanism to self-initiate NACKing (if there are outstanding repair needs) when no messages of
请注意，当没有消息时，接收器还采用超时机制来自启动NACKing（如果有未完成的修复需求）
any type are received from a sender. This inactivity timeout is related to the NORM_CMD(FLUSH) and NORM_ROBUST_FACTOR and is specified in Section 5.3. Receivers SHALL self-initiate the NACK repair process when the inactivity timeout has expired for a specific sender and the receiver has pending repairs needed from that sender. With a sufficiently large NORM_ROBUST_FACTOR value, data content is delivered with a high assurance of reliability. The penalty of a large NORM_ROBUST_FACTOR value is the potential transmission of excess NORM_CMD(FLUSH) messages and a longer inactivity timeout for receivers to self-initiate a terminal NACK process.
从发送方接收任何类型。该非活动超时与NORM_CMD（FLUSH）和NORM_ROBUST_因子有关，并在第5.3节中规定。当特定发送方的非活动超时已过期，且接收方需要该发送方进行待修复时，接收方应自行启动NACK修复过程。有了足够大的范数(NORM)稳健(ROBUST)因子值,数据内容的可靠性就有了很高的保证。较大的NORM_ROBUST_FACTOR值的代价是可能传输过多的NORM_CMD（FLUSH）消息，并且对于自启动终端NACK进程的接收器来说，不活动超时更长。
For finite-sized 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 can occur at any time, including in the middle of a FEC coding block if systematic FEC codes are employed. In this case, the sender will not yet be able to provide FEC parity content for the concurrent coding block and will be limited to explicitly repairing the stream with source 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 ongoing series of intermittent, relatively small messages 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NORM_CMD(FLUSH) Message Format
图10:NORM_CMD（FLUSH）消息格式
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM common message header as described in Section 4.1. 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.
“版本”、“类型”、“hdr_len”、“序列”和“源id”字段构成第4.1节所述的标准公共消息头。除了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
对于使用系统FEC代码的NORM_对象_流对象，如果给定的“编码符号_id”小于“源块_len”，则接收器必须请求“仅显式”修复已识别的“源块_编号”。此条件表示发送方尚未完成对相应FEC块的编码，奇偶校验内容尚不可用。“仅明确”修复请求包括
NACK content for the applicable "source_block_number" that does not include any requests for parity-based repair. This allows NORM sender applications to "flush" an ongoing stream of transmission when needed, even if in the middle of a 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. Note that a sender has the option of arbitrarily shortening a given code block when such an application "flush" occurs. In this case, the receiver will request explicit repair, but the sender MAY provide FEC-based repair (parity segments) in response. These parity segments MUST contain the corrected "source_block_len" for the shortened block and that "source_block_len" associated with segments containing parity content SHALL override the previously advertised "source_block_len". Similarly, the "source_block_len" associated with the highest ordinal "encoding_symbol_id" SHALL take precedence over prior symbols when a difference (e.g., due to code shortening at the sender) occurs. Normal receiver NACK initiation and construction is discussed in detail in Section 5.3.
适用“源块号”的NACK内容，不包括任何基于奇偶校验的修复请求。这允许规范发送器应用程序在需要时“刷新”正在进行的传输流，即使在FEC块的中间。一旦发送方恢复流传输并通过挂起的编码块的末尾，来自接收方的后续nack应像往常一样请求基于奇偶校验的修复。注意，此处假设使用系统FEC代码。注意，当应用程序发生“刷新”时，发送方可以选择任意缩短给定的代码块。在这种情况下，接收方将请求显式修复，但发送方可以提供基于FEC的修复（奇偶校验段）作为响应。这些奇偶校验段必须包含缩短块的已更正“源块长度”，与包含奇偶校验内容的段相关联的“源块长度”应覆盖先前公布的“源块长度”。类似地，当出现差异（例如，由于发送方的代码缩短）时，与最高顺序的“编码符号”id关联的“源块”应优先于先前的符号。第5.3节详细讨论了正常接收器NACK的启动和构造。
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.
可选的“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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NORM_CMD(EOT) Message Format
图11: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 that 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_sender 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, 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: NORM_CMD(SQUELCH) Message Format
图12: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 that initiated the NORM_CMD(SQUELCH) transmission. The value of the "hdr_len" field when no extensions are present is 4 plus the size of the "fec_payload_id" field that is dependent upon the FEC scheme identified by the "fec_id" field.
除了普通消息头和标准NORM_CMD字段外，NORM_CMD（静噪）消息还包含用于标识发送方当前修复窗口的最早逻辑传输位置的字段和“无效对象列表”从发起NORM_CMD（SQUELCH）传输的违规NACK消息中逻辑上最早的无效修复请求的索引开始。当不存在扩展时，“hdr_len”字段的值为4加上“fec_payload_id”字段的大小，该字段取决于由“fec_id”字段标识的fec方案。
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 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 cannot include the entire set of invalid objects in the repair window. In this case, the sender SHALL ensure that the list begins with a NormTransportId that is greater than or equal to the lowest ordinal invalid NormTransportId from the NACK message(s) that prompted the NORM_CMD(SQUELCH) generation. The NormTransportId in the "invalid_object_list" MUST be ordinally greater than the "object_transport_id" marking the beginning of the sender's repair window. This ensures 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 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.
“无效\u对象\u列表”是一个16位NORMTransportID的列表，尽管它们在发送方当前修复窗口的范围内，但发送方不再可以对其进行修复。例如，即使过期对象仍在修复窗口内，发送方应用程序也可能将其出列。“无效\u对象\u列表”内容的总大小可以根据数据包的有效负载长度确定，并限制为发送方的最大大小。因此，对于非常大的修复窗口，单个NORM_CMD（SQUELCH）消息可能无法在修复窗口中包含整个无效对象集。在这种情况下，发送方应确保列表以NormTransportId开头，该NormTransportId大于或等于NACK消息中提示生成NORM_CMD（静噪）的最低顺序无效NormTransportId。“无效对象列表”中的NormTransportId必须依次大于标记发送方修复窗口开始的“对象传输id”。这确保了静噪过程的收敛，即使需要多个无效的NACK/静噪迭代。发送方当前窗口中对无效内容的这种明确描述允许发送方应用程序（尤其是离散对象传输）任意使其不再希望提供可靠传输的排队内容（例如，某些对象）的部分无效（即，出列）。
The NORM_CMD(CC) message contains fields to enable sender-to-group 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 RFC 4654 is fully specified in Section 5.5.2 of this document. The NORM_CMD(CC) message is usually transmitted as part of NORM-CC 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 network where resources are explicitly dedicated to the NORM session and therefore congestion control operation is disabled, the NORM_CMD(CC) message is then used solely for GRTT measurement and MAY be sent less frequently than with congestion control operation.
NORM_CMD（CC）消息包含允许发送方对GRTT测量进行分组并激励该组进行拥塞控制反馈的字段。基于RFC 4654的TCP友好多播拥塞控制（TFMCC）方案的基线NORM拥塞控制方案（NORM-CC）在本文件第5.5.2节中有详细说明。NORM_CMD（CC）消息通常作为NORM-CC操作的一部分传输。下面定义了一个NORM头扩展，它与NORM_CMD（CC）消息一起使用，以支持NORM-CC操作。可以为NORM_CMD（CC）（和/或其他需要的NORM消息）定义不同的报头扩展，以支持将来的替代拥塞控制方案。如果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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 4 | reserved | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: NORM_CMD(CC) Message Format
图13:NORM_CMD（CC）消息格式
The NORM common message header and standard NORM_CMD fields serve their usual purposes. The value of the "hdr_len" field when no header extensions are present is 6.
NORM common message header和标准NORM_CMD字段用于其通常用途。当不存在标头扩展名时，“hdr_len”字段的值为6。
The "reserved" field is for potential future use and MUST be set to ZERO in this version of the NORM protocol and its baseline NORM-CC congestion control scheme. It is possible for alternative congestion control schemes to use the NORM_CMD(CC) message defined here and leverage the "reserved" field for scheme-specific purposes.
“保留”字段用于将来可能的使用，在此版本的NORM协议及其基线NORM-CC拥塞控制方案中必须设置为零。其他拥塞控制方案可以使用此处定义的NORM_CMD（CC）消息，并利用“reserved”字段用于特定于方案的目的。
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 RFC 4654. 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操作，它用于提供与RFC 4654中描述的“反馈轮数”（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")
“发送时间”字段是一个时间戳，指示NORM_CMD（CC）消息的传输时间。这包括一个64位字段，其中包含32位，时间单位为秒（“发送时间秒”）
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 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.
和32位，时间单位为微秒（“发送时间”（send_time_usec）），因为源保持一些参考时间（通常是1970年1月1日00:00:00）。字段的字节顺序为“大端”网络顺序。接收者使用此时间戳作为生成的NORM_ACK和NORM_NACK消息的“grtt_response”部分，该时间戳根据从接收NORM_CMD（CC）消息到响应时间的延迟量进行调整。这允许发送方评估到不同接收方的往返时间，以用于拥塞控制和其他（例如，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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 integer exponent (E) information in the least significant portion. The 12-bit mantissa portion of the field is scaled such that a base 10 mantissa (M) floating point value of 0.0 corresponds to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of the 16-bit "send_rate" field. Thus:
“发送速率”字段表示发送方的当前传输速率（字节/秒）。16位“发送速率”字段由最高有效部分的12位尾数和最低有效部分的4位基数为10的整数指数（E）信息组成。该字段的12位尾数部分被缩放，使得0.0的基10尾数（M）浮点值对应于0，10.0的值对应于16位“发送速率”字段的上12位中的4096。因此：
send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E;
send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E;
For example, to represent a transmission rate of 256 kbit/s (3.2e+04
bytes per second), the lower 4 bits of the 16-bit field contain a
value of 0x04 to represent the exponent (E) while the upper 12 bits
contain a value of 0x51f (M) as determined from the equation given
above:
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4
= 0x51f4
For example, to represent a transmission rate of 256 kbit/s (3.2e+04
bytes per second), the lower 4 bits of the 16-bit field contain a
value of 0x04 to represent the exponent (E) while the upper 12 bits
contain a value of 0x51f (M) as determined from the equation given
above:
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4
= 0x51f4
To decode the "send_rate" field, the following equation can be used:
要解码“发送速率”字段，可使用以下等式：
value = (send_rate >> 4) * (10/4096) * power(10, (send_rate & x000f))
value = (send_rate >> 4) * (10/4096) * power(10, (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" might be attached as the payload of the NORM_CMD(CC) message. The presence of this header extension also implies that NORM receivers MUST respond according to the procedures described in Section 5.5.2.
当存在此扩展时，可能会附加一个“cc_node_list”作为NORM_CMD（cc）消息的有效负载。该报头扩展的存在还意味着标准接收机必须根据第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 can be increased for more timely feedback to the group. The list length can be inferred from the length of the NORM_CMD(CC) message.
“cc_节点_列表”由normNodeId及其相关拥塞控制状态的列表组成。这包括限流接收器（CLR）节点、已识别的任何潜在限流接收器（PLR）节点，以及为其提供拥塞控制状态的一些接收器，最显著的是包括接收器的当前RTT测量。“cc_节点_列表”的最大长度至少为CLR和一个其他接收器提供，但可以增加，以便更及时地向组反馈。列表长度可以从NORM_CMD（CC）消息的长度推断出来。
Each item in the "cc_node_list" is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each item in the "cc_node_list" is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "cc_node_id" is the NormNodeId of the receiver 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. |
+--------------------+-------+--------------------------------------+
| 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. |
+--------------------+-------+--------------------------------------+
| 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 Multicast NACK Building Block [RFC5401] document.
“cc_rtt”包含由发送方相对于所指示的接收机测量的rtt的量化表示。只有在“CC_标志”字段中设置了NORM_标志\u CC_RTT标志时，此字段才有效。该单字节字段是RTT的量化表示，使用多播NACK构建块[RFC5401]文档中描述的算法。
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_速率”字段包含接收机当前计算（在稳态拥塞控制操作期间）或其测量（在慢启动阶段）拥塞控制速率两倍的表示。使用与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 relaying 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 [NormFeedback].
发送方使用NORM_CMD（REPAIR_ADV）消息从修复周期和/或接收到的拥塞控制反馈期间累积的NORM_NACK消息“公布”其聚合修复状态。仅当发送方通过单播传输而不是多播接收到NORM_NACK和/或NORM_ACK（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 5 | flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_adv_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: NORM_CMD(REPAIR_ADV) Message Format
图14:NORM\u CMD（REPAIR\u ADV）消息格式
The "instance_id", "grtt", "backoff", "gsize", and "sub-type" 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”和“sub type”字段的用途与其他NORM_CMD消息中的相同。当不存在扩展名时，“hdr_len”字段的值为4。
The "flags" field provides 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 SHALL limit their NACK response to generating NACK content only up through the maximum ordinal transmission position (objectTransportId::fecPayloadId) included in the "repair_adv_content".
当发送方无法将其完整的当前修复状态适应单个大小时，该标志由发送方设置。如果设置了此标志，则接收器应限制其NACK响应仅在“修复adv_内容”中包含的最大顺序传输位置（objectTransportId:：fecPayloadId）生成NACK内容。
When congestion control operation is enabled, a header extension SHOULD 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 can be used for 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) [PgmccPaper]) is used
启用拥塞控制操作时，应将标头扩展应用于表示最大限制（就拥塞控制反馈抑制而言）拥塞控制响应的NORM_CMD（REPAIR_ADV）。这允许NORM_CMD（REPAIR_ADV）消息抑制接收器拥塞控制响应以及NACK反馈消息。该字段被定义为标题扩展，以便在不修改本文档的情况下，替代拥塞控制方案可用于NORM。定义了一个NORM-CC反馈头扩展（EXT_-CC），用于将拥塞控制反馈封装在NORM_NACK、NORM_ACK和NORM_CMD（REPAIR_ADV）消息中。如果使用另一种拥塞控制技术（例如，实用通用多播拥塞控制（PGMCC）[PgmccPaper]）
within a 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:
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 = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
within a 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:
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 = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 SHOULD 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 SHALL 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 SHALL be set only when no feedback has been received from non-CLR or non-PLR receivers. And the NORM_FLAG_CC_LEAVE SHALL 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_LEVE。这些用于在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. 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
“cc_rtt”字段应设置为默认最大值，当没有接收机接收到rtt测量信息时，应清除NORM_FLAG_cc_rtt FLAG。当接收器接收到RTT测量信息时，应相应地设置“cc_RTT”值，并在“cc_标志”字段中设置NORM_标志\u cc_RTT标志。对于NORM_CMD（REPAIR_ADV）消息，发送方应将“cc_rtt”字段值设置为其拥有的最大非CLR/非PLR rtt
measured from receivers for the current feedback round.
从当前反馈回合的接收器测量。
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" = floor(decimal_loss_fraction * 65535.0)
"cc_loss" = floor(decimal_loss_fraction * 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 receiver's 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_标志\u CC_启动。否则，接收方将根据“cc_rate”字段的损耗测量和RTT测量信息（即使默认）计算拥塞控制率。对于NORM_CMD（REPAIR_ADV）消息，发送方应将“cc_loss”字段值设置为从接收方收到的当前反馈回合的最低非CLR/非PLR“cc_rate”报告。
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 Positive Acknowledgment Process including transmission of the NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are
发送方使用NORM_CMD（ACK_REQ）消息从指定的接收方列表请求确认。此消息用于提供轻量级肯定确认机制，该机制可供可靠多播应用程序选择使用。提供了一系列确认请求类型，供应用程序自行决定使用。提供应用程序定义的肯定确认命令，允许应用程序自动利用NORM协议可用的传输和往返定时信息。规范肯定确认过程的详细信息，包括规范CMD（确认REQ）消息和接收器响应（规范ACK）的传输
described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ)
message is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ)
message is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: NORM_CMD(ACK_REQ) Message Format
图15:NORM_CMD（ACK_REQ）消息格式
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"
NORM_ACK（CC）值仅用于响应拥塞控制操作中使用的NORM_CMD（CC）消息而生成的NORM_ACK。类似地，NORM_ACK（FLUSH）仅用于响应适用NORM_CMD（FLUSH）消息而生成的NORM_ACK。带有“确认类型”的NORM_CMD（确认请求）消息
of NORM_ACK(CC) or NORM_ACK(FLUSH) SHALL NOT be generated by the sender.
发送方不得生成正常确认（CC）或正常确认（FLUSH）的副本。
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 can implement application-defined, positively acknowledged commands that are able to leverage internal transmission and round-trip timing information available to the NORM protocol implementation.
提供“确认类型”值的NORM_ACK（APPLICATION）范围，以便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 can 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 acknowledgment (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_sender. 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 can include initiation of data transmission, other NORM_CMD(APPLICATION) messages, or even application-defined, positively acknowledged commands from other NormSession participants. The transmission of these commands will preempt data transmission when they are scheduled and can be multiplexed with ongoing data transmission. This type of robustly transmitted command allows NORM applications to define a complete set of session control mechanisms with less state than the transfer of FEC-encoded reliable content needs while taking advantage of NORM transmission and round-trip timing information.
此命令允许NORM应用程序可靠地传输应用程序定义的命令。命令消息抢占任何正在进行的数据传输，并以每2*GRTT\U发送方一次的速率重复至正常稳健因子次数。此重复率允许应用程序在重复之前观察任何响应（如果这是应用程序执行命令的目的）。可能的响应包括启动数据传输、其他NORM_CMD（应用程序）消息，甚至是应用程序定义的、来自其他NormSession参与者的肯定确认命令。这些命令的传输将在调度时抢占数据传输，并且可以与正在进行的数据传输进行多路复用。这种类型的可靠传输命令允许NORM应用程序定义一套完整的会话控制机制，其状态比FEC编码的可靠内容传输所需的状态少，同时利用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=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-type = 7 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-Defined Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: NORM_CMD(APPLICATION) Message Format
图16: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. Upon reception, the NORM protocol implementation SHALL deliver the content to the receiver application. Note that any detection of duplicate reception of a NORM_CMD(APPLICATION) message is the responsibility of the application.
“应用程序定义的内容”区域包含应用程序自行决定格式的信息。该有效载荷的大小应限制在发送器的最大尺寸设置范围内。接收后，NORM协议实施应将内容交付给接收方应用程序。请注意，任何重复接收NORM_CMD（应用程序）消息的检测都是应用程序的责任。
The NORM message types generated by participating receivers consist of the 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
NORM_NACK消息的有效负载包含一个或多个修复
requests for different objects or portions of those objects. The
NORM_NACK message format is as follows:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
requests for different objects or portions of those objects. The
NORM_NACK message format is as follows:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: NORM_NACK Message Format
图17:NORM_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 containing 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 delta from when the receiver received the NORM_CMD(CC) to when the NORM_NACK is transmitted in response to calculate the value in the "grtt_response" field. This is the "receive_to_response_delta"
“grtt_response”（grtt_response）字段包含所指示的NORM发送方最近收到的NORM_CMD（CC）消息的时间戳的调整版本。“grtt_响应”的格式与NORM_CMD（CC）的“发送_时间”字段相同。“grtt_response”值与源提供的“send_time”相对应，源提供了相应的NORM_CMD（CC）命令。接收机调整源的NORM_CMD（CC）“send_time”时间戳，方法是将从接收机接收NORM_CMD（CC）到发送NORM_NACK的时间增量相加，以计算“grtt_response”字段中的值。这是“接收到响应增量”
value used in the following formula:
grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta
value used in the following formula:
grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta
The receiver SHALL set the "grtt_response" to a ZERO value, to indicate it has not yet received a NORM_CMD(CC) message from the indicated sender, and the sender MUST 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 receiver's current state with respect to congestion control operation. 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_payload" 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 needs from the sender
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
can be concatenated within the "nack_payload" field of a NORM_NACK
message. 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:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "nack_payload" 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 needs from the sender
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
can be concatenated within the "nack_payload" field of a NORM_NACK
message. 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:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: NORM Repair Request Format
图18:NORM维修请求格式
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 |
+--------------------+-------+
+--------------------+-------+
| Form | Value |
+--------------------+-------+
| NORM_NACK_ITEMS | 1 |
| NORM_NACK_RANGES | 2 |
| NORM_NACK_ERASURES | 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 the "repair_request_items" list consists of pairs of repair request items corresponding to the inclusive ranges of repair needs. The NORM_NACK_ERASURES "form" indicates the repair request items are to be treated individually and 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_擦除“form”表示要单独处理修复请求项，并且修复请求项的“fec_payload_id”字段（见下文）的“encoding_symbol_id”部分将被解释为由修复请求项的“source_block_number”标识的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 needed as repair. |
| NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or |
| | | range of blocks in entirety that are |
| | | needed as repair. |
| NORM_NACK_INFO | 0x04 | Indicates NORM_INFO is needed as |
| | | repair for the listed object(s). |
| NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or |
| | | range of objects in entirety are |
| | | needed as repair. |
+-------------------+--------+--------------------------------------+
+-------------------+--------+--------------------------------------+
| Flag | Value | Purpose |
+-------------------+--------+--------------------------------------+
| NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or |
| | | range of segments needed as repair. |
| NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or |
| | | range of blocks in entirety that are |
| | | needed as repair. |
| NORM_NACK_INFO | 0x04 | Indicates NORM_INFO is needed as |
| | | repair for the listed object(s). |
| NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or |
| | | range of objects in entirety are |
| | | needed 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 receiver. When the NORM_NACK_BLOCK flag is set, this indicates the receiver is completely missing the indicated coding block(s), and that transmissions sufficient to repair the indicated block(s) in their entirety are needed. 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 can be set
当设置NORM_NACK_段标志时，“object_transport_id”和“fec_payload_id”字段用于确定需要哪些集合或范围的单个NORM_数据段来修复接收器上的内容。当设置NORM_NACK_块标志时，这表示接收机完全丢失所指示的编码块，并且需要足够的传输来修复所指示的块的整体。当设置了NORM_NACK_INFO标志时，这表示接收器缺少指示的“对象传输id”的NORM_INFO段。注意：可以设置NORM_NACK_信息
in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or can 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_段标志结合使用，或可单独设置。当设置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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NORM Repair Request Item Format
图19:NORM维修请求项格式
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 needed 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
当接收器的修复需求指示需要不同形式（混合范围和/或单个项目）或类型（混合特定段和/或块或对象整体）来完成可靠传输时，具有不同“形式”和/或“标志”值的多个范数修复请求可以在单个范数NACK消息中串联。此外，NORM接收者应按照以下顺序构造NORM_NACK消息及其修复请求：
"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.
“对象传输id”和“fec负载id”值。“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 can 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, and 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 1: NORM_NACK "nack_payload" for: Object 12, Coding Block 3,
Segments 2, 5, and 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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. The acknowledgment type NORM_ACK(CC) is provided for this purpose as described in the NORM_CMD(ACK_REQ) message description. The generation of NORM_ACK(CC) messages for round-trip timing estimation and congestion control operation is described in Section 5.5.1 and Section 5.5.2, respectively. However, some multicast applications can benefit from some limited form of positive acknowledgment for certain functions. A simple, scalable positive acknowledgment scheme is defined in Section 5.5.3, which can be leveraged by protocol implementations when appropriate. The NORM_CMD(FLUSH) can also 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 application-defined "ack_type" values is provided for use at the NORM
NORM_ACK消息主要用作NORM拥塞控制操作和往返计时测量的一部分。确认类型NORM_ACK（CC）用于此目的，如NORM_CMD（ACK_REQ）消息描述中所述。第5.5.1节和第5.5.2节分别描述了用于往返时间估计和拥塞控制操作的NORM_ACK（CC）消息的生成。然而，某些多播应用程序可以从某些功能的有限形式的肯定确认中获益。第5.5.3节定义了一个简单的、可扩展的肯定确认方案，协议实现可适当利用该方案。NORM_CMD（FLUSH）还可用于使用此机制从特定接收器向特定“水印”传输点选择性收集可靠接收的肯定确认。为此目的提供了NORM_ACK类型NORM_ACK（FLUSH），该确认类型的“nack_有效载荷”格式如下所示。除此之外，还提供了一系列应用程序定义的“ack_类型”值，供规范使用
application's discretion. Implementations making use of application-
defined positive acknowledgments MAY also make use of 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.
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
application's discretion. Implementations making use of application-
defined positive acknowledgments MAY also make use of 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.
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: NORM_ACK Message Format
图20:NORM_ACK消息格式
The NORM common message header fields serve their usual purposes. The value of the "hdr_len" field when no header extensions are present is 6.
NORM common message header字段用于其通常用途。当不存在标头扩展名时，“hdr_len”字段的值为6。
The "server_id", "instance_id", and "grtt_response" fields serve the same purpose as the corresponding fields in NORM_NACK messages. Header extensions can 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 the sender can verify a received NORM_ACK message 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:
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(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:
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 of 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 can 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 compliant NORM implementations.
这是NORM参与者生成的可选消息。此消息可用于实验性规范实现中接收器的定期性能报告。此邮件的格式当前未定义。实验性的NORM实现可以根据测试需要定义NORM_报告格式。应禁用这些报告消息，以便在不同的符合规范的实现之间进行互操作性测试。
This section describes the detailed interactions of senders and receivers participating in a NORM session. A simple synopsis of the protocol operation is given here:
本节描述参与NORM会话的发送方和接收方之间的详细交互。协议操作的简单概要如下所示：
1. The sender periodically transmits NORM_CMD(CC) messages as needed to initialize and collect round-trip 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. When applicable, 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. The receivers track the sender's most recent objectTransportId::fecPayloadId transmit position and NACK only for content that is ordinally prior to that current 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消息发起修复请求。接收者跟踪发送者最近的objectTransportId:：fecPayloadId传输位置，并且仅跟踪在当前传输位置之前依次出现的内容的NACK。接收机在生成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. FEC parity content not previously transmitted 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 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 need 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 not operating using dedicated resources, like in the general Internet. Even if congestion control operation is disabled at the sender, it can 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 might need the sender to also proceed with data transmission immediately. In other cases, the sender might wish to defer data transmission until it has received some feedback or request from the receiver set indicating 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 (EXT_FTI), 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 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对象传输信息报头扩展（EXT_FTI），NORM协议发送方消息报头可以包含为后续可靠接收准备接收方所需的所有信息。这包括FEC编码参数、发送方大小和其他信息。如果未使用该报头扩展，则假定接收机已经通过其他方式接收到FEC对象传输信息。此外，应用程序可以利用与会话中的会话数据对象相关联的NORM_INFO消息的使用，为会话和正在传输的数据提供特定于应用程序的上下文信息。这些机制允许在发送方和接收方之间进行最小程度的预协调操作。
The NORM sender begins segmenting application-enqueued data into NORM_DATA segments and transmitting it to the group. For objects of type NORM_OBJECT_DATA and NORM_OBJECT_FILE, the segmentation algorithm described in FEC Building Block [RFC5052] is RECOMMENDED. For objects of type NORM_OBJECT_STREAM, segmentation will typically be into uniform FEC coding block sizes, with individual segment sizes controlled by the application. In most cases, the application and NORM implementation SHOULD strive to produce full-sized
NORM发送方开始将应用程序排队的数据分割为NORM_数据段，并将其传输给组。对于NORM_OBJECT_DATA和NORM_OBJECT_FILE类型的对象，建议使用FEC构建块[RFC5052]中描述的分割算法。对于NORM_OBJECT_STREAM类型的对象，通常将分割成统一的FEC编码块大小，各个片段大小由应用程序控制。在大多数情况下，应用和规范实施应努力产生全尺寸
(NormSegmentSize) segments when possible. 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 for transmission or any pending repairs, it transmits a series of NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT_sender. Similar to the end of each transmitted FEC coding block during transmission, receivers SHALL respond to these NORM_CMD(FLUSH) messages with additional repair requests as needed. 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 purpose 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\U发送方一个的速率传输一系列NORM_CMD（FLUSH）消息。与传输期间每个传输的FEC编码块的结尾类似，接收器应根据需要对这些NORM_CMD（FLUSH）消息做出响应，并提出额外的修复请求。协议参数NORM_ROBUST_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 appropriate NACKs can be constructed to request repair of missing data. NORM FEC coding blocks are comprised of multi-byte symbols (segments) transmitted in the payload of NORM_DATA messages. Each NORM_DATA message will contain one or more source or encoding symbols identified by the "fec_payload_id" field, and the NormSegmentSize sender parameter defines the maximum size (in bytes) of the "payload_data" field containing the content (a "segment"). The FEC encoding type and associated parameters govern the source block size (number of source symbols per coding block, etc.). 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 Object Transmission Information for each object. The block partitioning algorithm described in the FEC Building Block [RFC5052] document is RECOMMENDED for use in computing 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 that 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_数据消息将包含由“fec_payload_id”字段标识的一个或多个源或编码符号，NormSegmentSize发送方参数定义了包含内容的“payload_数据”字段（一个“段”）的最大大小（以字节为单位）。FEC编码类型和相关参数控制源块大小（每个编码块的源符号数等）。NORM发送方和接收方使用这些FEC参数以及NORMSECTIONSIZE和传输对象大小来计算传输对象的源块结构。这些参数在每个对象的FEC对象传输信息中提供。建议在计算源块结构时使用FEC构建块[RFC5052]文档中描述的块划分算法，以使所有源块尽可能接近等长。这有助于避免“短”FEC块的性能缺点。请注意，此算法仅适用于对象大小固定且预先确定的静态大小的NORM_OBJECT_数据和NORM_OBJECT_文件传输对象类型。对于NORM_OBJECT_STREAM对象，根据FEC传输信息中给定的最大源块长度分割对象，除非FEC有效负载ID指示给定块的替代大小。
For typical operation, NORM receivers will join a specified multicast group and listen on a specific port number for sender transmissions. As the NORM receiver receives NORM_DATA messages, it will establish buffering state and provide content to its application as appropriate for the given data type. The NORM protocol allows receivers to join and leave the group at will, although some applications might need receivers to be members of the group prior to start of data transmission. Thus, different 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 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" might be appropriate for different applications and/or scenarios. For general purpose operation, a 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 the join policy constrain receivers to begin reliable reception at the current FEC coding block for which non-repair content is received.
对于典型操作，NORM接收器将加入指定的多播组，并在特定端口号上侦听发送方传输。当NORM接收器接收NORM_数据消息时，它将建立缓冲状态，并根据给定的数据类型向其应用程序提供内容。NORM协议允许接收器随意加入和离开组，尽管某些应用程序可能需要接收器在开始数据传输之前成为组的成员。因此，不同的规范应用可以使用不同的策略来约束新的接收者在会话中间加入组的影响。例如，一个有用的实施策略是让新加入组的接收者限制或避免对已在进行的传输对象的修复请求。NORM发送方实现可以施加额外的约束，以限制接收方通过经常加入、离开和重新加入组来中断可靠多播性能的能力。不同的接收方“加入策略”可能适用于不同的应用程序和/或场景。对于一般用途的操作，建议使用默认策略，其中允许接收器仅对NormTransportId和FEC编码块编号大于或等于加入组时接收到的第一个非修复NORM_数据或NORM_信息的编码块请求修复。对于NORM_OBJECT_STREAM类型的对象，建议联接策略约束接收器在接收非修复内容的当前FEC编码块处开始可靠接收。
In some deployments, different multicast receivers might have differing quality of network connectivity. Some receivers may suffer significantly poorer performance with very limited goodput due to low connection rate or substantial packet loss. Similar to the "join policies" described above, a NORM sender implementation MAY choose to enforce different "service policies" to perhaps exclude exceptionally poorly performing (or otherwise badly behaving) receivers from the group. The sender implementation could choose to ignore NACKs from such receivers and/or force advancement of its logical "repair window" (i.e., enforcing a minimal level of service) and use the NORM_CMD(SQUELCH) message to advise those poor performers of its advance. Note in some cases, the application may need to support the "weakest member" regardless of the time needed to achieve reliable delivery. When implemented, the protocol instantiation SHOULD expose controls to the set of "join" and/or "service" policies available to support the needs of different applications.
在某些部署中，不同的多播接收器可能具有不同的网络连接质量。由于低连接速率或大量数据包丢失，一些接收机可能会在非常有限的goodput的情况下显著降低性能。与上面描述的“加入策略”类似，NORM发送方实现可以选择实施不同的“服务策略”，以从组中排除性能异常差（或行为异常）的接收方。发送方实现可以选择忽略来自此类接收方的nack和/或强制推进其逻辑“修复窗口”（即强制实施最低级别的服务），并使用NORM_CMD（SQUELCH）消息将其推进告知那些表现不佳的人。注意：在某些情况下，应用程序可能需要支持“最弱成员”，而不管实现可靠交付所需的时间。在实现时，协议实例化应将控件公开给一组“连接”和/或“服务”策略，这些策略可用于支持不同应用程序的需求。
When the receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACKing procedure. The NACKing
当接收器检测到它丢失了来自发送方NORM传输的数据时，它启动其NACKing过程。震动
procedure SHALL be initiated only at FEC coding block boundaries, NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or upon an "inactivity" timeout when NORM_DATA or NORM_INFO transmissions are no longer received from a previously active sender. The RECOMMENDED value of such an inactivity timeout is:
只有在FEC编码块边界、NormObject边界、收到NORM_CMD（FLUSH）消息时，或在“非活动”超时时，当NORM_数据或NORM_信息传输不再从先前活动的发送方接收时，才应启动该程序。此类非活动超时的建议值为：
T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender
T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender
where the GRTT_sender value corresponds to the GRTT estimate advertised in the "grtt" field of NORM sender messages. A minimum T_inactivity value of 1 second is RECOMMENDED. The NORM receiver SHOULD reset this inactivity timer and repeat NACK initiation upon timeout for up to NORM_ROBUST_FACTOR times or more depending upon the application's need for persistence by its receivers. It is also important receivers rescale the T_inactivity timeout as the sender's advertised GRTT changes.
其中，GRTT_发送者值对应于标准发送者消息的“GRTT”字段中公布的GRTT估计值。建议最小T_不活动值为1秒。NORM接收器应重置此非活动计时器，并根据应用程序对其接收器持久性的需求，在超时时重复NACK启动，最多可达NORM_ROBUST_因子次数或更多。当发送方公布的GRTT发生变化时，接收方重新调整T_非活动超时也很重要。
The NACKing procedure begins with a random backoff timeout. The duration of the backoff timeout is chosen using the "RandomBackoff" algorithm described in the Multicast NACK Building Block [RFC5401] document using (K_sender*GRTT_sender) for the maxTime parameter and the sender advertised group size (GSIZE_sender) as the groupSize parameter. NORM senders provide values for GRTT_sender, K_sender and GSIZE_sender via the "grtt", "backoff", and "gsize" fields of transmitted messages. The GRTT_sender value is determined by the sender based on feedback it has received from the group while the K_sender and GSIZE_sender values can be determined by application requirements and expectations or ancillary information. The backoff factor K_sender MUST be greater than one to provide for effective feedback suppression. A value of K_sender = 4 is RECOMMENDED for the Any Source Multicast (ASM) model, while a value of K_sender = 6 is RECOMMENDED for Single Source Multicast (SSM) operation.
NACKing过程以随机回退超时开始。退避超时的持续时间是使用多播NACK构建块[RFC5401]文档中描述的“随机退避”算法选择的，该算法使用（K_sender*GRTT_sender）作为maxTime参数，使用发送方公布的组大小（GSIZE_sender）作为groupSize参数。标准发送方通过传输消息的“GRTT”、“退避”和“GSIZE”字段为GRTT_发送方、K_发送方和GSIZE_发送方提供值。GRTT_发送方值由发送方根据其从集团收到的反馈确定，而K_发送方和GSIZE_发送方值可由应用要求和期望或辅助信息确定。回退系数K_发送方必须大于1，以提供有效的反馈抑制。对于任意源多播（ASM）模型，建议使用K_sender=4的值，而对于单源多播（SSM）操作，建议使用K_sender=6的值。
Thus:
T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender)
Thus:
T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender)
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 (K_sender-1)*GRTT_sender. 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_回退大于（K_发送方-1）*GRTT_发送方时，接收方应自动抑制其NACK并立即进入下文所述的“延迟”期。否则，将进入退避期，接收方必须从收到的NORM_NACK消息和NORM_CMD（repair_ADV）消息中累积外部挂起修复状态。在退避时间结束时，仅当满足以下条件时，接收器才应生成NORM_NACK消息：
1. The sender's current transmit position (in terms of objectTransportId::fecPayloadId) exceeds the earliest repair position of the receiver.
1. 发送方的当前传输位置（就objectTransportId:：fecPayloadId而言）超过了接收方的最早修复位置。
2. The repair state accumulated from NORM_NACK and NORM_CMD(REPAIR_ADV) messages does 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 re-initiate 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 [RFC5401] is: T_rcvrHoldoff =(K_sender+2)*GRTT_sender
如果满足这些条件，当退避超时过期时，接收器立即生成NORM_NACK消息。否则，接收器的NACK被认为是“被抑制的”，并且消息不被发送。此时，接收器开始一个“延迟”期，在此期间，它约束自己不重新启动振铃过程。此超时的目的是在接收方再次请求修复之前，允许发送方在最坏情况下响应修复需求。[RFC5401]中描述的此“延迟”超时（T_rcvrHoldoff）的值为：T_rcvrHoldoff=（K_sender+2）*GRTT_sender
The NORM_NACK message contains repair request content beginning with the 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 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 the sender might have transmitted 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 needed to satisfy its total erasure needs for the block. The goal of this strategy is for the overall receiver set to request a lowest
对于需要修复的每个部分接收的FEC编码块，在其对该块的第一次修复尝试时，接收器应请求FEC编码块的奇偶校验部分，从最低顺序奇偶校验“encoding_symbol_id”（即，“encoding_symbol_id”=“source_block_len”）开始以及请求与其块的数据段擦除计数相对应的FEC符号的数目。在同一编码块的后续修复周期中，接收器应仅从其尚未收到的第一组中请求修复符号，直至该适用编码块的剩余擦除计数。注意，发送方可能已经为其他接收机发送了其他不同的附加奇偶校验段，这些奇偶校验段也可用于满足本地接收机的擦除填充需求。在部分接收的FEC编码块的擦除计数超过该块的发送方可用奇偶校验符号的最大数目的情况下（如NORM_DATA“FEC_num_奇偶校验”字段所示），接收器应请求所有可用奇偶校验段加上满足其块的总擦除需求所需的顺序最高缺失数据段。此策略的目标是使整个接收器集请求最低的
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 does not demand synchronization among the receiver set in their repair requests for the sender.
给定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 principal goal of the sender is to make forward progress in the transmission of data its application has enqueued. However, the sender will need to 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 [RFC5401], the period of time during which the sender aggregates NORM_NACK messages is equal to:
如[RFC5401]所述，发送方聚合NORM_NACK消息的时间段等于：
T_sndrAggregate = (K_sender + 1) * GRTT_sender
T_sndrAggregate = (K_sender + 1) * GRTT_sender
where K_sender is the backoff scaling value advertised to the receivers, and GRTT_sender is the sender's current estimate of the group's greatest round-trip time. Note, for NORM unicast sessions, the T_sndrAggregate time can be set to ZERO since there is only one receiver. Similarly, the K_sender value SHOULD be set to ZERO for NORM unicast sessions to minimize repair latency.
其中K_sender是向接收者公布的退避比例值，GRTT_sender是发送者对组的最大往返时间的当前估计。注意，对于标准单播会话，T_sndrAggregate time可以设置为零，因为只有一个接收机。类似地，对于标准单播会话，K_sender值应设置为零，以最小化修复延迟。
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 [RFC5401], the value of this sender "holdoff" period is:
传输完成后，发送方继续进行任何排队数据的新传输。此外，此时，发送方开始“延迟”超时，在此期间，发送方限制自己启动新的修复聚合周期，即使NORM_NACK消息到达。如[RFC5401]所述，此发送方“延迟”期的值为：
T_sndrHoldoff = (1 * GRTT_sender)
T_sndrHoldoff = (1 * GRTT_sender)
If additional NORM_NACK messages are received during this sender "holdoff" period, the sender will immediately incorporate these late-arriving messages into its pending transmission state if, and 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 started (upon arrival of a NACK) in concert with the pending repair and new data transmission. Recall 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 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.
如果在此发送方“延迟”期间收到其他NORM_NACK消息，则发送方将立即将这些延迟到达的消息合并到其挂起传输状态，前提是且仅当NACK内容通常大于发送方的当前传输位置。此“延迟”时间允许发送方在最坏情况下将其当前传输序列位置传播到组，从而避免冗余修复传输。延迟超时到期后，新的NACK累积期（在NACK到达时）可以与待修复和新数据传输一起开始。在发送方的逻辑传输位置超过其维修需求的最低顺序位置之前，召回接收方不得启动NACK维修流程。对于新的NACK聚合周期，发送方重复相同的过程，将累积的修复状态合并到其传输计划中，然后在聚合周期到期时“倒带”以传输最低顺序的修复数据。同样，这是与正在进行的新数据和/或待修复传输同步进行的。
The NORM sender SHOULD leverage transmission of FEC parity content for repair to the greatest extent possible. Recall that 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. The sender SHOULD NOT resort to explicit transmission of the receiver set's repair needs until after exhausting its supply of "fresh" (unsent) parity segments for a given coding block. In general, if a sufficiently powerful FEC code is used, the need for explicit repair will be an exception, and the
规范发送方应尽可能利用FEC奇偶校验内容的传输进行修复。回想一下，接收方在形成其NORM_NACK消息时使用一种策略来请求显式修复（包括奇偶校验内容）的最低公分母。在返回到显式满足不同接收方的修复需求之前，发送方可以利用FEC生成的奇偶校验段的一般擦除填充能力。发送方可以根据修复聚合期间接收的NORM_NACK消息确定单个FEC编码块的最大擦除填充需求。然后，如果发送方具有足够数量（小于或等于最大擦除计数）的先前未发送的奇偶校验段可用于适用的编码块，则发送方可以发送这些奇偶校验段来代替接收方集合请求的特定分组。发送方在耗尽其对给定编码块的“新鲜”（未发送）奇偶校验段的供应之前，不应求助于明确传输接收方集的修复需求。通常，如果使用功能足够强大的FEC代码，则需要显式修复是一个例外，并且
fulfillment of reliable multicast can be accomplished quite efficiently. However, the ability to resort to explicit repair allows the protocol to be continue to operate under even very extreme circumstances.
可靠组播的实现可以非常有效地完成。然而，借助于显式修复的能力允许协议在非常极端的情况下继续运行。
NORM_DATA messages sent as repair transmissions SHALL be flagged with the NORM_FLAG_REPAIR flag. This allows receivers to obey any policies limiting new receivers from joining the reliable transmission when only repair transmissions have been received. Additionally, the sender SHOULD 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 packets to those portions of the routing tree still requiring repair for a given coding block. Note the intermediate systems will need 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 NORM_NACK suppression/aggregation as it conducts this repair state accumulation for NORM repair cycles. The details of this type of operation are beyond the scope of this document, but this information is provided for possible future consideration.
尽管NORM终端系统接收器不使用NORM_FLAG_EXPLICIT标志，但希望“帮助”NORM协议性能的中间系统可以利用此消息传输状态。如果这样的系统相对于互惠反向路径多播路由被正确定位，那么它们只需要子广播足够数量的非显式奇偶校验修复，以满足多播路由子树对给定FEC编码块的擦除填充需求。当发送方求助于显式修复时，中间系统应将所有显式修复包分播到路由树中仍需要对给定编码块进行修复的部分。注：中间系统需要以类似于发送方维修状态累加的方式对子路由进行维修状态累加，以便有足够的信息来执行子广播。此外，中间系统可以执行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_sender. 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. The list includes as many lower ordinal invalid "object_transport_ids" that can fit for the NORM_CMD(SQUELCH) payload size to less than or equal to the sender's NormSegmentSize parameter.
如果发送方收到用于修复其不再支持的数据的NORM_NACK消息，发送方将生成NORM_CMD（SQUELCH）消息以公布其修复窗口，并禁止任何接收方接收其他无效数据。NORM_CMD（静噪）消息的传输速率限制为每2*GRTT_发送方一次。NORM_CMD（SQUELCH）消息的“无效对象_列表”（如果适用）应以自上次NORM_CMD（SQUELCH）传输以来接收到的无效NORM_NACK消息的最低“对象_传输_id”开始。该列表包括尽可能多的顺序较低的无效“object_transport_ID”，这些ID可以适合NORM_CMD（静噪）有效负载大小，使其小于或等于发送方的NormSegmentSize参数。
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. A NORM sender implementation MAY use a separate port number from the NormSession port number as the source port for its transmissions. Thus, NORM receivers can direct any unicast feedback messages to this separate sender port number, distinct from the NORM session (or destination) port number. Then, the NORM sender implementation can discriminate unicast feedback messages from multicast feedback messages when there is a mix of multicast and unicast feedback receivers. 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 that 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 is subject to the sender transmit rate limit and NormSegmentSize limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum size (as indicated by the flag NORM_REPAIR_ADV_FLAG_LIMIT), 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 will also need to provide any information needed so dynamic congestion control feedback can be suppressed among receivers. This document specifies the NORM-CC Feedback Header Extension that is applied for 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发送方通过单播传输从接收方接收NORM_NACK消息时，它使用NORM_CMD（REPAIR_ADV）消息将其累积的修复状态通告给接收方集，因为接收方集未通过多播通信直接共享其修复需求。NORM发送方实现可以使用NormSession端口号之外的单独端口号作为其传输的源端口。因此，NORM接收方可以将任何单播反馈消息定向到这个独立的发送方端口号，与NORM会话（或目的地）端口号不同。然后，当存在多播和单播反馈接收器的混合时，NORM发送器实现可以区分单播反馈消息和多播反馈消息。NORM_CMD（REPAIR_ADV）消息多播到发送方设置的接收方。此消息的有效负载部分具有与NORM_NACK接收器消息有效负载相同格式的内容。然后，接收机能够以与直接从其他接收机接收的NORM_NACK消息相同的方式执行反馈抑制。注意，发送方不仅重新传输它接收到的NACK内容，而是传输其聚合修复状态的表示。NORM_CMD（REPAIR_ADV）消息的传输受发送方传输速率限制和NormSegmentSize限制。当NoMr.CMD（ReaPixADV）消息具有最大大小时（如FrimeReopeAdvay-FraviLimax所示），接收者应考虑嵌入在消息中的最大序号传输位置值作为发送者当前传输位置，并隐式地抑制通常更高修复的请求。对于拥塞控制操作，发送方还需要提供所需的任何信息，以便在接收方之间抑制动态拥塞控制反馈。本文档指定了应用于基线NORM-CC操作的NORM-CC反馈标头扩展。如果在NORM实现中使用其他拥塞控制机制，则可以定义其他报头扩展。用于此目的的任何内容格式都应确保将最大可能的抑制状态传送到接收器集。
In addition to the principal function of data content transmission and repair, there are some other protocol mechanisms to 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 need
对于正常接收者适当地调整退避超时，发送者使用适当的相应超时，参与者需要
to use a common timeout basis. Each NORM sender monitors the round-trip time of active receivers and determines the greatest group round-trip time. The sender advertises this GRTT estimate in every message it transmits so receivers have this value available for scaling their timers. To measure the current GRTT, the sender periodically sends NORM_CMD(CC) messages containing 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，发送方定期发送包含本地生成的时间戳的NORM_CMD（CC）消息。接收方应记录此时间戳以及收到NORM_CMD（CC）消息的时间。然后，当接收器生成反馈消息给发送者时，发送者时间戳的调整版本被嵌入反馈消息中（NORM_NACK或NORM_ACK）。调整增加了接收器在生成响应之前保持时间戳的时间量。收到该调整后的时间戳后，发送方能够计算到该接收方的往返时间。
The round-trip time for each receiver is fed into an algorithm that assigns weights and smoothes the values for a conservative estimate of the GRTT. The algorithm and methodology are described in the Multicast NACK Building Block [RFC5401] document in the section entitled "One-to-Many Sender GRTT Measurement". A conservative estimate helps guarantee 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测量”一节中的多播NACK构建块[RFC5401]文档中进行了描述。保守估计有助于以较小的总体协议修复延迟成本保证反馈抑制。发送方当前对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 the NORM-CC Rate header extension MAY also be used to proactively solicit RTT feedback from the receiver group per congestion control operation even when the sender is not conducting
当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反馈，即使在发送方不执行该操作时也是如此
congestion control rate adjustment. NORM operation without congestion control SHOULD be considered only in closed networks.
拥塞控制速率调整。只有在封闭网络中才应考虑无拥塞控制的正常运行。
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 [RFC4654]. 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. 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 the NORM protocol message set MAY alternatively be used to support a window-based multicast congestion control scheme such as PGMCC. The details of such an 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 corresponding to the lowest resulting calculated transmission rate is identified as the "current limiting receiver" (CLR). In the case of a tie (where candidate CLRs are within 10% of the same calculated rate), the receiver with the largest RTT value SHOULD be designated as the CLR.
本节介绍NORM协议（NORM-CC）的基线拥塞控制操作。这里描述的支持规范消息格式和方法是对基于等式的TCP友好多播拥塞控制（TFMCC）方法[RFC4654]的一种改编。这种拥塞控制方案需要在通用互联网中运行，除非规范实现适合使用另一种IETF认可的可靠多播拥塞控制机制。通过这种基于TFMCC的方法，与TCP中基于窗口的拥塞控制算法相反，以基于速率的方式控制范数发送方的传输。然而，NORM协议消息集可以替代地用于支持基于窗口的多播拥塞控制方案，例如PGMCC。此类替代方案的细节可单独描述，或在本文件的未来版本中描述。在这两种情况下（基于速率的TFMCC或基于窗口的PGMCC），发送方传输的成功控制取决于发送方到接收方分组丢失估计和RTT的收集，以识别多播拓扑内的拥塞控制瓶颈路径并相应地调整发送方速率。具有与最低计算传输速率相对应的损耗和RTT估计的接收机被识别为“限流接收机”（CLR）。在平局的情况下（候选CLR在相同计算速率的10%以内），RTT值最大的接收机应指定为CLR。
As described in [TcpModel], a steady-state sender transmission rate,
to be "friendly" with competing TCP flows, can be calculated as:
S
Rsender = ----------------------------------------------------------
T_rtt*(sqrt((2/3)*p) + 12*sqrt((3/8)*p) * p * (1 + 32*(p^2)))
As described in [TcpModel], a steady-state sender transmission rate,
to be "friendly" with competing TCP flows, can be calculated as:
S
Rsender = ----------------------------------------------------------
T_rtt*(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），以考虑可变消息大小）。
T_rtt = RTT estimate of the current "current limiting receiver" (CLR).
T_rtt=电流“限流接收器”（CLR）的rtt估计值。
p = 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, they:
为了支持拥塞控制反馈收集和操作，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 the current worst path in the group multicast topology.
3. 启动CLR的快速（即时）反馈，以便密切跟踪组多播拓扑中当前最差路径的拥塞控制动态。
The format of the NORM_CMD(CC) message is described 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 might be determined administratively or possibly algorithmically based upon 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 PLR list MAY be populated with a small number of receivers the sender identifies as approaching the CLR loss and delay conditions based on feedback from the group.
本文件第4.2.3节描述了NORM_CMD（CC）信息的格式。NORM_CMD（CC）消息包含允许测量RTT、通知组拥塞控制CLR以及向组中的接收器提供单个RTT测量反馈的信息。NORM_CMD（CC）还提供来自可选的“潜在限制接收器”（PLR）节点的激励反馈，该反馈可基于拥塞控制反馈以管理方式或可能以算法方式确定。PLR节点是已经确定有可能（可能很快）成为CLR的接收器，因此即时、最新的反馈有利于拥塞控制性能。PLR列表可以填充少量的接收机，发送方根据组的反馈确定这些接收机接近CLR丢失和延迟条件。
The NORM_CMD(CC) message is transmitted periodically by the sender along with its normal data transmission. Note the repeated transmission of NORM_CMD(CC) messages MAY be initiated some time before transmission of user data content at session startup. This can 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 initial value of GRTT_sender = 0.5 seconds is RECOMMENDED when no feedback has yet been received from the group.
1. 默认情况下，间隔是根据当前发送方GRTT估计值设置的。当尚未收到来自团队的反馈时，建议启动初始值GRTT_sender=0.5秒。
2. Until a CLR has been identified (based on previous receiver feedback) or when no data transmission is pending, the NORM_CMD(CC) interval is doubled up from its current interval to a maximum of once per 30 seconds. This results in a low duty cycle for NORM_CMD(CC) probing when no CLR is identified or there is no pending data to transmit.
2. 在识别出CLR（基于之前的接收器反馈）之前，或者在没有数据传输挂起时，NORM_CMD（CC）间隔从其当前间隔加倍，最多每30秒一次。这导致在未识别CLR或无待传输数据时，NORM_CMD（CC）探测的占空比较低。
3. When a CLR has been identified (based on receiver feedback) and data transmission is pending, the probing interval is set to the RTT between the sender and the CLR (RTT_clr).
3. 当已识别CLR（基于接收器反馈）且数据传输挂起时，探测间隔设置为发送方和CLR之间的RTT（RTT_CLR）。
4. Additionally, when the data transmission rate is low with respect to the RTT_clr interval used for probing, the implementation SHOULD ensure no more than one NORM_CMD(CC) message is sent per NORM_DATA message when there is data pending transmission. This ensures the transmission of this control message is not done to the exclusion of user data transmission.
4. 此外，当数据传输速率相对于用于探测的RTT_clr间隔较低时，实现应确保在存在待传输数据时，每个NORM_数据消息发送的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 will 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 the CLR entry be the first in the list for implementation efficiency. Additional entries in the list are used to provide sender-measured 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 will allow the sender to be more responsive to congestion control dynamics. The length of the list can 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
“cc_节点_列表”包含一个条目列表，用于标识接收器及其当前拥塞控制状态（状态“标志”、“rtt”和“丢失”估计）。如果发件人尚未收到组的任何反馈，则列表将为空。如果发送者收到反馈，列表将至少包含一个标识CLR的条目。为“CC_标志”字段提供了NORM_FLAG_CC_CLR标志值，以标识CLR条目。为了提高实施效率，建议将CLR条目放在列表的第一位。列表中的其他条目用于向组中的接收方提供发送方测量的单个RTT估计值。此列表中附加条目的数量取决于发送方应用程序愿意发送的关于用户数据消息传输的控制通信量的百分比。列表中的更多条目将允许发送方对拥塞控制动态做出更大的响应。列表的长度可以根据当前传输速率和NORM_CMD（CC）消息的调度动态确定。列表的最大长度对应于会话的发送方NORMSECTIONSIZE参数。列入
additional entries in the list based on receiver feedback is prioritized with the following rules:
基于接收者反馈的列表中的其他条目按以下规则排列优先级：
1. Receivers that have not yet been provided an RTT measurement 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 an RTT measurement 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 used for other congestion control functions. The NORM_FLAG_CC_PLR flag value is used to mark additional receivers from which the sender would like to have immediate, non-suppressed feedback. These can be receivers the sender algorithmically identified as potential future CLRs or 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 the NORM sender has been pre-configured with a set of PLR nodes, feedback from those receivers might not have yet been collected and thus the "cc_rtt" field does not contain a valid value when this flag is not set. Similarly, a value of ZERO for the "cc_rate" field here MUST be treated as an invalid value and be ignored for the purposes of feedback suppression, etc.
除了用于其他拥塞控制功能的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 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 those 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_backoff * GRTT_sender, GSIZE_sender)
T_backoff = RandomBackoff(K_backoff * GRTT_sender, GSIZE_sender)
The RandomBackoff() algorithm provides a truncated exponentially distributed random number and is described in the Multicast NACK Building Block [RFC5401] document. The same backoff factor, K_backoff = K_sender, as used with NORM_NACK suppression is generally RECOMMENDED. However, in cases where the application purposefully
RandomBackoff（）算法提供了一个截断的指数分布随机数，在多播NACK构建块[RFC5401]文档中有描述。通常建议使用与NORM_NACK抑制相同的退避系数K_backoff=K_sender。但是，如果应用程序故意
specifies a very small K_sender backoff factor to minimize the NACK repair process latency (trading off group size scalability), it is RECOMMENDED a larger backoff factor for congestion control feedback be maintained, since there can be a larger volume of congestion control feedback than NACKs in many cases and some congestion control feedback latency might be tolerable where reliable delivery latency is not. As previously noted, a backoff factor value of K_sender = 4 is generally RECOMMENDED for ASM operation and K_sender = 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:
指定非常小的K_发送方回退因子以最小化NACK修复过程延迟（权衡组大小可伸缩性），建议为拥塞控制反馈保留更大的回退因子，因为在许多情况下，拥塞控制反馈的数量可能比NACK的数量大，并且在没有可靠传递延迟的情况下，一些拥塞控制反馈延迟可能是可以容忍的。如前所述，通常建议ASM操作使用K_sender=4的退避因子值，SSM操作使用K_sender=6的退避因子值。在以下条件下，接收器应取消退避超时，从而取消其等待传输的NORM_ACK（RTT）消息：
1. The receiver generates another feedback message (NORM_NACK or other NORM_ACK) before the congestion control feedback timeout expires (these messages will convey the current congestion control feedback information).
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_sender. 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 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) might wish to compete as a receiver with no prior RTT measurement after some long-term expiration period.
4. “抑制”拥塞控制反馈从另一个接收器（在NORM_ACK或NORM_NACK中）或通过来自发送方的NORM_CMD（REPAIR_ADV）消息听到。如果竞争反馈（Rfb）的速率足够接近或小于本地接收机的计算速率（Rcalc），则本地接收机的反馈被“抑制”。当Rcalc>（0.9*Rfb）时，本地接收器的反馈被取消。另外，请注意，尚未从发送方接收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
无论何时生成任何反馈（包括此NORM_ACK（RTT）消息），接收方都会包含发送方的调整版本
timestamp from the most recently received NORM_CMD(CC) message and its "cc_sequence" value in the corresponding 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_CMD（CC）消息的时间戳及其对应NORM_ACK或NORM_NACK消息字段中的“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_sender 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_sender * GRTT_sender)
T_ccHoldoff = (K_sender * GRTT_sender)
Thus, non-CLR receivers are constrained to providing explicit congestion control feedback once per K_sender*GRTT_sender intervals. However, 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 [TfmccPaper], 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反馈指示的速率。如[TfmccPaper]中所述，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 determined either 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 SHOULD use the "cc_rtt" provided in the NORM-CC Feedback header extension as the receiver's previous RTT measurement (RTT_rcvrPrev) averaged with the current measurement ("RTT_rcvrNew") as the receiver's RTT value:
发送方可以使用反馈消息中包含的“grtt_响应”时间戳计算接收方的当前RTT（RTT_rcvrNew）。当响应中的“cc_rtt”值无效时，发送方仅使用此rtt_rcvr新值作为接收方的当前rtt（rtt_rcvr）。对于非CLR和非PLR接收机，发送方应使用NORM-cc反馈报头扩展中提供的“cc_rtt”作为接收机先前的rtt测量值（rtt_rcvrPrev），并将当前测量值（“rtt_rcvrNew”）平均为接收机的rtt值：
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 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 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:
在会话启动期间，拥塞控制操作应遵守“慢启动”程序，以快速接近其公平带宽共享。假设初始发送方启动速率，其中：
Rinit = MIN(NormSegmentSize/GRTT_sender, NormSegmentSize) bytes/sec
Rinit = MIN(NormSegmentSize/GRTT_sender, NormSegmentSize) bytes/sec
The rate is increased only when feedback is received from the receiver set. The "slow start" phase proceeds until any receiver
仅当接收到来自接收器集的反馈时，速率才会增加。“慢启动”阶段继续进行，直到任何接收器
provides feedback indicating 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 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_速率”字段中报告的最小接收速率。注意：在慢速启动期间，接收器在其反馈的“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 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. The following algorithm is used to determine the decrease in sender rate (Rsender bytes/sec) as the CLR feedback, unexpectedly, excessively ages:
发送方还应通过将其当前“cc_序列”值（Seq_sender）与从CLR（Seq_CLR）收到的上一个“cc_序列”值进行比较，来跟踪其从CLR收到的反馈的期限。随着CLR反馈时间的增加而没有新的反馈，发送方应开始降低其每RTT_CLR一次的速率，作为拥塞避免措施。以下算法用于确定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 rates. 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 rate as the new CLR. Note this assumes the sender does not have explicit knowledge 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.
这种速率降低仅限于标准传输速率的下限。在NORM_ROBUST_FACTOR连续NORM_CMD（CC）轮且没有来自CLR的任何反馈后，发送方应假设CLR已离开该组，并选择下一个最低速率的接收方作为新的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.
当发送方的数据传输中断时，它可以继续使用NORM_CMD（CC）消息探测组，以维护来自组的RTT收集。这将使发送方能够在数据传输重新启动时快速确定适当的CLR。
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:
但是，发送方应随着中断时间的推移，以指数方式降低其用于传输重启的目标速率。每个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 observe 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 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) 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 SHOULD be conducted within the protocol implementation to take advantage of timing and transmission scheduling information available to the NORM transport.
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”字段，用于标识请求和提供的确认类型。为应用程序定义的使用提供了一系列“确认类型”值。当应用程序负责发起确认请求并解释应用程序定义的“ack_类型”值时，确认程序应在协议实现中执行，以利用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 a 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 of the receivers expected to 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 generating NORM_CMD(FLUSH) or NORM_CMD(ACK_REQ) messages in periodic rounds. For NORM_ACK(FLUSH) requests, the NORM_CMD(FLUSH) contains 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 that is similarly echoed in response so the sender can 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, with a uniform distribution, transmit NORM_ACK messages over a time window of (1*GRTT_sender). These NORM_ACK messages are typically unicast to the sender. (Note NORM_ACK(CC) messages SHALL be multicast or unicast in the same manner as NORM_NACK messages.)
为了响应NORM_CMD（ACK_REQ），列出的接收机以均匀分布随机地在（1*GRTT_sender）的时间窗口内发送NORM_ACK消息。这些标准确认消息通常单播给发送方。（注：NORM_ACK（CC）消息应采用与NORM_NACK消息相同的方式进行多播或单播。）
The ACK process is self-limiting and avoids ACK implosion because:
ACK过程是自限的，可避免ACK内爆，因为：
1. Only a single NORM_CMD(ACK_REQ) message is generated once per (2*GRTT_sender), and
1. 每个（2*GRTT\U发送方）只生成一条NORM\U CMD（ACK\U 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 will sometimes be necessary 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 (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 needed 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
由于包含列表的大小仅限于发送方的NORMSECTIONSIZE设置，因此有时需要多次NORM_CMD（ACK_REQ）轮次以获得所有指定接收方的响应。随此过程的进行，所附NormNodeId列表的内容将动态更新，并从指定的接收器集接收NORM_ACK响应。当发送方从接收方接收到有效响应（即匹配水印点或“确认id”）时，应将这些接收方从随后的NORM_CMD（确认请求）消息“确认节点列表”中删除，并在保持列表大小的NORMSECTIONSIZE限制的情况下添加任何待处理的接收方NORMNODEID。每个接收器被查询的次数最多（默认情况下为NORM\u ROBUST\u FACTOR）。在这个重复请求数内没有响应的接收器将从有效负载列表中删除，以便为等待确认的其他潜在接收器腾出空间。NORM_CMD（ACK_REQ）的传输被重复，直到不需要进一步的响应，或者直到所有待处理接收器的重复阈值被超过。用于执行肯定确认过程的NORM_CMD（ACK_REQ）或NORM_CMD（FLUSH）消息的传输与正在进行的发送方数据传输进行多路复用。但是，NORM_CMD（FLUSH）肯定确认过程可能会中断，以响应否定确认
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.
在确认期间从接收方收到的维修请求（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 that is used in scaling random backoff timer ranges. The use of the group size estimate within the NORM protocol does not demand 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. It is also possible the group size MAY be algorithmically approximated from the volume of congestion control feedback messages based on the exponentially weighted random backoff. However, the specification of such an algorithm is currently beyond the scope of this document.
NORM sender消息包含一个“gsize”字段，该字段表示组大小，用于缩放随机回退计时器范围。在NORM协议中使用组大小估计值并不需要精确的估计值，如果估计值在实际组大小的数量级内，则效果相当好。默认情况下，可以通过管理方式配置标准发送方组大小估计。此外，考虑到一般使用的NORM协议的预期可伸缩性，建议使用默认值10000作为组大小估计值。也有可能根据基于指数加权随机退避的拥塞控制反馈消息的量来算法地近似组大小。然而，这种算法的规范目前超出了本文件的范围。
The NORM protocol supports a modest number of configurable parameters that control operation. Most of these need only be set at NORM sender(s) and the configuration information is communicated to the receiver set in NORM header and/or header extension fields. A notable exception to this is the NORM_ROBUST_FACTOR that is presumed to be a common value preset among senders and receivers for a given NORM session. The following table summarizes these configurable elements:
NORM协议支持少量可配置参数来控制操作。其中大多数只需要在NORM发送方设置，配置信息在NORM报头和/或报头扩展字段中传递给接收方。一个值得注意的例外是NORM_ROBUST_因子，它被假定为给定NORM会话的发送方和接收方之间预设的公共值。下表总结了这些可配置元素：
+--------------------+----------------------------------------------+
| Configurable | Purpose |
| Element | |
+--------------------+----------------------------------------------+
| Sender initial | Sender's initial estimate of greatest group |
| GRTT Estimate | round-trip time. Affects timing of feedback |
| (GRTT_sender) | suppression and sender command transmissions |
| | at sender startup. |
| Backoff Factor | Sender's scaling factor used for timer-based |
| (K_sender) | feedback suppression. |
| Group Size | Sender's rough estimate of receiver group |
| Estimate | size used in generation of random feedback |
| (GSIZE_sender) | backoff timeout. |
| NORM_ROBUST_FACTOR | Integer factor determining how persistently |
| | (i.e., robust) senders transmit repeated |
| | control messages and receivers self-initiate |
| | timeout-based NACKing in the absence of |
| | sender activity. |
| FEC Type | Sender FEC encoding type. |
| ("fec_id") | |
| Sender segment | Maximum size (in bytes) of the payload |
| size | portion of NORM_DATA and other messages. |
| (NormSegmentSize) | |
| NormNodeId | Unique identifiers pre-assigned to all NORM |
| | session participants. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Configurable | Purpose |
| Element | |
+--------------------+----------------------------------------------+
| Sender initial | Sender's initial estimate of greatest group |
| GRTT Estimate | round-trip time. Affects timing of feedback |
| (GRTT_sender) | suppression and sender command transmissions |
| | at sender startup. |
| Backoff Factor | Sender's scaling factor used for timer-based |
| (K_sender) | feedback suppression. |
| Group Size | Sender's rough estimate of receiver group |
| Estimate | size used in generation of random feedback |
| (GSIZE_sender) | backoff timeout. |
| NORM_ROBUST_FACTOR | Integer factor determining how persistently |
| | (i.e., robust) senders transmit repeated |
| | control messages and receivers self-initiate |
| | timeout-based NACKing in the absence of |
| | sender activity. |
| FEC Type | Sender FEC encoding type. |
| ("fec_id") | |
| Sender segment | Maximum size (in bytes) of the payload |
| size | portion of NORM_DATA and other messages. |
| (NormSegmentSize) | |
| NormNodeId | Unique identifiers pre-assigned to all NORM |
| | session participants. |
+--------------------+----------------------------------------------+
The sender-controlled GRTT estimate (referred to as GRTT_sender in this document) is used to set and scale various timers associated with NORM protocol operation. During steady-state operation, the sender probes the receiver set, adapts to the group round-trip timing state, and advertises its estimate to the receiver set in the "grtt" field of relevant NORM protocol messages. However, an initial value must be assumed at sender startup. A large initial estimate is conservative and safer with regard to preventing feedback implosion and starting up congestion control operation, but requires the sender and receivers to allocate more buffering resources for a given transmission rate (i.e., larger effective delay*bandwidth product) to maintain efficient operation. A default initial value of GRTT_sender = 0.5 seconds is RECOMMENDED.
发送方控制的GRTT估计（在本文档中称为GRTT_发送方）用于设置和缩放与NORM协议操作相关的各种计时器。在稳态操作期间，发送方探测接收机集，适应组往返定时状态，并在相关NORM协议消息的“grtt”字段中向接收机集公布其估计。但是，在发送方启动时必须假定初始值。就防止反馈内爆和启动拥塞控制操作而言，较大的初始估计是保守和安全的，但要求发送方和接收方为给定传输速率（即，较大的有效延迟*带宽积）分配更多的缓冲资源以维持有效操作。建议使用默认初始值GRTT_sender=0.5秒。
The sender-controlled Backoff Factor (referred to a K_sender in this document) is used to scale protocol timers and contributes to the generation of the random backoff timeout value that facilitates timer-based feedback suppression. The sender advertises its configured Backoff Factor to the receiver set in the "backoff" field of applicable NORM messages and thus no receiver configuration is necessary. For ASM operation, a default value of K_sender = 4 is
发送方控制的退避因子（在本文档中称为K_发送方）用于缩放协议计时器，并有助于生成随机退避超时值，以促进基于计时器的反馈抑制。发送方在适用规范消息的“退避”字段中向接收方公布其配置的退避系数，因此无需进行接收方配置。对于ASM操作，默认值为K_sender=4
RECOMMENDED; for SSM operation, a default value of K_sender = 6 is RECOMMENDED.
推荐；对于SSM操作，建议使用默认值K_sender=6。
The sender estimate of session Group Size (referred to as GSIZE_sender in this document) also plays a role in the random selection of feedback suppression timeout values. The sender advertises its configured Group Size estimate to the receiver set in the "gsize" field of applicable NORM messages; thus, no receiver configuration is necessary. Only a rough estimate (i.e., "order-of-magnitude") is needed for effective feedback suppression and a default value of GSIZE_sender = 10,000 is RECOMMENDED as a conservative estimate for most uses.
会话组大小的发送方估计值（在本文档中称为GSIZE_发送方）也在反馈抑制超时值的随机选择中起作用。发送方在适用规范消息的“gsize”字段中向接收方公布其配置的组大小估计；因此，不需要接收器配置。有效的反馈抑制只需要粗略估计（即“数量级”），大多数情况下，建议将默认值GSIZE_sender=10000作为保守估计值。
The NORM_ROBUST_FACTOR is an integer parameter that determines how persistently NORM senders transmit control messages (NORM_CMD messages) such as end-of-transmission flushing, OPTIONAL positive acknowledgment requests, etc. Additionally, the receivers use their knowledge of NORM_ROBUST_FACTOR to determine when to consider a NORM sender inactive and MAY use the factor in determining how persistently to self-initiate repeated NACK repair requests upon such timeouts. This parameter is NOT communicated in NORM protocol message headers and is presumed to be preset to a consistent value among sender and receivers for a given NORM session. A default value of NORM_ROBUST_FACTOR = 20 is RECOMMENDED.
NORM_ROBUST_FACTOR是一个整数参数，用于确定NORM发送方如何持续传输控制消息（NORM_CMD消息），例如传输结束刷新、可选的肯定确认请求等。此外，接收器使用他们的NoalthRooBoStf因子的知识来确定何时考虑规范发送器不活动，并且可以使用该因子来确定如何持续地在这样的超时时发起重复的NACK修复请求。此参数不在NORM协议消息头中进行通信，并假定已预设为给定NORM会话的发送方和接收方之间的一致值。建议使用默认值NORM_ROBUST_FACTOR=20。
Another NORM sender configuration element is the FEC type used to encode NORM_DATA message content. The FEC type is communicated from the sender to the receiver set in the "fec_id" field of relevant NORM message headers. The "fec_id" value corresponds to an IANA-assigned value identifying the FEC encoding type as described in the FEC Building Block [RFC5052] document. Typically, a sender SHOULD use a consistent FEC encoding for its participation in a session to simplify receiver state allocation and maintenance, but its implementations MAY vary the FEC encoding type on a per-object basis if necessary.
另一个NORM sender配置元素是用于编码NORM_数据消息内容的FEC类型。FEC类型从发送方传送到相关NORM消息头的“FEC_id”字段中设置的接收方。“fec_id”值对应于如fec构建块[RFC5052]文档中所述的识别fec编码类型的IANA分配值。通常，发送方应使用一致的FEC编码来参与会话，以简化接收方状态分配和维护，但其实现可能会在必要时根据每个对象改变FEC编码类型。
The sender NormSegmentSize setting determines the maximum size of the payload portion of NORM_DATA and other messages that the sender transmits. Additionally, the payload size of feedback messages from receivers to a given sender is limited to that sender's NormSegmentSize. The NormSegmentSize SHOULD be configured to be compatible with expected network MTU limitations, given the added overhead of NORM, UDP, and IP protocol message headers. Additionally, MTU Discovery MAY be employed by the sender to determine an appropriate NormSegmentSize. The NormSegmentSize for a given sender can be determined by receivers from the FEC Object Transmission Information (FTI) provided either in applied EXT_FTI header extensions or pre-configured session information.
发送方NORMSECTIONSIZE设置确定发送方传输的NORM_数据和其他消息的有效负载部分的最大大小。此外，从接收者到给定发送者的反馈消息的有效负载大小被限制为该发送者的大小。鉴于NORM、UDP和IP协议消息头的额外开销，NormSegmentSize应配置为与预期的网络MTU限制兼容。此外，发送方可以使用MTU发现来确定适当的大小。给定发送方的大小可以由接收方根据应用的EXT_FTI报头扩展或预配置的会话信息中提供的FEC对象传输信息（FTI）来确定。
Although it is not technically a configurable element, the receivers MUST have FEC Object Transmission Information for transmitted NormObjects to properly buffer, decode, and reassemble the original content. For loosely organized NORM protocol sessions, the sender MAY apply the EXT_FTI Header Extension to NORM_DATA and NORM_INFO (if applicable) messages so that receivers can get this information without prior coordination. An implementation MAY also apply the EXT_FTI only to NORM_INFO messages for reduced overhead. Finally, applications MAY also provide the FTI out-of-band prior to sender transmission.
虽然在技术上它不是一个可配置的元素，但是接收器必须具有用于传输对象的FEC对象传输信息，以便正确地缓冲、解码和重新组装原始内容。对于松散组织的NORM协议会话，发送方可以将EXT_FTI报头扩展应用于NORM_数据和NORM_信息（如果适用）消息，以便接收方可以在没有事先协调的情况下获得该信息。为了减少开销，实现还可以仅将EXT_FTI应用于NORM_INFO消息。最后，应用程序还可以在发送器传输之前提供带外FTI。
Each participant in a NORM protocol session MUST be configured with a unique NormNodeId value. The NormNodeId value is used by receivers to identify the sender to which their NACK or other feedback messages are addressed, and senders use the NormNodeId to differentiate receivers for purposes of congestion control and OPTIONAL positive acknowledgment collection. Assignment of unique NormNodeId values can be done via a priori coordination and/or use of a deconfliction mechanism external to the NORM protocol itself. The values of NORM_NODE_NONE = 0x00000000 and NORM_NODE_ANY = 0xffffffff are reserved and MUST NOT be assigned to NORM participants.
NORM协议会话中的每个参与者都必须配置唯一的NormNodeId值。接收方使用NormNodeId值来标识其NACK或其他反馈消息所针对的发送方，而发送方使用NormNodeId来区分接收方，以实现拥塞控制和可选的肯定确认收集。唯一NormNodeId值的分配可以通过先验协调和/或使用NORM协议本身外部的解冲突机制来完成。NORM_NODE_NONE=0x00000000和NORM_NODE_ANY=0xFFFFFF的值是保留的，不能分配给NORM参与者。
The same security considerations that apply to the Multicast NACK [RFC5401], TFMCC [RFC4654], and FEC [RFC5052] Building Blocks also apply to the NORM protocol. In addition to the vulnerabilities to which any IP and IP multicast protocol implementation is subject, malicious hosts might engage in excessive NACKing in an attempt to prevent the NORM sender(s) from making forward progress in reliable transmission. Receiver "join" and "service" policy enforcement as described in Section 5.2 can be applied if such activity is detected. The use of cryptographic peer authentication, integrity checks, and/or confidentiality mechanisms can be used to provide a more effective degree of protection from objectionable transmissions from unauthorized hosts. But in some cases, even with authentication and integrity checks, the NACK-based feedback of NORM can be exploited by replay attacks forcing the NORM sender to unnecessarily transmit repair information. This MAY be addressed in part with network-layer IP security implementations that guard against this potential security exploitation or alternatively with a security mechanism using the EXT_AUTH header extension for similar purposes. Such security mechanisms SHOULD be deployed and used when available. Use of security mechanisms will impose additional "a priori" configuration upon the NORM deployment depending upon the techniques used.
适用于多播NACK[RFC5401]、TFMCC[RFC4654]和FEC[RFC5052]构建块的相同安全注意事项也适用于NORM协议。除了任何IP和IP多播协议实现都会遇到的漏洞外，恶意主机还可能参与过多的NACKing，试图阻止NORM发送方在可靠传输中向前推进。如果检测到此类活动，则可以应用第5.2节所述的接收方“加入”和“服务”策略强制。可以使用加密对等身份验证、完整性检查和/或保密机制来提供更有效的保护，防止来自未经授权主机的不良传输。但在某些情况下，即使使用身份验证和完整性检查，基于NACK的NORM反馈也可能被重放攻击利用，迫使NORM发送方不必要地传输修复信息。这可以部分地通过网络层IP安全实现来解决，网络层IP安全实现可以防止这种潜在的安全漏洞，或者出于类似目的，通过使用EXT_AUTH头扩展的安全机制来解决。应在可用时部署和使用此类安全机制。根据所使用的技术，使用安全机制将在标准部署上施加额外的“先验”配置。
The NORM protocol is compatible with the use of IP security (IPsec)
NORM协议与IP安全（IPsec）的使用兼容
[RFC4301], and the IPsec Encapsulating Security Payload (ESP) protocol or Authentication Header (AH) extension can be used to secure IP packets transmitted by NORM participants. A baseline approach to secure NORM operation using IPsec is described below. Compliant implementations of this specification are REQUIRED to be compatible with IPsec usage as described in Section 7.1. IPsec can be used to provide peer authentication, integrity protection, and/or encryption of packets containing NORM messages.
[RFC4301]和IPsec封装安全有效负载（ESP）协议或身份验证头（AH）扩展可用于保护NORM参与者传输的IP数据包。下面描述了使用IPsec保护NORM操作的基线方法。如第7.1节所述，本规范的兼容实现需要与IPsec使用兼容。IPsec可用于对包含NORM消息的数据包提供对等身份验证、完整性保护和/或加密。
Additionally, the EXT_AUTH header extension (HET = 1) is reserved for use by security mechanisms to provide alternatives to IPsec for the security of NORM messages. The format of this header extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the session description. It is possible an EXT_AUTH implementation MAY also provide for encryption of NORM message payloads as well as peer authentication and integrity protection. The use of this approach as compared to IPsec can allow for header compression techniques to be applied jointly to IP and NORM protocol headers. In cases where security analysis deems encryption of NORM protocol header content to be beneficial or necessary, the aforementioned use of IPsec ESP might be more appropriate. Additionally, the EXT_AUTH header extension can be utilized when NORM is implemented in a network with Network Address Translation (NAT) systems that are incompatible with use of the IPsec AH extension. If EXT_AUTH is present, whatever packet authentication or integrity checks that can be performed immediately upon reception of the packet MUST be performed before accepting the packet and performing any congestion-control-related action on it. Some packet authentication schemes impose a delay of several seconds between when a packet is received and when the packet can be fully authenticated. Any appropriate congestion control related action MUST NOT be postponed by any such packet security mechanism (i.e., security mechanisms MUST NOT result in poor congestion control behavior).
此外，EXT_AUTH头扩展（HET=1）保留供安全机制使用，以便为NORM消息的安全性提供IPsec的替代方案。此标题扩展及其处理的格式不在本文档的范围内，将作为会话描述的一部分在带外传达。EXT_AUTH实现还可能提供NORM消息有效负载的加密以及对等身份验证和完整性保护。与IPsec相比，使用这种方法可以允许将报头压缩技术联合应用于IP和NORM协议报头。在安全分析认为对NORM协议头内容进行加密是有益的或必要的情况下，上述使用IPsec-ESP可能更合适。此外，当NORM在具有与IPsec AH扩展的使用不兼容的网络地址转换（NAT）系统的网络中实现时，可以使用EXT_AUTH头扩展。如果存在EXT_AUTH，则在接收数据包并对其执行任何拥塞控制相关操作之前，必须执行在接收数据包后立即执行的任何数据包身份验证或完整性检查。一些包认证方案在接收到包和包可以完全认证之间施加几秒钟的延迟。任何此类数据包安全机制不得推迟任何与拥塞控制相关的适当行动（即，安全机制不得导致较差的拥塞控制行为）。
Consideration MUST also be given to the potential for replay-attacks that would transplant authenticated packets from one NORM session to another to disrupt service. To avoid this potential, unique keys SHOULD be assigned on a per-session basis or NORM sender nodes SHOULD be configured to use unique "instance_id" identifiers managed as part of the security association for the sessions.
还必须考虑重播攻击的可能性，这种攻击会将经过身份验证的数据包从一个NORM会话移植到另一个NORM会话，从而中断服务。为了避免这种可能性，应在每个会话的基础上分配唯一密钥，或者应将NORM发送方节点配置为使用作为会话安全关联的一部分管理的唯一“实例id”标识符。
Note NORM implementations can use the "sequence" field from the NORM common message header to detect replay attacks. This can be accomplished if the NORM sender maintains state on actively NACKing receivers. A cache of such receiver state can be used to provide protection against NACK replay attacks. NORM receivers MUST also maintain similar state for protection against possible replay of other receiver messages in ASM operation as well. For example, a
注意：NORM实现可以使用NORM公共消息头中的“sequence”字段来检测重播攻击。如果NORM发送方在活跃的NACKing接收方上保持状态，则可以实现这一点。这种接收器状态的缓存可用于针对NACK重播攻击提供保护。NORM接收器还必须保持类似的状态，以防止ASM操作中其他接收器消息的可能重播。例如，一个
receiver could be suppressed from providing NACK or congestion control feedback by replay of certain receiver messages. For these reasons, authentication of NORM messages (e.g., via IPsec) SHOULD be applied for protection against similar attacks that use fabricated messages. Also, encryption of messages to provide confidentiality of application data and protect privacy of users MAY also be applied using IPsec or similar mechanisms.
通过重播某些接收器消息，可以抑制接收器提供NACK或拥塞控制反馈。出于这些原因，应该应用NORM消息的身份验证（例如，通过IPsec）来防止使用伪造消息的类似攻击。此外，还可以使用IPsec或类似机制对消息进行加密，以提供应用程序数据的机密性并保护用户的隐私。
When applicable security measures are used, automated key management mechanisms such as those described in the Group Domain of Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY) [RFC3830], or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] specifications SHOULD be applied.
当使用适用的安全措施时，应采用自动密钥管理机制，如组解释域（GDOI）[RFC3547]、多媒体互联网密钥（MIKEY）[RFC3830]或组安全关联密钥管理协议（GSAKMP）[RFC4535]规范中所述的机制。
While NORM does leverage FEC-based repair for scalability, this alone does not guarantee integrity of received data. Application-level integrity-checking of received data content is highly RECOMMENDED. This recommendation also applies when the IPsec security approach described below is used for added assurance in data content integrity given the shared use of IPsec Security Association information among the group.
虽然NORM确实利用基于FEC的修复来实现可伸缩性，但仅此一点并不能保证所接收数据的完整性。强烈建议对接收到的数据内容进行应用程序级完整性检查。鉴于组间共享使用IPsec安全关联信息，当以下描述的IPsec安全方法用于增加数据内容完整性的保证时，本建议也适用。
This section describes a baseline mode of secure NORM protocol operation based on application of the IPsec security protocol. This approach is documented here to provide a baseline interoperable secure mode of operation. This particular approach represents one possible trade-off in the level of assurance that can be achieved and the scalability of multicast group-size given current IPsec mechanisms and the state required to support them. For example, this baseline approach specifies the use of a Security Association that is shared among the receiver set for feedback messages to the sender. This model requires that the receiver membership receiving the session keys is trusted and only provides protection from attacks that are external to the NORM group membership. More stateful and complex IPsec approaches and key management schemes may be applied for higher levels of assurance, but those are beyond the scope of this transport protocol specification. Additional approaches to NORM security, including other forms of IPsec application, MAY be specified in the future. For example, the use of the EXT_AUTH header extension could enable NORM-specific authentication or security encapsulation headers similar to those of IPsec to be specified and inserted into the NORM protocol message headers. This would allow header compression techniques to be applied to IP and NORM protocol headers when needed in a similar fashion to RTP [RFC3550] and as preserved in the specification for Secure Real Time Protocol (SRTP) [RFC3711].
本节描述了基于IPsec安全协议应用的安全规范协议操作的基线模式。本文记录了此方法，以提供基线互操作的安全操作模式。鉴于当前的IPsec机制和支持这些机制所需的状态，这种特定的方法代表了在可实现的保证级别和多播组大小的可伸缩性方面的一种可能的权衡。例如，此基线方法指定在接收方集合之间共享的安全关联的使用，以向发送方反馈消息。该模型要求接收会话密钥的接收方成员身份是可信的，并且仅提供保护，以防受到规范组成员身份之外的攻击。更多有状态和复杂的IPsec方法和密钥管理方案可用于更高级别的保证，但这些超出了本传输协议规范的范围。将来可能会指定规范安全性的其他方法，包括其他形式的IPsec应用程序。例如，使用EXT_AUTH头扩展可以指定特定于规范的身份验证或安全封装头，类似于IPsec的身份验证或安全封装头，并将其插入到规范协议消息头中。这将允许在需要时以与RTP[RFC3550]类似的方式将报头压缩技术应用于IP和NORM协议报头，并在安全实时协议（SRTP）[RFC3711]规范中保留。
The baseline approach described is applicable to NORM operation configured for SSM (or SSM-like) operation where there is a single sender and the receivers are providing unicast feedback. This form of NORM operation allows for IPsec to be used with a manageable number of security associations (SA).
所描述的基线方法适用于为SSM（或类似于SSM的）操作配置的NORM操作，其中存在单个发送器且接收器提供单播反馈。这种形式的规范操作允许IPsec与可管理数量的安全关联（SA）一起使用。
For NORM one-to-many SSM operation with unicast feedback from receivers, each node SHALL be configured with two transport mode IPsec security associations and corresponding Security Policy Database (SPD) entries. One entry will be used for sender-to-group multicast packet authentication and optionally encryption while the other entry will be used to provide security for the unicast feedback messaging from the receiver(s) to the sender. Note that this single SA for NORM receiver feedback messages is shared to protect traffic from possibly multiple receivers to the single sender.
对于具有来自接收器的单播反馈的标准一对多SSM操作，每个节点应配置两个传输模式IPsec安全关联和相应的安全策略数据库（SPD）条目。一个条目将用于发送方到组的多播数据包认证和可选加密，而另一个条目将用于为从接收方到发送方的单播反馈消息提供安全性。请注意，此NORM接收器反馈消息的单个SA是共享的，以保护可能从多个接收器到单个发送者的通信量。
For each NormSession, the NORM sender SHALL use an IPsec SA configured for ESP protocol [RFC4303] operation with the option for data origin authentication enabled. It is also RECOMMENDED this IPsec ESP SA be also configured to provide confidentiality protection for IP packets containing NORM protocol messages. This is suggested to make the realization of complex replay attacks much more difficult. The encryption key for this SA SHALL be preplaced at the sender and receiver(s) prior to NORM protocol operation. Use of automated key management is RECOMMENDED as a rekey SHALL be REQUIRED prior to expiration of the sequence space for the SA. This is necessary so receivers can use the built-in IPsec replay attack protection possible for an IPsec SA with a single source (the NORM sender). Thus, the receivers SHALL enable replay attack protection for this SA used to secure NORM sender traffic. An IPsec SPD entry MUST be configured to process outbound packets to the session (destination) address and UDP port number of the applicable (NormSession).
对于每个NormSession，NORM发送方应使用为ESP协议[RFC4303]操作配置的IPsec SA，并启用数据源身份验证选项。还建议将此IPsec ESP SA配置为为为包含NORM协议消息的IP数据包提供机密性保护。这使得复杂重放攻击的实现更加困难。此SA的加密密钥应在NORM协议操作之前预先放置在发送方和接收方。建议使用自动密钥管理，因为SA的序列空间到期之前需要重新密钥。这是必要的，以便接收者可以使用内置的IPsec重播攻击保护，该保护可用于具有单个源（NORM发送者）的IPsec SA。因此，接收器应为该SA启用重放攻击保护，该SA用于保护NORM发送者通信。必须将IPsec SPD条目配置为处理到相应会话（目标）地址和UDP端口号的出站数据包（正常会话）。
The NORM receiver(s) MUST be configured with the SA and SPD entry to properly process the IPsec-secured packets from the sender. The NORM receiver(s) SHALL also use a common, second IPsec SA (common Security Parameter Index (SPI) and encryption key) configured for ESP operation with the option for data origination authentication enabled. Similar to the NORM sender, is RECOMMENDED this IPsec ESP SA be also configured to provide confidentiality protection for IP packets containing NORM protocol messages. The receivers MUST have an IPsec SPD entry configured to process outbound NORM/UDP packets directed to the NORM sender source address and port number using this second SA. To support NORM unicast feedback, the sender's transmission port number SHOULD be selected to be distinct from the
NORM接收器必须配置SA和SPD条目，以正确处理来自发送方的IPsec安全数据包。NORM接收器还应使用为ESP操作配置的公共第二IPsec SA（公共安全参数索引（SPI）和加密密钥），并启用数据发起认证选项。与NORM发送器类似，建议还将此IPsec ESP SA配置为为为包含NORM协议消息的IP数据包提供机密性保护。接收器必须配置IPsec SPD条目，以便使用第二个SA处理定向到NORM发送方源地址和端口号的出站NORM/UDP数据包。为了支持标准单播反馈，发送方的传输端口号应选择为不同于标准单播反馈
multicast session port number to allow discrimination between unicast and multicast feedback messages when access to the IP destination address is not possible (e.g., a user-space NORM implementation). For processing of packets from receivers, the NORM sender SHALL be configured with this common, second SA (and the corresponding SPD entry needed) in order to properly process messages from the receiver.
当无法访问IP目标地址时（例如，用户空间规范实现），允许区分单播和多播反馈消息的多播会话端口号。为了处理来自接收方的数据包，NORM发送方应配置此通用第二SA（以及所需的相应SPD条目），以便正确处理来自接收方的消息。
Multiple receivers using a common IPsec SA for traffic directed to the NORM sender (i.e., many-to-one) typically prevents the use of built-in IPsec replay attack protection by the NORM sender with current IPsec implementations. Thus the built-in IPsec replay attack protection for this second SA at the sender MUST be disabled unless the particular IPsec implementation manages its replay protection on a per-source basis (which is not typical of existing IPsec implementations). So, to support a fully secure mode of operation, the NORM sender implementation MUST provide replay attack protection based upon the "sequence" field of NORM protocol messages from receivers. This can be accomplished with a high assurance of security, even with the limited size (16-bits) of this field, because:
对于定向到NORM发送方（即多对一）的流量，多个接收器使用公共IPsec SA通常会阻止NORM发送方在当前IPsec实现中使用内置IPsec重放攻击保护。因此，必须禁用发送方第二个SA的内置IPsec replay攻击保护，除非特定IPsec实现基于每个源管理其replay保护（这不是现有IPsec实现的典型情况）。因此，为了支持完全安全的操作模式，NORM发送方实现必须基于来自接收方的NORM协议消息的“序列”字段提供重播攻击保护。即使该字段的大小（16位）有限，也可以通过高度的安全保证来实现，因为：
1. NORM receiver NACK and non-CLR ACK feedback messages are sparse.
1. NORM接收器NACK和非CLR ACK反馈消息是稀疏的。
2. The more frequent NORM_ACK feedback from CLR or PLR nodes is only a small set of receivers for which the sender needs to keep more persistent replay attack state.
2. 来自CLR或PLR节点的更频繁的NORM_ACK反馈只是一小部分接收器，发送方需要为其保持更持久的重放攻击状态。
3. NORM_NACK feedback messages preceding the sender's current repair window do not significantly impact protocol operation (generation of NORM_CMD(SQUELCH) is limited) and could be in fact ignored. This means the sender can prune any replay attack state that precedes the current repair window.
3. 发送方当前修复窗口之前的NORM_NACK反馈消息不会显著影响协议操作（NORM_CMD（静噪）的生成受到限制），事实上可以忽略。这意味着发送方可以删除当前修复窗口之前的任何重播攻击状态。
4. NORM_ACK messages correspond to either a specific sender "ack_id", the sender "cc_sequence" for ACKs sent in response to NORM_CMD(CC), or the sender's current repair window in the case of ACKs sent in response to NORM_CMD(FLUSH). Thus, the sender can prune any replay attack state for receivers that precede the current applicable sequence or repair window space.
4. NORM_ACK消息对应于特定的发送方“ACK_id”、响应NORM_CMD（cc）发送的ACK的发送方“cc_序列”，或者响应NORM_CMD（FLUSH）发送的ACK的发送方当前修复窗口。因此，发送方可以删减当前适用序列之前接收方的任何重播攻击状态或修复窗口空间。
The use of ESP confidentiality for secure NORM protocol operation makes it more difficult for adversaries to conduct any form of replay attacks. Additionally, a NORM sender implementation with access to the full ESP protocol header could also use the ESP sequence information to make replay attack protection even more robust by maintaining the per-source ESP sequence state that existing IPsec implementations typically do not provide. The design of this
将ESP机密性用于安全规范协议操作使对手更难进行任何形式的重放攻击。此外，可以访问完整ESP协议头的NORM发送方实现还可以使用ESP序列信息，通过保持现有IPsec实现通常不提供的每源ESP序列状态，使重播攻击保护更加健壮。本系统的设计
baseline security approach for NORM intentionally places any more complex processing state or processing (e.g., replay attack protection given multiple receivers) at the NORM sender since NORM receiver implementations might often need to be less complex.
NORM的基线安全方法有意将任何更复杂的处理状态或处理（例如，给定多个接收器的重放攻击保护）置于NORM发送方，因为NORM接收器实现可能通常需要不那么复杂。
This baseline approach can be used for NORM protocol sessions with multiple senders if the SA pairs described are established for each sender. For small-sized groups, it is even possible many-to-many (ASM) IPsec configuration could be achieved where each participant uses a unique SA (with a unique SPI). In this case, the sender(s) would maintain an SA for each other participant rather than a single, shared SA for receiver feedback messages. This does not scale to larger group sizes given the complex set of SA and SPD entries each participant would need to maintain.
如果为每个发送方建立了描述的SA对，则此基线方法可用于具有多个发送方的NORM协议会话。对于小型组，甚至可以实现多对多（ASM）IPsec配置，其中每个参与者使用唯一的SA（具有唯一的SPI）。在这种情况下，发送方将为每个其他参与者维护SA，而不是为接收方反馈消息维护单个共享SA。考虑到每个参与者需要维护的SA和SPD条目的复杂集合，这无法扩展到更大的群体规模。
It is anticipated in early deployments of this baseline approach to NORM security that key management will be conducted out-of-band with respect to NORM protocol operation. In the case of one-to-many NORM operation, it is possible receivers will retrieve keying information from a central server as needed or otherwise conduct group key updates with a similar centralized approach. Alternatively, it is possible with some key management schemes for rekey messages to be transmitted to the group as a message or transport object within the NORM reliable transfer session. Similarly, for group-wise communication sessions, it is possible for potential group participants to request keying and/or rekeying as part of NORM communications. Additional specification is necessary to define an in-band key management scheme for NORM sessions perhaps using the mechanisms of the automated group key management specifications cited in this document. Additional specification outside of the scope of this document would be needed to provide an interoperable approach for key management in-band of a NORM reliable transport session.
在NORM安全性基线方法的早期部署中，预计密钥管理将在NORM协议操作的带外进行。在一对多标准操作的情况下，接收机可能会根据需要从中央服务器检索密钥信息，或者以类似的集中式方法执行组密钥更新。或者，可以使用一些密钥管理方案，在NORM可靠传输会话中，将重新密钥消息作为消息或传输对象发送到组。类似地，对于分组通信会话，潜在的分组参与者可以请求键入和/或重新键入，作为正常通信的一部分。可能需要使用本文档中引用的自动组密钥管理规范的机制来定义NORM会话的带内密钥管理方案。需要本文档范围之外的附加规范，以便为规范可靠传输会话中的密钥管理提供可互操作的方法。
In order to implement this secure mode of NORM protocol operation, the following IPsec capabilities are REQUIRED.
为了实现这种安全模式的NORM协议操作，需要以下IPsec功能。
The implementation MUST be able to use the source address, destination address, protocol (UDP), and UDP port numbers as selectors in the SPD.
实现必须能够使用源地址、目标地址、协议（UDP）和UDP端口号作为SPD中的选择器。
IPsec in transport mode MUST be supported. The use of IPsec [RFC4301] processing for secure NORM traffic MUST be configured such
必须支持传输模式下的IPsec。必须将IPsec[RFC4301]处理用于安全规范通信的配置为
that unauthenticated packets are not received by the NORM protocol implementation.
NORM协议实现不会接收未经验证的数据包。
An automated key management scheme for group key distribution and rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] is RECOMMENDED for use. Note it is possible for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be included as part of the NORM application reliable data transmission if appropriate interfaces are available between the NORM application and the key management daemon. Relatively short-lived NORM sessions MAY be able to use Manual Keying with a single, preplaced key, particularly if Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec implementation used. When manual keys are used, it is important that cryptographic algorithms suitable for manual key use are selected.
建议使用GDOI[RFC3547]、GSAKMP[RFC4535]或MIKEY[RFC3830]等用于组密钥分发和密钥更新的自动密钥管理方案。注：如果NORM应用程序和密钥管理守护程序之间有适当的接口，则密钥更新消息（例如，GDOI GROUPKEY-PUSH消息）可以作为NORM应用程序可靠数据传输的一部分包括在内。寿命相对较短的NORM会话可能能够使用带有单个预放置密钥的手动密钥，特别是在使用的IPsec实现中提供了扩展序列编号（ESN）[RFC4303]的情况下。使用手动密钥时，选择适合手动密钥使用的加密算法非常重要。
Receivers MUST accept protocol messages only from the designated, authorized sender(s). Appropriate key management will provide authentication, integrity and/or encryption keys only to receivers authorized to participate in a designated session. The approach outlined here allows receiver sets to be controlled on a per-sender basis.
接收者必须只接受来自指定、授权发送者的协议消息。适当的密钥管理将仅向授权参与指定会话的接收者提供身份验证、完整性和/或加密密钥。这里概述的方法允许在每个发送方的基础上控制接收方集。
Large NORM group sizes will necessitate some form of key management that does rely upon shared secrets. The GDOI and GSAKMP protocols mentioned here allow for certificate-based authentication. It is RECOMMENDED these certificates use IP addresses for authentication.
大的标准组大小需要某种形式的密钥管理，这种管理依赖于共享机密。这里提到的GDOI和GSAKMP协议允许基于证书的身份验证。建议这些证书使用IP地址进行身份验证。
The IPsec requirements profile outlined here is commonly available on many potential NORM hosts. Configuration and operation of IPsec typically requires privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to affect system IPsec configuration.
此处概述的IPsec需求概要文件通常可在许多潜在的NORM主机上使用。IPsec的配置和操作通常需要特权用户授权。自动密钥管理实现通常配置有影响系统IPsec配置所需的特权。
Values of NORM Header Extension Types, Stream Control Codes, and NORM_CMD message sub-types are subject to IANA registration. They are in the registry named "Reliable Multicast Transport (RMT) NORM Protocol Parameters" available from http://www.iana.org.
NORM头扩展类型、流控制代码和NORM_CMD消息子类型的值受IANA注册的约束。它们位于名为“可靠多播传输（RMT）规范协议参数”的注册表中，可从http://www.iana.org.
Note the reliable multicast building block components used by this specification also have their respective IANA considerations, and those documents SHOULD be consulted accordingly. 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 RFC 5052. It is possible additional extensions of the NORM protocol might be specified in the future (e.g., additional NORM message types) and additional registries be established at that time with appropriate IETF standards action.
注：本规范使用的可靠多播构建块组件也有各自的IANA注意事项，应相应地查阅这些文件。特别是，NORM使用的FEC构建块确实需要对所使用的FEC编解码器进行IANA注册。RFC 5052中提供了FEC编解码器的注册说明。将来可能会指定NORM协议的其他扩展（例如，其他NORM消息类型），并在当时通过适当的IETF标准行动建立额外的注册表。
This document introduces three registries for the NORM Header Extension Types, Stream Control Codes, and NORM_CMD Message sub-types. This section describes explicit IANA assignment guidelines for each of these.
本文介绍了NORM头扩展类型、流控制代码和NORM_CMD消息子类型的三个注册表。本节描述了每一项的明确IANA分配指南。
This document defines a registry for NORM Header Extensions named "NORM Header Extension Types".
本文档定义了一个名为“NORM Header Extension Types”的NORM Header扩展注册表。
The NORM Header Extension Type field is an 8-bit value. The values of this field identify extended header content allowing the protocol functionality to be expanded to include additional features and operating modes. The values that can be assigned within the "NORM Header Extensions" registry are numeric indexes in the range {0, 255}, boundaries included. Values in the range {0,127} indicate variable-length extended header fields while values in the range {128,255} indicate extensions of a fixed 4-byte length. This specification registers the following NORM Header Extension Types:
NORM Header扩展类型字段是一个8位值。此字段的值标识扩展标头内容，允许扩展协议功能以包括其他功能和操作模式。可以在“NORM Header Extensions”注册表中分配的值是{0，255}范围内的数值索引，包括边界。范围{0127}中的值表示可变长度扩展头字段，{128255}中的值表示固定4字节长度的扩展。本规范注册了以下规范标头扩展类型：
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 1 | EXT_AUTH | This specification |
| 3 | EXT_CC | This specification |
| 64 | EXT_FTI | This specification |
| 128 | EXT_RATE | This specification |
+-------+----------+--------------------+
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 1 | EXT_AUTH | This specification |
| 3 | EXT_CC | This specification |
| 64 | EXT_FTI | This specification |
| 128 | EXT_RATE | This specification |
+-------+----------+--------------------+
Requests for assignment of additional NORM Header Extension Type values are granted on a "Specification Required" basis as defined by IANA Guidelines [RFC5226]. Any such header extension specifications MUST include a description of protocol actions to be taken when the extension type is encountered by a protocol implementation not supporting that specific option. For example, it is often possible for protocol implementations to ignore unknown header extensions.
根据IANA指南[RFC5226]的定义，在“所需规范”的基础上批准分配额外规范标头扩展类型值的请求。任何此类头扩展规范都必须包括当不支持该特定选项的协议实现遇到扩展类型时要采取的协议操作的描述。例如，协议实现常常可以忽略未知的头扩展。
This document defines a registry for NORM Stream Control Codes named "NORM Stream Control Codes".
本文件定义了名为“NORM流控制代码”的NORM流控制代码注册表。
NORM Stream Control Codes are 16-bit values that can be inserted within a NORM_OBJECT_STREAM delivery object to convey sequenced, out-of-band (with respect to the stream data) control signaling applicable to the referenced stream object. These control codes are to be delivered to the application or protocol implementation with reliable delivery, in-order with respect to the their inserted position within the stream. This specification registers the following NORM Stream Control Code:
NORM流控制码是16位值，可插入NORM_对象_流交付对象内，以传送适用于所引用流对象的顺序带外（关于流数据）控制信令。这些控制代码将以可靠的方式交付给应用程序或协议实现，以便在流中插入它们的位置。本规范注册了以下规范流控制代码：
+-------+-----------------+--------------------+
| Value | Name | Reference |
+-------+-----------------+--------------------+
| 0 | NORM_STREAM_END | This specification |
+-------+-----------------+--------------------+
+-------+-----------------+--------------------+
| Value | Name | Reference |
+-------+-----------------+--------------------+
| 0 | NORM_STREAM_END | This specification |
+-------+-----------------+--------------------+
Additional NORM Stream Control Code value assignment requests are granted on a "Specification Required" basis as defined by IANA Guidelines [RFC5226]. The full 16-bit space outside of the value assigned in this specification are available for future assignment. In addition to describing the control code's expected interpretation, such specifications MUST include a description of protocol actions to be taken when the control code is encountered by a protocol implementation not supporting that specific option.
根据IANA指南[RFC5226]定义的“所需规范”基础，批准额外的规范流控制代码值分配请求。本规范中指定值之外的完整16位空间可用于将来的指定。除了描述控制代码的预期解释外，此类规范还必须包括当不支持该特定选项的协议实现遇到控制代码时将采取的协议操作的描述。
This document defines a registry for NORM_CMD message sub-types named "NORM Command Message Sub-types".
本文档定义了名为“NORM命令消息子类型”的NORM_CMD消息子类型的注册表。
The NORM_CMD message "sub-type" field is an 8-bit value with valid values in the range of 1-255. Note the value 0 is reserved to indicate an invalid NORM_CMD message sub-type. The current specification defines a number of NORM_CMD message sub-types senders can use to signal the receivers in various aspects of NORM protocol operation. This specification registers the following NORM_CMD Message Sub-types:
NORM_CMD message“sub type”字段是一个8位值，有效值范围为1-255。注意：保留值0表示NORM_CMD消息子类型无效。当前规范定义了许多NORM_CMD消息子类型，发送方可以使用这些子类型在NORM协议操作的各个方面向接收方发送信号。本规范注册了以下NORM_CMD消息子类型：
+-------+-----------------------+--------------------+
| Value | Name | Reference |
+-------+-----------------------+--------------------+
| 0 | reserved | This specification |
| 1 | NORM_CMD(FLUSH) | This specification |
| 2 | NORM_CMD(EOT) | This specification |
| 3 | NORM_CMD(SQUELCH) | This specification |
| 4 | NORM_CMD(CC) | This specification |
| 5 | NORM_CMD(REPAIR_ADV) | This specification |
| 6 | NORM_CMD(ACK_REQ) | This specification |
| 7 | NORM_CMD(APPLICATION) | This specification |
+-------+-----------------------+--------------------+
+-------+-----------------------+--------------------+
| Value | Name | Reference |
+-------+-----------------------+--------------------+
| 0 | reserved | This specification |
| 1 | NORM_CMD(FLUSH) | This specification |
| 2 | NORM_CMD(EOT) | This specification |
| 3 | NORM_CMD(SQUELCH) | This specification |
| 4 | NORM_CMD(CC) | This specification |
| 5 | NORM_CMD(REPAIR_ADV) | This specification |
| 6 | NORM_CMD(ACK_REQ) | This specification |
| 7 | NORM_CMD(APPLICATION) | This specification |
+-------+-----------------------+--------------------+
Future specifications extending NORM MAY define additional NORM_CMD messages to enhance protocol functionality. NORM_CMD message sub-type value assignment requests are granted on a "Specification Required" basis as defined by IANA Guidelines [RFC5226]. In addition to describing the command sub-type's expected interpretation, specifications MUST include a description of protocol actions to be taken when the command is encountered by a protocol implementation not supporting that specific option.
扩展NORM的未来规范可能会定义额外的NORM\u CMD消息，以增强协议功能。NORM_CMD消息子类型值分配请求是根据IANA指南[RFC5226]定义的“所需规范”授予的。除了描述命令子类型的预期解释外，规范还必须包括当不支持该特定选项的协议实现遇到命令时要采取的协议操作的描述。
This specification already defines an "application-defined" NORM_CMD message sub-type for use at the discretion of individual applications using NORM for transport. These "application-defined" commands are suitable for many application-specific purposes and do not involve standards action. In any case, such additional messages SHALL be subject to the same congestion control constraints as the existing NORM sender message set.
本规范已经定义了一个“应用程序定义的”NORM_CMD消息子类型，供使用NORM进行传输的各个应用程序自行决定使用。这些“应用程序定义”命令适用于许多特定于应用程序的用途，不涉及标准操作。在任何情况下，此类附加消息应受到与现有规范发送方消息集相同的拥塞控制约束。
The present NORM protocol is seen as a 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 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.
目前的NORM协议被认为是通过通用IP多播服务进行可靠数据传输的有用工具。作者无意建议它适用于支持所有预想的多播可靠性需求。NORM为多播应用程序提供了一个简单而灵活的框架，在一定程度上考虑了网络流量内爆和协议开销效率。类似规范的协议已在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 out-of-order delivery. Hybrid proactive/reactive
此外，该框架方法还具有一些设计特点，使其在非对称和无线互联网应用中具有大容量传输的吸引力。NORM能够独立于网络结构并在高数据包丢失、延迟和无序交付的环境中成功运行。混合主动/被动
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 is 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., direct broadcast satellite (DBS) or cable and public-switched telephone network (PSTN) hybrids, etc.) and efficient, reliable bulk data transfer will be an important capability for servicing large groups of subscribed receivers.
在某些多播场景中，基于FEC的修复可以提高协议性能。在非对称网络中，仅发送方的修复方法通常具有额外的工程意义。NORM的单播反馈功能适用于非对称网络或仅存在单向多播路由/交付服务的网络。支持多播传输的非对称架构可能构成未来互联网结构的重要组成部分（例如，直播卫星（DBS）或有线和公共交换电话网（PSTN）混合网络等），并且效率高，可靠的批量数据传输将是为大量订阅的接收器提供服务的重要能力。
This section lists the changes between the Experimental version of this specification, RFC 3940, and this version:
本节列出了本规范实验版本RFC 3940与本版本之间的变化：
1. Removal of the NORM_FLAG_MSG_START for NORM_OBJECT_STREAM, replacing it with the "payload_msg_start" field in the FEC-encoded preamble of the NORM_OBJECT_STREAM NORM_DATA payload.
1. 删除NORM_对象_流的NORM_标志_MSG_START，将其替换为NORM_对象_流NORM_数据有效载荷的FEC编码前导中的“payload_MSG_START”字段。
2. Definition of IANA registry for header extension and other assignments.
2. 标题扩展和其他分配的IANA注册表定义。
3. Removal of file blocking scheme description now specified in the FEC Building Block document [RFC5052].
3. 删除FEC构建块文档[RFC5052]中现在指定的文件阻止方案说明。
4. Removal of restriction of NORM receiver feedback message rate to local NORM sender rate (this caused congestion control failures in high speed operation. The extremely low feedback rate of the NORM protocol as compared to TCP avoids any resultant impact to the network as shown in [Mdpcc].)
4. 取消了NORM接收方反馈消息速率对本地NORM发送方速率的限制（这导致了高速运行中的拥塞控制失败。NORM协议与TCP相比的极低反馈速率避免了[Mdpcc]中所示的对网络的任何影响。）
5. Correction of errors in some message format descriptions.
5. 更正某些消息格式说明中的错误。
6. Correction of inconsistency in specification of the inactivity timeout.
6. 更正不活动超时规范中的不一致性。
7. Addition of IPsec secure mode description with IPsec requirements.
7. 添加IPsec安全模式描述和IPsec要求。
8. Addition of the EXT_AUTH header extension definition.
8. 添加EXT_AUTH头扩展定义。
9. Clarification of interpretation of "Source Block Length" when FEC codes are arbitrarily shortened by the sender.
9. 当FEC码被发送方任意缩短时，澄清对“源块长度”的解释。
(and these are not Negative)
（这些都不是负面的）
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对本文件的早期投入。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654]Widmer，J.和M.Handley，“TCP友好多播拥塞控制（TFMCC）：协议规范”，RFC 4654，2006年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Multicast Negative-Acknowledgment (NACK) Building Blocks", RFC 5401, November 2008.
[RFC5401]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“多播否定确认（NACK）构建块”，RFC 5401，2008年11月。
[FecHybrid] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOMM, 1998.
[FecHybrid]Gossink，D.和J.Macker，“具有信道估计的可靠多播和集成奇偶重传”，IEEE GlobeCom，1998年。
[McastFeedback] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", IEEE INFOCOM, p. 964, March/April 1998.
[McastFeedback]Nonnenmacher，J.和E.Biersack，“最佳多播反馈”，IEEE INFOCOM，p。1998年3月/4月，第964页。
[MdpToolkit] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol (MDP) Toolkit", Proc. IEEE MILCOM, October 1999.
[MdpToolkit]Macker，J.和B.Adamson，“多播传播协议（MDP）工具包”，Proc。IEEE MILCOM，1999年10月。
[Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism for NACK-Oriented Reliable Multicast Congestion Control", Proc. IEEE GLOBECOMM, November 2001.
[Mdpcc]Adamson，B.和J.Macker，“面向NACK的可靠组播拥塞控制的TCP友好、基于速率的机制”，Proc。IEEE GlobeCom，2001年11月。
[NormFeedback] Adamson, B. and J. Macker, "Quantitative Prediction of NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE MILCOM, October 2002.
[NormFeedback]Adamson，B.和J.Macker，“面向NACK的可靠多播（NORM）反馈的定量预测”，IEEE MILCOM，2002年10月。
[PgmccPaper] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", ACM SIGCOMM, August 2000.
[PgmccPaper]Rizzo，L.，“pgmcc：一种TCP友好的单速率多播拥塞控制方案”，ACM SIGCOMM，2000年8月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3048] 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.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）协议”，RFC 39402004年11月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445]Watson，M.，“基本前向纠错（FEC）方案”，RFC 54452009年3月。
[RmComparison] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", Proc. INFOCOMM, San Francisco CA, October 1993.
[RmComparison]Pingali，S.，Towsley，D.，和J.Kurose，“发送方发起和接收方发起的可靠多播协议的比较”，Proc。资讯科技，旧金山CA，1993年10月。
[TcpModel] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", ACM SIGCOMM, 1998.
[TcpModel]Padhye，J.，Firoiu，V.，Towsley，D.，和J.Kurose，“TCP吞吐量建模：一个简单模型及其实证验证”，ACM SIGCOMM，1998年。
[TfmccPaper] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", ACM SIGCOMM, August 2001.
[TfMcPaper]Widmer，J.和M.Handley，“将基于方程的拥塞控制扩展到多播应用”，ACM SIGCOMM，2001年8月。
Authors' Addresses
作者地址
Brian Adamson Naval Research Laboratory Washington, DC 20375 USA
布莱恩·亚当森海军研究实验室，华盛顿特区，美国20375
EMail: adamson@itd.nrl.navy.mil
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
EMail: cabo@tzi.org
EMail: cabo@tzi.org
Mark Handley University College London Gower Street London WC1E 6BT UK
马克·汉德利大学学院伦敦高尔街伦敦WC1E 6BT英国
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375 USA
乔·麦克尔海军研究实验室，华盛顿特区，美国20375
EMail: macker@itd.nrl.navy.mil
EMail: macker@itd.nrl.navy.mil