[要約] RFC 5740は、NACK指向の信頼性のあるマルチキャスト（NORM）トランスポートプロトコルに関するものであり、NORMプロトコルの目的は、信頼性のあるマルチキャスト通信を実現することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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マルチキャストネットワークを介して1つ以上の送信者から受信機のグループに信頼できるデータの輸送を提供できます。NORMの主要な設計目標は、効率的でスケーラブルで堅牢なバルクデータ（たとえば、コンピューターファイル、永続的なデータの送信）転送を提供することです。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.
このメモには、信頼できるマルチキャストトランスポートおよびアプリケーションプロトコル[RFC2357]を評価するためのIETF基準の基準に従って、信頼できるマルチキャストトランスポートプロトコルを完全に指定するために必要な定義が含まれています。このドキュメントで説明されている規範の仕様は、以前に実験カテゴリ[RFC3940]で公開されていました。RMTワーキンググループの指示された意図は、この仕様をIETF提案された基準としてやってきたとして再提出することでした。したがって、この提案された標準仕様はRFC 3940に基づいており、RFC 3940の公開以来、累積経験とプロトコルの成長の増加に応じて更新されています。RFC 3940とこのドキュメントの違いは、セクション10にリストされています。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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）は、事前に決定されたアドレスとホストポート番号を使用して、ネットワーク上のConnectionLess（例：Internet Protocol（IP）またはUser Datagram Protocol（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は、3種類のバルクデータコンテンツオブジェクト（Normobjects）を確実に輸送することを提供します。これらのタイプは次のとおりです。
1. static computer memory data content (NORM_OBJECT_DATA type),
1. 静的コンピューターメモリデータコンテンツ（norm_object_dataタイプ）、
2. computer storage files (NORM_OBJECT_FILE type), and
2. コンピューターストレージファイル（norm_object_fileタイプ）、および
3. non-finite streams of continuous data content (NORM_OBJECT_STREAM type).
3. 連続データコンテンツの非フィニットストリーム（norm_object_streamタイプ）。
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 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_dataとnorm_object_fileの区別は、受信したコンテンツ（メモリまたはファイルストレージ）に割り当てるためのストレージの種類について、複数のタイプのコンテンツを提供するNormsessionsのレシーバーにヒントを提供することです。その区別以外に、2つは同一であり、有限の（ただし非常に大きな）コンテンツの信頼できる輸送を提供します。これらの静的データとファイルサービスは、大量の静的データを確実に送信する機能を備えたマルチキャストベースのキャッシュアプリケーションに役立つと予想されます。他のタイプの静的データ/ファイル配信サービスは、これらのトランスポートオブジェクトタイプを利用する可能性があります。norm_object_streamタイプの使用は、アプリケーションの裁量であり、静的データまたはファイルコンテンツを運ぶために使用できます。Norm Reliable Streamサービスは、シリアル化された信頼できるメッセージングや、おそらく動的に生成されたその他の無制限のコンテンツなどの追加の可能性を開きます。NORM_OBJECT_STREAMは、送信制御プロトコル（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_INFOメッセージとして送信）を、送信者が送信するデータコンテンツオブジェクトに添付されます。この容易に利用可能なバンド外データにより、マルチキャストレシーバーは、送信される対応するデータ、ファイル、またはストリームのバルクコンテンツの性質を迅速かつ効率的に決定できます。これにより、現在の輸送アクティビティへのレシーバーノードの参加をアプリケーションレベルの制御が可能になります。また、これにより、送信者と受信機の間の最小限の事前調整でプロトコルを柔軟にすることができます。norm_infoコンテンツは、そのサイズが単一のノルムメッセージのペイロード部分に適合する必要があるという点でアトミックです。
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 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.
Normは、メッセージヘッダー内のデータコンテンツのグローバルまたはアプリケーションレベルの識別を提供していません。注Norm_Infoの帯域外データメカニズムは、必要に応じてこの目的のためにアプリケーションによって活用できます。または、識別をデータコンテンツに埋め込むことができます。Normは、送信者が指定されたオブジェクトを送信および/または修復している間にのみ適用可能な輸送識別子を使用して、送信コンテンツ（Normobjects）を識別します。これらのトランスポートデータコンテンツ識別子（NormTransportids）は、規範の過程で各NORM送信者によって単調に増加するファッションで割り当てられます。NORMプロトコルセッションの送信者を含む参加者は、一意の識別子（normnodeids）でも識別されます。各送信者は、NormTransportIDの割り当てを独立して維持するため、セッションとユニークの送信者識別子（Normnodeid）と割り当てられたNormTransportidの連結により、輸送中に個々のNormobjectsを一意に識別できます。NormTransportidsは、順序を増やして大規模であるが固定された数値空間から割り当てられ、長命のセッション中に再割り当てされます。NORMプロトコルはメカニズムを提供するため、送信者アプリケーションはデータコンテンツの送信を終了し、これのグループに効率的な方法で通知できます。他の類似のプロトコル制御メカニズム（セッション終了、受信機同期など）が指定されているため、信頼性の高いマルチキャストアプリケーションバリアントは、目標を達成するために異なる完全なバルク転送通信モデルを実現できます。
To summarize, the NORM protocol provides reliable transport of different types of data content (including potentially mixed types). The senders enqueue and transmit bulk content in the form of static data or files and/or non-finite, ongoing stream types. NORM senders provide for repair transmission of data and/or FEC content in response to NACK messages received from the receiver group. Mechanisms for out-of-band information and other transport control mechanisms are specified for use by applications to form complete reliable multicast solutions for different purposes.
要約すると、NORMプロトコルは、さまざまな種類のデータコンテンツ（潜在的に混合タイプを含む）の信頼できる輸送を提供します。送信者は、静的データまたはファイル、および/または非フィニットの継続的なストリームタイプの形式でバルクコンテンツをエンキューおよび送信します。NORM送信者は、受信機グループから受信したNACKメッセージに応じて、データおよび/またはFECコンテンツの修理を提供します。バンド外情報およびその他の輸送制御メカニズムのメカニズムは、アプリケーションで使用するために指定されており、さまざまな目的で完全に信頼できるマルチキャストソリューションを形成します。
Group communication scalability requirements lead to adaptation of 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]。FECベースの修理を使用して、信頼できるマルチキャスト修理要求の量を大幅に削減し、NACK指向のプロトコルで送信[MDPTOOLKIT]を修理できます。NORMスケーラビリティの主要な要因は、信頼性と混雑制御を促進するために受信機セットによって生成されるフィードバックトラフィックの量です。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 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プロトコルは、数万の受信機の順序でグループサイズを容易に拡張します。このタイプのプロトコルのフィードバックの量の研究は、[NormFeedback]で説明されています。Normは、比較的多数の受信機であっても、単一のTCP接続よりも少量のフィードバックで動作することができます。したがって、ネットワークトポロジに応じて、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).
NORMプロトコルは、基本的なIPマルチキャストグループ管理、ルーティング、および転送サービスを超えて中間システムからの支援を受けずに、エンドツーエンドの方法で動作することができます。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と互換性があります。さらに、NATデバイスがIPマルチキャストをサポートしている場合、NATはネットワークアドレス変換（NAT）を使用するネットワークで使用できます。
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).
規範は、送信者および/または受信者として機能する参加者（ノルムノード）で構成されています。NORM送信者は、Normobjectsの形式でデータコンテンツをセッションの宛先アドレスに送信し、Norm Receiverは、否定的な確認を使用して修理を要求するために送信されたコンテンツを確実に受信しようとします。ノルムセッション内の各ノルムノードには、事前に選択された一意の32ビット識別子（normnodeid）があると想定されています。ノルムノードには、単一の標準内に一意に割り当てられた識別子が必要であり、複数の可能な送信者を区別し、フィードバック情報を異なる受信機と区別する必要があります。予約された2つのNormNodeID値があります。0x00000000の値は無効なnormnodeid（norm_node_none）と見なされ、0xffffffffの値は「ワイルドカード」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は、3つの異なる基本タイプのデータコンテンツを信頼できる送信を可能にします。最初のタイプはnorm_object_dataです。これは、送信者のアプリケーションメモリストレージで維持されるデータコンテンツの静的で永続的なブロックに使用されます。2番目のタイプはnorm_object_fileです。これは、送信者の不揮発性ファイルシステムに保存されているデータに対応します。norm_object_dataおよびnorm_object_fileタイプは、どちらも有限であるが潜在的に非常に大きなサイズのnormobjectを表します。データコンテンツの3番目のタイプはnorm_object_streamで、未定義の長さの継続的な伝送に対応します。これは、ユニキャストデータ輸送のためにTCPが提供する信頼できるストリームサービスに類似しています。ストリームコンテンツの形式はアプリケーション定義であり、「バイト」または「メッセージ」指向にすることができます。Normプロトコルは、配信を促進するか、アプリケーションメッセージの境界を施行するために、ストリームの「フラッシング」を規定しています。NORMプロトコルの実装は、受信アプリケーションへのストリームデータのいずれか（またはその両方）の配信を提供する場合があります。どちらの場合でも、Norm SenderとReceiverの実装は、輸送されるストリームの修理を容易にするためのバッファリングを提供します。
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.
すべてのNormobjectは、送信者による送信用のFECコーディングブロックとシンボルに論理的にセグメント化されています。Normでは、FECエンコードシンボルは、norm_dataメッセージまたは「セグメント」のペイロードに直接対応します。系統的FECコードを使用すると、FECエンコーディングブロックの最初の部分に送信されるnorm_Dataメッセージのペイロードはソースシンボル（元のユーザーデータの実際のセグメント）であり、ブロックの残りの記号は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 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.
送信されたノルモブロックは、一時的に、しかしユニークで、指定された送信者のNormnodeid、NorminstanceID、および一時的なNormTransportidを使用してNormsessionコンテキスト内で識別されます。実装に応じて、個々のNORM送信者は独立してNorminstanceIDを管理することができます。または、セッション内のすべての参加ノード（必要に応じて、セッション識別子として一般的なNorminstanceIDが合意される可能性があります。NORM NORMTRANSPORTIDデータコンテンツ識別子は、Normobjectの実際の輸送中にのみ送信者が割り当てられ、適用可能であり、有効です（つまり、送信者が指定されたNormobjectの送信および修復を提供している限り）。長命のセッションでは、NormTransportidフィールドがラップでき、以前に使用されていた識別子が再利用されます。輸送されたデータコンテンツのグローバルに一意の識別は、NORMによって提供されておらず、必要に応じてNORMアプリケーションによって管理されることが期待されていることに注意してください。Normobjectの個々のセグメントまたはシンボルは、コーディングブロックとシンボル識別子を含む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 Senderは、主に型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エンコードデータコンテンツよりもわずかに低い遅延プロセスで修理および修復できます。norm_infoメッセージは、レシーバーがグループに途中でグループに参加し、送信されている現在のコンテンツに関するコンテキスト情報を確認する必要がある、いくつかのバルク転送、信頼できるマルチキャストアプリケーションの特別な目的を果たすことができます。norm_infoのNACKプロセスについては、後で説明します。norm_infoメッセージタイプが使用される場合、その伝送は、関連するnormobjectのnorm_dataメッセージの送信に先行する必要があります。
The sender also generates messages of type NORM_CMD to assist in 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).
また、送信者は型NORM_CMDのメッセージを生成して、混雑制御、移動の終了フラッシング、グループラウンドトリップ時間（GRTT）推定、受信者同期、およびオプションの肯定的な確認要求またはアプリケーション定義コマンドなどの特定のプロトコル操作を支援します。送信者からのnorm_cmdメッセージの送信は、3つの異なる手順のいずれかによって達成されます。コマンドの繰り返し冗長な送信。そして、積極的に認められたコマンド。特定のコマンドに使用される伝送手法は、コマンドの関数によって異なります。基本的なプロトコル操作のために、いくつかのコアコマンドが定義されています。さらに、実装は、コマンドに利用可能な送信方法を活用できるオプションのアプリケーション定義コマンドの提供を検討することをお勧めします。これにより、基礎となるNORMプロトコルエンジン（ラウンドトリップタイミング、伝送速度など）が利用できる情報を利用できるアプリケーションレベルのセッション管理メカニズムが可能になります。norm_dataメッセージといくつかのnorm_cmdメッセージの送信との顕著な区別は、通常、受信者がnorm_dataメッセージを受信したときに信頼できる受信を管理するためにリソースを割り当てる必要があることです。ただし、一部の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 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レシーバーは、送信者からのデータの送信とコマンドの送信に応じて、型norm_nackまたはnorm_ackのメッセージを生成します。NORM_NACKメッセージは、検出されたデータ送信損失の修復を要求するために生成されます。受信者は通常、送信者からの一連の送信を追跡することにより、損失を検出します。シーケンス情報は、送信されたデータパケットと送信者からの移動終了コマンドに組み込まれています。NORM_ACKメッセージは、送信者によって送信された特定のコマンドに応じて生成されます。一般的な（および最もスケーラブルな）プロトコルモードでは、NORM_ACKメッセージは、送信者からの輻輳制御コマンドに応答してのみ送信されます。これらの混雑制御norm_ackメッセージのフィードバックボリュームは、フィードバックの爆発を避けるために、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]ドキュメントに示されている概念に基づいています。これには、基本的なノルムアーキテクチャと、そのドキュメントで説明されているデータ送信、修理、フィードバック戦略が含まれます。「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」[RFC3048]で説明されているように、信頼できるマルチキャストビルディングブロックアプローチは、完全なNORMプロトコルインスタンスの作成に適用されます。Normはまた、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」[RFC3453]に記載されているように、修理メッセージと追加の伝送の堅牢性のためのパリティベースのエンコーディング技術を利用しています。Normは、FECビルディングブロックドキュメント[RFC5052]で指定されているように、FECペイロードIDを使用します。さらに、輻輳制御のために、このドキュメントは、TCPに優しいマルチキャスト輻輳制御（TFMCC）スキーム[TFMCCPAPE]、[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 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プロトコルは大きな遅延帯域幅トポロジーで最も効率的に実行され、より長いフィードバック抑制バックオフタイムアウトが可能になります。これにより、グループサイズのスケーラビリティが向上します。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:
このドキュメントは、NORMプロトコルの実装を順守する際に必要な次のメッセージタイプとメカニズムを指定します。
+----------------------+--------------------------------------------+
| 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. |
+----------------------+--------------------------------------------+
This document also describes the following message types and associated mechanisms that are OPTIONAL for complying NORM protocol implementations:
このドキュメントでは、NORMプロトコルの実装を順守するためにオプションの次のメッセージタイプと関連するメカニズムについても説明します。
+-----------------------+-------------------------------------------+
| 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. |
+-----------------------+-------------------------------------------+
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.
ノルムメッセージには2つの主要なクラスがあります（セクション2.1を参照）：送信者メッセージと受信者メッセージ。norm_cmd、norm_info、およびnorm_dataメッセージタイプは、データコンテンツの送信者によって生成され、normsession内の受信機によって生成されたnorm_nackおよびnorm_ackメッセージが生成されます。送信者メッセージは、インターネット使用のための輻輳制御によって管理されるものとします。セッション管理またはその他の目的のために、受信者はnorm_cmdメッセージ送信も使用できます。送信者と受信者メッセージを区別するための主な根拠は、通常、受信者が送信者からの信頼できる受信をサポートするためにリソースを割り当てる必要があることです。NORMレシーバーは、アプリケーション定義の目的でNORM_CMDメッセージタイプを使用する場合がありますが、輻輳制御とフィードバックの爆発の問題に対処することをお勧めします。さらに、norm_reportの補助メッセージタイプも実験目的で提供されます。このセクションでは、NORMプロトコルで使用されるメッセージ形式について説明します。これらのメッセージとそのフィールドは、セクション5で与えられたNORMプロトコルの詳細な機能的説明で参照されます。個々のNORMメッセージは、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プロトコルメッセージは、次のように情報フィールドを持つ共通のヘッダーで始まります。
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 Commonメッセージヘッダー形式
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の実装は、独自のバージョン番号が異なるバージョン番号を持つ受信メッセージを無視する必要があります。この数値は、非操作不可能なプロトコルのアップグレードを示して区別することを目的としています。この仕様のNORMバージョン番号は1です。
The message "type" field is a 4-bit value indicating the NORM protocol message type. These types are defined as follows:
メッセージ「タイプ」フィールドは、ノルムプロトコルメッセージタイプを示す4ビット値です。これらのタイプは次のように定義されています。
+------------------+------------------+
| 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」値が指定されたメッセージ「タイプ」の基本値よりも大きい場合に暗示されます。
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ビット値です。「シーケンス」フィールドは、メッセージタイプに応じて、2つの別々の目的を果たします。
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 NORM as part of its reliability procedures. The NORM object and FEC payload identifiers are used to detect missing content for reliable transfer purposes.
1. Norm Sendersは、送信者メッセージの「シーケンス」フィールド（norm_info、norm_data、およびnorm_cmd）を設定する必要があります。これにより、受信者は「シーケンス」値を監視して、混雑制御の目的に使用できるパケット損失の推定値を維持できます（セクション5.5を参照してください。2規範輻輳制御操作の詳細な説明については）。この方法でノーム送信者メッセージをマークするには、単調に増加するシーケンス番号スペースを維持する必要があります。この「シーケンス」数は、信頼性手順の一部としてNORMで明示的に使用されていないことに注意してください。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フィードバックメッセージは、Active Norm Sender（S）のセッションマルチキャストアドレスまたはユニキャストアドレス（ES）に送信されることに注意してください。したがって、ノルムレシーバーがフィードバックメッセージを送信している各宛先アドレスに対して、個別の単調に増加するシーケンス番号スペースを維持する必要があります。
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.
これらの2つの別々の目的では、ここで説明する機能をサポートするために、個別のシーケンススペースのメンテナンスが必要であることに注意してください。また、ノルム受信機の場合、セッションアドレスの代わりにフィードバックメッセージが送信者ユニキャストアドレス（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ビット値です。この値はノルドノード識別子（normnodeid）と呼ばれ、一意のノルムノディドは単一のノルムセッション内で割り当てる必要があります。場合によっては、ホストIPv4アドレスまたはアドレスのハッシュの使用で十分である可能性がありますが、マルチキャストセッション内のノード識別子の割り当ておよび潜在的な衝突解像度のための代替方法論を考慮する必要があります。たとえば、リアルタイムプロトコル（RTP）仕様[RFC3550]で定義されている32ビットの「同期ソース」（SSRC）識別子を管理する手法は、ASMトラフィックモデルが観察されたときにノードノード識別子での使用に適用できます。これまでのNORMプロトコルのほとんどの展開では、NormNodeID割り当てが管理上構成されており、この形式のNormNodeID割り当てはほとんどの目的で推奨されます。NORM SENDER NORMNODEID値は、ASMセッション内で一意でなければならないため、NORMレシーバーのフィードバックが送信者によって適切に反転され、NORM Receiver 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.
ヘッダー拡張機能が適用されると、メッセージタイプのベースヘッダーに従い、ペイロード部分の前にあります。ヘッダー拡張機能には2つの形式があり、どちらも8ビット「HET」（ヘッダー拡張タイプ）フィールドから始まります。1つの形式は、0〜127までの範囲の「HET」値を持つ可変長拡張機能に対して提供されます。もう1つの形式は、128〜255の範囲の「HET」値を持つ固定長（1つの32ビットワード）拡張機能用です。。
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ビット単語の倍数で表されるヘッダー拡張機能全体の長さです。「ヘル」フィールドは、可変長拡張（0〜127の間の「ヘット」）に存在する必要があり、固定長拡張（128〜255の間の「ヘット」）には存在しないでください。
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：ノルム可変長ヘッダー拡張形式
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.
ヘッダー拡張機能の「ヘッダー拡張コンテンツ」部分は、各拡張型タイプに対して定義されています。いくつかのヘッダー拡張機能は、NORMベースラインFECおよび輻輳制御操作のためにこのドキュメント内で定義されています。
NORM sender messages include the NORM_DATA type, the NORM_INFO type, and the NORM_CMD type. NORM_DATA and NORM_INFO messages contain application data content while NORM_CMD messages are used for various protocol control functions.
Norm Senderメッセージには、norm_dataタイプ、norm_infoタイプ、および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_Dataメッセージは、一般に、Norm Sendersによって送信される主要なタイプです。これらのメッセージは、型norm_object_data、norm_object_file、およびnorm_object_streamのタイプのオブジェクトのセグメント化されたデータコンテンツをカプセル化するために使用されます。Norm_Dataメッセージには、元のまたは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* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NORM_DATA Message Format
図4：norm_dataメッセージ形式
*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.
*重要な注意：「payload_len」、「payload_msg_start」、「payload_offset」フィールドは、型norm_object_streamのオブジェクトにのみ存在します。これらのフィールドは、ペイロード全体と同様に、使用されるFECエンコードの対象となります。したがって、系統的FECコードを使用する場合、これらの値はソースシンボルを含むパケットに対してのみ直接解釈できますが、これらのフィールドを解釈する前にFECパリティコンテンツを含むパケットがデコードする必要があります。
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM common message header as described in Section 4.1. The value of the NORM_DATA "type" field is 2. The NORM_DATA base "hdr_len" value is 4 (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.
「バージョン」、「タイプ」、「HDR_LEN」、「シーケンス」、および「SOURCE_ID」フィールドは、セクション4.1で説明されているように、NORM共通メッセージヘッダーを形成します。Norm_Data "Type"フィールドの値は2です。NORM_DATAベース "HDR_LEN"値は4（つまり、4つの32ビット単語）に加えて、「FEC_PAYLOAD_ID」フィールドのサイズです。「FEC_PAYLOAD_ID」フィールドサイズは、「FEC_ID」フィールドで参照されるFECエンコードタイプに依存します。たとえば、系統的コードを使用すると、129の「fec_id」値が示され、「fec_payload_id」のサイズが2つの32ビット単語です。この場合、Norm_Dataベース「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」フィールドには、送信者によって生成された値が含まれており、規範への参加の現在のインスタンスを一意に識別します。これにより、受信者は、送信者がおそらく進行中のセッションに再び去り、再会したときに検出できます。送信者（その「source_id」で識別）が新しい「instance_id」を持つように検出される場合、標準レシーバーは送信者に以前の状態をドロップして、レセプションを新たに開始するか、少なくともこの「インスタンス」を新しい別々のものとして扱う必要があります。送信者。
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_SENDER）の送信者の現在の推定値の非線形量子化された表現が含まれています（これは[TFMCCPAPE]のR_MAXとも呼ばれます）。この値は、このドキュメントに記載されているように、NACK修復プロセスのタイミングとプロトコル操作の他の側面を制御するために使用されます。通常、広告された「GRTT」値は、送信者がグループからのフィードバックに基づいて測定したものに対応しますが、低透過率では、宣伝されている「GRTT」は最大に設定されます（GRTTTTMEASURED、NORMSEGMENTSIZE/SENDERRATE）。送信者のセグメントサイズはバイトで、センデラートは、送信者の現在の伝送速度で1秒あたりのバイトです。このフィールドをエンコードおよびデコードするためのアルゴリズムは、マルチキャスト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.
「バックオフ」フィールド値は、レシーバーが使用して、タイマーベースのNorm NACKフィードバック抑制で使用される最大バックオフタイマー値を決定します。この4ビットフィールドは、GRTT_SENDERによって乗算されて最大バックオフタイムアウトを決定する0〜15の値をサポートします。「バックオフ」フィールドは、受信者に送信者のバックオフファクターパラメーター（k_sender）を通知します。推奨される値とその用途は、セクション5.3のNORM受信機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 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.
「gsize」フィールドには、グループサイズ（gsize_sender）の送信者の現在の推定値の表現が含まれています。この4ビットフィールドは、0または1の最も重要なビット値がそれぞれ1または5のマンティッサを表し、1つによって増加する3つの最も重要なビットをベース10指数を表す値10から5億の値をほぼ表すことができます。大きさの順序）。たとえば、「0x0」のフィールド値は1.0e 01（10）を表し、「0x8」の値は5.0e 01（50）を表し、「0x1」の値は1.0e 02（100）、値は「0xf」は5.0e 08を表します。ノルムフィードバック抑制の目的では、グループサイズを高度な精度で表現する必要はありません。グループサイズは、低レベルのフィードバックトラフィックを維持するために、控えめに（つまり、過大評価されている）と推定される場合があります。NORMプロトコルを使用した汎用信頼性の高いマルチキャストアプリケーションには、デフォルトのグループサイズ推定10,000（「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. |
+----------------------+-------+------------------------------------+
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 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_FLAG_REPAIRは、関連するメッセージが修理伝送の場合に設定されます。この情報は、新たに参加するレシーバーが新しい（非修復）データコンテンツを受け取ったときにのみNACKプロセスに参加し始めることが望まれる場合に、参加ポリシーを観察するためにレシーバーが使用できます。norm_flag_explicitは、データ送信者が修理として「新鮮な」（以前に送信されていなかった）パリティセグメントを提供する能力を使い果たしたときに送信されるメッセージをマークするために使用されます。このフラグは、機能を実装する中間システムで使用される可能性があります。これは、異なる修理ニーズを備えた信頼性の高いマルチキャストトポロジのさまざまな脚に修復コンテンツのサブキャストを制御することができます。norm_flag_infoは、オプションのnorm_infoコンテンツが実際に関連するオブジェクトで実際に使用できる場合にのみ設定されます。したがって、受信機は、特定のオブジェクトで使用可能な場合にのみ、norm_infoの再送信を削減します。NORM_FLAG_UNRELIABLEは、送信者が「最良の努力」配信のみでオブジェクトを送信したい場合に設定され、オブジェクトの修理送信を提供しません。NORM_FLAG_UNRELIABLEフラグでマークされたオブジェクトの修理要求を実行しないでください。これらのオブジェクトのすべてのセグメント（または情報コンテンツ）が受信されない場合、受信機はそのようなオブジェクトの修理を不注意に要求できる場合があります（つまり、「Object_transport_id」シーケンスのギャップが記録されます）。この場合、送信者は、セクション4.2.3で説明されているように、NORM_CMD（Squelch）プロセスを呼び出すものとします。
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_FILEは、関連するオブジェクトを不揮発性ストレージに保存する必要があるという送信者からのヒントとして設定できます。norm_flag_streamは、識別されたオブジェクトが型norm_object_streamのタイプの場合に設定されます。norm_flag_streamの存在は、オブジェクトサイズの解釈とnorm_dataメッセージの形式に関して、norm_flag_fileの存在を無効にします。
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_PAYLOAD_ID」フィールドの形式を意味し、FECオブジェクト伝送情報と組み合わせて、FECエンコードコンテンツをデコードする手順を意味します。小さなブロック、系統的コード（ "FEC_ID" = 129）がほとんどの標準で使用されることが期待されており、norm_object_streamトランスポートの最も効率的なパフォーマンスには系統的FECコードが推奨されます。
The "object_transport_id" field is a monotonically and incrementally increasing value assigned by the sender to NormObjects being transmitted. Transmissions and repair requests related to that object use the same "object_transport_id" value. For sessions of very long or indefinite duration, the "object_transport_id" field 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」フィールドは、送信者が送信されているNormobjectsに割り当てられた単調および漸進的に増加する値です。そのオブジェクトに関連する送信および修理要求は、同じ「object_transport_id」値を使用します。非常に長いまたは無期限のセッションでは、「object_transport_id」フィールドは包み込んで繰り返されますが、16ビットのフィールドサイズは、受信者とソース間のオブジェクトの混乱を避けるための十分なシーケンス空間を提供すると推定されます（すなわち、受信者は再生する必要があります。-SINCRONIZE SENCRONIZEは、特定のソースの現在の状態が保持されていて、オブジェクトシーケンス識別子を十分に範囲外にしている場合に十分に範囲外にします）。NORMセッション内での送信の過程で、オブジェクトは、送信者「source_id」と指定された「object_transport_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) 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ペイロード識別子、「source_block_number」、「source_block_len」、および「encoding_symbol_id」フィールドは、「ソースブロック番号」、「ソースブロック長」、およびFECペイロードID形式の「シンボルID」フィールドに対応しています。FEC基本スキーム[RFC5445]仕様で指定されている「FEC_ID」値129によって識別される小さなブロックの系統的FECスキームの場合。「source_block_number」は、コードブロックの相対位置をnormobjectで識別します。型norm_object_streamタイプのnormobjectsの場合、「source_block_number」は非常に長寿命のセッションにラップすることに注意してください。「source_block_len」は、識別されたコーディングブロックのユーザーデータセグメントの数を示します。ブロックに含まれるアプリケーションデータのシンボルの数の「source_block_len」情報を考えると、受信者は添付セグメントがデータまたはパリティコンテンツであるかどうかを判断し、適切に処理できます。アプリケーションは、保留中の情報コンテンツが予測不可能な場合（リアルタイムメッセージストリームなど）、コードブロックを動的に「短縮」する場合があります。その場合、FECパリティコンテンツを含む「encoding_symbol_id」に与えられた「source_block_len」値は、ソース記号を含むパケットに提供される「source_block_len」値よりも優先されます。また、通常の「encoding_symbol_id」に対して与えられた「source_block_len」値は、以前のエンコード記号に対して与えられた「source_block_len」よりも優先されます。この理由は、送信者がソースシンボルを送信している時点での最大ソースブロック長を把握し、その後コードを「短く」し、その最後のソースシンボルおよび/またはFECパリティコンテンツを含むシンボルをエンコードすることができるからです。「encoding_symbol_id」は、添付のペイロードが添付されているコーディングブロック内の特定のシンボル（セグメント）を識別します。ブロックの「encoding_symbol_id」と関連する「source_block_len」パラメーターの値に応じて、参照されるシンボル（セグメント）はユーザーデータまたはFECパリティセグメントです。体系的なコードの場合、Source_block_lenよりも番号が付けられた数字のエンコードシンボルには元のアプリケーションデータが含まれ、Source_block_lenはブロックに対して計算されたパリティシンボルを含みます。Object_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]で説明されているように）は、ノルムトランスポートオブジェクトを適切に受信およびデコードするために必要です。この情報は、バンド外のセッション情報として提供される場合があります。場合によっては、送信者がこの情報を最小限の事前設定で容易にするためにこの情報を「インバンド」含めることが役立ちます。この目的のために、NORM FECオブジェクトトランスミッション情報ヘッダー拡張機能（EXT_FTI）が定義されています。このヘッダー拡張機能は、norm_dataおよびnorm_infoメッセージに適用して、この必要な情報を提供することができます。ext_ftiの形式は2つの部分で構成されています。これは、関連する輸送オブジェクトのサイズと使用されているFECスキームに依存する部分を含む一般的な部分です。norm_dataおよびnorm_infoメッセージの「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 ... |
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 buffer to the receiver group. In turn, the receivers SHOULD use this information to allocate a stream buffer for reception of corresponding size.
48ビットの「Object_size」フィールドは、norm_object_fileおよびnorm_object_dataの静的オブジェクトタイプのオブジェクトの総長さ（バイト）を示します。この情報は、受信機がストレージ要件を決定したり、受信したオブジェクトにストレージを割り当てるために使用されます。ストレージ機能が不十分なレシーバーは、指定されたオブジェクトの信頼できる受信（つまり、NACKではない）を控えることを望む場合があります。型norm_object_streamタイプのオブジェクトの場合、「object_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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です。Ext_FTIヘッダー拡張のサイズは、他のFECスキームで異なる可能性があります。
The 48-bit "object_size" serves the purpose described previously.
48ビットの「Object_size」は、前述の目的に役立ちます。
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_INSTANCE_ID」は、FECビルディングブロック[RFC5052]ドキュメントで説明されている「FECインスタンスID」に対応しています。この場合、「FEC_INSTANCE_ID」は、使用されている特定のタイプの小さなブロック系統コードに対応する値です（例：Reed-Solomon GF（2^8）、Reed-Solomon GF（2^16）など）。FECインスタンスID値の標準化された割り当ては、RFC 5052で説明されています。
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 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_NUM_PARITY」は、FECビルディングブロック[RFC5052]ドキュメントに記載されている小さなブロック系統的コードのFECオブジェクト伝送情報に記載されているように、「任意のソースブロックで生成できるエンコード記号の最大数」に対応します。たとえば、リードソロモンコードを任意に短縮して、特定のブロック長の異なるコードバリエーションを作成できます。Reed-Solomon（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_Dataメッセージのペイロード部分には、ソースデータまたはFECエンコードされたアプリケーションコンテンツが含まれます。このペイロードの内容は、採用されているFECスキームと、該当する場合はnorm_object_streamタイプを使用したストリーミングのサポートに依存します。
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.
「payload_len」、「payload_msg_start」、および「payload_offset」フィールドは、型norm_object_streamのトランスポートオブジェクトにのみ存在します。これらの必要なフィールドにより、送信者はストリームのnorm_dataペイロードセグメントのサイズを任意に変化させることができます。これにより、アプリケーションは必要に応じて送信されたストリームをフラッシュして、一意のストリーミング要件を満たすことができます。型norm_object_fileおよびnorm_object_dataのタイプのオブジェクトの場合、受信者はfecビルディングブロック[RFC5052]ドキュメントで説明されている必要なブロックパーティションアルゴリズムを使用して、ペイロード長さと「fec_payload_id」からのオフセット情報を計算できるため、これらのフィールドは不要です。系統的FECコード（「FEC_ID」= 129など）が使用される場合、「Payload_len」、「Payload_msg_start」、および「Payload_offset」フィールドには、実際のPayload_data長、メッセージ開始インデックス（またはストリームコントロールコード）、およびバイトオフセット値が含まれています。ソースデータ記号を含むnorm_dataメッセージの関連するアプリケーションストリームデータセグメント（「payload_data」フィールドコンテンツの残り）。FECパリティコンテンツを含むNORM_DATAメッセージでは、これらのフィールドには直接解釈できる値を含むのではなく、「Payload_len」、「Payload_msg_start」、および「Payload_offset」フィールドをエンコードするFECから計算された値です。対応するコーディングブロック。欠損データコンテンツの実際の「payload_msg_start」、「payload_len」、および「payload_offset」値は、FECコーディングブロックをデコードすると決定できます。これらのフィールドは、NORM_DATA "HDR_LEN"フィールドの価値に寄与していないことに注意してください。これらのフィールドは、norm_dataメッセージの「フラグ」部分がトランスポートオブジェクトが型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 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.
「payload_len」値は、非ゼロの場合、関連する「payload_data」フィールドに含まれるソースコンテンツの長さ（バイト単位）を示します。ただし、「payload_len」値がゼロに等しい場合、これは「payload_msg_start」フィールドが「stream_control_code」と交互に解釈されることを示します。定義された唯一の「stream_control_code」値はnorm_stream_end = 0です。NORM_STREAM_ENDコードは、送信者がストリーム内の対応する位置でストリームコンテンツの送信を終了していることを示しています。ストリーム内の位置。追加の仕様は、追加のストリーム制御コードを定義することにより、Norm Stream Transport Modeの機能を拡張する場合があります。これらの制御コードは、ストリーミングされたアプリケーションデータコンテンツに関して、受信者アプリケーションに確実に配信され、確実に配信されます。
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」フィールドは、2つの排他的な目的のいずれかを提供します。「payload_len」値がゼロ以外の場合、「payload_msg_start」フィールドは、ゼロ以外の値に設定されている場合、関連する「payload_data」コンテンツにアプリケーション定義のメッセージ境界（メッサージの開始）が含まれていることを示します。このようなメッセージ境界が示されている場合、「Payload_Data」フィールドに関するアプリケーション定義のメッセージの最初のバイトは、「Payload_msg_start -1」バイトのオフセットで見つかります。したがって、norm_object_streamのnorm_dataペイロードが「payload_data」フィールドの最初のバイトでアプリケーションメッセージの開始を含む場合、「payload_msg_start」フィールドの値は「1」になります。Normの実装は、送信者ストリームアプリケーションに、この方法でメッセージの境界をマークする機能を提供する必要があります。同様に、NORM受信機の実装により、アプリケーションがそのようなメッセージ境界情報を回復できるようにする必要があります。これにより、NORM受信機は、既に進行中のセッションに参加するか、セッションを出発して返信するかにかかわらず、いつでも意味のある方法で（つまり、アプリケーションにとって意味のある）、送信されたメッセージストリームコンテンツの信頼できる受信を「同期」することができます。「payload_msg_start」フィールドの値がゼロの場合、メッセージの境界が存在しないことに注意してください。「payload_msg_start」値は、「payload_len = 0」の特別なケースを除き、「payload_len」値を除き、常に「payload_len」値以下になります。
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 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.
「Payload_Data」フィールドには、「FEC_PayLoad_ID」で識別されたシンボルの元のアプリケーションソースまたはパリティコンテンツが含まれています。このフィールドの長さは、オブジェクトのFTIに与えられた送信者の標準化バイトの最大値に制限されなければなりません。パリティコンテンツを含むメッセージのこのフィールドの長さは、常に長さの標準化されます。さまざまなサイズのデータセグメントをエンコードする場合、FECエンコーダーは、Normsegmentsizeよりも長いデータセグメントに対してゼロ値パディングを想定しなければなりません。送信者の規範化は、一般に、特定の送信者のセッションへの参加期間の期間中に一定であるが、オブジェクトごとに異なる場合があることをお勧めします。Normsegmentsizeは、ネットワークトポロジMTUの考慮事項に必要に応じて、セッション参加前に送信者アプリケーションによって構成可能である必要があります。IPv6の場合、MTU発見は、この構成を実行するためにセッションスタートアップでレバレッジされる可能性があります。「Payload_Data」コンテンツは、Sourceシンボルのアプリケーション（系統的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メッセージは、送信されたnormobjectsのオプションのアプリケーション定義のバンド外コンテキスト情報を伝えるために使用されます。バルクファイル転送に使用するnorm_infoの例は、関連するファイル、データ、またはオブジェクトをnorm_infoペイロードにストリーミングするためのmimeタイプ情報を配置することです。レシーバーは、NORM_INFOコンテンツを使用して、関連するオブジェクトの信頼できる受信に参加するかどうかを決定することができます。各normobjectは、それが関連付けられているnorm_infoの独立した単位を持つことができます。NORM_DATAメッセージには、特定のnormobjectのnorm_infoの可用性を示すフラグが含まれています。NORMレシーバーは、特定のnormobjectに対してそれを受け取っていない場合、norm_infoの再送信を求めます。norm_infoコンテンツのサイズは、指定された送信者の単一のnormsegmentsizeのサイズに制限されています。この原子性により、NORM_INFOは、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_infoコンテンツがnormobjectで使用可能な場合、norm_flag_infoフラグは、対応する「object_transport_id」のnorm_dataメッセージに設定され、norm_infoメッセージはnormobjectの最初のメッセージとして送信されます。
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_infoメッセージ形式
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」、「シーケンス」、および「SOURCE_ID」フィールドは、セクション4.1で説明されているように、NORM共通メッセージヘッダーを形成します。ヘッダー拡張機能が存在しない場合の「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.
「instance_id "、" grtt "、" backoff "、" gsize "、" flags "、" fec_id "、および" object_transport_id "フィールドは同じ情報を持ち、norm_dataメッセージと同じ目的を果たします。これらの値により、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_dataメッセージと同様に、normftiヘッダー拡張機能（ext_fti）は、norm_infoメッセージにオプションで適用される場合があります。プロトコルのオーバーヘッドを保存するために、Norm_Infoメッセージのみに使用され、norm_Dataメッセージではなく、norm_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"フィールドには、上記のようにさまざまな目的でレシーバーアプリケーションで使用できるSenderアプリケーション定義コンテンツが含まれています。
NORM_CMD messages are transmitted by senders to perform a number of
different protocol functions. This includes functions such as round-
trip timing collection, congestion control functions, synchronization
of sender/receiver repair "windows", and notification of sender
status. A core set of NORM_CMD messages is enumerated.
Additionally, a range of command types remain available for potential
application-specific use. Some NORM_CMD types 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_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」、「シーケンス」、および「SOURCE_ID」フィールドは、セクション4.1で説明されているように、NORM共通メッセージヘッダーを形成します。ヘッダー拡張機能のないnorm_cmdメッセージの「HDR_LEN」フィールドの値は、「サブタイプ」フィールドに依存します。
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_dataやnorm_infoメッセージと同じ目的を果たします。「サブタイプ」フィールドは、従うべきコマンドのタイプを示します。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. |
| 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）コマンドは、送信者がすべてのデータコンテンツの終了に達し、送信用にキューに入っている保留中の修理に到達したときに送信されます。これは、一時的または永続的なDATAの終了伝送のいずれかを示しますが、送信者はまだ修理リクエストに応答することをいとわないことを示しています。このコマンドは、2*grtt_senderに1回繰り返され、norm_cmd（フラッシュ）メッセージ内に示されている送信ポイントまでの未解決の修理要求のレシーバーセットを励起します。繰り返しの数は、明示的な肯定的な確認が予想されるレシーバーのリスト（ "acking_node_list"）が与えられない限り、norm_robust_factorに等しくなります。その場合、「Acking_node_list」は、謝辞が受信されると更新され、norm_cmd（フラッシュ）はセクション5.5.3で説明されているメカニズムに従って繰り返されます。Norm_Obust_Factorが大きいほど、すべての該当する受信機が確認または修理リクエスト（NACK）のために励起される可能性が高く、対応するNACKが送信者に配信される可能性が高くなります。20に等しいNORM_OBUST_FACTORのデフォルト値が推奨されます。norm_nackメッセージがフラッシュプロセスを中断した場合、送信者は、結果として生じる修理送信が完了した後、フラッシュプロセスを再開するものとします。
Note that receivers also employ a timeout mechanism to self-initiate NACKing (if there are outstanding repair needs) when no messages of any type are received from a sender. This inactivity timeout is related to 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（フラッシュ）およびnorm_robust_factorに関連しており、セクション5.3で指定されています。受信者は、特定の送信者の非アクティブタイムアウトが期限切れになった場合、NACK修復プロセスを自己開始し、受信者はその送信者から必要な保留中の修理を持っています。十分に大きいNORM_OBUST_FACTOR値により、データコンテンツは信頼性の高い保証で配信されます。大規模なnorm_obust_factor値のペナルティは、過剰なnorm_cmd（フラッシュ）メッセージの潜在的な送信と、レシーバーが端末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修復情報は、フラッシュコマンドによって引き出される修理リクエストに応じて、常に修理に利用できます。ただし、norm_object_streamの場合、系統的FECコードが採用されている場合は、FECコーディングブロックの中央を含め、フラッシュはいつでも発生する可能性があります。この場合、送信者はまだ同時コーディングブロックにFECパリティコンテンツを提供することができず、そのブロックのソースデータコンテンツを使用してストリームを明示的に修復することに制限されます。Streamコンテンツの頻繁なフラッシングを予測するアプリケーションは、FECコーディングブロックサイズの選択において賢明である必要があります（つまり、頻繁にフラッシングが発生した場合、非常に大きなコーディングブロックサイズを使用しないでください）。たとえば、適切なFECコーディングブロックサイズを備えたNORM_OBJECT_STREAMパラダイムに対して、norm_object_dataパラダイムを使用してトレードオフする必要がある、継続的な断続的で比較的小さなメッセージを送信する信頼性の高いマルチキャストアプリケーションが送信されます。これは、「遅延なし」などのさまざまな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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NORM_CMD(FLUSH) Message Format
図10：norm_cmd（フラッシュ）メッセージ形式
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」、「シーケンス」、および「SOURCE_ID」フィールドは、セクション4.1で説明されているように、NORM共通メッセージヘッダーを形成します。Norm Commonメッセージヘッダーと標準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（フラッシュ）メッセージの「HDR_LEN」値は、ヘッダー拡張機能が存在しない場合の「FEC_PAYLOAD_ID」フィールドのサイズに加えて4に加えています。
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_dataメッセージタイプと同じ方法で解釈されます。Norm_CMD（フラッシュ）を受信すると、受信機はこの送信位置を介して完成状態を確認することが期待されます。受信機がこの範囲で優れた修理ニーズを持っている場合、セクション5.3で説明されているように、標準NACK修理プロセスを開始するものとします。受信機に未解決の修理ニーズがない場合、NORM_CMD（フラッシュ）への応答は生成されません。
For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers MUST request "explicit-only" repair of the identified "source_block_number" if the given "encoding_symbol_id" is less than the "source_block_len". This condition indicates the sender has not yet completed encoding the corresponding FEC block and parity content is not yet available. An "explicit-only" repair request consists of NACK content for the applicable "source_block_number" 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.
系統的FECコードを使用したnorm_object_streamオブジェクトの場合、受信者は、指定された「ecoding_symbol_id」が「source_block_len」よりも小さい場合、識別された「source_block_number」の「明示的なみの」修復を要求する必要があります。この条件は、送信者がまだ対応するFECブロックをエンコードしていないことを示しており、パリティコンテンツはまだ利用できないことを示しています。「明示的なみの」修理リクエストは、パリティベースの修理のリクエストが含まれていない該当する「source_block_number」のnackコンテンツで構成されています。これにより、Norm Senderアプリケーションは、FECブロックの中央にある場合でも、必要に応じて進行中の送信ストリームを「フラッシュ」できます。送信者がストリームトランスミッションを再開し、保留中のコーディングブロックの終わりを通過すると、レシーバーからのその後のNACKは、通常どおりパリティベースの修理を要求するものとします。ここでは、系統的FECコードの使用が想定されていることに注意してください。そのようなアプリケーション「フラッシュ」が発生した場合、送信者は特定のコードブロックを任意に短縮するオプションがあることに注意してください。この場合、受信者は明示的な修理を要求しますが、送信者はそれに応じてFECベースの修理（パリティセグメント）を提供できます。これらのパリティセグメントには、短縮ブロックの修正された「source_block_len」が含まれている必要があり、パリティコンテンツを含むセグメントに関連付けられた「source_block_len」は、以前に宣伝された「source_block_len」をオーバーライドするものとします。同様に、最高の序数に関連付けられた「source_block_len」は、違いが発生した場合（たとえば、コードの短縮による）が発生する場合、以前の記号よりも優先されるものとします。通常のレシーバーNACKの開始と構造については、セクション5.3で詳しく説明します。
The OPTIONAL "acking_node_list" field contains a list of NormNodeIds for receivers from which the sender is requesting explicit positive acknowledgment of reception up through the transmission point identified by the "object_transport_id" and "fec_payload_id" fields. The length of the list can be inferred from the length of the received NORM_CMD(FLUSH) message. When the "acking_node_list" is present, the lightweight positive acknowledgment process described in Section 5.5.3 SHALL be observed.
オプションの「Acking_node_list」フィールドには、送信者が「object_transport_id」および「fec_payload_id」フィールドによって識別された送信ポイントを介して、受信の明示的な肯定的な確認を要求しているレシーバーのnormnodeidsのリストが含まれています。リストの長さは、受信したNORM_CMD（フラッシュ）メッセージの長さから推測できます。「acking_node_list」が存在する場合、セクション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.
NORM_CMD（EOT）コマンドは、送信者がNormsessionに関して永続的な移動の終了に到達し、さらなる修理リクエストに応答しないときに送信されます。これにより、受信者はこの送信者で操作の閉鎖に優雅に到達し（タイムアウトを必要とせずに）、不要なリソースを解放できます。norm_cmd（eot）コマンドは、norm_cmd（フラッシュ）コマンドに使用されるのと同じ堅牢なメカニズムで送信され、受信者セットによる受信の高い保証を提供する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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_unrelaibleフラグでマークされた送信されたオブジェクトの修理要求が含まれます。このコマンドは、修理に利用できるコンテンツを受信者に示し、送信者の現在の「修理ウィンドウ」の説明として機能します。受信機は、NORM_CMD（Squelch）によって無効であると特定されたコンテンツの修理要求を生成してはなりません。
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_senderに1回送信されます。Norm_CMD（Squelch）は、修理を提供する最も早い（最低）送信ポイントを識別することにより、送信者の現在の「修理ウィンドウ」を宣伝し、そのポイントからのオブジェクトのエンコードされたリストが修理に有効でないことを識別します。このメカニズムにより、送信者アプリケーションは、以前に除く特定のオブジェクトの送信および/または修復をキャンセルまたは中止できます。リストには、norm_flag_unrelaibleフラグセットで送信された修理ウィンドウ内の任意のオブジェクトの識別子も含まれています。通常の条件では、NORM_CMD（Squelch）はまれに必要であり、一般に、ネットワーク条件が非常に低いために送信者と「整頓」した受信機に参照修理ウィンドウを提供するためにのみ必要になります。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: NORM_CMD(SQUELCH) Message Format
図12：norm_cmd（squelch）メッセージ形式
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 Commonメッセージヘッダーと標準NORM_CMDフィールドに加えて、NORM_CMD（Squelch）メッセージにはフィールドが含まれており、送信者の現在の修理ウィンドウの最も早い論理送信位置と、論理的に初期の無効な修理要求のインデックスから始まる「Invalid_Object_List」を識別します。norm_cmd（squelch）送信を開始した問題のNACKメッセージから。拡張機能が存在しない場合の「HDR_LEN」フィールドの値は、「FEC_ID」フィールドによって識別されるFECスキームに依存する「FEC_Payload_ID」フィールドのサイズ4に加えています。
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_payload_id」フィールドのサイズと形式を意味します。これは、受信機が修理を要求する「同期」ポイントの広告として機能します。「encoding_symbol_id」は「fec_payload_id」フィールドに含まれる可能性があるが、送信者の修理ウィンドウはFECコーディングブロック境界に並べる必要があるため、「encoding_symbol_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.
「Invalid_object_list」は、16ビットNormtransportidsのリストであり、送信者の現在の修理ウィンドウの範囲内にありますが、送信者からの修理に使用できなくなりました。たとえば、送信者アプリケーションは、修理ウィンドウ内にある場合でも、時代遅れのオブジェクトをデキューする場合があります。「Invalid_object_list」コンテンツの合計サイズは、パケットのペイロード長から決定でき、送信者の標準の最大値に制限されます。したがって、非常に大きな修理ウィンドウの場合、単一のnorm_cmd（squelch）メッセージに、修理ウィンドウに無効なオブジェクトのセット全体を含めることができない可能性があります。この場合、送信者は、NORM_CMD（Squelch）の生成を促したNACKメッセージから最も低い序数のNORMTRANSPORTIDよりも大きいまたは等しいNORMTRANSPORTIDでリストが始まることを保証するものとします。「invalid_object_list」のnormtransportidは、送信者の修理ウィンドウの開始をマークする「object_transport_id」よりも通常大きくなければなりません。これにより、複数の無効なNACK/SCELCH反復が必要であっても、スケルチプロセスの収束が保証されます。送信者の現在のウィンドウ内の無効なコンテンツのこの明示的な説明により、送信者アプリケーション（最も顕著なオブジェクト輸送用）は、信頼できるコンテンツ（特定のオブジェクトなど）の部分を任意に無効（つまり、dequeue）を任意に無効にします。輸送。
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）メッセージには、Sender-to-GRTT測定を有効にし、輻輳制御フィードバックのためにグループを励起するフィールドが含まれています。RFC 4654のTCPフレンドリーマルチキャスト輻輳制御（TFMCC）スキームに基づくベースラインノルム輻輳制御スキーム（NORM-CC）は、このドキュメントのセクション5.5.2で完全に指定されています。norm_cmd（CC）メッセージは通常、norm-cc操作の一部として送信されます。NORM-CC操作をサポートするために、NORM_CMD（CC）メッセージで使用するために、NORMヘッダー拡張機能を以下に定義します。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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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とStandard 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）メッセージを使用し、スキーム固有の目的で「予約済み」フィールドを活用する代替の輻輳制御スキームが使用される可能性があります。
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_Sequence」フィールドは、送信者によって適用されるシーケンス番号です。NORM-CC操作の場合、RFC 4654で説明されている「フィードバックラウンド番号」（FB_NR）に相当する機能を提供するために使用されます。その送信者のレシーバーによって生成された制御フィードバック。「CC_Sequence」数は、NORM実装でも使用して、レシーバーが送信者からNORM_CMD（CC）プローブをどの程度受信したかを評価することもできます。これは、複雑なマルチキャストルーティング環境または実験的なマルチキャストルーティング環境に役立つ計装です。
The "send_time" field is a timestamp indicating the time that the NORM_CMD(CC) message was transmitted. This consists of a 64-bit field containing 32-bits with the time in seconds ("send_time_sec") and 32-bits with the time in microseconds ("send_time_usec") since some reference time the source maintains (usually 00:00:00, 1 January 1970). The byte ordering of the fields is "Big Endian" network order. Receivers use this timestamp adjusted by the amount of delay 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.
「send_time」フィールドは、norm_cmd（cc）メッセージが送信された時間を示すタイムスタンプです。これは、32ビットを含む64ビットフィールドで、秒単位の時間（ "send_time_sec"）と32ビットで構成され、マイクロ秒単位（ "send_time_usec"）の時間とともに32ビットで構成されています。、1970年1月1日）。フィールドのバイト順序は「ビッグエンディアン」ネットワーク注文です。受信者は、norm_cmd（cc）メッセージを受け取った時間から、生成されたnorm_ackの「grtt_response」部分とnorm_nackメッセージの「grtt_response」部分としての応答時までの遅延の量によって調整されたこのタイムスタンプを使用します。これにより、送信者は、混雑制御およびその他の（GRTT決定）目的のために、さまざまな受信機への往復時間を評価できます。
To facilitate the baseline NORM-CC scheme described in Section 5.5.2,
a NORM-CC Rate header extension (EXT_RATE) is defined to inform the
group of the sender's current transmission rate. This is used along
with the loss detection "sequence" field of all NORM sender messages
and the NORM_CMD(CC) GRTT collection process to support NORM-CC
congestion control operation. The format of this header extension is
as follows:
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:
「send_rate」フィールドは、送信者の現在の伝送速度を1秒あたりのバイトで示します。16ビットの「send_rate」フィールドは、最も重要な部分で12ビットのマンティッサと、最小重要な部分で4ビットのベース10整数指数（e）情報で構成されています。フィールドの12ビットのマンティッサ部分は、0.0のベース10マンティッサ（m）の浮動小数点値が0に対応し、10.0の値が16ビットの「send_rate」フィールドフィールドの上部12ビットの4096に対応するようにスケーリングされています。。したがって：
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
To decode the "send_rate" field, the following equation can be used:
「send_rate」フィールドをデコードするには、次の方程式を使用できます。
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で説明されている手順に従ってNORM受信機が応答する必要があることも意味します。
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_NODE_LIST」は、NormNodeIDSのリストとそれに関連する混雑制御ステータスで構成されています。これには、現在の制限レシーバー（CLR）ノード、特定された潜在的な制限レシーバー（PLR）ノード、および特に受信機の現在のRTT測定を含む混雑制御ステータスが提供されているいくつかの受信機が含まれます。「CC_NODE_LIST」の最大長は、少なくともCLRと他の1つのレシーバーを提供しますが、グループへのよりタイムリーなフィードバックのために増加させることができます。リストの長さは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "cc_node_id" is the NormNodeId of the receiver the item represents.
「cc_node_id」は、アイテムが表すレシーバーの標準的なものです。
The "cc_flags" field contains flags indicating the congestion control status of the indicated receiver. The following flags are defined:
「CC_FLAGS」フィールドには、指定された受信機の混雑制御ステータスを示すフラグが含まれています。次のフラグが定義されています。
+--------------------+-------+--------------------------------------+
| Flag | Value | Purpose |
+--------------------+-------+--------------------------------------+
| NORM_FLAG_CC_CLR | 0x01 | Receiver is the current limiting |
| | | receiver (CLR). |
| NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). |
| NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with |
| | | respect to sender. |
| NORM_FLAG_CC_START | 0x08 | Sender/receiver is in "slow start" |
| | | phase of congestion control |
| | | operation (i.e., the receiver has |
| | | not yet detected any packet loss and |
| | | the "cc_rate" field is the |
| | | receiver's actual measured receive |
| | | rate). |
| NORM_FLAG_CC_LEAVE | 0x10 | Receiver is imminently leaving the |
| | | session and its feedback SHOULD not |
| | | be considered in congestion control |
| | | operation. |
+--------------------+-------+--------------------------------------+
The "cc_rtt" contains a quantized representation of the RTT as measured by the sender with respect to the indicated receiver. This field is valid only if the NORM_FLAG_CC_RTT flag is set in the "cc_flags" field. This one-byte field is a quantized representation of the RTT using the algorithm described in the Multicast NACK Building Block [RFC5401] document.
「CC_RTT」には、指定された受信機に関して送信者によって測定されたRTTの量子表現が含まれています。このフィールドは、norm_flag_cc_rttフラグが「cc_flags」フィールドに設定されている場合にのみ有効です。この1バイトフィールドは、マルチキャストNACKビルディングブロック[RFC5401]ドキュメントで説明されているアルゴリズムを使用して、RTTの量子表現です。
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_RATE」フィールドには、計算された（定常状態の混雑制御操作中）またはその2倍の測定（スロースタートフェーズ中）の混雑制御レートの表現が含まれています。このフィールドは、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（REPARE_ADV）メッセージは、送信者によって使用され、REPARICEサイクルおよび/または輻輳制御フィードバック中に蓄積されたNORM_NACKメッセージから集計された修理状態を「宣伝」します。このメッセージは、送信者がnorm_nackおよび/またはnorm_ack（cc）（輻輳制御が有効になっている場合）メッセージをマルチキャストではなくユニキャスト送信を介して受信した場合にのみ送信されます。この情報を受信機セットに中継することにより、グループ[NormFeedback]でマルチリキャストする代わりに、受信機がそのフィードバックを単一補充している場合でも、フィードバックの抑制を達成できます。
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_CMD（Repair_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）コンテンツに関する情報を提供します。現在、定義されている1つのnorm_cmd（repair_adv）フラグがあります。
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".
このフラグは、電流の完全な修理状態を単一の規範化に収めることができない場合、送信者によって設定されます。このフラグが設定されている場合、受信機は、「Repais_Adv_Content」に含まれる最大順序伝送位置（ObjectTransportid :: fecPayloadID）を介してのみNACKコンテンツを生成することに対する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
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）メッセージの場合、送信者は、送信された最後のnorm_cmd（cc）メッセージに設定された値に「cc_sequence」フィールド値を設定するものとします。
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は、送信者が受信したすべてのフィードバックメッセージにフラグセットがある場合にのみ設定されます。同様に、NORM_FLAG_CC_CLRまたはNORM_FLAG_CC_PLRは、非CLRまたは非PLRレシーバーからフィードバックを受け取っていない場合にのみ設定されます。また、NORM_FLAG_CC_LEAVEは、送信者が受け取ったすべてのフィードバックメッセージにこのフラグが設定されている場合にのみ設定されます。Norm_CMD（Repair_Adv）にフラグを設定するためのこれらのヒューリスティックは、ユニキャストフィードバックメッセージを提供する受信機の最も効果的な抑制を保証します。
The "cc_rtt" field SHALL be set to a default maximum value, and the NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet received RTT measurement information. When a receiver has received RTT measurement information, it SHALL set the "cc_rtt" value accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags" field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has measured from receivers for the current feedback round.
「CC_RTT」フィールドはデフォルトの最大値に設定され、RTT測定情報をまだ受け取っていない場合、NORM_FLAG_CC_RTTフラグはクリアされます。受信者がRTT測定情報を受け取った場合、それに応じて「CC_RTT」値を設定し、「CC_FLAGS」フィールドにNORM_FLAG_CC_RTTフラグを設定するものとします。norm_cmd（Repair_Adv）メッセージの場合、送信者は、現在のフィードバックラウンドのレシーバーから測定した最大の非CLR/非PLR RTTに「CC_RTT」フィールド値を設定するものとします。
The "cc_loss" field represents the receiver's current packet loss fraction estimate for the indicated source. The loss fraction is a value from 0.0 to 1.0 corresponding to a range of zero to 100 percent packet loss. The 16-bit "cc_loss" value is calculated by the following formula:
「CC_LOSS」フィールドは、指定されたソースの受信機の現在のパケット損失率の推定値を表します。損失率は、0.0〜1.0の値であり、ゼロから100％のパケット損失の範囲に対応しています。16ビットの「CC_LOSS」値は、次の式で計算されます。
"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）メッセージの場合、送信者は、現在のフィードバックラウンドのレシーバーから受け取った最大の非CLR/非PLR損失の見積もりに「CC_LOSS」フィールド値を設定するものとします。
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_RATE」フィールドは、受信者の現在のローカル輻輳制御率を表します。「スロースタート」中、受信機が損失を検出しなかったとき、この値は、対応する送信者から測定された実際のレートの2倍に設定され、norm_flag_cc_startは「cc_flags」フィールドに設定されます。それ以外の場合、レシーバーは、「CC_RATE」フィールドの損失測定とRTT測定情報（デフォルトであっても）に基づいて輻輳制御レートを計算します。norm_cmd（repair_adv）メッセージの場合、送信者は、現在のフィードバックラウンドのレシーバーから受け取った最低のnon-clr/nonplr "cc_rate" cc_rate "レポートに「cc_loss」フィールド値を設定するものとします。
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」フィールドは、将来の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_content」とまったく同じ形式であり、norm_repair_adv_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
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とStandard 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」値が定義されており、後で説明されたNORM_ACKメッセージでも使用されます。
+-----------------------+------------+------------------------------+
| ACK Type | Value | Purpose |
+-----------------------+------------+------------------------------+
| NORM_ACK(CC) | 1 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(CC) messages. |
| NORM_ACK(FLUSH) | 2 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(FLUSH) messages. |
| NORM_ACK(RESERVED) | 3-15 | Reserved for possible future |
| | | NORM protocol use. |
| NORM_ACK(APPLICATION) | 16-255 | Used at application's |
| | | discretion. |
+-----------------------+------------+------------------------------+
The NORM_ACK(CC) value is provided for use only in NORM_ACKs generated in response to the NORM_CMD(CC) messages used in congestion control operation. Similarly, the NORM_ACK(FLUSH) is provided for use only in NORM_ACKs generated in response to applicable NORM_CMD(FLUSH) messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK(CC) or NORM_ACK(FLUSH) SHALL NOT be generated by the sender.
norm_ack（cc）値は、混雑制御操作で使用されるnorm_cmd（cc）メッセージに応じて生成されたnorm_acksでのみ使用するために提供されます。同様に、norm_ack（フラッシュ）は、該当するnorm_cmd（フラッシュ）メッセージに応じて生成されたnorm_acksでのみ使用するために提供されます。norm_cmd（ack_req）norm_ack（cc）またはnorm_ack（flush）の「ack_type」を含むメッセージは、送信者によって生成されてはなりません。
The NORM_ACK(RESERVED) range of "ack_type" values is provided for possible future NORM protocol use.
将来のNORMプロトコルの使用のために、「ACK_TYPE」値のNORM_ACK（予約済み）範囲が提供されます。
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（ACK_TYPE」値の範囲が提供されるため、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.
「acking_node_list」フィールドには、この要求に肯定的な確認（norm_ack）を提供することが望まれる現在のノルムレシーバーのnormnodeidが含まれています。パケットペイロードの長さは、「acking_node_list」の長さを意味し、その長さは送信者normsegmentsizeに限定されます。個々のNormNodeIDアイテムは、ネットワーク（Big Endian）BYTE ORDERにリストされています。受信者のnormnodeIDが「Acking_node_list」に含まれている場合、セクション5.5.3で説明されているように、norm_ackメッセージの送信をスケジュールするものとします。
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_senderに1回のレートでnorm_robust_factorの時間まで繰り返されます。この繰り返しのレートにより、アプリケーションは、繰り返される前に、アプリケーションがアプリケーションの目的である場合）を観察することができます。考えられる応答には、データ送信の開始、その他のNORM_CMD（アプリケーション）メッセージ、または他のNormSession参加者からのアプリケーション定義の肯定的に認められたコマンドさえ含まれます。これらのコマンドの送信は、スケジュールされた場合にデータ送信を先取りし、進行中のデータ送信で多重化できます。このタイプの堅牢な送信コマンドにより、NORMアプリケーションは、NORMの送信と往復タイミング情報を活用しながら、FECエンコードされた信頼できるコンテンツニーズを転送するよりも少ない状態のセッション制御メカニズムの完全なセットを定義できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=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メッセージヘッダーとNORM_CMDフィールドは、前述のように解釈されます。Header拡張機能が存在しない場合のnorm_cmd（アプリケーション） "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_nackおよびnorm_ackメッセージタイプで構成されています。NORM_NACKメッセージは、送信者伝送からの欠落データコンテンツの修復を要求するために送信され、norm_cmd（CC）やnorm_cmd（ack_req）を含む特定の送信者コマンドに応じてnorm_ackメッセージが生成されます。
The principal purpose of NORM_NACK messages is for receivers to request repair of sender content via selective, negative acknowledgment upon detection of incomplete data. NORM_NACK messages will be transmitted according to the rules of NORM_NACK generation and suppression described in Section 5.3. NORM_NACK messages also contain additional fields to provide feedback to the sender(s) for purposes of round-trip timing collection and congestion control.
norm_nackメッセージの主な目的は、レシーバーが、不完全なデータを検出したときに選択的で否定的な認識を介して送信者コンテンツの修理を要求することです。norm_nackメッセージは、セクション5.3で説明されているnorm_nack生成と抑制のルールに従って送信されます。norm_nackメッセージには、往復タイミングコレクションと混雑制御の目的で送信者にフィードバックを提供する追加のフィールドも含まれています。
The payload of NORM_NACK messages contains one or more repair
requests for different objects or portions of those objects. The
NORM_NACK message format is as follows:
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メッセージヘッダーフィールドは、通常の目的を果たします。ヘッダー拡張機能のない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メッセージが運命づけられる標準送信者を識別します。
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」フィールドによって識別された送信者によって指定された現在のセッション識別子が含まれています。送信者は、無効な「instance_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" value used in the following formula: grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta
「GRTT_RESPONSE」フィールドには、指定されたNORM送信者の最近受信したNORM_CMD（CC）メッセージからの調整されたバージョンのタイムスタンプが含まれています。「grtt_response」の形式は、norm_cmd（cc）の「send_time」フィールドと同じです。「grtt_response」値は、対応するnorm_cmd（cc）コマンドで提供されるソースが「send_time」に関連しています。受信者は、受信者がnorm_cmd（cc）を受け取ったときから「grtt_response」フィールドの値を計算するためにnorm_nackを送信するときにtime deltaを追加することにより、ソースのnorm_cmd（cc） "send_time"タイムスタンプを調整します。これは、次の式で使用されている「Receive_to_response_delta」値です：grtt_response = norm_cmd（cc）send_time_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_RESPONSE」をゼロ値に設定し、指定された送信者からNORM_CMD（CC）メッセージをまだ受信していないことを示し、送信者はこのメッセージの「GRTT_RESPONSE」を無視する必要があります。
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_CMD（REPAIR_ADV}メッセージの説明に記載されているNORM-CCフィードバックヘッダー拡張機能がNORM_NACKメッセージに追加され、混雑制御操作に関して受信機の現在の状態に関するフィードバックを提供します。制御フィードバックは、将来の規範使用のための代替輻輳制御スキームのために定義される場合があります。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: NORM Repair Request Format
図18：ノルム修理要求フォーマット
The "form" field indicates the type of repair request items given in the "repair_request_items" list. Possible values for the "form" field include:
「フォーム」フィールドは、「Repair_Request_Items」リストに記載されている修理要求項目のタイプを示します。「フォーム」フィールドの可能な値は次のとおりです。
+--------------------+-------+
| 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_itemsの「フォーム」値は、「Repair_Request_Items」リストの各修理要求項目を個別のリクエストとして扱うことを示します。norm_nack_rangesの値は、「修理_request_items」リストは、修理ニーズの包括的な範囲に対応する修理要求項目のペアで構成されていることを示します。norm_nack_erasures "form"は、修理要求項目が個別に扱われることを示し、修理要求項目の「fec_payload_id」フィールドの「encoding_symbol_id」部分（以下を参照）は、識別されたFECコーディングブロックの消去カウントとして解釈されます。修理要求項目の「source_block_number」によって。
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. |
+-------------------+--------+--------------------------------------+
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 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_segmentフラグが設定されている場合、「object_transport_id」および「fec_payload_id」フィールドを使用して、レシーバーのコンテンツを修復するために個々のnorm_dataセグメントのセットまたは範囲を決定する必要があります。norm_nack_blockフラグが設定されている場合、これはレシーバーに示されたコーディングブロックが完全に欠落していることを示し、示されたブロック全体を修復するのに十分な送信が必要であることを示します。norm_nack_infoフラグが設定されている場合、これはレシーバーが示されている「object_transport_id」のnorm_infoセグメントが欠落していることを示します。NORM_NACK_INFOは、norm_nack_blockまたはnorm_nack_segmentフラグと組み合わせて設定することも、単独で設定することもできます。norm_nack_objectフラグが設定されている場合、これはレシーバーが「object_transport_id」で参照されるnormtransportobject全体が欠落していることを示します。これはまた、該当する場合、normobjectで利用可能なnorm_infoを暗黙的に要求します。flag norm_nack_objectが設定されている場合、「fec_payload_id」フィールドは無視されます。
The "length" field value is the length in bytes of the "repair_request_items" field.
「長さ」フィールド値は、「Repair_Request_Items」フィールドのバイトの長さです。
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：ノルム修理要求項目形式
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_PAYLOAD_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」は、修理が要求されているnormobjectに対応し、「fec_payload_id」は特定のFECコーディングブロックおよび/または要求されているセグメントを識別します。norm_nack_objectフラグが設定されると、「fec_payload_id」フィールドの値は無視されます。norm_nack_blockフラグが設定されている場合、「fec_payload_id」のFECコードブロック識別子部分のみが解釈されます。
The format of the "fec_payload_id" field depends upon the "fec_id" field value.
「fec_payload_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
受信者の修理が必要な場合は、信頼できる送信、異なる「フォーム」の複数のノルム修理要求を完了するために、異なるフォーム（混合範囲および/または個々のアイテム）またはタイプ（特定のセグメントおよび/またはブロックまたはオブジェクト全体）が必要であることを決定する場合または、「フラグ」値は、単一のnorm_nackメッセージ内で連結することができます。さらに、ノルム受信者は、修理要求を順番に修理要求で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.
「Object_transport_id」および「fec_payload_id」値。「nack_payload」サイズは、norm_nackが運命づけられている送信者のnormsegmentsizeを超えてはなりません。
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_items修復要求のリストが与えられます。例2では、norm_nack_rangesリクエストと単一のnorm_nack_itemsリクエストのリストを連結して、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 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
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メッセージヘッダーフィールドは、通常の目的を果たします。ヘッダー拡張機能が存在しない場合の「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.
「server_id」、「instance_id」、および「grtt_response」フィールドは、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.
「ACK_TYPE」フィールドは、NORM_ACKメッセージの性質を示します。これは、この承認が適用される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メッセージが実際に現在の確認要求に適用されることを確認できます。「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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
「object_transport_id」と「fec_payload_id」は、「server_id」フィールドによって識別された送信者によって送信された該当するnorm_cmd（フラッシュ）メッセージを確認するために受信者によって使用されます。
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".
アプリケーション定義の「ACK_TYPE」値のnorm_ackメッセージの「ack_payload」は、アプリケーションに固有ですが、「server_id」で参照される送信者のnormsegmentsizeの最大値までサイズが制限されています。
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_report形式を定義する場合があります。これらのレポートメッセージは、異なる準拠の規範実装間の相互運用性テストのために無効にする必要があります。
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. 送信者は、normtransportidsでラベル付けされたnorm_dataメッセージの形式でセグメント化された標準項の順序セットを送信し、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（フラッシュ）メッセージを送信します。エンキュー送信コンテンツの終了と保留中の修理に到達します。レシーバーは、NORM_NACK TRANSMISSIONS（データと同じ抑制バックオフタイムアウト戦略に従って）を使用してNORM_CMD（フラッシュ）メッセージに応答します。
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操作では、規範の各送信者は独自の独立した輻輳制御状態を維持しています。受信機は、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.
この全体的な概念は比較的単純ですが、これらの側面のそれぞれには、成功し、効率的で、堅牢で、スケーラブルなノルムプロトコル操作のために対処する必要がある詳細があります。
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レートヘッダー拡張はこれらのメッセージに含める必要があります。一般的なインターネットのように、専用のリソースを使用して操作していないときは、常に輻輳制御操作が観察されます。送信者で混雑制御操作が無効になっている場合でも、Baseline Norm-CCフィードバックメカニズムを使用してグループからフィードバックを収集するためにNorm_CMD（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 (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.
Norm Senderは、アプリケーションで囲まれたデータのセグメント化データをNorm_Dataセグメントに開始し、グループに送信します。型norm_object_dataおよびnorm_object_fileのタイプのオブジェクトの場合、FECビルディングブロック[RFC5052]で説明されているセグメンテーションアルゴリズムが推奨されます。型norm_object_streamタイプのオブジェクトの場合、セグメンテーションは通常、アプリケーションによって制御される個々のセグメントサイズを使用して、均一なFECコーディングブロックサイズになります。ほとんどの場合、アプリケーションと規範の実装は、可能であれば、フルサイズの（標準化）セグメントを生成するよう努力する必要があります。伝送速度は、混雑制御メカニズムを介して制御されるか、閉じたネットワーク操作に必要な場合は固定レートです。マルチキャストグループに参加しているレシーバーは、必要に応じて送信者にフィードバックを提供します。送信者がデータの終了に到達すると、送信または保留中の修理に排出された場合、2*GRTT_SENDERごとに1つのnorm_CMD（フラッシュ）メッセージを1つのレートで送信します。送信中の各送信FECコーディングブロックの最後と同様に、受信機は必要に応じて追加の修理要求を使用してこれらのnorm_cmd（フラッシュ）メッセージに応答するものとします。プロトコルパラメーターnorm_robust_factorは、送信されるフラッシュメッセージの数を決定します。受信者が修理を要求する場合、修理が提供され、修理伝送の終了時にフラッシングが再び発生します。送信者は、受信者のnormnodeidsを含むnorm_cmd（フラッシュ）にオプションの「acking_node_list」を添付することができます。NORM_CMD（フラッシュ）メッセージは、継続的なデータ送信で多重化されたNORM_CMD（フラッシュ）メッセージを使用して送信用にデータが終了する前に、いつでもこのオプションの目的に使用できます。オプションのNORM肯定的な確認手順は、セクション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.
NORM送信者と受信機は、不足しているデータの修復を要求するために適切なNACKを構築できるため、輸送データをFECエンコードブロックとシンボルに論理的にセグメント化するために共通のアルゴリズムを使用する必要があります。NORM FECコーディングブロックは、norm_dataメッセージのペイロードで送信されるマルチバイトシンボル（セグメント）で構成されています。各norm_dataメッセージには、「fec_payload_id」フィールドによって識別される1つ以上のソースまたはエンコードシンボルが含まれ、normsegmentsize senderパラメーターは、コンテンツを含む（ "segment"）を含む「payload_data」フィールドの最大サイズ（バイト）を定義します。FECエンコーディングタイプと関連するパラメーターは、ソースブロックサイズ（コーディングブロックごとのソースシンボルの数など）を管理します。Norm Sendersと受信機は、これらのFECパラメーターを使用し、Normsegmentsize and Transport objectオブジェクトサイズを使用して、輸送オブジェクトのソースブロック構造を計算します。これらのパラメーターは、各オブジェクトのFECオブジェクト伝送情報で提供されます。FECビルディングブロック[RFC5052]ドキュメントで説明されているブロックパーティションアルゴリズムは、すべてのソースブロックが可能な限り等しい長さに近いように、ソースブロック構造の計算に使用するために推奨されます。これにより、「短い」FECブロックのパフォーマンスの欠点を回避できます。このアルゴリズムは、オブジェクトサイズが固定され、事前に決定されている静的なサイズのnorm_object_dataおよびnorm_object_fileトランスポートオブジェクトタイプにのみ適用されることに注意してください。norm_object_streamオブジェクトの場合、FECペイロードIDが特定のブロックの代替サイズを示していない限り、FEC送信情報に与えられた最大ソースブロック長に従ってオブジェクトがセグメント化されます。
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_Dataメッセージを受信すると、バッファリング状態を確立し、指定されたデータ型に適したアプリケーションにコンテンツを提供します。NORMプロトコルにより、受信機がグループに参加して自由に離れることができますが、一部のアプリケーションでは、データ送信の開始前に受信機がグループのメンバーになる必要がある場合があります。したがって、異なるNORMアプリケーションは、異なるポリシーを使用して、セッションの途中でグループに参加する新しいレシーバーの影響を制約する場合があります。たとえば、有用な実装ポリシーは、グループに参加する新しいレシーバーが、すでに進行中の輸送オブジェクトの修理要求を制限または回避するためです。Norm Senderの実装は、グループに参加、去り、再加入することにより、信頼性の高いマルチキャストパフォーマンスを混乱させるレシーバーの能力を制限するための追加の制約を課す可能性があります。さまざまなレシーバー「参加ポリシー」が異なるアプリケーションやシナリオに適している場合があります。汎用操作のために、受信機が最初の非修復型norm_dataまたはグループに参加したときに受信したNORM_INFOメッセージ以上のNORMTRANSPORTIDおよびFECコーディングブロック番号のコーディングブロックのみの修理を要求できるデフォルトポリシーをお勧めします。型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.
一部の展開では、さまざまなマルチキャストレシーバーがネットワーク接続の品質が異なる場合があります。一部のレシーバーは、接続率が低いか、パケット損失が大幅に低下しているため、非常に限られたグッドプットでパフォーマンスが大幅に低下する可能性があります。上記の「参加ポリシーの参加」と同様に、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 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:
受信者が送信者の標準送信からのデータが欠落していることを検出すると、ナッキング手順が開始されます。Nacking手順は、norm_cmd（フラッシュ）メッセージを受信したときに、FECコーディングブロック境界、normobject境界、またはnorm_dataまたはnorm_info送信が以前にアクティブな送信者から受信されなくなった場合にのみ「不活性」タイムアウトでのみ開始されます。このような非アクティブタイムアウトの推奨値は次のとおりです。
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_SENDER値がNORM Senderメッセージの「GRTT」フィールドで宣伝されているGRTT推定値に対応する場合。1秒の最小T_INACTIVITY値をお勧めします。NORMレシーバーは、この不活動タイマーをリセットし、タイムアウト時にNACKの開始を繰り返し、norm_robust_factorの時間以上に応じて、受信機による永続性の必要性に応じて繰り返します。また、送信者が宣伝されているGRTTが変更されるにつれて、T_INACTIVITYタイムアウトをレシーバーが再スケーリングすることも重要です。
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.
ナッキング手順は、ランダムバックオフタイムアウトから始まります。バックオフタイムアウトの期間は、MAXTIMEパラメーターの（k_sender*grtt_sender）を使用して、マルチキャストNACKビルディングブロック[RFC5401]ドキュメントで説明されている「ランダムバックオフ」アルゴリズムを使用して選択されます。Norm Sendersは、送信されたメッセージの「GRTT」、「バックオフ」、および「GSIZE」フィールドを介してGRTT_SENDER、K_SENDER、GSIZE_SENDERの値を提供します。GRTT_SENDERの値は、グループから受け取ったフィードバックに基づいて送信者によって決定されますが、K_SENDERとGSIZE_SENDERの値は、アプリケーションの要件と期待または補助情報によって決定できます。バックオフファクターK_Senderは、効果的なフィードバック抑制を提供するために1つ以上でなければなりません。任意のソースマルチキャスト（ASM）モデルにはk_sender = 4の値が推奨されますが、k_sender = 6の値はシングルソースマルチキャスト（SSM）操作に推奨されます。
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: 1. The sender's current transmit position (in terms of objectTransportId::fecPayloadId) exceeds the earliest repair position of the receiver.
SSM操作中に送信者またはネットワーク障害の場合のNACK爆発の可能性を回避するために、受信者は自動的にNACKを抑制し、T_Backoffが（k_sender-1）*grtt_senderよりも大きい場合に以下に説明する「ホールドオフ」期間を直ちに入力するものとします。それ以外の場合、バックオフ期間が入力され、受信者はnorm_nackメッセージとnorm_cmd（repair_adv）メッセージから外部保留中の修理状態を蓄積する必要があります。バックオフ時間の終了時に、受信者は次の条件が満たされている場合にのみnorm_nackメッセージを生成するものとします。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 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コーディングブロックごとに、受信者はブロックの最初の修理試行時に、最低の順序パリティ「encoding_symbol_id」（すなわち、「encoding_symbol_id "=" source_block_lenen）から始まるFECコーディングブロックのパリティ部分を要求するものとします。"）そして、ブロックのデータセグメント消去数に対応するFEC記号の数を要求します。同じコーディングブロックの後続の修理サイクルでは、受信者は、適用されるコーディングブロックの残りの消去カウントまでまだ受け取っていない最初のセットからそれらの修理記号のみを要求するものとします。注は、地元の受信機の消去済みのニーズを満たすために使用できる他のレシーバーに他の異なる追加のパリティセグメントを送信した可能性があることに注意してください。部分的に受信されたFECコーディングブロックの消去カウントが、ブロックに対して送信者から利用可能なパリティ記号の最大数を超える場合（norm_data "fec_num_parity"フィールドで示されているように）、受信者は利用可能なすべてのパリティセグメントに加えて、ブロックの総消去ニーズを満たすために必要な、通常最も高い欠落データセグメントが必要でした。この戦略の目標は、レシーバー全体のセットが、特定の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 Receiverは、norm_nack_blockまたはnorm_nack_objectフラグを使用して修理要求を作成します。NORM_INFOの再送信のリクエストは、対応する修理要求にnorm_nack_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イベントが発生したときに最適な修復戦略を決定するために使用されます。受信機はコーディングブロックまたはオブジェクトの境界で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
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時間は、レシーバーが1つしかないため、ゼロに設定できます。同様に、k_sender値は、修理レイテンシを最小限に抑えるために、Norm Unicastセッションでゼロに設定する必要があります。
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)
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 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送信者は、可能な限り最大限に修理するために、FECパリティコンテンツの送信を活用する必要があります。受信者は戦略を使用して、norm_nackメッセージの形成において明示的な修復の最低一般的な分母（パリティコンテンツを含む）を要求することを思い出してください。さまざまな受信機の修理ニーズを明示的に満たすことに戻る前に、送信者はFEC生成パリティセグメントの一般的な消去能力を利用できます。送信者は、修理集約期間中に受信したNORM_NACKメッセージから個々のFECコーディングブロックの最大消去充填ニーズを決定できます。次に、送信者が、該当するコーディングブロックで利用可能な以前に安全でないパリティセグメントの十分な数（最大消去率以下）を持っている場合、送信者はレシーバーセットが要求した特定のパケットの代わりにこれらを送信できます。送信者は、特定のコーディングブロックの「新鮮な」（無関心）パリティセグメントの供給を使い果たすまで、受信機セットの修理ニーズの明示的な送信に頼らないでください。一般に、十分に強力なFECコードを使用する場合、明示的な修理の必要性は例外であり、信頼できるマルチキャストの履行を非常に効率的に達成できます。ただし、明示的な修理に頼る機能により、プロトコルを非常に極端な状況でも動作させ続けることができます。
NORM_DATA messages sent as repair transmissions SHALL be flagged with the NORM_FLAG_REPAIR flag. This allows receivers to obey any policies 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_dataの修理送信として送信されたメッセージは、norm_flag_repairフラグにフラグを立てるものとします。これにより、受信者は、修理送信のみが受信された場合に、信頼できる送信の参加を制限する新しいレシーバーを制限するポリシーに従うことができます。さらに、送信者は、norm_flag_explicitフラグを使用して明示的な修復として送信されるnorm_data送信をフラグする必要があります。
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 End System Receiversはnorm_flag_explicitフラグを使用していませんが、このメッセージの伝達ステータスは、Normプロトコルのパフォーマンスを「支援」したい中間システムによって活用される可能性があります。そのようなシステムが相互の逆パスマルチキャストルーティングに関して適切に配置されている場合、特定のFECコーディングブロックに対するマルチキャストルーティングサブツリーの消去充填ニーズを満たすために、非推定パリティ修理の十分なカウントのみをサブキャストする必要があります。送信者が明示的な修理に頼った場合、中間システムは、特定のコーディングブロックの修理を必要とするルーティングツリーの部分にすべての明示的な修理パケットをサブキャストする必要があります。注中級システムは、サブキャストを実行するのに十分な情報を持つために、送信者の修理状態の蓄積と同様の方法で、サブルートの修理状態蓄積を実施する必要があります。さらに、中間システムは、ノルム修復サイクルのこの修復状態の蓄積を実施するため、norm_nack抑制/集約を実行できます。このタイプの操作の詳細は、このドキュメントの範囲を超えていますが、この情報は将来の検討の可能性のために提供されています。
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（scelch）メッセージを生成し、無効なデータの追加のナックから受信機を抑制します。norm_cmd（squelch）メッセージの伝送速度は、2*grtt_senderに1回限定されています。norm_cmd（squelch）メッセージの「invalid_object_list」（該当する場合）は、最後のnorm_cmd（squelch）送信以来受信した無効なnorm_nackメッセージから最低の「object_transport_id」から開始するものとします。リストには、NORM_CMD（Squelch）ペイロードサイズに適合することができる「Object_transport_ids」の低い順序の無効な「Object_transport_ids」が含まれています。
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 Senderの実装では、その送信のソースポートとしてNormsessionポート番号から個別のポート番号を使用できます。したがって、NORMレシーバーは、NORMセッション（または宛先）ポート番号とは異なるこの個別の送信者ポート番号に、ユニキャストフィードバックメッセージを指示できます。次に、Norm Senderの実装は、マルチキャストとユニキャストのフィードバックレシーバーが混在している場合、マルチキャストフィードバックメッセージからユニキャストフィードバックメッセージを区別できます。NORM_CMD（REPARE_ADV）メッセージは、送信者によって設定された受信機へのマルチキャストです。このメッセージのペイロード部分には、norm_nackレシーバーメッセージペイロードと同じ形式のコンテンツがあります。レシーバーは、他の受信機から直接受信したnorm_nackメッセージと同じ方法でフィードバック抑制を実行できます。送信者は、受け取ったNACKコンテンツを単に再送信するだけでなく、その凝集した修復状態の表現を送信することに注意してください。norm_cmd（Repair_Adv）メッセージの送信は、送信者送信レート制限の対象となり、normsegmentsizeの制限があります。norm_cmd（repair_adv）メッセージが最大サイズ（flag norm_repair_adv_flag_limitで示されているように）の場合、受信者は、送信者が現在の伝送位置としてメッセージに埋め込まれた最大順序伝送位置値を考慮し、通常の高い修復の要求を暗黙的に抑制します。輻輳制御操作の場合、送信者は必要な情報を提供する必要があるため、受信機の間で動的な混雑制御フィードバックを抑制できます。このドキュメントは、ベースライン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の保守的な推定値の重みを割り当て、値を滑らかにするアルゴリズムに供給されます。アルゴリズムと方法論は、「1対Many Sender 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 congestion control rate adjustment. NORM operation without congestion control SHOULD be considered only in closed networks.
NORM-CCレートヘッダー拡張機能がNORM_CMD（CC）メッセージに存在する場合、受信機はセクション5.5.2「NORM輻輳制御操作」で説明されているように、NORM_CMD（CC）メッセージに応答します。NORM_CMD（CC）メッセージは、輻輳制御操作について説明されているように、送信者によって定期的に生成されます。これにより、NORM_ACKメッセージの形でグループからのプロアクティブな、しかし制御されたフィードバックが提供されます。これにより、norm_nackメッセージが送信されていない場合でも、GRTTフィードバックが提供されます。閉じたネットワークで混雑制御なしで動作する場合、NORM-CCレートヘッダー拡張なしにNORM_CMD（CC）メッセージを定期的に送信できます。この場合、NORM_ACKメッセージが生成されないため、NORM_NACKメッセージが生成される場合、受信機はGRTT測定フィードバックを提供します。この場合、NORM_CMD（CC）メッセージは、ネットワーク容量を節約するために、おそらく1分に1回だけ送信される頻度で送信される場合があります。注NORM-CCレートヘッダー拡張は、送信者が混雑制御レートの調整を行っていない場合でも、混雑制御操作ごとに受信機グループからのRTTフィードバックを積極的に求めるために使用することもできます。混雑制御のないノルム操作は、閉じたネットワークでのみ考慮する必要があります。
This section describes baseline congestion control operation for the NORM protocol (NORM-CC). The supporting NORM message formats and approach described here are an adaptation of the equation-based TCP-Friendly Multicast Congestion Control (TFMCC) approach [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ベースのアプローチにより、NORM送信者の送信は、TCPのようにウィンドウベースの混雑制御アルゴリズムとは対照的に、レートベースの方法で制御されます。ただし、NORMプロトコルメッセージセットを、PGMCCなどのウィンドウベースのマルチキャスト輻輳制御スキームをサポートするために、代わりに使用する場合があります。このような代替案の詳細は、このドキュメントの将来の改訂で別々に説明できます。どちらの場合でも（レートベースのTFMCCまたはウィンドウベースのPGMCC）、送信者トランスミッションの成功した制御は、送信者から受信者へのパケット損失推定値とRTTの収集に依存して、マルチキャストトポロジ内の混雑制御ボトルネックパスを特定し、調整しますそれに応じて送信者率。損失と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)))
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 =名目上の送信パケットサイズ。（NORMでは、「公称」パケットサイズは、送信されたパケットサイズの指数関数的に加重移動平均（EWMA）として、変動するメッセージサイズを考慮して送信者によって決定できます）。
T_rtt = RTT estimate of the current "current limiting receiver" (CLR).
T_RTT = RTT現在の「現在の制限受信機」（CLR）の推定値。
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 Senderは定期的にNorm_CMD（CC）コマンドメッセージを送信します。norm_cmd（cc）メッセージは、ノルムデータと修理送信で多重化され、いくつかの目的に役立ちます。
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.
Norm_CMD（CC）メッセージの形式は、このドキュメントのセクション4.2.3で説明されています。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）メッセージは、Sender Startupですぐに送信されます。後続の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秒あたり1回の最大値に2倍になります。これにより、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_CLR）の間のRTTに設定されます。
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_Dataメッセージごとに1つ以下の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レートヘッダー拡張機能は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 additional entries in the list based on receiver feedback is prioritized with the following rules:
「CC_NODE_LIST」には、受信機とその現在の混雑制御状態（ステータス「フラグ」、「RTT」、および「損失」の推定値を識別するエントリのリストが含まれています。送信者がグループからまだフィードバックを受け取っていない場合、リストは空になります。送信者がフィードバックを受け取った場合、リストにはCLRを識別するエントリが最小限に含まれます。clrエントリを識別するために、「CC_FLAGS」フィールドにnorm_flag_cc_clrフラグ値が提供されます。CLRエントリが実装効率のためのリストの最初のものになることをお勧めします。リスト内の追加のエントリは、グループ内の受信機に送信者が測定した個々のRTT推定値を提供するために使用されます。このリストの追加のエントリの数は、ユーザーデータメッセージの送信に関して送信者アプリケーションが喜んで送信する制御トラフィックの割合に依存します。リストのより多くのエントリにより、送信者は混雑制御のダイナミクスに対してより敏感になります。リストの長さは、Norm_CMD（CC）メッセージの現在の伝送レートとスケジューリングに従って動的に決定できます。リストの最大長は、セッションの送信者のnormsegmentsizeパラメーターに対応します。受信機フィードバックに基づいてリストに追加のエントリを含めることは、次のルールで優先されます。
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フラグ値は、送信者が即座に抑制されていないフィードバックを持ちたい追加の受信機をマークするために使用されます。これらは、潜在的な将来の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）を受信すると、データ損失の検出に応じてレシーバーが修復サイクルを開始したときに使用されるものと同様のランダムフィードバックバックオフタイムアウトを開始します。混雑制御応答のバックオフタイムアウトは、次のように生成されます。
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 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:
randombackoff（）アルゴリズムは、切り捨てられた指数分布乱数を提供し、マルチキャストNACKビルディングブロック[RFC5401]ドキュメントで説明されています。norm_nack抑制で使用される同じバックオフファクター、k_backoff = k_senderが一般的に推奨されます。ただし、アプリケーションが非常に小さなK_SENDERバックオフファクターを意図的に指定してNACK修復プロセスの遅延を最小限に抑える場合（グループサイズのスケーラビリティを取引）、渋滞制御フィードバックの大きなバックオフ係数を維持することをお勧めします。多くの場合、NACKよりも混雑制御フィードバックの量があり、信頼性の高い配送遅延がない場合、いくつかの混雑制御フィードバックのレイテンシは許容できる可能性があります。前述のように、k_sender = 4のバックオフ係数値は、ASM操作には一般に、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. 通常の「CC_シーケンス」フィールド値を備えたNORM_CMD（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_backoffが1*grtt_senderを超える場合。これにより、送信者またはネットワークの障害が発生した場合の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_NODE_LIST」に含まれていない）は、長期的な有効期限の後、以前の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）メッセージを生成するものとします。このメッセージは、ASMトポロジーの最も効果的な抑制またはNORMプロトコルの展開と構成の方法に応じて送信者にユニキャストするためにグループにマルチキャストされる場合があります。
Whenever any feedback is generated (including this NORM_ACK(RTT) message), receivers include an adjusted version of the sender timestamp from the most recently received NORM_CMD(CC) message and 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_ack（RTT）メッセージを含む）、受信者には、最近受信したNORM_CMD（CC）メッセージと、対応するnorm_ackまたはnorm_nackメッセージフィールドの「cc_sequence」値からの送信者タイムスタンプの調整版が含まれます。NORM-CC操作の場合、生成されたフィードバックメッセージには、NORM-CCフィードバックヘッダー拡張機能も含まれています。受信機は、現在の「CC_RATE」推定値、「CC_LOSS」推定、「CC_RTT」、既知の場合は「CC_RTT」、およびこのヘッダー拡張機能を介して該当する「CC_FLAGS」を提供します。
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_RATE」フィールドの送信者からの測定レートの2倍に等しい値を使用します。定常状態の混雑制御操作の場合、受信機「CC_RATE」値は、現在の損失イベント推定値と送信者<->レシーバーRTT情報を使用して、方程式ベースの値からのものです。（GRTT_SENDERは、レシーバーが個々のRTTをまだ測定していない場合に使用されます。）
The "cc_loss" field value reflects the receiver's current loss event estimate with respect to the sender in question.
「CC_LOSS」フィールド値は、問題の送信者に関するレシーバーの現在の損失イベントの推定値を反映しています。
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」フィールドにこの値を含めるものとします。norm_flag_cc_rttは、「cc_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:
輻輳制御フィードバックメッセージが生成された後、またはフィードバックが抑制されたときに、norm_cmd（cc）メッセージが受信されたとしても、非CLRレシーバーは「ホールドオフ」タイムアウト期間を開始します。送信者（受信がCLRまたはPLRノードとしてマークされない限り）。このホールドオフタイムアウト（T_CCholdoff）期間の値は次のとおりです。
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_Sender*GRTT_SENDER間隔に1回明示的な輻輳制御フィードバックを提供することに制約されています。ただし、セッションが進行するにつれて、異なる受信機が異なる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からのフィードバックによって示されるレートに送信速度を直接調整します。[TFMCCPAPE]に記載されているように、CLRのパラメーター（損失とRTT）の推定は、一般に許容範囲内で可能なレートの変化を制限します。レートの上昇については、送信者は、定常状態の動作中に常にRTTごとに1つのパケットの最大増加率を観察しなければなりません。
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_RATE」から直接決定されるか、フィードバックを受け取ったときに個々のRTTおよび損失推定値（「CC_LOSS」）を使用して方程式ベースの計算を実行します。
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_RESPONSE」タイムスタンプを使用して、レシーバー（RTT_RCVRNEW）の現在のRTTを計算できます。応答の「cc_rtt」値が有効でない場合、送信者はこのrtt_rcvrnew値をレシーバーの現在のRTT（RTT_RCVR）として単純に使用します。非CLRおよび非PLRレシーバーの場合、送信者は、レシーバーのRTTTとして平均化されたレシーバーの以前のRTT測定（RTT_RCVRPREV）として、受信者の以前のRTT測定（RTT_RCVRPREV）としてNORM-CCフィードバックヘッダー拡張機能で提供される「CC_RTT」を使用する必要があります。価値：
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_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_RATE」フィールドの最小レシーバーレートです。スロースタート中に注意して、受信機はフィードバックの「CC_RATE」フィールドで送信者からの測定レートの2倍を使用します。レートの増加調整は、スロースタート中にGRTTごとに1回限定されています。
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が低レートレシーバーに変更されると、送信者はすぐに新しい低レートに調整する必要があります。送信者は、RTTごとに1つの追加パケットで、新しいCLRレートに向けて1つの追加パケットでレートを上げることに制限されています。
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_Sequence」値（SEQ_SENDER）をCLR（SEQ_CLR）から受信した最後の「CC_Sequence」値と比較することにより、CLRから受け取ったフィードバックの年齢を追跡する必要があります。CLRフィードバックの年齢が新しいフィードバックなしで増加するにつれて、送信者は、混雑回避尺度としてRTT_CLRごとに1回そのレートを減らし始めるものとします。次のアルゴリズムを使用して、CLRフィードバックとして送信者率の低下（RSENDERバイト/秒）を決定します。
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_obust_factor連続norm_cmd（cc）がCLRからのフィードバックなしでラウンドした後、送信者はCLRがグループを離れ、新しいCLRとして次の低いレートで受信機を選択したと想定する必要があります。これは、送信者がCLRが意図的にグループを去った明示的な知識を持っていないと仮定していることに注意してください。受信機フィードバックが受信されない場合、送信者は、Norm_Dataセグメントのさらなる送信を差し控え、フィードバックが検出されるまで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.
送信者がデータ送信を中断すると、グループからRTTコレクションを維持するために、Norm_CMD（CC）メッセージでグループをプローブし続けることができます。これにより、送信者はデータ送信の再起動時に適切な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ごとに1回再計算する必要があります。
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フラグを設定する必要があり、グループは、受信者が新しい損失イベントを経験するまでスロースタートの混雑制御手順を観察する必要があります。
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プロトコルに対して定義されたいくつかの具体的な承認要求と、アプリケーションによって定義される可能性のある一連の確認要求タイプがあります。事前定義された承認タイプの1つは、norm_ack（フラッシュ）タイプです。この承認は、受信者が送信者の一連の送信に関する特定の論理送信ポイントを介して信頼できる受信の完了を達成したかどうかを判断するために使用されます。NORM_ACK（フラッシュ）確認は、送信者が受信機セットの一部に関する情報を持っている場合、アプリケーションフロー制御を支援するために使用できます。もう1つの事前定義された承認タイプは、NORM-CC操作のために送信者が送信したNORM_CMD（CC）メッセージに応答して、混雑制御フィードバックを明示的に提供するために使用されるnorm_ack（CC）です。注意NORM_ACK（CC）応答は、ここで説明する肯定的な承認手順に従いません。norm_cmd（ack_req）およびnorm_ackメッセージには、「ack_type」フィールドが含まれており、要求されて提供された承認のタイプを識別します。アプリケーション定義の使用のために、さまざまな「ACK_TYPE」値が提供されます。アプリケーションは、確認要求の開始を担当し、アプリケーション定義の「ack_type」値を解釈しますが、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 Positive Ancountcement手順では、送信者によるポーリングを使用して、レシーバーグループに応答を照会します。このポーリング手順は、非常に大規模な受信機グループにスケーリングすることを意図していませんが、グループの重要なサブセットを照会するために大規模なグループ設定で使用できます。norm_cmd（ack_req）、または該当する場合、norm_cmd（フラッシュ）メッセージがポーリングに使用され、コマンドに応答すると予想されるレシーバーの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.
ACKプロセスは、定期ラウンドでNORM_CMD（フラッシュ）またはNORM_CMD（ACK_REQ）メッセージを生成する送信者によって開始されます。norm_ack（フラッシュ）リクエストの場合、norm_cmd（flush）には、「object_transport_id」と「fec_payload_id」が含まれています。この透かし伝達ポイントは、応答して受信機によって送信されたNORM_ACK（フラッシュ）メッセージの対応するフィールドに反映されています。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メッセージは、通常、送信者にとってユニキャストです。（ノート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. 単一のnorm_cmd（ack_req）メッセージのみが1回（2*grtt_sender）、および
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. normnodeidsの「acking_node_list」のサイズは、承認が要求されるnormnodeidsのサイズに制限されています。
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 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.
付属のリストのサイズは、送信者のnormsegmentsizeの設定に限定されているため、指定されたすべての受信機から応答を達成するために複数のnorm_cmd（ack_req）ラウンドが必要になる場合があります。添付のNormNodeIDリストのコンテンツは、このプロセスが進行し、指定された受信機セットからNORM_ACK応答が受信されると動的に更新されます。送信者が受信機から有効な応答（つまり、ウォーターマークポイントまたは「ACK_ID」を一致させる）を受信すると、後続のNORM_CMD（ACK_REQ）メッセージ「ACKING_NODE_LIST」からそれらの受信機を排除し、保留中のレシーバーNORMNODEIDSを追加しながら、NORMSEGMENTINEの制限内に維持しながら、保留中のレシーバーNORMNODEIDSを追加します。リストサイズ。各レシーバーには、最大回数（norm_robust_factor、デフォルト）が照会されます。この数の繰り返しのリクエスト内で応答しない受信者は、ペイロードリストから削除され、他の潜在的なレシーバーが承認を保留しているためのスペースを確保します。NORM_CMD（ACK_REQ）の送信は、それ以上の応答が不要になるまで、またはすべての保留中の受信機の繰り返ししきい値を超えるまで繰り返されます。norm_cmd（ack_req）またはnorm_cmd（フラッシュ）メッセージの送信は、継続的な送信者データ送信で多重化されます。ただし、norm_cmd（フラッシュ）肯定的な謝辞プロセスは、確認期間中に受信者から受け取った否定的な確認修理要求（NACK）に応じて中断される場合があります。NORM_CMD（フラッシュ）肯定的な謝辞プロセスは、修理が送信された後、承認が保留されているため、受信機のために再起動されます。
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".
添付された「acking_node_list」を備えたnorm_cmd（フラッシュ）コマンドの場合、受信者は、指定された透かし伝達ポイントまでのすべてのデータの完全な送信を受信するまでACKしません。すべてのレシーバーは、nack nack nack nack nackに必要な場合は、norm_cmd（flush）コマンドが添付されていないように、「acking_node_list」を添付していない透かし式ポイントを解釈するものとします。
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プロトコル内でのグループサイズ推定の使用は、正確な推定を必要とせず、推定値が実際のグループサイズの大きさ1桁以内にある場合、合理的にうまく機能します。デフォルトでは、Norm Sender Groupサイズの推定値を管理上構成することができます。また、一般的な使用のためのNORMプロトコルの予想されるスケーラビリティを考えると、グループサイズの推定として使用するには10,000のデフォルト値が推奨されます。また、グループサイズが、指数関数的に重み付けされたランダムバックオフに基づいて、輻輳制御フィードバックメッセージのボリュームからアルゴリズム的に近似される可能性があります。ただし、このようなアルゴリズムの指定は現在、このドキュメントの範囲を超えています。
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 Senderでのみ設定されている必要があり、構成情報はNormヘッダーおよび/またはヘッダー拡張フィールドに設定された受信機に通知されます。これの顕著な例外は、特定のNORMセッションの送信者と受信機の間で一般的な価値のプリセットであると推定されるNORM_OBUST_FACTORです。次の表は、これらの構成可能な要素をまとめたものです。
+--------------------+----------------------------------------------+
| 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_SENDERと呼ばれる）は、NORMプロトコル操作に関連するさまざまなタイマーを設定および拡張するために使用されます。定常状態の動作中、送信者は受信機セットをプローブし、グループラウンドトリップタイミング状態に適応し、関連するNORMプロトコルメッセージの「GRTT」フィールドに設定された受信機に見積もりを宣伝します。ただし、Sender Startupで初期値を想定する必要があります。フィードバックの爆発を防止し、混雑制御操作を開始することに関して、大きな初期見積もりは保守的で安全ですが、送信者と受信機には、特定の伝送速度（つまり、より大きな効果的な遅延*帯域幅製品）により多くのバッファリングリソースを割り当てる必要があります。手術。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 RECOMMENDED; for SSM operation, a default value of K_sender = 6 is RECOMMENDED.
送信者制御されたバックオフファクター（このドキュメントのK_Senderを参照）は、プロトコルタイマーのスケーリングに使用され、タイマーベースのフィードバック抑制を促進するランダムバックオフタイムアウト値の生成に貢献します。送信者は、適用されるノルムメッセージの「バックオフ」フィールドに設定された受信機に構成されたバックオフファクターを宣伝するため、受信機の構成は必要ありません。ASM操作には、k_sender = 4のデフォルト値が推奨されます。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_SENDERと呼ばれる）の送信者推定も、フィードバック抑制タイムアウト値のランダム選択に役割を果たします。送信者は、該当するノルムメッセージの「GSIZE」フィールドに設定された受信機に設定されたグループサイズの見積もりを宣伝します。したがって、受信機の構成は必要ありません。効果的なフィードバック抑制には大まかな推定値（つまり、「マグナンスの順序」）のみが必要であり、ほとんどの用途の保守的な推定としてGSIZE_SENDER = 10,000のデフォルト値が推奨されます。
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_obust_factorは、トランスミッションの洗浄、オプションの肯定的な確認要求などの制御メッセージ（norm_cmdメッセージ）をどのように維持するかを決定する整数パラメーターです。Norm Senderは非アクティブであり、そのようなタイムアウト時に繰り返されるNACK修復要求を自己把握するために持続的にどれだけ持続的にどの程度開催されるかを決定する要因を使用する場合があります。このパラメーターは、NORMプロトコルメッセージヘッダーでは通知されず、特定のNORMセッションの送信者と受信機の間で一貫した値にプリセットされると推定されます。NORM_OBUST_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.
もう1つのノルム送信者構成要素は、norm_dataメッセージコンテンツをエンコードするために使用されるFECタイプです。FECタイプは、送信者から、関連するノルムメッセージヘッダーの「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.
Sender normsegmentsize設定は、Norm_Dataのペイロード部分の最大サイズと、送信者が送信する他のメッセージを決定します。さらに、受信機から特定の送信者へのフィードバックメッセージのペイロードサイズは、その送信者の標準化に限定されます。Normsegmentsizeは、Norm、UDP、およびIPプロトコルメッセージヘッダーのオーバーヘッドが追加されているため、予想されるネットワークMTU制限と互換性があるように構成する必要があります。さらに、MTUの発見が送信者によって採用され、適切な規範化を決定することができます。特定の送信者のNormsegmentsizeは、適用された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.
技術的には構成可能な要素ではありませんが、受信機には、元のコンテンツを適切にバッファー、デコード、再組み立てするために、送信されたnormobjectsがFECオブジェクト伝送情報が必要です。ゆるく整理されたNORMプロトコルセッションの場合、送信者は、ext_ftiヘッダー拡張機能をnorm_dataおよびnorm_info（該当する場合は該当する場合）メッセージに適用して、受信者が事前の調整なしにこの情報を取得できるようにすることができます。実装では、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 = 0xffffffffの値は予約されており、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マルチキャストプロトコルの実装が対象となる脆弱性に加えて、悪意のあるホストは、NORM送信者が信頼できる送信で前進することを防ぐために、過度のナックに関与する可能性があります。セクション5.2で説明されているように、そのようなアクティビティが検出された場合、レシーバー「結合」および「サービス」ポリシー施行を適用できます。暗号化のピア認証、整合性チェック、および/または機密保持メカニズムの使用を使用して、不正なホストからの不快な送信からより効果的な保護を提供できます。しかし、場合によっては、認証と整合性のチェックがあっても、NORMのNACKベースのフィードバックは、Norm Senderが不必要に修理情報を送信することを強制するリプレイ攻撃によって活用される可能性があります。これは、この潜在的なセキュリティの搾取を防ぐネットワーク層の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]、およびセキュリティペイロード（ESP）プロトコルまたは認証ヘッダー（AH）拡張機能をカプセル化するIPSECは、NORM参加者が送信するIPパケットを保護するために使用できます。IPSECを使用してノルム操作を保護するためのベースラインアプローチを以下に説明します。この仕様の準拠の実装は、セクション7.1で説明されているように、IPSEC使用と互換性がある必要があります。IPSECは、ノルムメッセージを含むパケットのピア認証、整合性保護、および/または暗号化を提供するために使用できます。
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）は、ノルムメッセージのセキュリティのためにIPSECの代替案を提供するために、セキュリティメカニズムによって使用するために予約されています。このヘッダー拡張機能とその処理の形式は、このドキュメントの範囲外であり、セッションの説明の一部として帯域外に伝えられます。ext_authの実装は、ピア認証と整合性の保護だけでなく、ノルムメッセージペイロードの暗号化も提供する可能性があります。IPSECと比較したこのアプローチの使用により、ヘッダー圧縮技術をIPおよびNORMプロトコルヘッダーに共同で適用できます。セキュリティ分析により、NORMプロトコルヘッダーコンテンツの暗号化が有益または必要であると考える場合、IPSEC ESPの前述の使用がより適切かもしれません。さらに、ext_Authヘッダー拡張機能は、IPSEC AH拡張機能の使用と互換性のないネットワークアドレス変換（NAT）システムを備えたネットワークでNORMが実装されている場合に使用できます。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.
また、サービスを混乱させるために、あるノルムセッションから別のセッションに認証されたパケットを移植する可能性を考慮する必要があります。この潜在能力を回避するには、セッションごとに一意のキーを割り当てる必要があります。または、セッションのセキュリティ協会の一部として管理されている一意の「Instance_ID」識別子を使用するように、NORM SENDERノードを構成する必要があります。
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 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.
注NORMの実装は、Norm Commonメッセージヘッダーの「シーケンス」フィールドを使用して、リプレイ攻撃を検出できます。これは、NORM送信者が積極的にナッキングレシーバーで状態を維持している場合に達成できます。このようなレシーバー状態のキャッシュを使用して、NACKリプレイ攻撃に対する保護を提供できます。また、NORM受信機は、ASM操作における他の受信者メッセージの可能なリプレイに対する保護のために、同様の状態を維持する必要があります。たとえば、特定のレシーバーメッセージを再生することにより、受信機を抑制することができます。これらの理由により、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）[RFC453555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555年までに説明されているような自動化された主要な管理メカニズムが使用されます。]仕様を適用する必要があります。
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はScalabilityのために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セキュリティプロトコルの適用に基づいた安全なノルムプロトコル操作のベースラインモードについて説明します。このアプローチは、ベースラインの相互運用可能な安全な動作モードを提供するためにここに文書化されています。この特定のアプローチは、達成できる保証レベルでのトレードオフの1つを表し、現在のIPSECメカニズムとそれらをサポートするために必要な状態を与えられたマルチキャストグループサイズのスケーラビリティを表しています。たとえば、このベースラインアプローチは、送信者へのフィードバックメッセージのレシーバーセット間で共有されるセキュリティ協会の使用を指定します。このモデルでは、セッションキーを受け取る受信機メンバーシップが信頼されており、NORMグループメンバーシップの外部の攻撃からのみ保護を提供する必要があります。より高いレベルのIPSECアプローチと主要な管理スキームは、より高いレベルの保証に適用される場合がありますが、これらはこの輸送プロトコル仕様の範囲を超えています。IPSECアプリケーションの他の形式を含む規範セキュリティへの追加のアプローチは、将来的に指定される場合があります。たとえば、ext_authヘッダー拡張機能を使用すると、指定されて挿入されたIPSECのヘッダーと同様の標準固有の認証またはセキュリティカプセル化ヘッダーが可能になります。これにより、ヘッダー圧縮技術を、必要に応じて、必要に応じてRTP [RFC3550]と同様の方法で、および安全なリアルタイムプロトコル（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操作に適用できます。ここでは、単一の送信者があり、受信機がユニキャストフィードバックを提供しています。この形式のNORM操作により、管理可能な数のセキュリティ協会（SA）でIPSECを使用できます。
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.
受信機からのユニキャストフィードバックを備えたNorm-1-Many SSM操作の場合、各ノードは、2つのトランスポートモードIPSECセキュリティアソシエーションと対応するセキュリティポリシーデータベース（SPD）エントリで構成されなければなりません。1つのエントリは、Sender-to-Groupマルチキャストパケット認証とオプションの暗号化に使用されますが、もう1つのエントリは、受信者から送信者へのユニキャストフィードバックメッセージングのセキュリティを提供するために使用されます。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).
各規範について、NORM送信者は、ESPプロトコル[RFC4303]操作用に構成されたIPSEC SAを使用して、データオリジン認証を有効にするオプションを使用します。また、このIPSEC ESP SAは、NORMプロトコルメッセージを含むIPパケットの機密保護を提供するように構成されていることもお勧めします。これは、複雑なリプレイ攻撃の実現をはるかに困難にするために提案されています。このSAの暗号化キーは、NORMプロトコル操作の前に、送信者と受信機で事前に行われるものとします。SAのシーケンススペースの有効期限が切れる前に、Rekeyが必要であるため、自動化されたキー管理の使用が推奨されます。これが必要なため、受信機は単一のソース（NORM送信者）を備えたIPSEC SAに可能な内蔵IPSECリプレイ攻撃保護を使用できます。したがって、受信機は、NORM送信者のトラフィックを確保するために使用されるこのSAのリプレイ攻撃保護を有効にする必要があります。IPSEC SPDエントリは、該当するもの（Normsession）のセッション（宛先）および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 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.
NORMレシーバーは、SAおよびSPDエントリで構成して、送信者からIPSECで配置されたパケットを適切に処理する必要があります。NORMレシーバーは、データオリジネーション認証を有効にするためのオプションを使用して、ESP操作用に構成された共通の2番目のIPSEC SA（Common Security Parameter Index（SPI）および暗号化キー）を使用するものとします。Norm Senderと同様に、このIPSEC ESP SAは、NORMプロトコルメッセージを含むIPパケットの機密保護を提供するように構成されていることをお勧めします。受信機には、この2番目のSAを使用してNORM SENDERソースアドレスとポート番号に向けられたアウトバウンドNORM/UDPパケットを処理するように構成されたIPSEC SPDエントリが必要です。ノルムユニキャストフィードバックをサポートするには、IP宛先アドレスへのアクセスが不可能な場合、ユニキャストとマルチキャストのフィードバックメッセージを識別できるように、マルチキャストセッションポート番号とは異なるように送信者の送信ポート番号を選択する必要があります（例：ユーザー空間標準実装）。受信機からのパケットを処理するには、レシーバーからのメッセージを適切に処理するために、この一般的な2番目のSA（および対応するSPDエントリが必要）でNORM送信者を構成するものとします。
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を使用する複数の受信機（つまり、多くの1対1）は、通常、現在のIPSEC実装を備えたNORM送信者による組み込みのIPSECリプレイ攻撃保護の使用を防ぎます。したがって、特定のIPSEC実装がソースごとにリプレイ保護を管理しない限り（既存のIPSEC実装の典型ではない）、送信者のこの2番目のSAの組み込みIPSECリプレイ攻撃保護を無効にする必要があります。したがって、完全に安全な動作モードをサポートするには、NORM Senderの実装は、受信機からのNORMプロトコルメッセージの「シーケンス」フィールドに基づいてリプレイ攻撃保護を提供する必要があります。これは、このフィールドのサイズ（16ビット）が限られている場合でも、セキュリティの高い保証で達成できます。
1. NORM receiver NACK and non-CLR ACK feedback messages are sparse.
1. Norm Receiver 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の生成（Squelch）が制限されている）に大きな影響を与えることはなく、実際には無視される可能性があります。これは、送信者が現在の修理ウィンドウの前にあるリプレイ攻撃状態をプルンできることを意味します。
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_Sequence」、またはNORM_CMD（フラッシュ）に応答して送信された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 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.
安全な規範プロトコル操作のためにESPの機密性を使用することで、敵があらゆる形態のリプレイ攻撃を実施することがより困難になります。さらに、完全なESPプロトコルヘッダーにアクセスできるNORM送信者の実装は、ESPシーケンス情報を使用して、既存のIPSEC実装が通常提供しないというソースごとのESPシーケンス状態を維持することにより、リプレイ攻撃保護をさらに堅牢にすることもできます。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ペアが確立されている場合、複数の送信者とのノルムプロトコルセッションに使用できます。小規模なグループの場合、各参加者が一意のSA（一意のSPIを使用）を使用する場合、多くの（ASM）IPSEC構成を達成できます。この場合、送信者は、レシーバーフィードバックメッセージの単一の共有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.
規範セキュリティに対するこのベースラインアプローチの早期展開において、主要な管理がノルムプロトコル操作に関して帯域外に行われることが予想されます。1対多くのNORM操作の場合、受信機は必要に応じて中央サーバーからキーイング情報を取得するか、同様の集中アプローチでグループキーの更新を実施する可能性があります。あるいは、REKEYメッセージのいくつかの主要な管理スキームを、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.
実装は、SPDのセレクターとして、ソースアドレス、宛先アドレス、プロトコル（UDP）、およびUDPポート番号を使用できる必要があります。
IPsec in transport mode MUST be supported. The use of IPsec [RFC4301] processing for secure NORM traffic MUST be configured such that unauthenticated packets are not received by the NORM protocol implementation.
輸送モードのIPSECをサポートする必要があります。安全なノルムトラフィックのためのIPSEC [RFC4301]処理の使用は、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]などのグループキーディストリビューションと再キーイングの自動化されたキー管理スキームを使用することをお勧めします。注キーアップデートメッセージ（GDOI GroupKey-Pushメッセージなど）は、NORMアプリケーションと主要な管理デーモンの間で適切なインターフェイスが利用可能な場合、NORMアプリケーションの信頼できるデータ送信の一部として含めることができます。比較的短命のノルムセッションは、特に拡張シーケンス番号（ESN）[RFC4303]が使用されているIPSEC実装で利用可能な場合、単一の事前に前状のキーを使用して手動キーイングを使用できる場合があります。手動キーを使用する場合、手動キーの使用に適した暗号化アルゴリズムが選択されることが重要です。
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登録の対象となります。それらは、http://www.iana.orgから入手可能な「信頼性の高いマルチキャストトランスポート（RMT）NORMプロトコルパラメーター」という名前のレジストリにあります。
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登録が必要です。FECコーデックの登録手順はRFC 5052で提供されています。将来（たとえば、追加の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 Header拡張タイプ、ストリーム制御コード、およびnorm_cmdメッセージサブタイプの3つのレジストリを紹介します。このセクションでは、これらのそれぞれの明示的なIANA割り当てガイドラインについて説明します。
This document defines a registry for NORM Header Extensions named "NORM Header Extension Types".
このドキュメントでは、「Norm Header Extensionタイプ」という名前の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拡張機能」レジストリ内で割り当てることができる値は、範囲{0、255}の数値インデックスであり、境界が含まれています。範囲内の値{0,127}は、可変長の拡張ヘッダーフィールドを示し、範囲{128,255}の値は、固定された4バイトの長さの拡張を示します。この仕様は、次のノルムヘッダー拡張タイプを登録します。
+-------+----------+--------------------+
| 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 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 Stream Controlコードは、NORM_OBJECT_STREAM配信オブジェクト内に挿入できる16ビット値です。これらの制御コードは、ストリーム内に挿入された位置に関して、信頼できる配信でアプリケーションまたはプロトコルの実装に配信されます。この仕様は、次のノルムストリーム制御コードを登録します。
+-------+-----------------+--------------------+
| 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メッセージ「サブタイプ」フィールドは、1〜255の範囲で有効な値を持つ8ビット値です。注値0は、無効なnorm_cmdメッセージサブタイプを示すために予約されています。現在の仕様では、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 |
+-------+-----------------------+--------------------+
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_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.
この仕様では、輸送にnormsを使用して個々のアプリケーションの裁量で使用するための「アプリケーション定義」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は、ネットワークトラフィックの爆発とプロトコルのオーバーヘッド効率にある程度の関心を持つ、マルチキャストアプリケーションにシンプルで柔軟なフレームワークを提供します。NORMのようなプロトコルは、大規模なグループの受信機と信頼できる「プッシュ」アプリケーションを提供する気象衛星圧縮画像更新など、バルクデータ普及アプリケーションのMBONE内で正常に実証されています。
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 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.
さらに、このフレームワークアプローチにはいくつかの設計機能があり、非対称およびワイヤレスインターネットワークアプリケーションでのバルク転送に魅力的です。NORMは、ネットワーク構造とは独立して、パケット損失、遅延、秩序外の配信が高い環境で正常に動作することができます。ハイブリッドプロアクティブ/リアクティブ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_object_streamのnorm_flag_msg_startを削除し、norm_object_stream norm_dataペイロードのfec-encoded preambleの「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送信者レートに対するノルム受信フィードバックメッセージレートの制限の削除（これにより、高速動作における混雑制御障害が発生しました。TCPと比較したNORMプロトコルの非常に低いフィードバックレートは、[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.
著者は、リック・ジョーンズ、ヴィンセント・ロカ、ロッド・ウォルシュ、トニ・パイラ、マイケル・ルビー、ジョーグ・ウィドマーの貴重な入力とこの文書に関するコメントに感謝したいと思います。著者はまた、RMTワーキンググループの椅子、ロジャー・カーモードとロレンツォ・ヴィジサノに、この仕様の開発を支援してくれたこと、そしてこの文書への早期入力についてサリー・フロイドに感謝したいと思います。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年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 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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用のソース固有のマルチキャスト」、RFC 4607、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 Globecomm、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。964、1998年3月/4月。
[MdpToolkit] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol (MDP) Toolkit", Proc. IEEE MILCOM, October 1999.
[Mdptoolkit] Macker、J。およびB. Adamson、「マルチキャスト普及プロトコル（MDP）Toolkit」、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 Globecomm、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.
[PGMCCPAPE] 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、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、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、「The Group Domain of Strettation」、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 3550、2003年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、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年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、「Mikey：Multimedia Internet Keying」、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 3940、2004年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：Group Secure Association Key Management Protocol」、RFC 4535、2006年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：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445] Watson、M。、「基本的なフォワードエラー補正（FEC）スキーム」、RFC 5445、2009年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。Infocomm、San Francisco 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.
[TFMCCPAPE] Widmer、J。およびM. Handley、「式ベースの輻輳制御をマルチキャストアプリケーションに拡張」、ACM Sigcomm、2001年8月。
Authors' Addresses
著者のアドレス
Brian Adamson Naval Research Laboratory Washington, DC 20375 USA
ブライアンアダムソン海軍研究所ワシントンDC 20375米国
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 D-28334 Bremen Germany
EMail: cabo@tzi.org
Mark Handley University College London Gower Street London WC1E 6BT UK
マークハンドリー大学カレッジロンドンガワーストリートロンドンWC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375 USA
ジョーマッカー海軍研究所ワシントンDC 20375米国
EMail: macker@itd.nrl.navy.mil