[要約] RFC 3940は、NACK指向の信頼性のあるマルチキャスト（NORM）プロトコルに関するものであり、マルチキャスト通信における信頼性と効率性を向上させることを目的としています。
Network Working Group B. Adamson
Request for Comments: 3940 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
否定応答 (NACK) 指向の信頼できるマルチキャスト (NORM) プロトコル
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネット コミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準も指定しません。改善のための議論と提案が求められます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design.
この文書では、否定応答 (NACK) Oriented Reliable Multicast (NORM) プロトコルのメッセージと手順について説明します。このプロトコルは、汎用 IP マルチキャスト ルーティングおよび転送サービスを介してバルク データ オブジェクトまたはストリームのエンドツーエンドの信頼できるトランスポートを提供するように設計されています。NORM は、トランスポートの信頼性を確保するために選択的な否定応答メカニズムを使用し、送信者と受信者の間で最小限の「事前」調整による動作を可能にする追加のプロトコル メカニズムを提供します。輻輳制御スキームは、NORM プロトコルが伝送制御プロトコル (TCP) などの他のトランスポート プロトコルと利用可能なネットワーク帯域幅を公平に共有できるように指定されています。送信者と受信者間の相互マルチキャスト ルーティングと、送信者と受信者間の非対称接続 (おそらくユニキャスト リターン パス) の両方で動作できます。このプロトコルは、さまざまな種類のアプリケーションや、場合によっては他の高レベルのトランスポート プロトコルがそのサービスをさまざまな方法で利用できるようにするための多くの機能を提供します。このプロトコルは、FEC ベースの修復とその他の IETF の信頼性の高いマルチキャスト トランスポート (RMT) ビルディング ブロックの使用を設計に活用しています。
Table of Contents
目次
1. Introduction and Applicability. . . . . . . . . . . . . . . . 3
1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . 4
1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . 6
1.3. Environmental Requirements and Considerations. . . . . . 7
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7
2.1. Protocol Operation Overview. . . . . . . . . . . . . . . 9
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . 10
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . 11
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. NORM Common Message Header and Extensions. . . . . . . . 14
4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . 16
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . 16
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . 24
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . 26
4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . 43
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . 43
4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . 50
4.4. General Purpose Messages . . . . . . . . . . . . . . . . 52
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . 52
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 52
5.1. Sender Initialization and Transmission . . . . . . . . . 54
5.1.1. Object Segmentation Algorithm . . . . . . . . . . 55
5.2. Receiver Initialization and Reception. . . . . . . . . . 57
5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . 57
5.4. Sender NACK Processing and Response. . . . . . . . . . . 59
5.4.1. Sender Repair State Aggregation . . . . . . . . . 60
5.4.2. Sender FEC Repair Transmission Strategy . . . . . 61
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . 62
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . 62
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . 63
5.5.1. Greatest Round-trip Time Collection . . . . . . . 63
5.5.2. NORM Congestion Control Operation . . . . . . . . 64
5.5.3. NORM Positive Acknowledgment Procedure. . . . . . 72
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . 74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 75
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1. Normative References. . . . . . . . . . . . . . . . . . 76
10.2. Informative References. . . . . . . . . . . . . . . . . 77
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 79
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 80
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol is designed to provide reliable transport of data from one or more sender(s) to a group of receivers over an IP multicast network. The primary design goals of NORM are to provide efficient, scalable, and robust bulk data (e.g., computer files, transmission of persistent data) transfer across possibly heterogeneous IP networks and topologies. The NORM protocol design provides support for distributed multicast session participation with minimal coordination among senders and receivers. NORM allows senders and receivers to dynamically join and leave multicast sessions at will with minimal overhead for control information and timing synchronization among participants. To accommodate this capability, NORM protocol message headers contain some common information allowing receivers to easily synchronize to senders throughout the lifetime of a reliable multicast session. NORM is designed to be self-adapting to a wide range of dynamic network conditions with little or no pre-configuration. The protocol is purposely designed to be tolerant of inaccurate timing estimations or lossy conditions that may occur in many networks including mobile and wireless. The protocol is also designed to exhibit convergence and efficient operation even in situations of heavy packet loss and large queuing or transmission delays.
否定応答 (NACK) Oriented Reliable Multicast (NORM) プロトコルは、IP マルチキャスト ネットワーク上で 1 つ以上の送信者から受信者のグループへの信頼性の高いデータ転送を提供するように設計されています。NORM の主な設計目標は、異種の可能性がある IP ネットワークおよびトポロジ全体で、効率的でスケーラブルかつ堅牢なバルク データ (コンピュータ ファイル、永続データの送信など) 転送を提供することです。NORM プロトコル設計は、送信者と受信者間の最小限の調整で分散マルチキャスト セッションへの参加をサポートします。NORM を使用すると、送信者と受信者は、参加者間の制御情報とタイミング同期のためのオーバーヘッドを最小限に抑えながら、マルチキャスト セッションに動的に参加および自由に離脱できます。この機能に対応するために、NORM プロトコル メッセージ ヘッダーにはいくつかの共通情報が含まれており、信頼性の高いマルチキャスト セッションの存続期間中、受信者が送信者と簡単に同期できるようになります。NORM は、事前構成をほとんどまたはまったく行わなくても、広範囲にわたる動的なネットワーク条件に自己適応するように設計されています。このプロトコルは、モバイルやワイヤレスを含む多くのネットワークで発生する可能性のある不正確なタイミング推定や損失の多い状況に耐えられるように意図的に設計されています。このプロトコルは、大量のパケット損失や大きなキューイングまたは送信遅延が発生する状況でも、収束と効率的な動作を示すように設計されています。
This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [1]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書は IETF RMT WG の成果物であり、RFC 3269 [1] で提供されるガイドラインに従っています。この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [2] に記載されているように解釈されます。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモには、RFC 2357 に従って信頼性の高いマルチキャスト トランスポート プロトコルを完全に指定するために必要な定義の一部が含まれています。RFC 2357 に従って、インターネットで信頼性の高いマルチキャスト プロトコルを使用するには、適切な輻輳制御スキームが必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームが利用可能になるか、既存のスキームが適切であることが証明されるのを待つ間、高信頼性マルチキャスト トランスポート ワーキング グループ (RMT) は、このコメント募集を「実験」カテゴリで公開します。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT の目的は、上記の条件が満たされ次第、この仕様を IETF 提案標準として再提出することです。
A NORM protocol instance (NormSession) is defined within the context of participants communicating connectionless (e.g., Internet Protocol (IP) or User Datagram Protocol (UDP)) packets over a network using pre-determined addresses and host port numbers. Generally, the participants exchange packets using an IP multicast group address, but unicast transport may also be established or applied as an adjunct to multicast delivery. In the case of multicast, the participating NormNodes will communicate using a common IP multicast group address and port number that has been chosen via means outside the context of the given NormSession. Other IETF data format and protocol standards exist that may be applied to describe and convey the required "a priori" information for a specific NormSession (e.g., Session Description Protocol (SDP) [7], Session Announcement Protocol (SAP) [8], etc.).
NORM プロトコル インスタンス (NormSession) は、参加者が事前に決定されたアドレスとホスト ポート番号を使用してネットワーク上でコネクションレス (インターネット プロトコル (IP) やユーザー データグラム プロトコル (UDP) など) パケットを通信するコンテキスト内で定義されます。一般に、参加者は IP マルチキャスト グループ アドレスを使用してパケットを交換しますが、マルチキャスト配信の付属物としてユニキャスト トランスポートを確立または適用することもできます。マルチキャストの場合、参加している NormNode は、指定された NormSession のコンテキスト外の手段で選択された共通の IP マルチキャスト グループ アドレスとポート番号を使用して通信します。特定の NormSession に必要な「事前」情報を記述および伝達するために適用できる他の IETF データ形式およびプロトコル標準も存在します (例: セッション記述プロトコル (SDP) [7]、セッション アナウンスメント プロトコル (SAP) [8]、等。）。
The NORM protocol design is principally driven by the assumption of a single sender transmitting bulk data content to a group of receivers. However, the protocol MAY operate with multiple senders within the context of a single NormSession. In initial implementations of this protocol, it is anticipated that multiple senders will transmit independent of one another and receivers will maintain state as necessary for each sender. However, in future versions of NORM, it is possible that some aspects of protocol operation (e.g., round-trip time collection) may provide for alternate modes allowing more efficient performance for applications requiring multiple senders.
NORM プロトコルの設計は主に、単一の送信者が大量のデータ コンテンツを受信者のグループに送信するという想定によって推進されます。ただし、このプロトコルは、単一の NormSession のコンテキスト内で複数の送信者と動作してもよい(MAY)。このプロトコルの初期実装では、複数の送信者が互いに独立して送信し、受信者が各送信者の必要に応じて状態を維持することが予想されます。ただし、NORM の将来のバージョンでは、プロトコル動作の一部の側面 (往復時間の収集など) が、複数の送信者を必要とするアプリケーションのより効率的なパフォーマンスを可能にする代替モードを提供する可能性があります。
NORM provides for three types of bulk data content objects (NormObjects) to be reliably transported. These types include:
NORM は、確実に転送される 3 種類のバルク データ コンテンツ オブジェクト (NormObject) を提供します。これらのタイプには次のようなものがあります。
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 should be allocated for received content (i.e., memory or file storage). Other than that distinction, the two are identical, providing for reliable transport of finite (but potentially very large) units of content. These static data and file services are anticipated to be useful for multicast-based cache applications with the ability to reliably provide transmission of large quantities of static data. Other types of static data/file delivery services might make use of these 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 の信頼性の高いストリーム サービスは、シリアル化された信頼性の高いメッセージングや、おそらく動的に生成されるその他の無制限のコンテンツなど、さらなる可能性を開きます。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 designed to be atomic in that its size MUST fit into the payload portion of a single NORM message.
NORM プロトコルでは、送信者によって送信されるデータ コンテンツ オブジェクトに少量の「帯域外」データ (NORM_INFO メッセージとして送信) を添付することもできます。このすぐに利用できる「帯域外」データにより、マルチキャスト受信者は、送信されている対応するデータ、ファイル、またはストリームのバルク コンテンツの性質を迅速かつ効率的に判断できます。これにより、現在のトランスポート アクティビティへの受信ノードの参加をアプリケーション レベルで制御できるようになります。これにより、送信者と受信者間の事前調整を最小限に抑えて、プロトコルを柔軟にすることもできます。NORM_INFO コンテンツは、そのサイズが単一の NORM メッセージのペイロード部分に収まらなければならないという点でアトミックになるように設計されています。
NORM does _not_ provide for global or application-level identification of data content within in its message headers. Note the NORM_INFO out-of-band data mechanism could be leveraged by the application for this purpose if desired, or identification could alternatively be embedded within the data content. NORM does identify transmitted content (NormObjects) with transport identifiers that are applicable only while the sender is transmitting and/or repairing the given object. These transport data content identifiers (NormTransportIds) are assigned in a monotonically increasing fashion by each NORM sender during the course of a NormSession. Each sender maintains its NormTransportId assignments independently so that individual NormObjects may be uniquely identified during transport with the concatenation of the sender session-unique identifier (NormNodeId) and the assigned NormTransportId. The NormTransportIds are assigned from a large, but fixed, numeric space in increasing order and may be reassigned during long-lived sessions. The NORM protocol provides mechanisms so that the sender application may terminate transmission of data content and inform the group of this in an efficient manner. Other similar protocol control mechanisms (e.g., session termination, receiver synchronization, etc.) are specified so that reliable multicast application variants may construct different, complete bulk transfer communication models to meet their goals.
NORM は、メッセージ ヘッダー内のデータ コンテンツのグローバルまたはアプリケーション レベルの識別を提供しません。必要に応じて、NORM_INFO アウトオブバンド データ メカニズムをアプリケーションでこの目的に利用することも、代わりにデータ コンテンツ内に ID を埋め込むこともできることに注意してください。NORM は、送信者が特定のオブジェクトを送信および/または修復している間にのみ適用されるトランスポート識別子を使用して、送信されたコンテンツ (NormObject) を識別します。これらのトランスポート データ コンテンツ識別子 (NormTransportIds) は、NormSession の過程で各 NORM 送信者によって単調増加方式で割り当てられます。各送信者は、送信者のセッション固有の識別子 (NormNodeId) と割り当てられた NormTransportId を連結することで、転送中に個々の NormObject を一意に識別できるように、NormTransportId の割り当てを独立して維持します。NormTransportId は、大きいが固定された数値スペースから昇順に割り当てられ、長時間存続するセッション中に再割り当てされる場合があります。NORM プロトコルは、送信側アプリケーションがデータ コンテンツの送信を終了し、そのことを効率的な方法でグループに通知できるメカニズムを提供します。他の同様のプロトコル制御メカニズム (セッション終了、受信機の同期など) は、信頼性の高いマルチキャスト アプリケーションのバリアントが、目的を達成するために異なる完全な一括転送通信モデルを構築できるように指定されています。
To summarize, the NORM protocol provides reliable transport of different types of data content (including potentially mixed types). The senders enqueue and transmit bulk content in the form of static data or files and/or non-finite, ongoing stream types. NORM senders provide for repair transmission of data and/or FEC content in response to NACK messages received from the receiver group. Mechanisms for "out-of-band" information and other transport control mechanisms are specified for use by applications to form complete reliable multicast solutions for different purposes.
要約すると、NORM プロトコルは、さまざまなタイプのデータ コンテンツ (タイプが混在している可能性も含む) の信頼できる転送を提供します。送信者は、静的データまたはファイル、および/または非有限の進行中のストリーム タイプの形式でバルク コンテンツをキューに入れて送信します。NORM 送信側は、受信側グループから受信した NACK メッセージに応答して、データおよび/または FEC コンテンツの修復送信を提供します。「帯域外」情報のメカニズムとその他のトランスポート制御メカニズムは、さまざまな目的に合わせて完全で信頼性の高いマルチキャスト ソリューションを形成するためにアプリケーションで使用するために指定されています。
Group communication scalability requirements lead to adaptation of negative acknowledgment (NACK) based protocol schemes when feedback for reliability is required [9]. NORM is a protocol centered around the use of selective NACKs to request repairs of missing data. NORM provides for the use of packet-level forward error correction (FEC) techniques for efficient multicast repair and optional proactive transmission robustness [10]. FEC-based repair can be used to greatly reduce the quantity of reliable multicast repair requests and repair transmissions [11] in a NACK-oriented protocol. The principal factor in NORM scalability is the volume of feedback traffic generated by the receiver set to facilitate reliability and congestion control. NORM uses probabilistic suppression of redundant feedback based on exponentially distributed random backoff timers. The performance of this type of suppression relative to other techniques is described in [12]. NORM dynamically measures the group's roundtrip timing status to set its suppression and other protocol timers. This allows NORM to scale well while maintaining reliable data delivery transport with low latency relative to the network topology over which it is operating.
グループ通信のスケーラビリティ要件により、信頼性のためのフィードバックが必要な場合、否定応答 (NACK) ベースのプロトコル スキームの適応が必要になります [9]。NORM は、欠落データの修復を要求するための選択的 NACK の使用を中心としたプロトコルです。NORM は、効率的なマルチキャスト修復とオプションのプロアクティブな送信堅牢性のために、パケット レベルの前方誤り訂正 (FEC) 技術の使用を提供します [10]。FEC ベースの修復を使用すると、NACK 指向のプロトコルにおける信頼できるマルチキャスト修復リクエストと修復送信の量を大幅に削減できます [11]。NORM スケーラビリティの主な要因は、信頼性と輻輳制御を容易にするために受信機セットによって生成されるフィードバック トラフィックの量です。NORM は、指数関数的に分散されたランダム バックオフ タイマーに基づいて、冗長なフィードバックを確率的に抑制します。他の技術と比較したこのタイプの抑制のパフォーマンスについては、[12] で説明されています。NORM は、グループのラウンドトリップ タイミング ステータスを動的に測定して、その抑制およびその他のプロトコル タイマーを設定します。これにより、NORM は、動作しているネットワーク トポロジに比べて遅延が少なく、信頼性の高いデータ配信トランスポートを維持しながら、適切に拡張できます。
Feedback messages can be either multicast to the group at large or sent via unicast routing to the sender. In the case of unicast feedback, the sender "advertises" the feedback state to the group to facilitate feedback suppression. In typical Internet environments, it is expected that the NORM protocol will readily scale to group sizes on the order of tens of thousands of receivers. A study of the quantity of feedback for this type of protocol is described in [13]. NORM is able to operate with a smaller amount of feedback than a single TCP connection, even with relatively large numbers of receivers. Thus, depending upon the network topology, it is possible that NORM may scale to larger group sizes. With respect to computer resource usage, the NORM protocol does _not_ require that state be kept on all receivers in the group. NORM senders maintain state only for receivers providing explicit congestion control feedback. NORM receivers must maintain state for each active sender. This may constrain the number of simultaneous senders in some uses of NORM.
フィードバック メッセージは、グループ全体にマルチキャストすることも、ユニキャスト ルーティング経由で送信者に送信することもできます。ユニキャスト フィードバックの場合、送信者はフィードバックの抑制を容易にするために、フィードバックの状態をグループに「アドバタイズ」します。一般的なインターネット環境では、NORM プロトコルは数万の受信機のオーダーのグループ サイズに容易に拡張できると予想されます。このタイプのプロトコルのフィードバック量の研究については、[13] で説明されています。NORM は、受信機の数が比較的多い場合でも、単一の TCP 接続よりも少ない量のフィードバックで動作できます。したがって、ネットワーク トポロジによっては、NORM がより大きなグループ サイズに拡張される可能性があります。コンピュータ リソースの使用に関して、NORM プロトコルでは、グループ内のすべての受信機で状態を維持する必要はありません。NORM 送信者は、明示的な輻輳制御フィードバックを提供する受信者に対してのみ状態を維持します。NORM 受信者は、アクティブな各送信者の状態を維持する必要があります。これにより、NORM の使用によっては同時送信者の数が制限される場合があります。
All of the environmental requirements and considerations that apply to the RMT NORM Building Block [4] and the RMT FEC Building Block [5] also apply to the NORM protocol.
RMT NORM ビルディング ブロック [4] および RMT FEC ビルディング ブロック [5] に適用される環境要件と考慮事項はすべて、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 RFC 1112 [3], but SHALL also be capable of scalable operation in asymmetric topologies such as Source Specific Multicast (SSM) [14] where there may only be unicast routing service from the receivers to the sender(s).
NORM プロトコルは、基本的な IP マルチキャスト グループ管理、ルーティング、および転送サービスを超えて、中間システムの支援なしでエンドツーエンド方式で動作できるものとします (SHALL)。NORM で利用される技術は主に「フラットな」エンドツーエンド IP マルチキャスト トポロジに適用できますが、必要に応じて階層型 (ツリーベースなど) マルチキャスト配信のサブレベルにも適用できます。NORM は、RFC 1112 [3] で定義されている Any-Source Multicast (ASM) モデルの下で相互 (送信者と受信者の間で) マルチキャスト通信を利用できますが、Source Specific Multicast (SSM) などの非対称トポロジーでのスケーラブルな動作も可能であるものとします (SHALL)。) [14] ここでは、受信者から送信者へのユニキャスト ルーティング サービスのみが存在する可能性があります。
NORM is compatible with IPv4 and IPv6. Additionally, NORM may be used with networks employing Network Address Translation (NAT) providing the NAT device supports IP multicast and/or can cache UDP traffic source port numbers for remapping feedback traffic from receivers to the sender(s).
NORM は IPv4 および IPv6 と互換性があります。さらに、NORM は、NAT デバイスが IP マルチキャストをサポートしている、および/または受信者から送信者へのフィードバック トラフィックを再マッピングするために UDP トラフィック ソース ポート番号をキャッシュできる場合、ネットワーク アドレス変換 (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 possible multiple senders and to distinguish feedback information from different receivers. There are two reserved NormNodeId values. A value of 0x00000000 is considered an invalid NormNodeId value and a value of 0xffffffff is a "wildcard" NormNodeId. While the protocol does not preclude multiple sender nodes concurrently transmitting within the context of a single NORM session (i.e., many-to-many operation), any type of interactive coordination among NORM senders is assumed to be controlled by the application or higher protocol layer. There are some optional mechanisms specified in this document that can be leveraged for such application layer coordination.
NormSession は、送信者および/または受信者として機能する参加者 (NormNode) で構成されます。NORM 送信側はデータ コンテンツを NormObject の形式でセッション宛先アドレスに送信し、NORM 受信側は修復を要求するために否定応答を使用して送信されたコンテンツを確実に受信しようとします。NormSession 内の各 NormNode は、事前に選択された一意の 32 ビット識別子 (NormNodeId) を持っていると想定されます。NormNodes は、考えられる複数の送信者を区別し、異なる受信者からのフィードバック情報を区別するために、単一の NormSession 内で一意に割り当てられた識別子を持たなければなりません (MUST)。NormNodeId 値は 2 つ予約されています。値 0x00000000 は無効な NormNodeId 値とみなされ、値 0xffffffff は「ワイルドカード」NormNodeId です。このプロトコルは、単一の NORM セッション (つまり、多対多の操作) のコンテキスト内で複数の送信側ノードが同時に送信することを妨げるものではありませんが、NORM 送信側間のあらゆるタイプの対話型調整は、アプリケーションまたは上位のプロトコル層によって制御されると想定されます。。このドキュメントでは、このようなアプリケーション層の調整に利用できるオプションのメカニズムがいくつか指定されています。
As previously noted, NORM allows for reliable transmission of three different basic types of data content. The first type is NORM_OBJECT_DATA, which is used for static, persistent blocks of data content maintained in the sender's application memory storage. The second type is NORM_OBJECT_FILE, which corresponds to data stored in the sender's non-volatile file system. The NORM_OBJECT_DATA and NORM_OBJECT_FILE types both represent "NormObjects" of finite but potentially very large size. The third type of data content is NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of undefined length. This is analogous to the reliable stream service provide by TCP for unicast data transport. The format of the stream content is application-defined and may be byte or message oriented. The NORM protocol provides for "flushing" of the stream to expedite delivery or possibly enforce application message boundaries. NORM protocol implementations may offer either (or both) in-order delivery of the stream data to the receive application or out-of-order (more immediate) delivery of received segments of the stream to the receiver application. In either case, NORM sender and receiver implementations provide buffering to facilitate repair of the stream as it is transported.
前述したように、NORM では 3 つの異なる基本タイプのデータ コンテンツを確実に送信できます。1 つ目のタイプは NORM_OBJECT_DATA で、送信側のアプリケーション メモリ ストレージに保持されるデータ コンテンツの静的で永続的なブロックに使用されます。2 番目のタイプは NORM_OBJECT_FILE で、送信側の不揮発性ファイル システムに保存されているデータに対応します。NORM_OBJECT_DATA タイプと NORM_OBJECT_FILE タイプはどちらも、有限ではあるが潜在的に非常に大きなサイズの「NormObject」を表します。データ コンテンツの 3 番目のタイプは NORM_OBJECT_STREAM で、これは未定義の長さの進行中の送信に対応します。これは、ユニキャスト データ トランスポート用に TCP によって提供される信頼性の高いストリーム サービスに似ています。ストリーム コンテンツの形式はアプリケーションによって定義され、バイト指向またはメッセージ指向の場合があります。NORM プロトコルは、配信を促進したり、場合によってはアプリケーション メッセージ境界を強制したりするために、ストリームの「フラッシュ」を提供します。NORM プロトコルの実装では、受信アプリケーションへのストリーム データのインオーダー配信、または受信アプリケーションへのストリームの受信セグメントのアウトオブオーダー (より即時) 配信のいずれか (または両方) を提供できます。いずれの場合も、NORM の送信側と受信側の実装は、ストリームの転送時の修復を容易にするバッファリングを提供します。
All NormObjects are logically segmented into FEC coding blocks and symbols for transmission by the sender. In NORM, an FEC encoding symbol directly corresponds to the payload of NORM_DATA messages or "segment". Note that when systematic FEC codes are used, the payload of NORM_DATA messages sent for the first portion of a FEC encoding block are source symbols (actual segments of original user data), while the remaining symbols for the block consist of parity symbols generated by FEC encoding. These parity symbols are generally sent in response to repair requests, but some number may be sent proactively at the end each encoding block to increase the robustness of transmission. When non-systematic FEC codes are used, all symbols sent consist of FEC encoding parity content. In this case, the receiver must receive a sufficient number of symbols to reconstruct (via FEC decoding) the original user data for the given block. In this document, the terms "symbol" and "segment" are used interchangeably.
すべての 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 NormObjectTransportId. Depending upon the implementation, individual NORM senders may manage their NormInstanceIds independently, or a common NormInstanceId may be agreed upon for all participating nodes within a session if needed as a session identifier. NORM NormObjectTransportId data content identifiers are sender-assigned and applicable and valid only during a NormObject's actual _transport_ (i.e., for as long as the sender is transmitting and providing repair of the indicated NormObject). For a long-lived session, the NormObjectTransportId field can wrap and previously-used identifiers may be re-used. Note that globally unique identification of transported data content is not provided by NORM and, if required, must be managed by the NORM application. The individual segments or symbols of the NormObject are further identified with FEC payload identifiers which include coding block and symbol identifiers. These are discussed in detail later in this document.
送信された NormObject は、指定された送信者の NormNodeId、NormInstanceId、および一時的な NormObjectTransportId を使用して、NormSession コンテキスト内で一時的に一意に識別されます。実装に応じて、個々の NORM 送信者が独自に NormInstanceId を管理することも、セッション識別子として必要な場合にはセッション内のすべての参加ノードに対して共通の NormInstanceId を合意することもできます。NORM NormObjectTransportId データ コンテンツ識別子は送信者によって割り当てられ、NormObject の実際の_transport_ 中にのみ (つまり、送信者が送信し、指定された NormObject の修復を提供している限り) 適用可能で有効です。存続期間の長いセッションの場合、NormObjectTransportId フィールドをラップして、以前に使用した識別子を再利用できます。転送されるデータ コンテンツのグローバルに一意な ID は 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 optionally configured to proactively transmit some amount of redundant FEC symbols along with the original content to potentially enhance performance (e.g., improved delay) at the cost of additional transmission overhead. This option may be sensible for certain network conditions and can allow for robust, asymmetric multicast (e.g., unidirectional routing, satellite, cable) [15] with reduced receiver feedback, or, in some cases, no feedback.
NORM 送信側は主に NORM_DATA タイプのメッセージを生成します。これらのメッセージは、元のデータ セグメントまたは FEC シンボルを伝送し、転送されるバルク データ/ファイルまたはストリーム NormObject のセグメント/シンボルを修復します。デフォルトでは、冗長 FEC シンボルは受信機修復要求 (NACK) に応答してのみ送信されるため、通常、FEC エンコーディングによる追加の送信オーバーヘッドはほとんど、またはまったく課されません。ただし、NORM 実装は、追加の送信オーバーヘッドを犠牲にして潜在的にパフォーマンスを向上させる (遅延の改善など) ために、元のコンテンツとともにある程度の量の冗長 FEC シンボルを積極的に送信するようにオプションで構成されてもよい (MAY)。このオプションは、特定のネットワーク条件に対して賢明である可能性があり、受信機のフィードバックを低減した、または場合によってはフィードバックなしで、堅牢な非対称マルチキャスト (例: 一方向ルーティング、衛星、ケーブル) [15] を可能にすることができます。
A sender message of type NORM_INFO is also defined and is used to carry OPTIONAL "out-of-band" context information for a given transport object. A single NORM_INFO message can be associated with a NormObject. Because of its atomic nature, missing NORM_INFO messages can be NACKed and repaired with a slightly lower delay process than NORM's general FEC-encoded data content. NORM_INFO may serve special purposes for some bulk transfer, reliable multicast applications where receivers join the group mid-stream and need to ascertain contextual information on the current content being transmitted. The NACK process for NORM_INFO will be described later. When the NORM_INFO message type is used, its transmission should precede transmission of any NORM_DATA message for the associated NormObject.
NORM_INFO タイプの送信者メッセージも定義され、特定のトランスポート オブジェクトのオプションの「帯域外」コンテキスト情報を運ぶために使用されます。単一の NORM_INFO メッセージを NormObject に関連付けることができます。そのアトミックな性質により、欠落した NORM_INFO メッセージは NACK され、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, round trip time estimation, receiver synchronization, and optional positive acknowledgment requests or application defined commands. The transmission of NORM_CMD messages from the sender is accomplished by one of three different procedures. These procedures are: single, best effort unreliable transmission of the command; repeated redundant transmissions of the command; and positively-acknowledged commands. The transmission technique used for a given command depends upon the function of the command. Several core commands are defined for basic protocol operation. Additionally, implementations MAY wish to consider providing the OPTIONAL application-defined commands that can take advantage of the transmission methodologies available for commands. This allows for application-level session management mechanisms that can make use of information available to the underlying NORM protocol engine (e.g., round-trip timing, transmission rate, etc.).
また、送信側は、輻輳制御、送信終了フラッシング、往復時間推定、受信側同期、およびオプションの肯定応答要求やアプリケーション定義コマンドなどの特定のプロトコル操作を支援するために、タイプ NORM_CMD のメッセージを生成します。送信者からの NORM_CMD メッセージの送信は、3 つの異なる手順のいずれかによって実行されます。これらの手順は次のとおりです。 単一のベストエフォートで信頼性の低いコマンドの送信。コマンドの冗長な送信の繰り返し。および肯定的に承認されたコマンド。特定のコマンドに使用される送信手法は、コマンドの機能によって異なります。基本的なプロトコル操作のために、いくつかのコア コマンドが定義されています。さらに、実装では、コマンドに利用可能な送信方法を利用できる、オプションのアプリケーション定義コマンドの提供を検討してもよい(MAY)。これにより、基礎となる NORM プロトコル エンジンで利用可能な情報 (ラウンドトリップ タイミング、送信速度など) を利用できるアプリケーション レベルのセッション管理メカニズムが可能になります。
NORM receivers generate messages of type NORM_NACK or NORM_ACK in response to transmissions of data and commands from a sender. The NORM_NACK messages are generated to request repair of detected data transmission losses. Receivers generally detect losses by tracking the sequence of transmission from a sender. Sequencing information is embedded in the transmitted data packets and end-of-transmission commands from the sender. NORM_ACK messages are generated in response to certain commands transmitted by the sender. In the general (and most scalable) protocol mode, NORM_ACK messages are sent only in response to congestion control commands from the sender. The feedback volume of these congestion control NORM_ACK messages is controlled using the same timer-based probabilistic suppression techniques as for NORM_NACK messages to avoid feedback implosion. In order to meet potential application requirements for positive acknowledgment from receivers, other NORM_ACK messages are defined and available for use. All sender and receiver transmissions are subject to rate control governed by a peak transmission rate set for each participant by the application. This can be used to limit the quantity of multicast data transmitted by the group. When NORM's congestion control algorithm is enabled the rate for senders is automatically adjusted. In some networks, it may be desirable to establish minimum and maximum bounds for the rate adjustment depending upon the application even when dynamic congestion control is enabled. However, in the case of the general Internet, congestion control policy SHALL be observed that is compatible with coexistent TCP flows.
NORM 受信者は、送信者からのデータおよびコマンドの送信に応答して、NORM_NACK または NORM_ACK タイプのメッセージを生成します。NORM_NACK メッセージは、検出されたデータ伝送損失の修復を要求するために生成されます。受信機は通常、送信機からの送信シーケンスを追跡することで損失を検出します。シーケンス情報は、送信側から送信されるデータ パケットと送信終了コマンドに埋め込まれます。NORM_ACK メッセージは、送信者によって送信された特定のコマンドに応答して生成されます。一般的な (そして最もスケーラブルな) プロトコル モードでは、NORM_ACK メッセージは送信側からの輻輳制御コマンドに応答してのみ送信されます。これらの輻輳制御 NORM_ACK メッセージのフィードバック量は、NORM_NACK メッセージと同じタイマーベースの確率的抑制技術を使用して制御され、フィードバックの内破を回避します。受信者からの肯定応答に対する潜在的なアプリケーション要件を満たすために、他の NORM_ACK メッセージが定義され、使用可能です。すべての送信側と受信側の送信は、アプリケーションによって各参加者に設定されたピーク送信レートによって制御されるレート制御の対象となります。これを使用して、グループによって送信されるマルチキャスト データの量を制限できます。NORM の輻輳制御アルゴリズムが有効になっている場合、送信者のレートは自動的に調整されます。一部のネットワークでは、動的輻輳制御が有効になっている場合でも、アプリケーションに応じてレート調整の最小境界と最大境界を確立することが望ましい場合があります。ただし、一般的なインターネットの場合、共存する TCP フローと互換性のある輻輳制御ポリシーを遵守する必要があります (SHALL)。
The operation of the NORM protocol is based primarily upon the concepts presented in the Nack-Oriented Reliable Multicast (NORM) Building Block document [4]. This includes the basic NORM architecture and the data transmission, repair, and feedback strategies discussed in that document. Additional reliable multicast building blocks are applied in creating the full NORM protocol instantiation [16]. NORM also makes use of Forward Error Correction encoding techniques for repair messaging and optional transmission robustness as described in [10]. NORM uses the FEC Payload ID as specified by the FEC Building Block Document [5]. Additionally, for congestion control, this document includes a baseline congestion control mechanism (NORM-CC) based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme described in [19].
NORM プロトコルの動作は、主に Nack-Oriented Reliable Multicast (NORM) Building Block 文書 [4] に示されている概念に基づいています。これには、その文書で説明されている基本的な NORM アーキテクチャとデータ送信、修復、およびフィードバック戦略が含まれます。完全な NORM プロトコルのインスタンス化 [16] を作成する際に、追加の信頼できるマルチキャスト ビルディング ブロックが適用されます。NORM は、[10] で説明されているように、修復メッセージングとオプションの送信堅牢性のために前方誤り訂正符号化技術も利用します。NORM は、FEC Building Block Document [5] で指定されている FEC ペイロード ID を使用します。さらに、輻輳制御のために、この文書には、[19] で説明されている TCP フレンドリー マルチキャスト輻輳制御 (TFMCC) 方式に基づくベースライン輻輳制御メカニズム (NORM-CC) が含まれています。
While the various features of NORM are designed to provide some measure of general purpose utility, it is important to emphasize the understanding that "no one size fits all" in the reliable multicast transport arena. There are numerous engineering tradeoffs involved in reliable multicast transport design and this requires an increased awareness of application and network architecture considerations. Performance requirements affecting design can include: group size, heterogeneity (e.g., capacity and/or delay), asymmetric delivery, data ordering, delivery delay, group dynamics, mobility, congestion control, and transport across low capacity connections. NORM contains various parameters to accommodate many of these differing requirements. The NORM protocol and its mechanisms MAY be applied in multicast applications outside of bulk data transfer, but there is an assumed model of bulk transfer transport service that drives the trade-offs that determine the scalability and performance described in this document.
NORM のさまざまな機能は、ある程度の汎用性を提供するように設計されていますが、信頼性の高いマルチキャスト トランスポートの分野では「すべてに適合する万能のものはない」という理解を強調することが重要です。信頼性の高いマルチキャスト トランスポートの設計には多くのエンジニアリング上のトレードオフが関係しており、これにはアプリケーションとネットワーク アーキテクチャの考慮事項に対する意識を高める必要があります。設計に影響を与えるパフォーマンス要件には、グループ サイズ、異質性 (容量や遅延など)、非対称配信、データ順序付け、配信遅延、グループ ダイナミクス、モビリティ、輻輳制御、低容量接続間のトランスポートなどが含まれます。NORM には、これらのさまざまな要件の多くに対応するさまざまなパラメータが含まれています。NORM プロトコルとそのメカニズムは、バルク データ転送以外のマルチキャスト アプリケーションに適用できます (MAY) が、このドキュメントで説明するスケーラビリティとパフォーマンスを決定するトレードオフを引き起こすバルク転送トランスポート サービスの想定モデルがあります。
The ability of NORM to provide reliable data delivery is also governed by any buffer constraints of the sender and receiver applications. NORM protocol implementations SHOULD be designed to operate with the greatest efficiency and robustness possible within application-defined buffer constraints. Buffer requirements for reliability, as always, are a function of the delay-bandwidth product of the network topology. NORM performs best when allowed more buffering resources than typical point-to-point transport protocols. This is because NORM feedback suppression is based upon randomly-delayed transmissions from the receiver set, rather than immediately transmitted feedback. There are definitive tradeoffs between buffer utilization, group size scalability, and efficiency of performance. Large buffer sizes allow the NORM protocol to perform most efficiently in large delay-bandwidth topologies and allow for longer feedback suppression backoff timeouts. This yields improved group size scalability. NORM can operate with reduced buffering but at a cost of decreased efficiency (lower relative goodput) and reduced group size scalability.
信頼性の高いデータ配信を提供する NORM の機能は、送信側アプリケーションと受信側アプリケーションのバッファ制約によっても左右されます。NORM プロトコルの実装は、アプリケーション定義のバッファ制約内で可能な限り最大の効率と堅牢性で動作するように設計される必要があります (SHOULD)。いつものように、信頼性のためのバッファ要件は、ネットワーク トポロジの遅延と帯域幅の積の関数です。NORM は、一般的なポイントツーポイント トランスポート プロトコルよりも多くのバッファリング リソースが許可されている場合に最高のパフォーマンスを発揮します。これは、NORM フィードバック抑制が、即座に送信されるフィードバックではなく、受信機セットからのランダムに遅延された送信に基づいているためです。バッファ使用率、グループ サイズのスケーラビリティ、パフォーマンスの効率の間には決定的なトレードオフがあります。バッファ サイズが大きいため、NORM プロトコルは大きな遅延帯域幅トポロジで最も効率的に実行でき、フィードバック抑制バックオフ タイムアウトを長くすることができます。これにより、グループ サイズのスケーラビリティが向上します。NORM はバッファリングを減らして動作できますが、効率の低下 (相対的なグッドプットの低下) とグループ サイズのスケーラビリティの低下が伴います。
This Protocol Instantiation document, in conjunction with the RMT Building Block documents of [4] and [5], completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357 [17].
このプロトコルインスタンス化文書は、[4] および [5] の RMT ビルディングブロック文書と連携して、RFC 2357 [17] に記載されている要件に準拠する、動作する信頼性の高いマルチキャストトランスポートプロトコルを完全に指定します。
This document specifies the following message types and mechanisms which are REQUIRED in complying NORM protocol implementations:
この文書では、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 may be OPTIONAL if |
| | alternative congestion control mechanism and |
| | round trip timing collection is used). |
+--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
+--------------------+-----------------------------------------------+
+--------------------+-----------------------------------------------+
|NORM_ACK | Receiver message used to proactively provide |
| | feedback for congestion control purposes. |
| | Also used with the OPTIONAL NORM Positive |
| | Acknowledgment Process. |
+--------------------+-----------------------------------------------+
This document also describes the following message types and associated mechanisms which 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. |
+----------------------+----------------------------------------------+
As mentioned in Section 2.1, there are two primary classes of NORM messages: sender messages and receiver messages. NORM_CMD, NORM_INFO, and NORM_DATA message types are generated by senders of data content, and NORM_NACK and NORM_ACK messages generated by receivers within a NormSession. An auxiliary message type of NORM_REPORT is also provided for experimental purposes. This section describes the message formats used by the NORM protocol. These messages and their fields are referenced in the detailed functional description of the NORM protocol given in Section 5. Individual NORM messages are designed to be compatible with the MTU limitations of encapsulating Internet protocols including IPv4, IPv6, and UDP. The current NORM protocol specification assumes UDP encapsulation and leverages the transport features of UDP. The NORM messages are independent of network addresses and can be used in IPv4 and IPv6 networks.
セクション 2.1 で述べたように、NORM メッセージには送信側メッセージと受信側メッセージという 2 つの主要なクラスがあります。NORM_CMD、NORM_INFO、および NORM_DATA メッセージ タイプはデータ コンテンツの送信者によって生成され、NORM_NACK および NORM_ACK メッセージは NormSession 内の受信者によって生成されます。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 プロトコルの機能を拡張するヘッダー拡張メカニズムが定義されています。すべての 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Common Message Header Format
NORM 共通メッセージ ヘッダー形式
The "version" field is a 4-bit value indicating the protocol version number. NORM implementations SHOULD ignore received messages with version numbers different from their own. This number is intended to indicate and distinguish upgrades of the protocol which may be non-interoperable. The NORM version number for this specification is 1.
「バージョン」フィールドは、プロトコルのバージョン番号を示す 4 ビットの値です。NORM 実装は、自分のものとは異なるバージョン番号を持つ受信メッセージを無視すべきです (SHOULD)。この番号は、相互運用できない可能性があるプロトコルのアップグレードを示し、区別することを目的としています。この仕様の NORM バージョン番号は 1 です。
The message "type" field is a 4-bit value indicating the NORM protocol message type. These types are defined as follows:
メッセージ「タイプ」フィールドは、NORM プロトコルのメッセージ タイプを示す 4 ビットの値です。これらのタイプは次のように定義されます。
Message Value
メッセージ値
NORM_INFO 1 NORM_DATA 2 NORM_CMD 3 NORM_NACK 4 NORM_ACK 5 NORM_REPORT 6
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 header extensions that may be applied. The presence of header extensions are implied when the "hdr_len" value is greater than the base value for the given message "type".
8 ビットの「hdr_len」フィールドは、特定のメッセージのヘッダー部分を構成する 32 ビット ワードの数を示します。これは、適用されるヘッダー拡張を容易にするために使用されます。「hdr_len」値が指定されたメッセージ「type」の基本値より大きい場合、ヘッダー拡張子の存在が暗黙的に示されます。
The "sequence" field is a 16-bit value that is set by the message originator as a monotonically increasing number incremented with each NORM message transmitted to a given destination address. A "sequence" field number space SHOULD be maintained for messages sent to the NormSession group address. This value can be monitored by receiving nodes to detect packet losses in the transmission from a sender and used in estimating raw packet loss for congestion control purposes. Note that this value is NOT used in the NORM protocol to detect missing reliable data content and does NOT identify the application data or FEC payload that may be attached. With message authentication, the "sequence" field may also be leveraged for protection from message "replay" attacks, particularly of NORM_NACK or other feedback messages. In this case, the receiver node should maintain a monotonically increasing "sequence" field space for each destination to which it transmits (this may be multiple destinations when unicast feedback is used). The size of this field is intended to be sufficient to allow detection of a reasonable range of packet loss within the delay-bandwidth product of expected network connections.
「シーケンス」フィールドは、メッセージ発信者によって、特定の宛先アドレスに送信される NORM メッセージごとに単調増加する数値として設定される 16 ビット値です。「シーケンス」フィールド番号スペースは、NormSession グループ アドレスに送信されるメッセージのために維持される必要があります (SHOULD)。この値は、送信側からの送信におけるパケット損失を検出するために受信ノードによって監視され、輻輳制御を目的とした生のパケット損失の推定に使用されます。この値は、信頼できるデータ コンテンツの欠落を検出するために NORM プロトコルで使用されず、添付される可能性のあるアプリケーション データや FEC ペイロードを識別するものではないことに注意してください。メッセージ認証では、「シーケンス」フィールドは、特に NORM_NACK またはその他のフィードバック メッセージのメッセージ「リプレイ」攻撃から保護するために利用されることもあります。この場合、受信ノードは、送信先の宛先ごとに単調増加する「シーケンス」フィールド スペースを維持する必要があります (ユニキャスト フィードバックが使用される場合、これは複数の宛先になる可能性があります)。このフィールドのサイズは、予想されるネットワーク接続の遅延帯域幅積内で妥当な範囲のパケット損失を検出できるようにするのに十分なサイズにすることを目的としています。
The "source_id" field is a 32-bit value identifying the node that sent the message. A participant's NORM node identifier (NormNodeId) can be set according to application needs but unique identifiers must be assigned within a single NormSession. In some cases, use of the host IP address or a hash of it can suffice, but alternative methodologies for assignment and potential collision resolution of node identifiers within a multicast session need to be considered. For example, the "source identifier" mechanism defined in the Real-Time Protocol (RTP) specification [18] may be applicable to use for NORM node identifiers. At this point in time, the protocol makes no assumptions about how these unique identifiers are actually assigned.
「source_id」フィールドは、メッセージを送信したノードを識別する 32 ビット値です。参加者の NORM ノード識別子 (NormNodeId) はアプリケーションのニーズに応じて設定できますが、一意の識別子は単一の NormSession 内で割り当てる必要があります。場合によっては、ホスト IP アドレスまたはそのハッシュの使用で十分な場合もありますが、マルチキャスト セッション内でのノード識別子の割り当てと潜在的な衝突解決のための代替方法を考慮する必要があります。たとえば、リアルタイム プロトコル (RTP) 仕様 [18] で定義されている「ソース識別子」メカニズムは、NORM ノード識別子の使用に適用できる可能性があります。現時点では、プロトコルはこれらの一意の識別子が実際にどのように割り当てられるかについて何も仮定しません。
NORM Header Extensions
NORM ヘッダー拡張子
When header extensions are applied, they follow the message type's base header and precede any payload portion. There are two formats for header extensions, both of which begin with an 8-bit "het" (header extension type) field. One format is provided for variable-length extensions with "het" values in the range from 0 through 127. The other format is for fixed length (one 32-bit word) extensions with "het" values in the range from 128 through 255. These formats are given here:
ヘッダー拡張子が適用される場合、ヘッダー拡張子はメッセージ タイプの基本ヘッダーの後に続き、ペイロード部分の前に置かれます。ヘッダー拡張には 2 つの形式があり、どちらも 8 ビットの「het」（ヘッダー拡張タイプ）フィールドで始まります。1 つの形式は、0 ～ 127 の範囲の「het」値を持つ可変長拡張子用に提供されます。もう 1 つの形式は、128 ～ 255 の範囲の「het」値を持つ固定長 (1 つの 32 ビット ワード) 拡張子用です。これらの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het <=127 | hel | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Header Extension Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Variable Length Header Extension Format
NORM可変長ヘッダー拡張フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het >=128 | reserved | Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Fixed Length (32-bit) Header Extension Format
The "Header Extension Content" portion of these header extension format is defined for each header extension type defined for NORM messages. Some header extensions are defined within this document for NORM baseline FEC and congestion control operations.
これらのヘッダ拡張形式の「ヘッダ拡張コンテンツ」部分は、NORM メッセージに対して定義されたヘッダ拡張タイプごとに定義されます。一部のヘッダー拡張は、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 送信側メッセージには、NORM_DATA タイプ、NORM_INFO タイプ、および NORM_CMD タイプが含まれます。NORM_DATA および NORM_INFO メッセージにはアプリケーション データ コンテンツが含まれており、NORM_CMD メッセージはさまざまなプロトコル制御機能に使用されます。
The NORM_DATA message is expected to be the predominant type transmitted by NORM senders. These messages are used to encapsulate segmented data content for objects of type NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. NORM_DATA messages may contain original or FEC-encoded application data content.
NORM_DATA メッセージは、NORM 送信者によって送信される主なタイプであると予想されます。これらのメッセージは、タイプ 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.
NORM_DATA メッセージのフォーマットは、3 つの論理部分で構成されます。1) 固定フォーマットの NORM_DATA ヘッダー部分、2) 使用される FEC エンコードに依存するフォーマットの FEC ペイロード ID 部分、3) ソースまたはエンコードされたアプリケーションを含むペイロード部分データの内容。NORM_OBJECT_STREAM タイプのオブジェクトの場合、ペイロード部分にはストリーム コンテンツを適切に復元するために使用される追加フィールドが含まれていることに注意してください。NORM 実装は、FEC Object Transmission Information (EXT_FTI) ヘッダ拡張を含めるように NORM_DATA ヘッダを拡張してもよい (MAY)。これにより、NORM 受信機は、事前設定や帯域外情報を必要とせずに、自動的にリソースを割り当て、FEC デコードを適切に実行できるようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=2| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_reserved* | payload_len* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_DATA Message Format
NORM_DATA メッセージの形式
*NOTE: The "payload_reserved", "payload_len" and "payload_offset" fields are present only for objects of type NORM_OBJECT_STREAM. The "payload_len" and "payload_offset" fields allow senders to arbitrarily vary the size of NORM_DATA payload segments for streams. This allows applications to flush transmitted streams as needed to meet unique streaming requirements. For objects of types NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary since the receiver can calculate the payload length and offset information from the "fec_payload_id" using the algorithm described in Section 5.1.1. The "payload_reserved" field is kept for anticipated future NORM stream control functions. When systematic FEC codes (e.g., "fec_id" = 129) are used, the "payload_len" and "payload_offset" fields contain actual length and offset values for the encapsulated application data segment for those NORM_DATA messages containing source data symbols. In NORM_DATA messages that contain parity information, these fields are not actual length or offset values, but instead are values computed from FEC encoding the "payload_len" and "payload_offset" fields of the _source_ data symbols of the corresponding applicable coding block.
*注意: 「payload_reserved」、「payload_len」、および「payload_offset」フィールドは、タイプ NORM_OBJECT_STREAM のオブジェクトにのみ存在します。「payload_len」フィールドと「payload_offset」フィールドを使用すると、送信者はストリームの NORM_DATA ペイロード セグメントのサイズを任意に変更できます。これにより、アプリケーションは、固有のストリーミング要件を満たすために、必要に応じて送信されたストリームをフラッシュできるようになります。NORM_OBJECT_FILE および NORM_OBJECT_DATA タイプのオブジェクトの場合、受信機はセクション 5.1.1 で説明されているアルゴリズムを使用して「fec_payload_id」からペイロード長とオフセット情報を計算できるため、これらのフィールドは不要です。「payload_reserved」フィールドは、予想される将来の NORM ストリーム制御機能のために保持されます。体系的な FEC コード (例: "fec_id" = 129) が使用される場合、"payload_len" および "payload_offset" フィールドには、ソース データ シンボルを含む NORM_DATA メッセージのカプセル化されたアプリケーション データ セグメントの実際の長さとオフセット値が含まれます。パリティ情報を含む NORM_DATA メッセージでは、これらのフィールドは実際の長さやオフセット値ではなく、対応する該当するコーディング ブロックの _source_ データ シンボルの "payload_len" および "payload_offset" フィールドを FEC エンコードして計算された値です。
The "version", "type", "hdr_len", "sequence", and "source_id" fields form the NORM Common Message Header as described in Section 4.1. The value of the NORM_DATA "type" field is 2. The NORM_DATA _base_ "hdr_len" value is 4 (32-bit words) plus the size of the "fec_payload_id" field. The "fec_payload_id" field size depends upon the FEC encoding used for the referenced NormObject. The "fec_id" field is used to indicate the FEC coding type. For example, when small block, systematic codes are used, a "fec_id" value of 129 is indicated and the size of the "fec_payload_id" is two 32-bit words. In this case the NORM_DATA base "hdr_len" value is 6. The cumulative size of any header extensions applied is added into the "hdr_len" field.
セクション 4.1 で説明されているように、「version」、「type」、「hdr_len」、「sequence」、および「source_id」フィールドは NORM 共通メッセージ ヘッダーを形成します。NORM_DATA の「type」フィールドの値は 2 です。NORM_DATA _base_「hdr_len」の値は、4 (32 ビット ワード) に「fec_payload_id」フィールドのサイズを加えたものです。「fec_payload_id」フィールドのサイズは、参照される NormObject に使用される FEC エンコーディングによって異なります。「fec_id」フィールドは、FEC コーディングのタイプを示すために使用されます。たとえば、小さなブロックの体系的なコードが使用される場合、「fec_id」値 129 が示され、「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.
「instance_id」フィールドには、NormSession への参加の現在のインスタンスを一意に識別するために送信者によって生成された値が含まれます。これにより、受信者は、送信者が進行中のセッションから離れ、再び参加したことを検出できるようになります。送信者（「source_id」で識別される）が新しい「instance_id」を持つことが検出された場合、NORM 受信者は送信者の以前の状態を破棄し、新たに受信を開始する必要があります（SHOULD）。
The "grtt" field contains a non-linear quantized representation of the sender's current estimate of group round-trip time (GRTT) (this is also referred to as R_max in [19]). This value is used to control timing of the NACK repair process and other aspects of protocol operation as described in this document. The algorithm for encoding and decoding this field is described in the RMT NORM Building Block document [4].
「grtt」フィールドには、送信者のグループ往復時間 (GRTT) の現在の推定値の非線形量子化表現が含まれます (これは [19] では R_max とも呼ばれます)。この値は、この文書で説明されているように、NACK 修復プロセスのタイミングとプロトコル動作の他の側面を制御するために使用されます。このフィールドのエンコードおよびデコードのアルゴリズムは、RMT NORM Building Block 文書 [4] で説明されています。
The "backoff" field value is used by receivers to determine the maximum backoff timer value used in the timer-based NORM NACK feedback suppression. This 4-bit field supports values from 0-15 which is multiplied by the sender GRTT to determine the maximum backoff timeout. The "backoff" field informs the receiver set of the sender's backoff factor parameter "Ksender". Recommended values and their use are described in the NORM receiver NACK procedure description in Section 5.3. The "gsize" field contains a representation of the sender's current estimate of group size. This 4-bit field can roughly represent values from ten to 500 million where the most significant bit value of 0 or 1 represents a mantissa of 1 or 5, respectively and the three least significant bits incremented by one represent a base 10 exponent (order of magnitude). For examples, a field value of "0x0" represents 1.0e+01 (10), a value of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02 (100), and a value of "0xf" represents 5.0e+08. For NORM feedback suppression purposes, the group size does not need to be represented with a high degree of precision. The group size may even be estimated somewhat conservatively (i.e., overestimated) to maintain low levels of feedback traffic. A default group size estimate of 10,000 ("gsize" = 0x4) is recommended for general purpose reliable multicast applications using the NORM protocol.
「バックオフ」フィールド値は、タイマーベースの NORM NACK フィードバック抑制で使用される最大バックオフ タイマー値を決定するために受信機によって使用されます。この 4 ビット フィールドは、最大バックオフ タイムアウトを決定するために送信者の GRTT を乗じた 0 ～ 15 の値をサポートします。「バックオフ」フィールドは、送信側のバックオフ係数パラメータ「Ksender」を受信側セットに通知します。推奨値とその使用法については、セクション 5.3 の NORM 受信側 NACK プロシージャの説明で説明されています。「gsize」フィールドには、送信者のグループ サイズの現在の推定値が表示されます。この 4 ビット フィールドは、1000 万から 5 億までの値を大まかに表すことができます。0 または 1 の最上位ビット値は、それぞれ 1 または 5 の仮数を表し、1 ずつ増分された 3 つの下位ビットは、基数 10 の指数 (次数) を表します。大きさ）。たとえば、フィールド値「0x0」は 1.0e 01 (10) を表し、値「0x8」は 5.0e 01 (50) を表し、値「0x1」は 1.0e 02 (100) を表し、値「0xf」は 5.0e 08 を表します。NORM フィードバック抑制の目的では、グループ サイズを高い精度で表す必要はありません。グループ サイズは、フィードバック トラフィックのレベルを低く維持するために、ある程度控えめに見積もられる (つまり、過大に見積もられる) 場合もあります。NORM プロトコルを使用する汎用の信頼できるマルチキャスト アプリケーションには、デフォルトのグループ サイズ推定値 10,000 (「gsize」 = 0x4) が推奨されます。
The "flags" field contains a number of different binary flags providing information and hints regarding how the receiver should handle the identified object. Defined flags in this field include:
「フラグ」フィールドには、受信機が識別されたオブジェクトをどのように処理すべきかに関する情報とヒントを提供する、さまざまなバイナリ フラグが多数含まれています。このフィールドで定義されているフラグは次のとおりです。
+--------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair |
| | | transmission |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to |
| | | meet a specific receiver erasure, as |
| | | compared to parity segments provided by |
| | | the sender for general purpose (with |
| | | respect to an FEC coding block) erasure |
| | | filling. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO for |
| | | object. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_UNRELIABLE| 0x08 | Indicates that repair transmissions for |
| | | the specified object will be unavailable|
| | | (One-shot, best effort transmission). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_FILE | 0x10 | Indicates object is "file-based" data |
| | | (hint to use disk storage for |
| | | reception). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_STREAM | 0x20 | Indicates object is of type |
| | | NORM_OBJECT_STREAM. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_MSG_START | 0x40 | Marks the first segment of application |
| | | messages embedded in |
| | | NORM_OBJECT_STREAMs. |
+--------------------+-------+-----------------------------------------+
NORM_FLAG_REPAIR is set when the associated message is a repair transmission. This information can be used by receivers to help observe a join policy where it is desired that newly joining receivers only begin participating in the NACK process upon receipt of new (non-repair) data content. NORM_FLAG_EXPLICIT is used to mark repair messages sent when the data sender has exhausted its ability to provide "fresh" (previously untransmitted) parity segments as repair. This flag could possibly be used by intermediate systems implementing functionality to control sub-casting of repair content to different legs of a reliable multicast topology with disparate repair needs. NORM_FLAG_INFO is set only when optional NORM_INFO content is actually available for the associated object. Thus, receivers will NACK for retransmission of NORM_INFO only when it is available for a given object. NORM_FLAG_UNRELIABLE is set when the sender wishes to transmit an object with only "best effort" delivery and will not supply repair transmissions for the object. NORM receivers SHOULD NOT execute repair requests for objects marked with the NORM_FLAG_UNRELIABLE flag. Note that receivers may inadvertently request repair of such objects when all segments (or info content) for those objects are not received (i.e., a gap in the "object_transport_id" sequence is noted). In this case, the sender should invoke the NORM_CMD(SQUELCH) process as described in Section 4.2.3. NORM_FLAG_FILE can be set as a "hint" from the sender that the associated object should be stored in non-volatile storage. NORM_FLAG_STREAM is set when the identified object is of type NORM_OBJECT_STREAM. When NORM_FLAG_STREAM is set, the NORM_FLAG_MSG_START can be optionally used to mark the first data segments of application-layer messages transported within the NORM stream. This allows NORM receiver applications to "synchronize" with NORM senders and to be able to properly interpret application layer data when joining a NORM session already in progress. In practice, the NORM implementation MAY set this flag for the segment transmitted following an explicit "flush" of the stream by the application.
NORM_FLAG_REPAIR は、関連するメッセージが修復送信である場合に設定されます。この情報は、受信機が、新規に参加する受信機が新しい（非修復）データ コンテンツの受信時にのみ NACK プロセスへの参加を開始することが望まれる参加ポリシーを遵守するのに役立ちます。NORM_FLAG_EXPLICIT は、データ送信側が修復として「新しい」(以前は送信されていない) パリティ セグメントを提供する能力を使い果たしたときに送信される修復メッセージをマークするために使用されます。このフラグは、異なる修復ニーズを持つ信頼性の高いマルチキャスト トポロジの異なるレッグへの修復コンテンツのサブキャストを制御する機能を実装する中間システムによって使用される可能性があります。NORM_FLAG_INFO は、オプションの NORM_INFO コンテンツが関連オブジェクトで実際に利用可能な場合にのみ設定されます。したがって、受信側は、特定のオブジェクトで NORM_INFO が利用可能な場合にのみ、NORM_INFO の再送信に対して NACK を返します。NORM_FLAG_UNRELIABLE は、送信者が「ベスト エフォート」配信のみでオブジェクトを送信することを希望し、オブジェクトの修復送信を提供しない場合に設定されます。NORM 受信者は、NORM_FLAG_UNRELIABLE フラグが付けられたオブジェクトの修復リクエストを実行すべきではありません (SHOULD NOT)。それらのオブジェクトのすべてのセグメント（または情報コンテンツ）が受信されていない場合（つまり、「object_transport_id」シーケンスのギャップが注目されている場合）、受信者はそのようなオブジェクトの修復を誤って要求する可能性があることに注意してください。この場合、送信者はセクション 4.2.3 で説明されている NORM_CMD(SQUELCH) プロセスを呼び出す必要があります。NORM_FLAG_FILE は、関連するオブジェクトを不揮発性ストレージに保存する必要があるという送信者からの「ヒント」として設定できます。NORM_FLAG_STREAM は、識別されたオブジェクトのタイプが NORM_OBJECT_STREAM の場合に設定されます。NORM_FLAG_STREAM が設定されている場合、オプションで NORM_FLAG_MSG_START を使用して、NORM ストリーム内で転送されるアプリケーション層メッセージの最初のデータ セグメントをマークできます。これにより、NORM 受信側アプリケーションは NORM 送信側と「同期」し、すでに進行中の NORM セッションに参加するときにアプリケーション層のデータを適切に解釈できるようになります。実際には、NORM 実装は、アプリケーションによるストリームの明示的な「フラッシュ」に続いて送信されるセグメントに対してこのフラグを設定してもよい(MAY)。
The "fec_id" field corresponds to the FEC Encoding Identifier described in the FEC Building Block document [5]. The "fec_id" value implies the format of the "fec_payload_id" field and, coupled with FEC Object Transmission Information, the procedures to decode FEC encoded content. Small block, systematic codes ("fec_id" = 129) are expected to be used for most NORM purposes and the NORM_OBJECT_STREAM requires systematic FEC codes for most efficient performance.
「fec_id」フィールドは、FEC Building Block 文書 [5] に記載されている FEC Encoding Identifier に対応します。「fec_id」値は、「fec_payload_id」フィールドの形式と、FEC オブジェクト送信情報と組み合わせて、FEC エンコードされたコンテンツをデコードする手順を意味します。小さなブロックの体系的なコード (「fec_id」 = 129) は、ほとんどの NORM 目的で使用されることが想定されており、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 may be repeated, but it is presumed that the 16-bit field size provides an adequate enough sequence space to avoid object confusion amongst receivers and sources (i.e., receivers SHOULD re-synchronize with a server when receiving object sequence identifiers sufficiently out-of-range with the current state kept for a given source). During the 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」フィールドは、送信者によって送信される NormObject に割り当てられる、単調かつ増分的に増加する値です。そのオブジェクトに関連する送信および修復リクエストは、同じ「object_transport_id」値を使用します。非常に長いセッションまたは無期限のセッションの場合、「object_transport_id」フィールドが繰り返される可能性がありますが、16 ビットのフィールド サイズは、受信者と送信元の間でオブジェクトの混乱を避けるのに十分なシーケンス スペースを提供すると推定されます（つまり、受信者は、再送信する必要があります）。特定のソースに対して保持されている現在の状態の範囲外にあるオブジェクト シーケンス識別子を受信した場合、サーバーと同期します)。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 FEC Building Block document [5] and any subsequent extensions of that document. As an example, the format of the "fec_payload_id" format small block, systematic codes ("fec_id" = 129) given here:
「fec_payload_id」は、添付された NORM_DATA「ペイロード」コンテンツを識別します。「fec_payload_id」フィールドのサイズおよび形式は、「fec_id」フィールドによって示されるFECタイプに依存します。これらの形式は、FEC Building Block 文書 [5] およびその文書の後続の拡張版で提供されています。例として、「fec_payload_id」形式の小さなブロック、体系的なコード (「fec_id」= 129) の形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_len | encoding_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Small Block, Systematic Code ("fec_id" = 129) "fec_payload_id" Format
小さなブロック、体系的なコード ("fec_id" = 129) "fec_payload_id" 形式
The FEC payload identifier "source_block_number", "source_block_len", and "encoding_symbol_id" fields correspond to the "Source Block Number", "Source Block Length, and "Encoding Symbol ID" fields of the FEC Payload ID format given by the IETF FEC Building Block document [5]. The "source_block_number" identifies the coding block's relative position with a NormObject. Note that, for NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may wrap for very long lived sessions. The "source_block_len" indicates the number of user data segments in the identified coding block. Given the "source_block_len" information of how many symbols of application data are contained in the block, the receiver can determine whether the attached segment is data or parity content and treat it appropriately. The "encoding_symbol_id" identifies which specific symbol (segment) within the coding block the attached payload conveys. Depending upon the value of the "encoding_symbol_id" and the associated "source_block_len" parameters for the block, the symbol (segment) referenced may be a user data or an FEC parity segment. For systematic codes, encoding symbols numbered less than the source_block_len contain original application data while segments greater than or equal to source_block_len contain parity symbols calculated for the block. The concatenation of 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」フィールドは、IETF FEC Building によって指定された FEC ペイロード ID 形式の「Source Block Number」、「Source Block Length」、および「Encoding Symbol ID」フィールドに対応します。ブロック ドキュメント [5]。「source_block_number」は、NormObject とのコーディング ブロックの相対位置を識別します。NORM_OBJECT_STREAM タイプの NormObject の場合、「source_block_number」は非常に長期間存続するセッションでラップされる可能性があることに注意してください。「source_block_len」はユーザーの数を示します識別されたコーディング ブロック内のデータ セグメント。ブロックにアプリケーション データのシンボルが何個含まれているかに関する「source_block_len」情報が与えられると、受信機は、添付されたセグメントがデータ コンテンツであるかパリティ コンテンツであるかを判断し、それを適切に処理できます。添付されたペイロードが伝えるコーディング ブロック内の特定のシンボル (セグメント)。ブロックの「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 (as described in the FEC Building Block document [5]) is required to properly receive and decode NORM transport objects. This information MAY be provided as out-of-band session information. However, in some cases, it may be useful for the sender to include this information "in band" to facilitate receiver operation with minimal preconfiguration. For this purpose, the NORM FEC Object Transmission Information Header Extension (EXT_FTI) is defined. This header extension MAY be applied to NORM_DATA and NORM_INFO messages to provide this necessary information. The exact format of the extension depends upon the FEC code in use, but in general it SHOULD contain any required details on the FEC code in use (e.g., FEC Instance ID, etc.) and the byte size of the associated NormObject (For the NORM_OBJECT_STREAM type, this size corresponds to the stream buffer size maintained by the NORM sender). As an example, the format of the EXT_FTI for small block systematic codes ("fec_id" = 129) is given here:
NORM トランスポート オブジェクトを適切に受信してデコードするには、追加の FEC オブジェクト送信情報 (FEC Building Block 文書 [5] で説明されている) が必要です。この情報は帯域外セッション情報として提供されてもよい(MAY)。ただし、場合によっては、送信側が最小限の事前設定で受信側の操作を容易にするために、この情報を「帯域内」に含めることが役立つ場合があります。この目的のために、NORM FEC オブジェクト送信情報ヘッダー拡張 (EXT_FTI) が定義されます。このヘッダ拡張は、この必要な情報を提供するために NORM_DATA および NORM_INFO メッセージに適用されてもよい (MAY)。拡張子の正確な形式は使用中の FEC コードに依存しますが、一般に、使用中の FEC コードに関する必要な詳細 (FEC インスタンス ID など) および関連する NormObject のバイト サイズを含めるべきです (SHOULD)。NORM_OBJECT_STREAM タイプ、このサイズは NORM 送信者によって維持されるストリーム バッファー サイズに対応します)。例として、小さなブロックの体系的コード (「fec_id」 = 129) の 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_length (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_length (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object Transmission Information Header Extension (EXT_FTI) for Small Block Systematic Codes ("fec_id" = 129)
スモールブロック組織コード用の FEC オブジェクト送信情報ヘッダー拡張 (EXT_FTI) ("fec_id" = 129)
The header extension type "het" field value for this header extension is 64. The header extension length "hel" depends upon the format of the FTI for FEC code type identified by the "fec_id" field. In this example (for "fec_id" = 129), the "hel" field value is 4.
このヘッダ拡張のヘッダ拡張タイプ「het」フィールド値は 64 です。ヘッダ拡張長「hel」は、「fec_id」フィールドによって識別される FEC コード タイプの FTI の形式に依存します。この例 (「fec_id」 = 129) では、「hel」フィールドの値は 4 です。
The 48-bit "object_length" field indicates the total size of the object (in bytes) for the static object types of NORM_OBJECT_FILE and NORM_OBJECT_DATA. This information is used by receivers to determine storage requirements and/or allocate storage for the received object. Receivers with insufficient storage capability may wish to forego reliable reception (i.e., not NACK for) of the indicated object. In the case of objects of type NORM_OBJECT_STREAM, the "object_length" field is used by the sender to indicate the size of its stream buffer to the receiver group. In turn, the receivers SHOULD use this information to allocate a stream buffer for reception of corresponding size.
48 ビットの「object_length」フィールドは、NORM_OBJECT_FILE および NORM_OBJECT_DATA の静的オブジェクト タイプのオブジェクトの合計サイズ (バイト単位) を示します。この情報は、受信者がストレージ要件を決定したり、受信したオブジェクトにストレージを割り当てたりするために使用されます。ストレージ能力が不十分な受信機は、示されたオブジェクトの信頼できる受信（つまり、NACK を受信しないこと）を控えることを望む場合があります。NORM_OBJECT_STREAM タイプのオブジェクトの場合、「object_length」フィールドは、送信側がそのストリーム バッファのサイズを受信側グループに示すために使用されます。次に、受信者はこの情報を使用して、対応するサイズの受信用のストリーム バッファを割り当てる必要があります (SHOULD)。
The "fec_instance_id" corresponds to the "FEC Instance ID" described in the FEC Building Block document [5]. In this case, the "fec_instance_id" SHALL be a value corresponding to the particular type of Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), Reed-Solomon GF(2^16), etc). The standardized assignment of FEC Instance ID values is described in [5]. The "segment_size" field indicates the sender's current setting for maximum message payload content (in bytes). This allows receivers to allocate appropriate buffering resources and to determine other information in order to properly process received data messaging.
「fec_instance_id」は、FEC Building Block 文書 [5] に記載されている「FEC Instance ID」に対応します。この場合、「fec_instance_id」は、使用されている特定のタイプのスモールブロック体系的コードに対応する値であるものとします(例: Reed-Solomon GF(2^8)、Reed-Solomon GF(2^16) など)。FEC インスタンス ID 値の標準化された割り当てについては、[5] で説明されています。「segment_size」フィールドは、送信者の最大メッセージ ペイロード コンテンツの現在の設定 (バイト単位) を示します。これにより、受信側は適切なバッファリング リソースを割り当て、受信したデータ メッセージングを適切に処理するために他の情報を決定できるようになります。
The "fec_max_block_len" indicates the current maximum number of user data segments per FEC coding block to be used by the sender during the session. This allows receivers to allocate appropriate buffer space for buffering blocks transmitted by the sender.
「fec_max_block_len」は、セッション中に送信側が使用する FEC コーディング ブロックあたりのユーザー データ セグメントの現在の最大数を示します。これにより、受信側は、送信側が送信したブロックをバッファリングするために適切なバッファ スペースを割り当てることができます。
The "fec_num_parity" corresponds to the "maximum number of encoding symbols that can be generated for any source block" as described in for FEC Object Transmission Information for Small Block Systematic Codes in the FEC Building Block document [5]. For example, Reed-Solomon codes may be arbitrarily shortened to create different code variations for a given block length. In the case of Reed-Solomon (GF(2^8) and GF(2^16)) codes, this value indicates the maximum number of parity segments available from the sender for the coding blocks. This field MAY be interpreted differently for other systematic codes as they are defined.
「fec_num_parity」は、FEC ビルディング ブロック文書 [5] のスモール ブロック システムマティック コードの FEC オブジェクト送信情報で説明されているように、「任意のソース ブロックに対して生成できる符号化シンボルの最大数」に対応します。たとえば、リード ソロモン コードを任意に短縮して、特定のブロック長に対してさまざまなコードのバリエーションを作成できます。リードソロモン (GF(2^8) および GF(2^16)) コードの場合、この値は、コーディング ブロックの送信側から利用できるパリティ セグメントの最大数を示します。このフィールドは、他の体系的なコードが定義されている場合には、異なるように解釈されてもよい(MAY)。
The payload portion of NORM_DATA messages includes source data or FEC encoded application content.
NORM_DATA メッセージのペイロード部分には、ソース データまたは FEC エンコードされたアプリケーション コンテンツが含まれます。
The "payload_reserved", "payload_len" and "payload_offset" fields are present ONLY for transport objects of type NORM_OBJECT_STREAM. These fields indicate the size and relative position (within the stream) of the application content represented by the message payload. For senders employing systematic FEC encoding, these fields contain _actual_ length and offset values (in bytes) for the payload of messages which contain original data source symbols. For NORM_DATA messages containing calculated parity content, these fields will actually contain values computed by FEC encoding of the "payload_len" and "payload_offset" values of the NORM_DATA data segments of the corresponding FEC coding block. Thus, the "payload_len" and "payload_offset" values of missing data content can be determined upon decoding a FEC coding block. Note that these fields do NOT contribute to the value of the NORM_DATA "hdr_len" field. These fields are NOT present when the "flags" portion of the NORM_DATA message indicate the transport object if of type NORM_OBJECT_FILE or NORM_OBJECT_DATA. In this case, the length and offset information can be calculated from the "fec_payload_id" using the methodology described in Section 5.1.1. Note that for long-lived streams, the "payload_offset" field can wrap.
「payload_reserved」、「payload_len」、および「payload_offset」フィールドは、タイプ NORM_OBJECT_STREAM のトランスポート オブジェクトにのみ存在します。これらのフィールドは、メッセージ ペイロードによって表されるアプリケーション コンテンツのサイズと (ストリーム内の) 相対位置を示します。システマティックな FEC エンコーディングを使用する送信者の場合、これらのフィールドには、元のデータ ソース シンボルを含むメッセージのペイロードの _actual_ 長さとオフセット値 (バイト単位) が含まれます。計算されたパリティ コンテンツを含む NORM_DATA メッセージの場合、これらのフィールドには実際には、対応する FEC コーディング ブロックの NORM_DATA データ セグメントの「payload_len」および「payload_offset」値の FEC エンコードによって計算された値が含まれます。したがって、欠落データコンテンツの「payload_len」および「payload_offset」値は、FECコーディングブロックを復号するときに決定できます。これらのフィールドは、NORM_DATA の「hdr_len」フィールドの値には影響しないことに注意してください。NORM_DATA メッセージの「フラグ」部分が NORM_OBJECT_FILE または NORM_OBJECT_DATA タイプのトランスポート オブジェクトを示す場合、これらのフィールドは存在しません。この場合、長さとオフセット情報は、セクション5.1.1で説明されている方法を使用して「fec_payload_id」から計算できます。存続期間の長いストリームの場合、「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 length less than the NormSegmentSize. It is RECOMMENDED that a sender's NormSegmentSize generally be constant for the duration of a given sender's term of participation in the session, but may possibly vary on a per-object basis. The NormSegmentSize is expected to be configurable by the sender application prior to session participation as needed for network topology maximum transmission unit (MTU) considerations. For IPv6, MTU discovery may be possibly leveraged at session startup to perform this configuration. The "payload_data" content may be delivered directly to the application for source symbols (when systematic FEC encoding is used) or upon decoding of the FEC block. For NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment length and offset can be calculated using the algorithm described in Section 5.1.1. For NORM_OBJECT_STREAM objects, the length and offset is obtained from the segment's corresponding "payload_len" and "payload_offset" fields.
「payload_data」フィールドには、「fec_payload_id」で識別されるシンボルの元のアプリケーション ソースまたはパリティ コンテンツが含まれます。このフィールドの長さは、オブジェクトの FTI で指定されている送信者の NormSegmentSize バイトの最大値に制限されるものとします (SHALL)。パリティ コンテンツを含むメッセージのこのフィールドの長さは、常に NormSegmentSize になることに注意してください。さまざまなサイズのデータ セグメントをエンコードする場合、FEC エンコーダは、NormSegmentSize よりも短い長さのデータ セグメントに対してゼロ値パディングを想定するものとします (SHALL)。送信者の NormSegmentSize は、通常、セッションへの特定の送信者の参加期間中は一定であることが推奨されますが、オブジェクトごとに異なる可能性があります。NormSegmentSize は、ネットワーク トポロジの最大伝送単位 (MTU) を考慮する必要に応じて、セッションに参加する前に送信側アプリケーションによって構成可能であることが期待されます。IPv6 の場合、この構成を実行するためにセッションの開始時に MTU 検出が利用される可能性があります。「payload_data」コンテンツは、ソース シンボル用にアプリケーションに直接配信されるか（システマティック FEC エンコードが使用される場合）、または FEC ブロックのデコード時に配信されます。NORM_OBJECT_FILE および NORM_OBJECT_STREAM オブジェクトの場合、データ セグメントの長さとオフセットは、セクション 5.1.1 で説明されているアルゴリズムを使用して計算できます。NORM_OBJECT_STREAM オブジェクトの場合、長さとオフセットは、セグメントの対応する「payload_len」フィールドと「payload_offset」フィールドから取得されます。
The NORM_INFO message is used to convey OPTIONAL, application-defined, "out-of-band" context information for transmitted NormObjects. An example NORM_INFO use for bulk file transfer is to place MIME type information for the associated file, data, or stream object into the NORM_INFO payload. Receivers may use the NORM_INFO content to make a decision as whether to participate in reliable reception of the associated object. Each NormObject can have an independent unit of NORM_INFO associated with it. NORM_DATA messages contain a flag to indicate the availability of NORM_INFO for a given NormObject. NORM receivers may NACK for retransmission of NORM_INFO when they have not received it for a given NormObject. The size of the NORM_INFO content is limited to that of a single NormSegmentSize 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 メッセージは、送信される NormObject のオプションのアプリケーション定義の「帯域外」コンテキスト情報を伝えるために使用されます。一括ファイル転送での NORM_INFO の使用例は、関連付けられたファイル、データ、またはストリーム オブジェクトの MIME タイプ情報を NORM_INFO ペイロードに配置することです。受信者は、NORM_INFO コンテンツを使用して、関連するオブジェクトの信頼できる受信に参加するかどうかを決定できます。各 NormObject には、NORM_INFO の独立したユニットを関連付けることができます。NORM_DATA メッセージには、特定の NormObject の NORM_INFO が利用可能であることを示すフラグが含まれています。NORM 受信者は、特定の NormObject に対する NORM_INFO を受信していない場合、NORM_INFO の再送信に対して NACK を返すことができます。NORM_INFO コンテンツのサイズは、指定された送信者の単一の NormSegmentSize のサイズに制限されます。このアトミックな性質により、NORM の信頼性の高い送信プロセス内で NORM_INFO を迅速かつ効率的に修復できます。
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 で利用可能な場合、対応する「object_transport_id」の NORM_DATA メッセージに NORM_FLAG_INFO フラグが設定されるものとし、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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_INFO Message Format
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 "hdr_len" field when no header extensions are present is 4.
セクション 4.1 で説明されているように、「version」、「type」、「hdr_len」、「sequence」、および「source_id」フィールドは 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 with NORM_DATA messages. These values allow the receiver to prepare appropriate buffering, etc, for further transmissions from the sender when NORM_INFO is the first message received.
「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, some NORM implementations may wish to apply the EXT_FTI when used to NORM_INFO messages only and not to NORM_DATA messages.
NORM_DATA メッセージと同様に、NORM FTI ヘッダー拡張 (EXT_FTI) を NORM_INFO メッセージにオプションで適用できます。プロトコルのオーバーヘッドを節約するために、一部の NORM 実装では、EXT_FTI を NORM_DATA メッセージではなく NORM_INFO メッセージにのみ使用する場合に適用する必要がある場合があります。
The NORM_INFO "payload_data" field contains sender application-defined content which can be used by receiver applications for various purposes as described above.
NORM_INFO の「payload_data」フィールドには、上で説明したさまざまな目的で受信側アプリケーションによって使用できる、送信側アプリケーション定義のコンテンツが含まれています。
NORM_CMD messages are transmitted by senders to perform a number of different protocol functions. This includes functions such as round-trip timing collection, congestion control functions, synchronization of sender/receiver repair "windows", and notification of sender status. A core set of NORM_CMD messages is enumerated. Additionally, a range of command types remain available for potential application-specific use. Some NORM_CMD types may have dynamic content attached. Any attached content will be limited to maximum length of the sender NormSegmentSize to retain the atomic nature of commands. All NORM_CMD messages begin with a common set of fields, after the usual NORM message common header. The standard NORM_CMD fields are:
NORM_CMD メッセージは、さまざまなプロトコル機能を実行するために送信者によって送信されます。これには、往復タイミング収集、輻輳制御機能、送信側/受信側修復「ウィンドウ」の同期、送信側ステータスの通知などの機能が含まれます。NORM_CMD メッセージのコア セットが列挙されます。さらに、潜在的なアプリケーション固有の使用のために、さまざまなコマンド タイプを引き続き使用できます。一部の NORM_CMD タイプには、動的コンテンツがアタッチされている場合があります。コマンドのアトミックな性質を維持するために、添付されたコンテンツは送信者の NormSegmentSize の最大長に制限されます。すべての NORM_CMD メッセージは、通常の NORM メッセージ共通ヘッダーの後に、共通のフィールド セットで始まります。標準の NORM_CMD フィールドは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD Standard Fields
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 "flavor" field.
セクション 4.1 で説明されているように、「version」、「type」、「hdr_len」、「sequence」、および「source_id」フィールドは NORM 共通メッセージ ヘッダーを形成します。ヘッダ拡張が存在しない NORM_CMD メッセージの「hdr_len」フィールドの値は、「flavor」フィールドによって異なります。
The "instance_id", "grtt", "backoff", and "gsize" fields provide the same information and serve the same purpose as with NORM_DATA and NORM_INFO messages. The "flavor" field indicates the type of command to follow. The remainder of the NORM_CMD message is dependent upon the command type ("flavor"). NORM command flavors include:
「instance_id」、「grtt」、「backoff」、および「gsize」フィールドは、NORM_DATA および NORM_INFO メッセージと同じ情報を提供し、同じ目的を果たします。「フレーバー」フィールドは、従うべきコマンドのタイプを示します。NORM_CMD メッセージの残りの部分は、コマンド タイプ (「フレーバー」) によって異なります。NORM コマンドのフレーバーは次のとおりです。
+----------------------+-------------+---------------------------------+
| Command |Flavor Value | Purpose |
+----------------------+-------------+---------------------------------+
|NORM_CMD(FLUSH) | 1 | Used to indicate sender |
| | | temporary end-of-transmission. |
| | | (Assists in robustly initiating |
| | | outstanding repair requests from|
| | | receivers). May also be |
| | | optionally used to collect |
| | | positive acknowledgment of |
| | | reliable reception from subset |
| | | of receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(SQUELCH) | 3 | Used to advertise sender's |
| | | current repair window in |
| | | response to out-of-range NACKs |
| | | from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(CC) | 4 | Used for GRTT measurement and |
| | | collection of congestion control|
| | | feedback. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender's |
| | | aggregated repair/feedback state|
| | | for suppression of unicast |
| | | feedback from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment |
| | | from a list of receivers |
| | | (OPTIONAL). |
+----------------------+-------------+---------------------------------+
|NORM_CMD(APPLICATION) | 7 | Used for application-defined |
| | | purposes which may need to |
| | | temporarily preempt data |
| | | transmission (OPTIONAL). |
+----------------------+-------------+---------------------------------+
The NORM_CMD(FLUSH) command is sent when the sender reaches the end of all data content and pending repairs it has queued for transmission. This may indicate a temporary or permanent end of data transmission, but the sender is still willing to respond to repair requests. This command is repeated once per 2*GRTT to excite the receiver set for any outstanding repair requests up to and including the transmission point indicated within the NORM_CMD(FLUSH) message. The number of repeats is equal to NORM_ROBUST_FACTOR unless a list of receivers from which explicit positive acknowledgment is expected ("acking_node_list") is given. In that case, the "acking_node_list" is updated as acknowledgments are received and the NORM_CMD(FLUSH) is repeated according to the mechanism described in Section 5.5.3. The greater the NORM_ROBUST_FACTOR, the greater the probability that all applicable receivers will be excited for acknowledgment or repair requests (NACKs) _and_ that the corresponding NACKs are delivered to the sender. If a NORM_NACK message interrupts the flush process, the sender will re-initiate the flush process after any resulting repair transmissions are completed.
NORM_CMD(FLUSH) コマンドは、送信側が送信用にキューに入れられたすべてのデータ コンテンツと保留中の修復の終わりに到達したときに送信されます。これは、データ送信の一時的または永続的な終了を示している可能性がありますが、送信者は依然として修復要求に応じる意思があります。このコマンドは 2*GRTT ごとに 1 回繰り返され、NORM_CMD(FLUSH) メッセージ内で示された送信ポイントまでの未処理の修復要求に対して受信機セットを励起します。明示的な肯定応答が期待される受信者のリスト (「acking_node_list」) が指定されていない限り、繰り返しの数は NORM_ROBUST_FACTOR に等しくなります。その場合、確認応答が受信されると「acking_node_list」が更新され、セクション 5.5.3 で説明されているメカニズムに従って NORM_CMD(FLUSH) が繰り返されます。NORM_ROBUST_FACTOR が大きいほど、該当するすべての受信者が確認応答または修復要求 (NACK) に対して励起され、対応する NACK が送信者に配信される可能性が高くなります。NORM_NACK メッセージがフラッシュ プロセスを中断した場合、送信者は結果として生じる修復送信が完了した後にフラッシュ プロセスを再開始します。
Note that receivers also employ a timeout mechanism to self-initiate NACKing (if there are outstanding repair needs) when no messages of any type are received from a sender. This inactivity timeout is related to 2*GRTT*NORM_ROBUST_FACTOR and will be discussed more later. With a sufficient NORM_ROBUST_FACTOR value, data content is delivered with a high assurance of reliability. The penalty of a large NORM_ROBUST_FACTOR value is potentially excess sender NORM_CMD(FLUSH) transmissions and a longer timeout for receivers to self-initiate the terminal NACK process.
受信者は、送信者からどのタイプのメッセージも受信しない場合に、（未解決の修復の必要がある場合に）NACK を自動的に開始するタイムアウト メカニズムも採用していることに注意してください。この非アクティブ タイムアウトは 2*GRTT*NORM_ROBUST_FACTOR に関連しており、後で詳しく説明します。十分な NORM_ROBUST_FACTOR 値があれば、データ コンテンツは高い信頼性を保証して配信されます。NORM_ROBUST_FACTOR 値を大きくすると、送信側の NORM_CMD(FLUSH) 送信が過剰になる可能性があり、受信側が端末 NACK プロセスを自己開始するためのタイムアウトが長くなる可能性があります。
For finite-size transport objects such as NORM_OBJECT_DATA and NORM_OBJECT_FILE, the flush process (if there are no further pending objects) occurs at the end of these objects. Thus, FEC repair information is always available for repairs in response to repair requests elicited by the flush command. However, for NORM_OBJECT_STREAM, the flush may occur at any time, including in the middle of an FEC coding block if systematic FEC codes are employed. In this case, the sender will not yet be able to provide FEC parity content as repair for the concurrent coding block and will be limited to explicitly repairing stream data content for that block. Applications that anticipate frequent flushing of stream content SHOULD be judicious in the selection of the FEC coding block size (i.e., do not use a very large coding block size if frequent flushing occurs). For example, a reliable multicast application transmitting an on-going series of intermittent, relatively small messaging content will need to trade-off using the NORM_OBJECT_DATA paradigm versus the NORM_OBJECT_STREAM paradigm with an appropriate FEC coding block size. This is analogous to application trade-offs for other transport protocols such as the selection of different TCP modes of operation such as "no delay", etc.
NORM_OBJECT_DATA や NORM_OBJECT_FILE などの有限サイズのトランスポート オブジェクトの場合、フラッシュ プロセス (保留中のオブジェクトが他にない場合) はこれらのオブジェクトの最後に発生します。したがって、FEC 修復情報は、フラッシュ コマンドによって引き起こされた修復要求に応じた修復に常に利用できます。ただし、NORM_OBJECT_STREAM の場合、体系的な FEC コードが使用されている場合は、FEC コーディング ブロックの途中を含め、フラッシュはいつでも発生する可能性があります。この場合、送信者は同時コーディング ブロックの修復として FEC パリティ コンテンツを提供することはまだできず、そのブロックのストリーム データ コンテンツを明示的に修復することに限定されます。ストリーム コンテンツの頻繁なフラッシュを予期するアプリケーションは、FEC コーディング ブロック サイズの選択において賢明であるべきです (つまり、頻繁なフラッシュが発生する場合は、非常に大きなコーディング ブロック サイズを使用しないでください)。たとえば、継続的な一連の断続的で比較的小さいメッセージング コンテンツを送信する信頼性の高いマルチキャスト アプリケーションでは、NORM_OBJECT_DATA パラダイムと NORM_OBJECT_STREAM パラダイムを適切な FEC コーディング ブロック サイズでトレードオフする必要があります。これは、「遅延なし」などのさまざまな TCP 動作モードの選択など、他のトランスポート プロトコルに対するアプリケーションのトレードオフに似ています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(FLUSH) Message Format
NORM_CMD(FLUSH) メッセージ形式
In addition to the NORM common message header and standard NORM_CMD fields, the NORM_CMD(FLUSH) message contains fields to identify the current status and logical transmit position of the sender.
NORM 共通メッセージ ヘッダーと標準 NORM_CMD フィールドに加えて、NORM_CMD(FLUSH) メッセージには送信者の現在のステータスと論理送信位置を識別するフィールドが含まれています。
The "fec_id" field indicates the FEC type used for the flushing "object_transport_id" and implies the size and format of the "fec_payload_id" field. Note the "hdr_len" value for the NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id" field when no header extensions are present.
「fec_id」フィールドは、「object_transport_id」のフラッシュに使用される FEC タイプを示し、「fec_payload_id」フィールドのサイズと形式を意味します。ヘッダー拡張が存在しない場合、NORM_CMD(FLUSH) メッセージの「hdr_len」値は 4 に「fec_payload_id」フィールドのサイズを加えたものであることに注意してください。
The "object_transport_id" and "fec_payload_id" fields indicate the sender's current logical "transmit position". These fields are interpreted in the same manner as in the NORM_DATA message type. Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check their completion state _through_ (including) this transmission position. If receivers have outstanding repair needs in this range, they SHALL initiate the NORM NACK Repair Process as described in Section 5.3. If receivers have no outstanding repair needs, no response to the NORM_CMD(FLUSH) is generated.
「object_transport_id」フィールドと「fec_payload_id」フィールドは、送信者の現在の論理的な「送信位置」を示します。これらのフィールドは、NORM_DATA メッセージ タイプの場合と同じ方法で解釈されます。NORM_CMD(FLUSH) を受信すると、受信機はこの送信位置 (を含む) を通じて完了状態をチェックすることが期待されます。受信機がこの範囲内で未解決の修復ニーズがある場合、セクション5.3で説明されているように、NORM NACK修復プロセスを開始するものとします(SHALL)。受信機に未処理の修復の必要性がない場合、NORM_CMD(FLUSH) に対する応答は生成されません。
For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers MUST request "explicit-only" repair of the identified "source_block_number" if the given "encoding_symbol_id" is less than the "source_block_len". This condition indicates the sender has not yet completed encoding the corresponding FEC block and parity content is not yet available. An "explicit-only" repair request consists of NACK content for the applicable "source_block_number" which does not include any requests for parity-based repair. This allows NORM sender applications to "flush" an ongoing stream of transmission when needed, even if in the middle of an FEC block. Once the sender resumes stream transmission and passes the end of the pending coding block, subsequent NACKs from receivers SHALL request parity-based repair as usual. Note that the use of a systematic FEC code is assumed here. Normal receiver NACK initiation and construction is discussed in detail in Section 5.3. The OPTIONAL "acking_node_list" field contains a list of NormNodeIds for receivers from which the sender is requesting explicit positive acknowledgment of reception up through the transmission point identified by the "object_transport_id" and "fec_payload_id" fields. The length of the list can be inferred from the length of the received NORM_CMD(FLUSH) message. When the "acking_node_list" is present, the lightweight positive acknowledgment process described in Section 5.5.3 SHALL be observed.
体系的な FEC コードを使用する NORM_OBJECT_STREAM オブジェクトの場合、受信者は、指定された "encoding_symbol_id" が "source_block_len" より小さい場合、識別された "source_block_number" の "明示的のみ" の修復を要求しなければなりません (MUST)。この状態は、送信者が対応する FEC ブロックのエンコードをまだ完了しておらず、パリティ コンテンツがまだ利用できないことを示します。「明示的のみ」の修復要求は、パリティベースの修復の要求を含まない、該当する「source_block_number」の NACK コンテンツで構成されます。これにより、NORM 送信側アプリケーションは、FEC ブロックの途中であっても、必要に応じて進行中の送信ストリームを「フラッシュ」できます。送信者がストリーム送信を再開し、保留中のコーディングブロックの終わりを通過すると、受信者からの後続の NACK は通常どおりパリティベースの修復を要求するものとします(SHALL)。ここでは体系的な FEC 符号の使用が想定されていることに注意してください。通常の受信側 NACK の開始と構築については、セクション 5.3 で詳しく説明します。オプションの「acking_node_list」フィールドには、送信者が「object_transport_id」および「fec_payload_id」フィールドで識別される送信ポイントまでの明示的な受信肯定応答を要求している受信者の NormNodeId のリストが含まれます。リストの長さは、受信した NORM_CMD(FLUSH) メッセージの長さから推測できます。「acking_node_list」が存在する場合、セクション5.5.3で説明されている軽量の肯定応答プロセスが監視されるものとします(SHALL)。
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(FLUSH) コマンドに使用されるのと同じ堅牢なメカニズムで送信されるべきです (SHOULD)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(EOT) Message Format
NORM_CMD(EOT)メッセージフォーマット
The value of the "hdr_len" field for NORM_CMD(EOT) messages without header extensions present is 4. The "reserved" field is reserved for future use and MUST be set to an all ZERO value. Receivers MUST ignore the "reserved" field.
ヘッダ拡張が存在しない NORM_CMD(EOT) メッセージの「hdr_len」フィールドの値は 4 です。「reserved」フィールドは将来の使用のために予約されており、すべてゼロの値に設定しなければなりません。受信者は「reserved」フィールドを無視しなければなりません(MUST)。
The NORM_CMD(SQUELCH) command is transmitted in response to outdated or invalid NORM_NACK content received by the sender. Invalid NORM_NACK content consists of repair requests for NormObjects for which the sender is unable or unwilling to provide repair. This includes repair requests for outdated objects, aborted objects, or those objects which the sender previously transmitted marked with the NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what content is available for repair, thus serving as a description of the sender's current "repair window". Receivers SHALL not generate repair requests for content identified as invalid by a NORM_CMD(SQUELCH).
NORM_CMD(SQUELCH) コマンドは、送信者が受信した古いまたは無効な NORM_NACK コンテンツに応答して送信されます。無効な NORM_NACK コンテンツは、送信者が修復を提供できない、または修復を希望しない NormObject の修復リクエストで構成されます。これには、期限切れのオブジェクト、中止されたオブジェクト、または送信者が以前に送信した NORM_FLAG_UNRELIABLE フラグを付けたオブジェクトの修復リクエストが含まれます。このコマンドは、受信者にどのコンテンツが修復可能であるかを示し、送信者の現在の「修復ウィンドウ」の説明として機能します。受信者は、NORM_CMD(SQUELCH) によって無効であると識別されたコンテンツに対して修復要求を生成してはならない(SHALL)。
The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most. The NORM_CMD(SQUELCH) advertises the current "repair window" of the sender by identifying the earliest (lowest) transmission point for which it will provide repair, along with an encoded list of objects from that point forward that are no longer valid for repair. This mechanism allows the sender application to cancel or abort transmission and/or repair of specific previously enqueued objects. The list also contains the identifiers for any objects within the repair window that were sent with the NORM_FLAG_UNRELIABLE flag set. In normal conditions, it is expected the NORM_CMD(SQUELCH) will be needed infrequently, and generally only to provide a reference repair window for receivers who have fallen "out-of-sync" with the sender due to extremely poor network conditions.
NORM_CMD(SQUELCH) コマンドは、最大 2*GRTT ごとに 1 回送信されます。NORM_CMD(SQUELCH) は、修復を提供する最も早い (最も低い) 送信ポイントを識別することによって、送信者の現在の「修復ウィンドウ」を通知します。また、その時点以降、修復が無効になったオブジェクトのエンコードされたリストも併せて指定します。このメカニズムにより、送信側アプリケーションは、以前にキューに入れられた特定のオブジェクトの送信や修復をキャンセルまたは中止できます。このリストには、NORM_FLAG_UNRELIABLE フラグが設定されて送信された、修復ウィンドウ内のオブジェクトの識別子も含まれています。通常の状況では、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:
無効な NormObject リストの開始点は、スケルチの生成を促した無効な NACK から始まる現在の「修復ウィンドウ」よりも大きい、最も低い無効な NormTransportId から始まります。リストの長さは、送信者の NormSegmentSize によって制限されます。これにより、受信側は、NORM_CMD(SQUELCH) コマンドの送信を最小限に抑えて、送信側の該当するオブジェクト修復ウィンドウのステータスを知ることができます。NORM_CMD(SQUELCH) メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type = 3 | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(SQUELCH) Message Format
NORM_CMD(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 which initiated the squelch transmission.
NORM 共通メッセージ ヘッダーと標準 NORM_CMD フィールドに加えて、NORM_CMD(SQUELCH) メッセージには、送信者の現在の修復ウィンドウの最も早い論理送信位置と、論理的に最も古い無効のインデックスで始まる「無効オブジェクト リスト」を識別するフィールドが含まれています。スケルチ送信を開始した問題の NACK メッセージからの修復要求。
The "object_transport_id" and "fec_payload_id" fields are concatenated to indicate the beginning of the sender's current repair window (i.e., the logically earliest point in its transmission history for which the sender can provide repair). The "fec_id" field implies the size and format of the "fec_payload_id" field. This serves as an advertisement of a "synchronization point" for receivers to request repair. Note, that while an "encoding_symbol_id" may be included in the "fec_payload_id" field, the sender's repair window SHOULD be aligned on FEC coding block boundaries and thus the "encoding_symbol_id" SHOULD be zero.
「object_transport_id」フィールドと「fec_payload_id」フィールドは、送信者の現在の修復ウィンドウの始まり（つまり、送信者が修復を提供できる送信履歴の論理的に最も早い時点）を示すために連結されます。「fec_id」フィールドは、「fec_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 is can be determined from the packet's payload length and is limited to a maximum of the NormSegmentSize of the sender. Thus, for very large repair windows, it is possible that a single NORM_CMD(SQUELCH) message may not be capable of listing the entire set of invalid objects in the repair window. In this case, the sender SHALL ensure that the list begins with a NormObjectId that is greater than or equal to the lowest ordinal invalid NormObjectId from the NACK message(s) that prompted the NORM_CMD(SQUELCH) generation. The NormObjectIds in the "invalid_object_list" MUST be greater than the "object_transport_id" marking the beginning of the sender's repair window. This insures convergence of the squelch process, even if multiple invalid NACK/ squelch iterations are required. This explicit description of invalid content within the sender's current window allows the sender application (most notably for discrete "object" based transport) to arbitrarily invalidate (i.e., dequeue) portions of enqueued content (e.g., certain objects) for which it no longer wishes to provide reliable transport.
「invalid_object_list」は、送信者の現在の修復ウィンドウの範囲内にあるものの、送信者からの修復にはもう利用できない 16 ビットの NormTransportId のリストです。たとえば、送信側アプリケーションは、まだ修復期間内であっても、期限切れのオブジェクトをデキューする場合があります。「invalid_object_list」コンテンツの合計サイズは、パケットのペイロード長から決定でき、送信者の最大 NormSegmentSize に制限されます。したがって、修復ウィンドウが非常に大きい場合、単一の NORM_CMD(SQUELCH) メッセージでは修復ウィンドウ内の無効なオブジェクトのセット全体をリストできない可能性があります。この場合、送信者は、リストが、NORM_CMD(SQUELCH) 生成を促した NACK メッセージの無効な NormObjectId の最小順序以上の NormObjectId で始まることを保証するものとします (SHALL)。「invalid_object_list」内の NormObjectId は、送信者の修復ウィンドウの開始を示す「object_transport_id」より大きくなければなりません。これにより、無効な NACK/スケルチの反復が複数回必要な場合でも、スケルチ プロセスの収束が保証されます。送信側の現在のウィンドウ内で無効なコンテンツを明示的に記述することにより、送信側アプリケーション (特に個別の「オブジェクト」ベースのトランスポートの場合) は、キューに入っているコンテンツ (特定のオブジェクトなど) の不要になった部分を任意に無効にする (つまり、デキューする) ことができます。信頼性の高い輸送を提供します。
The NORM_CMD(CC) messages contains fields to enable sender-to-receiver group greatest round-trip time (GRTT) measurement and to excite the group for congestion control feedback. A baseline NORM congestion control scheme (NORM-CC), based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme of [19] is described in Section 5.5.2 of this document. The NORM_CMD(CC) message is usually transmitted as part of NORM-CC congestion control operation. A NORM header extension is defined below to be used with the NORM_CMD(CC) message to support NORM-CC operation. Different header extensions may be defined for the NORM_CMD(CC) (and/or other NORM messages as needed) to support alternative congestion control schemes in the future. If NORM is operated in a private network with congestion control operation disabled, the NORM_CMD(CC) message is then used for GRTT measurement only and may optionally be sent less frequently than with congestion control operation.
NORM_CMD(CC) メッセージには、送信者から受信者へのグループ最大ラウンドトリップ時間 (GRTT) の測定を可能にし、輻輳制御フィードバックのためにグループを励起するためのフィールドが含まれています。[19] の TCP フレンドリー マルチキャスト輻輳制御 (TFMCC) スキームに基づくベースライン NORM 輻輳制御スキーム (NORM-CC) は、この文書のセクション 5.5.2 で説明されています。NORM_CMD(CC) メッセージは通常、NORM-CC 輻輳制御動作の一部として送信されます。NORM ヘッダー拡張は、NORM-CC 動作をサポートするために NORM_CMD(CC) メッセージとともに使用されるように以下で定義されています。将来、代替の輻輳制御スキームをサポートするために、NORM_CMD(CC) (および/または必要に応じて他の NORM メッセージ) に対して異なるヘッダー拡張が定義される可能性があります。NORM が輻輳制御動作が無効なプライベート ネットワークで動作している場合、NORM_CMD(CC) メッセージは GRTT 測定のみに使用され、オプションで輻輳制御動作よりも少ない頻度で送信される場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 4 | reserved | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(CC) Message Format
NORM_CMD(CC)メッセージフォーマット
The NORM common message header and standard NORM_CMD fields serve their usual purposes.
NORM 共通メッセージ ヘッダーと標準 NORM_CMD フィールドは、通常の目的を果たします。
The "reserved" field is for potential future use and should be set to ZERO in this version of the NORM protocol.
「予約済み」フィールドは将来使用される可能性があるため、NORM プロトコルのこのバージョンでは 0 に設定する必要があります。
The "cc_sequence" field is a sequence number applied by the sender. For NORM-CC operation, it is used to provide functionality equivalent to the "feedback round number" (fb_nr)described in [19]. The most recently received "cc_sequence" value is recorded by receivers and can be fed back to the sender in congestion control feedback generated by the receivers for that sender. The "cc_sequence" number can also be used in NORM implementations to assess how recently a receiver has received NORM_CMD(CC) probes from the sender. This can be useful instrumentation for complex or experimental multicast routing environments.
「cc_sequence」フィールドは、送信者によって適用されるシーケンス番号です。NORM-CC 動作の場合、[19] で説明されている「フィードバック ラウンド番号」(fb_nr) と同等の機能を提供するために使用されます。最近受信した「cc_sequence」値は受信機によって記録され、その送信機に対して受信機によって生成される輻輳制御フィードバックで送信機にフィードバックできます。「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)メッセージが送信された時刻を示すタイムスタンプである。これは、ソースが維持する基準時間 (通常は 00:00:00) から、秒単位の時刻を含む 32 ビット (「send_time_sec」) とマイクロ秒単位の時刻を含む 32 ビット (「send_time_usec」) を含む 64 ビット フィールドで構成されます。、1970年1月1日）。フィールドのバイト順序は「ビッグ エンディアン」ネットワーク順序です。受信機は、NORM_CMD(CC) メッセージの受信時から、生成された NORM_ACK および NORM_NACK メッセージの「grtt_response」部分としての応答時までの遅延量によって調整されたこのタイムスタンプを使用します。これにより、送信者は、輻輳制御やその他 (GRTT 決定など) の目的で、さまざまな受信者への往復時間を評価することができます。
To facilitate the baseline NORM-CC scheme described in Section 5.5.2, a NORM-CC Rate header extension (EXT_RATE) is defined to inform the group of the sender's current transmission rate. This is used along with the loss detection "sequence" field of all NORM sender messages and the NORM_CMD(CC) GRTT collection process to support NORM-CC congestion control operation. The format of this header extension is as follows:
セクション 5.5.2 で説明されているベースライン NORM-CC スキームを容易にするために、NORM-CC レート ヘッダー拡張 (EXT_RATE) が定義され、送信者の現在の送信レートをグループに通知します。これは、すべての NORM 送信者メッセージの損失検出「シーケンス」フィールドおよび NORM-CC 輻輳制御動作をサポートする 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Rate Header Extension Format (EXT_RATE)
NORM-CC レート ヘッダー拡張フォーマット (EXT_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 exponent (order of magnitude) information in the least significant portion. The 12-bit mantissa portion of the field is scaled such that a floating point value of 0.0 corresponds to 0 and a floating point value of 10.0 corresponds to 4096. Thus:
「send_rate」フィールドは、送信者の現在の送信速度をバイト/秒で示します。16 ビットの「send_rate」フィールドは、最上位部分の 12 ビットの仮数と、最下位部分の 4 ビットの 10 進数の指数 (大きさの桁) 情報で構成されます。フィールドの 12 ビットの仮数部分は、浮動小数点値 0.0 が 0 に対応し、浮動小数点値 10.0 が 4096 に対応するようにスケーリングされます。つまり、次のようになります。
send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) |
Value_exponent;
For example, to represent a transmission rate of 256kbps (3.2e+04 bytes per second), the lower 4 bits of the 16-bit field contain a value of 0x04 to represent the exponent while the upper 12 bits contain a value of 0x51f as determined from the equation given above:
たとえば、256kbps (3.2e 04 バイト/秒) の伝送速度を表すには、16 ビット フィールドの下位 4 ビットには指数を表す値 0x04 が含まれ、上位 12 ビットには決定された値 0x51f が含まれます。上に与えられた式から:
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4
= 0x51f4
= 0x51f4
To decode the "send_rate" field, the following equation can be used:
「send_rate」フィールドをデコードするには、次の方程式を使用できます。
value = (send_rate >> 4) * 10.0 / 4096.0 *
power(10.0, (send_rate & x000f))
Note the maximum transmission rate that can be represented by this scheme is approximately 9.99e+15 bytes per second.
この方式で表現できる最大伝送速度は、1 秒あたり約 9.99e 15 バイトであることに注意してください。
When this extension is present, a "cc_node_list" may be attached as the payload of the NORM_CMD(CC) message. The presence of this header extension also implies that NORM receivers should respond according to the procedures described in Section 5.5.2. The "cc_node_list" consists of a list of NormNodeIds and their associated congestion control status. This includes the current limiting receiver (CLR) node, any potential limiting receiver (PLR) nodes that have been identified, and some number of receivers for which congestion control status is being provided, most notably including the receivers' current RTT measurement. The maximum length of the "cc_node_list" provides for at least the CLR and one other receiver, but may be configurable for more timely feedback to the group. The list length can be inferred from the length of the NORM_CMD(CC) message.
この拡張が存在する場合、「cc_node_list」が NORM_CMD(CC) メッセージのペイロードとして添付される可能性があります。このヘッダー拡張の存在は、NORM 受信者がセクション 5.5.2 で説明されている手順に従って応答する必要があることも意味します。「cc_node_list」は、NormNodeId のリストとそれに関連する輻輳制御ステータスで構成されます。これには、電流制限受信機 (CLR) ノード、特定された潜在的制限受信機 (PLR) ノード、輻輳制御ステータスが提供されているいくつかの受信機が含まれ、特に受信機の現在の RTT 測定値が含まれます。「cc_node_list」の最大長は、少なくとも CLR と他の 1 つの受信機に提供されますが、グループへのよりタイムリーなフィードバックのために構成可能である場合があります。リストの長さは、NORM_CMD(CC) メッセージの長さから推測できます。
Each item in the "cc_node_list" is in the following format:
「cc_node_list」の各項目は次の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Control Node List Item Format
輻輳制御ノードリスト項目フォーマット
The "cc_node_id" is the NormNodeId of the receiver which the item represents.
「cc_node_id」は、アイテムが表す受信者の NormNodeId です。
The "cc_flags" field contains flags indicating the congestion control status of the indicated receiver. The following flags are defined:
「cc_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 NORM Building Block document [4]. The "cc_rate" field contains a representation of the receiver's current calculated (during steady-state congestion control operation) or twice its measured (during the "slow start" phase) congestion control rate. This field is encoded and decoded using the same technique as described for the NORM_CMD(CC) "send_rate" field.
「cc_rtt」には、指定された受信者に関して送信者によって測定された RTT の量子化表現が含まれます。このフィールドは、NORM_FLAG_CC_RTT フラグが「cc_flags」フィールドに設定されている場合にのみ有効です。この 1 バイトのフィールドは、NORM Building Block 文書 [4] で説明されているアルゴリズムを使用した RTT の量子化表現です。「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 "echoing" this information to the receiver set, suppression of feedback can be achieved even when receivers are unicasting that feedback instead of multicasting it among the group [13].
NORM_CMD(REPAIR_ADV) メッセージは、受信した修復サイクルおよび/または輻輳制御フィードバック中に蓄積された NORM_NACK メッセージから集約された修復状態を「通知」するために送信者によって使用されます。このメッセージは、送信者がマルチキャストではなくユニキャスト送信経由で NORM_NACK および/または NORM_ACK(CC) (輻輳制御が有効な場合) メッセージを受信した場合にのみ送信されます。この情報を受信機セットに「エコー」することにより、受信機がそのフィードバックをグループ内でマルチキャストするのではなくユニキャストしている場合でも、フィードバックの抑制を達成できます[13]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 5 | flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_adv_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(REPAIR_ADV) Message Format
NORM_CMD(REPAIR_ADV) メッセージ形式
The "instance_id", "grtt", "backoff", "gsize", and "flavor" fields serve the same purpose as in other NORM_CMD messages. The value of the "hdr_len" field when no extensions are present is 4.
「instance_id」、「grtt」、「backoff」、「gsize」、および「flavor」フィールドは、他の NORM_CMD メッセージと同じ目的を果たします。拡張子が存在しない場合の「hdr_len」フィールドの値は 4 です。
The "flags" field provide information on the NORM_CMD(REPAIR_ADV) content. There is currently one NORM_CMD(REPAIR_ADV) flag defined:
「flags」フィールドは、NORM_CMD(REPAIR_ADV) コンテンツに関する情報を提供します。現在、NORM_CMD(REPAIR_ADV) フラグが 1 つ定義されています。
NORM_REPAIR_ADV_FLAG_LIMIT = 0x01
This flag is set by the sender when it is unable to fit its full current repair state into a single NormSegmentSize. If this flag is set, receivers should limit their NACK response to generating NACK content only up through the maximum ordinal transmission position (objectId::fecPayloadId) included in the "repair_adv_content".
このフラグは、現在の修復状態を 1 つの NormSegmentSize に完全に収めることができない場合に、送信者によって設定されます。このフラグが設定されている場合、受信機は NACK 応答を、「repair_adv_content」に含まれる最大順序送信位置 (objectId::fecPayloadId) までのみ NACK コンテンツの生成に制限する必要があります。
When congestion control operation is enabled, a header extension may be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting (in terms of congestion control feedback suppression) congestion control response. This allows the NORM_CMD(REPAIR_ADV) message to suppress receiver congestion control responses as well as NACK feedback messages. The field is defined as a header extension so that alternative congestion control schemes may be used with NORM without revision to this document. A NORM-CC Feedback Header Extension (EXT_CC) is defined to encapsulate congestion control feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV) messages. If another congestion control technique (e.g., Pragmatic General Multicast Congestion Control (PGMCC) [20]) is used within a NORM implementation, an additional header extension MAY need to be defined to encapsulate any required feedback content. The NORM-CC Feedback Header Extension format is:
輻輳制御動作が有効な場合、(輻輳制御フィードバック抑制の点で) 最も制限的な輻輳制御応答を表す NORM_CMD(REPAIR_ADV) にヘッダ拡張が適用される場合があります。これにより、NORM_CMD(REPAIR_ADV) メッセージは、NACK フィードバック メッセージだけでなく受信機の輻輳制御応答も抑制できます。このフィールドはヘッダー拡張として定義されているため、この文書を改訂することなく代替の輻輳制御スキームを NORM で使用できるようになります。NORM-CC フィードバック ヘッダー拡張 (EXT_CC) は、NORM_NACK、NORM_ACK、および NORM_CMD(REPAIR_ADV) メッセージ内に輻輳制御フィードバックをカプセル化するために定義されています。NORM 実装内で別の輻輳制御技術 (例: Pragmatic General Multicast Congestion Control (PGMCC) [20]) が使用される場合、必要なフィードバック コンテンツをカプセル化するために追加のヘッダ拡張を定義する必要があってもよい(MAY)。NORM-CC フィードバック ヘッダー拡張の形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Feedback Header Extension (EXT_CC) Format
NORM-CC フィードバック ヘッダー拡張 (EXT_CC) フォーマット
The "cc_sequence" field contains the current greatest "cc_sequence" value receivers have received in NORM_CMD(CC) messages from the sender. This information assists the sender in congestion control operation by providing an indicator of how current ("fresh") the receiver's round-trip measurement reference time is and whether the receiver has been successfully receiving recent congestion control probes. For example, if it is apparent the receiver has not been receiving recent congestion control probes (and thus possibly other messages from the sender), the sender may choose to take congestion avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_sequence" field value to the value set in the last NORM_CMD(CC) message sent.
「cc_sequence」フィールドには、受信者が送信者から NORM_CMD(CC) メッセージで受信した現在の最大の「cc_sequence」値が含まれます。この情報は、受信側の往復測定基準時間がどの程度最新 (「最新」) であるか、また受信側が最近の輻輳制御プローブを正常に受信できているかどうかの指標を提供することにより、送信側の輻輳制御動作を支援します。たとえば、受信者が最近輻輳制御プローブ (および送信者からの他のメッセージ) を受信していないことが明らかな場合、送信者は輻輳回避措置を講じることを選択できます。NORM_CMD(REPAIR_ADV) メッセージの場合、送信者は、「cc_sequence」フィールドの値を、最後に送信された NORM_CMD(CC) メッセージに設定された値に設定するものとします(SHALL)。
The "cc_flags" field contains bits representing the receiver's state with respect to congestion control operation. The possible values for the "cc_flags" field are those specified for the NORM_CMD(CC) message node list item flags. These fields are used by receivers in controlling (suppressing as necessary) their congestion control feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT should be set only when all feedback messages received by the sender have the flag set. Similarly, the NORM_FLAG_CC_CLR or NORM_FLAG_CC_PLR should be set only when no feedback has been received from non-CLR or non-PLR receivers. And the NORM_FLAG_CC_LEAVE should be set only when all feedback messages the sender has received have this flag set. These heuristics for setting the flags in NORM_CMD(REPAIR_ADV) ensure the most effective suppression of receivers providing unicast feedback messages.
「cc_flags」フィールドには、輻輳制御動作に関する受信機の状態を表すビットが含まれています。「cc_flags」フィールドの可能な値は、NORM_CMD(CC) メッセージ ノード リスト項目フラグに指定された値です。これらのフィールドは、受信機が輻輳制御フィードバックを制御する (必要に応じて抑制する) 際に使用されます。NORM_CMD(REPAIR_ADV) メッセージの場合、送信者が受信したすべてのフィードバック メッセージにフラグが設定されている場合にのみ、NORM_FLAG_CC_RTT を設定する必要があります。同様に、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.
「cc_rtt」フィールドはデフォルトの最大値に設定されるものとし(SHALL)、受信機がまだRTT測定情報を受信していない場合、NORM_FLAG_CC_RTTフラグはクリアされるものとする(SHALL)。受信機が RTT 測定情報を受信すると、それに応じて「cc_rtt」値を設定し、「cc_flags」フィールドに NORM_FLAG_CC_RTT フラグを設定します。
For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has measured from receivers for the current feedback round.
NORM_CMD(REPAIR_ADV) メッセージの場合、送信者は、「cc_rtt」フィールドの値を、現在のフィードバック ラウンドで受信者から測定した最大の非 CLR/非 PLR RTT に設定するものとします (SHALL)。
The "cc_loss" field represents the receiver's current packet loss fraction estimate for the indicated source. The loss fraction is a value from 0.0 to 1.0 corresponding to a range of zero to 100 percent packet loss. The 16-bit "cc_loss" value is calculated by the following formula:
「cc_loss」フィールドは、指定されたソースに対する受信者の現在のパケット損失率推定値を表します。損失率は 0.0 ～ 1.0 の値で、パケット損失の 0 ～ 100 パーセントの範囲に対応します。16 ビットの「cc_loss」値は次の式で計算されます。
"cc_loss" = decimal_loss_fraction * 65535.0
"cc_loss" = 10 進数の損失率 * 65535.0
For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" field value to the largest non-CLR/non-PLR loss estimate it has received from receivers for the current feedback round.
NORM_CMD(REPAIR_ADV) メッセージの場合、送信者は、「cc_loss」フィールド値を、現在のフィードバック ラウンドで受信者から受信した最大の非 CLR/非 PLR 損失推定値に設定するものとします (SHALL)。
The "cc_rate" field represents the receivers current local congestion control rate. During "slow start", when the receiver has detected no loss, this value is set to twice the actual rate it has measured from the corresponding sender and the NORM_FLAG_CC_START is set in the "cc_flags' field. Otherwise, the receiver calculates a congestion control rate based on its loss measurement and RTT measurement information (even if default) for the "cc_rate" field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" field value to the lowest non-CLR/non-PLR "cc_rate" report it has received from receivers for the current feedback round.
「cc_rate」フィールドは、受信機の現在のローカル輻輳制御レートを表します。「スロー スタート」中、受信機が損失を検出しない場合、この値は対応する送信機から測定した実際のレートの 2 倍に設定され、NORM_FLAG_CC_START が「cc_flags」フィールドに設定されます。それ以外の場合、受信機は輻輳制御を計算します。"cc_rate" フィールドの損失測定および RTT 測定情報 (デフォルトであっても) に基づくレート。NORM_CMD(REPAIR_ADV) メッセージの場合、送信者は "cc_loss" フィールド値を最も低い非 CLR/非 PLR に設定するものとします (SHALL)。cc_rate" は、現在のフィードバック ラウンドで受信機から受信したレポートを返します。
The "cc_reserved" field is reserved for future NORM protocol use. Currently, senders SHALL set this field to ZERO, and receivers SHALL ignore the content of this field.
「cc_reserved」フィールドは、将来の NORM プロトコルの使用のために予約されています。現在、送信者はこのフィールドをゼロに設定し、受信者はこのフィールドの内容を無視するものとします(SHALL)。
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_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:
NORM_CMD(ACK_REQ) メッセージは、指定された受信者のリストからの確認応答を要求するために送信者によって使用されます。このメッセージは、信頼性の高いマルチキャスト アプリケーションによる使用がオプションである軽量の肯定応答メカニズムを提供するために使用されます。アプリケーションの裁量で使用できるよう、さまざまな確認要求タイプが提供されています。アプリケーション定義の肯定応答コマンドの提供により、アプリケーションは NORM プロトコルで利用可能な送信および往復のタイミング情報を自動的に利用できるようになります。NORM_CMD(ACK_REQ) メッセージと受信側応答 (NORM_ACK) の送信を含む NORM 肯定応答プロセスの詳細は、セクション 5.5.3 で説明されています。NORM_CMD(ACK_REQ) メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(ACK_REQ) Message Format
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 共通メッセージ ヘッダーと標準 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_ACK でのみ使用するために提供されます。同様に、NORM_ACK_FLUSH は、該当する NORM_CMD(FLUSH) メッセージに応答して生成される NORM_ACK でのみ使用するために提供されます。NORM_ACK_CC または NORM_ACK_FLUSH の "ack_type" を持つ NORM_CMD(ACK_REQ) メッセージは、送信者によって生成されてはなりません (SHALL NOT)。
The NORM_ACK_RESERVED range of "ack_type" values is provided for possible future NORM protocol use.
「ack_type」値の NORM_ACK_RESERVED 範囲は、将来の NORM プロトコルの使用に備えて提供されています。
The NORM_ACK_APPLICATION range of "ack_type" values is provided so that NORM applications may implement application-defined, positively-acknowledged commands that are able to leverage internal transmission and round-trip timing information available to the NORM protocol implementation.
「ack_type」値の NORM_ACK_APPLICATION 範囲は、NORM アプリケーションが、NORM プロトコル実装で利用可能な内部送信および往復タイミング情報を活用できる、アプリケーション定義の肯定応答コマンドを実装できるように提供されます。
The "ack_id" provides a sequenced identifier for the given NORM_CMD(ACK_REQ) message. This "ack_id" is returned in NORM_ACK messages generated by the receivers so that the sender may associate the response with its corresponding request.
「ack_id」は、指定された NORM_CMD(ACK_REQ) メッセージの順序付けされた識別子を提供します。この「ack_id」は、送信者が応答を対応する要求に関連付けることができるように、受信者によって生成された NORM_ACK メッセージで返されます。
The "reserved" field is reserved for possible future protocol use and SHALL be set to ZERO by senders and ignored by receivers.
「予約済み」フィールドは、将来のプロトコル使用の可能性のために予約されており、送信者はゼロに設定し、受信者は無視するものとします (SHALL)。
The "acking_node_list" field contains the NormNodeIds of the current NORM receivers that are desired to provide positive acknowledge (NORM_ACK) to this request. The packet payload length implies the length of the "acking_node_list" and its length is limited to the sender NormSegmentSize. The individual NormNodeId items are listed in network (Big Endian) byte order. If a receiver's NormNodeId is included in the "acking_node_list", it SHALL schedule transmission of a NORM_ACK message as described in Section 5.5.3.
「acking_node_list」フィールドには、この要求に対して肯定応答 (NORM_ACK) を提供することが望まれる現在の NORM 受信者の NormNodeId が含まれます。パケットのペイロード長は「acking_node_list」の長さを意味し、その長さは送信者の NormSegmentSize に制限されます。個々の NormNodeId 項目は、ネットワーク (ビッグ エンディアン) バイト オーダーでリストされます。受信者のNormNodeIdが「acking_node_list」に含まれている場合、セクション5.5.3で説明されているように、NORM_ACKメッセージの送信をスケジュールするものとします(SHALL)。
This command allows the NORM application to robustly transmit application-defined commands. The command message preempts any ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR times at a rate of once per 2*GRTT. This rate of repetition allows the application to observe any response (if that is the application's purpose for the command) before it is repeated. Possible responses may include initiation of data transmission, other NORM_CMD(APPLICATION) messages, or even application-defined, positively-acknowledge commands from other NormSession participants. The transmission of these commands will preempt data transmission when they are scheduled and may be multiplexed with ongoing data transmission. This type of robustly transmitted command allows NORM applications to define a complete set of session control mechanisms with less state than the transfer of FEC encoded reliable content requires while taking advantage of NORM transmission and round-trip timing information.
このコマンドにより、NORM アプリケーションはアプリケーション定義のコマンドを確実に送信できるようになります。コマンド メッセージは進行中のデータ送信をプリエンプトし、2*GRTT ごとに 1 回の割合で NORM_ROBUST_FACTOR 回まで繰り返されます。この繰り返し速度により、アプリケーションは応答が繰り返される前に (それがアプリケーションのコマンドの目的である場合) 応答を観察できます。考えられる応答には、データ送信の開始、他の NORM_CMD(APPLICATION) メッセージ、または他の 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 7 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-Defined Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(APPLICATION) Message Format
NORM_CMD(APPLICATION) メッセージ形式
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 共通メッセージ ヘッダーと NORM_CMD フィールドは、前述のように解釈されます。ヘッダー拡張が存在しない場合の NORM_CMD(APPLICATION) の「hdr_len」フィールドの値は 4 です。
The "Application-Defined Content" area contains information in a format at the discretion of the application. The size of this payload SHALL be limited to a maximum of the sender's NormSegmentSize setting.
「アプリケーション定義コンテンツ」領域には、アプリケーションの裁量による形式で情報が含まれます。このペイロードのサイズは、送信者の NormSegmentSize 設定の最大値に制限されるものとします (SHALL)。
The NORM message types generated by participating receivers consist of NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent to request repair of missing data content from sender transmission and NORM_ACK messages are generated in response to certain sender commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).
参加している受信者によって生成される NORM メッセージ タイプは、NORM_NACK および NORM_ACK メッセージ タイプで構成されます。NORM_NACK メッセージは、送信側の送信で失われたデータ コンテンツの修復を要求するために送信され、NORM_ACK メッセージは、NORM_CMD(CC) や NORM_CMD(ACK_REQ) などの特定の送信側コマンドに応答して生成されます。
The principal purpose of NORM_NACK messages is for receivers to request repair of sender content via selective, negative acknowledgment upon detection of incomplete data. NORM_NACK messages will be transmitted according to the rules of NORM_NACK generation and suppression described in Section 5.3. NORM_NACK messages also contain additional fields to provide feedback to the sender(s) for purposes of round-trip timing collection and congestion control.
NORM_NACK メッセージの主な目的は、受信者が不完全なデータの検出時に選択的な否定応答を介して送信者のコンテンツの修復を要求することです。NORM_NACK メッセージは、セクション 5.3 で説明されている NORM_NACK の生成と抑制の規則に従って送信されます。NORM_NACK メッセージには、ラウンドトリップ タイミングの収集と輻輳制御の目的で送信者にフィードバックを提供するための追加フィールドも含まれています。
The payload of NORM_NACK messages contains one or more repair requests for different objects or portions of those objects. The NORM_NACK message format is as follows:
NORM_NACK メッセージのペイロードには、さまざまなオブジェクトまたはそれらのオブジェクトの一部に対する 1 つ以上の修復要求が含まれています。NORM_NACK メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=4| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nack_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_NACK Message Format
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 共通メッセージ ヘッダー フィールドは、通常の目的を果たします。ヘッダー拡張が存在しない NORM_NACK メッセージの「hdr_len」フィールドの値は 6 です。
The "server_id" field identifies the NORM sender to which the NORM_NACK message is destined.
「server_id」フィールドは、NORM_NACK メッセージの宛先となる NORM 送信者を識別します。
The "instance_id" field contains the current session identifier given by the sender identified by the "server_id" field in its sender messages. The sender SHOULD ignore feedback messages which contain an invalid "instance_id" value.
「instance_id」フィールドには、送信者メッセージの「server_id」フィールドで識別される送信者によって指定された現在のセッション識別子が含まれます。送信者は、無効な "instance_id" 値を含むフィードバック メッセージを無視すべきです (SHOULD)。
The "grtt_response" fields contain an adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender. The format of the "grtt_response" is the same as the "send_time" field of the NORM_CMD(CC). The "grtt_response" value is _relative_ to the "send_time" the source provided with a corresponding NORM_CMD(CC) command. The receiver adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the time differential from when the receiver received the NORM_CMD(CC) to when the NORM_NACK is transmitted to calculate the value in the "grtt_response" field. This is the "receive_to_response_differential" value used in the following formula:
「grtt_response」フィールドには、指定された NORM 送信者に対して最後に受信した NORM_CMD(CC) メッセージからのタイムスタンプの調整されたバージョンが含まれます。「grtt_response」のフォーマットは、NORM_CMD(CC)の「send_time」フィールドと同じである。「grtt_response」値は、対応する NORM_CMD(CC) コマンドでソースが提供した「send_time」に対して_相対的_です。受信機は、受信機が NORM_CMD(CC) を受信したときから NORM_NACK が送信されるときまでの時間差を加算して、「grtt_response」フィールドの値を計算することで、送信元の NORM_CMD(CC) の「send_time」タイムスタンプを調整します。これは、次の式で使用される「receive_to_response_Difference」値です。
"grtt_response" = NORM_CMD(CC) "send_time" + receive_to_response_differential
"grtt_response" = NORM_CMD(CC) "send_time" 受信対応答差分
The receiver SHALL set the "grtt_response" to a ZERO value, to indicate that it has not yet received a NORM_CMD(CC) message from the indicated sender and that the sender should ignore the "grtt_response" in this message.
受信者は、指定された送信者から NORM_CMD(CC) メッセージをまだ受信していないこと、および送信者がこのメッセージ内の "grtt_response" を無視する必要があることを示すために、「grtt_response」をゼロ値に設定するものとします(SHALL)。
For NORM-CC operation, the NORM-CC Feedback Header Extension, as described in the NORM_CMD(REPAIR_ADV} message description, is added to NORM_NACK messages to provide feedback on the receivers current state with respect to congestion control operation. Note that alternative header extensions for congestion control feedback may be defined for alternative congestion control schemes for NORM use in the future.
NORM-CC 動作の場合、NORM_CMD(REPAIR_ADV} メッセージの説明で説明されているように、NORM-CC フィードバック ヘッダー拡張機能が NORM_NACK メッセージに追加され、輻輳制御動作に関する受信者の現在の状態に関するフィードバックが提供されます。代替ヘッダー拡張機能に注意してください。輻輳制御フィードバックは、将来 NORM で使用される代替輻輳制御スキームに対して定義される可能性があります。
The "reserved" field is for potential future NORM use and SHALL be set to ZERO for this version of the protocol.
「予約済み」フィールドは、将来の NORM 使用の可能性のためのものであり、このバージョンのプロトコルでは 0 に設定されるものとします (SHALL)。
The "nack_content" of the NORM_NACK message specifies the repair needs of the receiver with respect to the NORM sender indicated by the "server_id" field. The receiver constructs repair requests based on the NORM_DATA and/or NORM_INFO segments it requires from the sender in order to complete reliable reception up to the sender's transmission position at the moment the receiver initiates the NACK Procedure as described in Section 5.3. A single NORM Repair Request consists of a list of items, ranges, and/or FEC coding block erasure counts for needed NORM_DATA and/or NORM_INFO content. Multiple repair requests may be concatenated within the "nack_payload" field of a NORM_NACK message. Note that a single NORM Repair Request can possibly include multiple "items", "ranges", or "erasure_counts". In turn, the "nack_payload" field may contain multiple repair requests. A single NORM Repair Request has the following format:
NORM_NACKメッセージの「nack_content」は、「server_id」フィールドによって示されるNORM送信者に対する受信者の修復の必要性を指定する。受信者は、セクション5.3で説明されているように、受信者がNACK手順を開始した瞬間に送信者の送信位置まで信頼性の高い受信を完了するために、送信者から要求するNORM_DATAおよび/またはNORM_INFOセグメントに基づいて修復リクエストを構築します。単一の NORM 修復リクエストは、必要な NORM_DATA および/または NORM_INFO コンテンツの項目、範囲、および/または FEC コーディング ブロック消去カウントのリストで構成されます。複数の修復要求は、NORM_NACK メッセージの「nack_payload」フィールド内で連結される場合があります。単一の NORM 修復リクエストには、複数の「項目」、「範囲」、または「erasure_counts」が含まれる可能性があることに注意してください。さらに、「nack_payload」フィールドには複数の修復リクエストが含まれる場合があります。単一の 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form | flags | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_request_items |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Repair Request Format
NORM修理リクエストフォーマット
The "form" field indicates the type of repair request items given in the "repair_request_items" list. Possible values for the "form" field include:
「form」フィールドは、「repair_request_items」リストに示される修理依頼項目の種類を示します。「フォーム」フィールドに指定できる値は次のとおりです。
Form Value NORM_NACK_ITEMS 1 NORM_NACK_RANGES 2 NORM_NACK_ERASURES 3
フォーム値 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 that the "repair_request_items" list consists of pairs of repair request items that correspond to inclusive ranges of repair needs. And the NORM_NACK_ERASURES "form" indicates that the repair request items are to be treated individually and that the "encoding_symbol_id" portion of the "fec_payload_id" field of the repair request item (see below) is to be interpreted as an "erasure count" for the FEC coding block identified by the repair request item's "source_block_number".
NORM_NACK_ITEMS の「form」値は、「repair_request_items」リスト内の各修復リクエスト項目が個別のリクエストとして扱われることを示します。NORM_NACK_RANGES の値は、「repair_request_items」リストが、修復ニーズの包括的な範囲に対応する修復要求項目のペアで構成されていることを示します。そして、NORM_NACK_ERASURES「フォーム」は、修復要求項目が個別に処理されること、および修復要求項目の「fec_payload_id」フィールドの「encoding_symbol_id」部分 (以下を参照) が、修復要求項目の「消去カウント」として解釈されることを示します。修復要求項目の「source_block_number」によって識別される FEC コーディング ブロック。
The "flags" field is currently used to indicate the level of data content for which the repair request items apply (i.e., an individual segment, entire FEC coding block, or entire transport object). Possible flag values include:
現在、「フラグ」フィールドは、修復要求項目が適用されるデータ コンテンツのレベル (つまり、個々のセグメント、FEC コーディング ブロック全体、またはトランスポート オブジェクト全体) を示すために使用されています。可能なフラグ値は次のとおりです。
+------------------+-------+-----------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+-----------------------------------------+
|NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range|
| | | of segments are required as repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range |
| | | of blocks in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_INFO | 0x04 | Indicates that NORM_INFO is required as |
| | | repair for the listed object(s). |
+------------------+-------+-----------------------------------------+
|NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or range |
| | | of objects in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and "fec_payload_id" fields are used to determine which sets or ranges of individual NORM_DATA segments are needed to repair content at the receiver. When the NORM_NACK_BLOCK flag is set, this indicates the receiver is completely missing the indicated coding block(s) and requires transmissions sufficient to repair the indicated block(s) in their entirety. When the NORM_NACK_INFO flag is set, this indicates the receiver is missing the NORM_INFO segment for the indicated "object_transport_id". Note the NORM_NACK_INFO may be set in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or may be set alone. When the NORM_NACK_OBJECT flag is set, this indicates the receiver is missing the entire NormTransportObject referenced by the "object_transport_id". This also implicitly requests any available NORM_INFO for the NormObject, if applicable. The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT is set.
NORM_NACK_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 も暗黙的に要求します。NORM_NACK_OBJECT フラグが設定されている場合、「fec_payload_id」フィールドは無視されます。
The "length" field value is the length in bytes of the "repair_request_items" field.
「length」フィールドの値は、「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.
「repair_request_items」フィールドは、次の形式のトランスポート データ ユニット識別子の個別または範囲ペアのリストで構成されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Repair Request Item Format
NORM修理依頼品フォーマット
The "fec_id" indicates the FEC type and can be used to determine the format of the "fec_payload_id" field. The "reserved" field is kept for possible future use and SHALL be set to a ZERO value and ignored by NORM nodes processing NACK content.
「fec_id」は FEC タイプを示し、「fec_payload_id」フィールドの形式を決定するために使用できます。「予約済み」フィールドは将来の使用に備えて保持され、ゼロ値に設定され、NACK コンテンツを処理する NORM ノードによって無視されるものとします (SHALL)。
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 required to complete reliable transmission, multiple NORM Repair Requests with different "form" and or "flags" values can be concatenated within a single NORM_NACK message. Additionally, NORM receivers SHALL construct NORM_NACK messages with their repair requests in ordinal order with respect to "object_transport_id" and "fec_payload_id" values. The "nack_payload" size SHALL NOT exceed the NormSegmentSize for the sender to which the NORM_NACK is destined.
受信機の修復ニーズにより、信頼性の高い送信を完了するには、異なる形式 (範囲および/または個々の項目の混合) またはタイプ (特定のセグメントおよび/またはブロックまたはオブジェクト全体の混合) が必要であることが指示される場合、異なる「形式」とまたは、「フラグ」値を単一の NORM_NACK メッセージ内で連結できます。さらに、NORM 受信者は、「object_transport_id」および「fec_payload_id」の値に関して順序どおりに修復要求を含む NORM_NACK メッセージを構築するものとします (SHALL)。「nack_payload」サイズは、NORM_NACK の宛先となる送信者の NormSegmentSize を超えてはなりません (SHALL NOT)。
NORM_NACK Content Examples:
NORM_NACK の内容の例:
In these examples, a small block, systematic FEC code ("fec_id" = 129) is assumed with a user data block length of 32 segments. In Example 1, a list of individual NORM_NACK_ITEMS repair requests is given. In Example 2, a list of NORM_NACK_RANGES requests _and_ a single NORM_NACK_ITEMS request are concatenated to illustrate the possible content of a NORM_NACK message. Note that FEC coding block erasure counts could also be provided in each case. However, the erasure counts are not really necessary since the sender can easily determine the erasure count while processing the NACK content. However, the erasure count option may be useful for operation with other FEC codes or for intermediate system purposes.
これらの例では、小さなブロックの体系的な FEC コード (「fec_id」 = 129) が、ユーザー データ ブロック長が 32 セグメントであると想定されています。例 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,8
例 1: NORM_NACK「nack_payload」: オブジェクト 12、コーディング ブロック 3、セグメント 2、5、8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x01 | length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. As mentioned in the NORM_CMD(ACK_REQ) message description, the acknowledgment type NORM_ACK_CC is provided for this purpose. The generation of NORM_ACK(CC) messages for round-trip timing estimation and congestion-control operation is described in Sections 5.5.1 and 5.5.2, respectively. However, some multicast applications may benefit from some limited form of positive acknowledgment for certain functions. A simple, scalable positive acknowledgment scheme is defined in Section 5.5.3 that can be leveraged by protocol implementations when appropriate. The NORM_CMD(FLUSH) may be used for OPTIONAL collection of positive acknowledgment of reliable reception to a certain "watermark" transmission point from specific receivers using this mechanism. The NORM_ACK type NORM_ACK_FLUSH is provided for this purpose and the format of the "nack_payload" for this acknowledgment type is given below. Beyond that, a range of application-defined "ack_type" values is provided for use at the NORM application's discretion. Implementations making use of application-defined positive acknowledgments may also make use the "nack_payload" as needed, observing the constraint that the "nack_payload" field size be limited to a maximum of the NormSegmentSize for the sender to which the NORM_ACK is destined.
NORM_ACK メッセージは、主に NORM 輻輳制御動作および往復タイミング測定の一部として使用されることを目的としています。NORM_CMD(ACK_REQ) メッセージの説明で述べたように、確認応答タイプ NORM_ACK_CC はこの目的のために提供されています。往復タイミング推定と輻輳制御動作のための NORM_ACK(CC) メッセージの生成については、それぞれセクション 5.5.1 と 5.5.2 で説明されています。ただし、一部のマルチキャスト アプリケーションでは、特定の機能に対する限定的な形式の肯定応答から恩恵を受ける場合があります。シンプルでスケーラブルな肯定応答スキームがセクション 5.5.3 で定義されており、必要に応じてプロトコル実装で活用できます。NORM_CMD(FLUSH) は、このメカニズムを使用する特定の受信機から特定の「ウォーターマーク」送信ポイントへの信頼できる受信の肯定応答のオプションの収集に使用できます。NORM_ACK タイプ NORM_ACK_FLUSH はこの目的のために提供されており、この確認応答タイプの「nack_payload」の形式は以下に示されています。さらに、アプリケーション定義の「ack_type」値の範囲が、NORM アプリケーションの裁量で使用するために提供されます。アプリケーション定義の肯定応答を利用する実装では、「nack_payload」フィールド サイズが NORM_ACK の宛先となる送信者の最大 NormSegmentSize に制限されるという制約を遵守しながら、必要に応じて「nack_payload」を使用することもできます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=5| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ack_payload (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_ACK Message Format
NORM_ACK メッセージのフォーマット
The NORM common message header fields serve their usual purposes.
NORM 共通メッセージ ヘッダー フィールドは、通常の目的を果たします。
The "server_id", "instance_id", and "grtt_response" fields serve the same purpose as the corresponding fields in NORM_NACK messages. And header extensions may be applied to support congestion control feedback or other functions in the same manner.
「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 that the sender can verify that a NORM_ACK message received actually applies to a current acknowledgment request. The "ack_id" field is not used in the case of the NORM_ACK_CC and NORM_ACK_FLUSH acknowledgment types.
「ack_id」フィールドはシーケンス番号として機能するため、送信者は受信した NORM_ACK メッセージが実際に現在の確認要求に適用されることを確認できます。「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:
「ack_payload」形式は「ack_type」の関数です。NORM_ACK_CC メッセージにはコンテンツが添付されていません。NORM_ACK ヘッダーのみが適用されます。NORM_ACK_FLUSH の場合、特定の「ack_payload」形式が定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_ACK_FLUSH "ack_payload" Format
NORM_ACK_FLUSH「ack_payload」形式
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(FLUSH) メッセージを受信者が確認するために使用されます。
The "ack_payload" of NORM_ACK messages for application-defined "ack_type" values is specific to the application but is limited in size to a maximum the NormSegmentSize of the sender referenced by the "server_id".
アプリケーション定義の「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 could be used for periodic performance reports from receivers in experimental NORM implementations. The format of this message is currently undefined. Experimental NORM implementations may define NORM_REPORT formats as needed for test purposes. These report messages SHOULD be disabled for interoperability testing between different NORM implementations.
これは、NORM 参加者によって生成されるオプションのメッセージです。このメッセージは、実験的な NORM 実装における受信機からの定期的なパフォーマンス レポートに使用できます。このメッセージの形式は現在未定義です。実験的な NORM 実装では、テスト目的で必要に応じて NORM_REPORT 形式を定義する場合があります。これらのレポート メッセージは、異なる NORM 実装間の相互運用性テストでは無効にする必要があります (SHOULD)。
This section describes the detailed interactions of senders and receivers participating in a NORM session. A simple synopsis of protocol operation is given here: 1) The sender periodically transmits NORM_CMD(CC) messages as needed to initialize and collect roundtrip timing and congestion control feedback from the receiver set.
このセクションでは、NORM セッションに参加する送信者と受信者の詳細な対話について説明します。プロトコル動作の簡単な概要を以下に示します。 1) 送信側は、必要に応じて NORM_CMD(CC) メッセージを定期的に送信し、ラウンドトリップ タイミングと受信側セットからの輻輳制御フィードバックを初期化して収集します。
2) The sender transmits an ordinal set of NormObjects segmented in the form of NORM_DATA messages labeled with NormTransportIds and logically identified with FEC encoding block numbers and symbol identifiers. NORM_INFO messages may optionally precede the transmission of data content for NORM transport objects.
2) 送信者は、NormTransportIds でラベル付けされ、FEC エンコード ブロック番号とシンボル識別子で論理的に識別される NORM_DATA メッセージの形式でセグメント化された NormObject の順序セットを送信します。NORM_INFO メッセージは、オプションで、NORM トランスポート オブジェクトのデータ コンテンツの送信に先行する場合があります。
3) As receivers detect missing content from the sender, they initiate repair requests with NORM_NACK messages. Note the receivers track the sender's most recent objectId::fecPayloadId transmit position and NACK _only_ for content ordinally prior to that transmit position. The receivers schedule random backoff timeouts before generating NORM_NACK messages and wait an appropriate amount of time before repeating the NORM_NACK if their repair request is not satisfied.
3) 受信者は送信者からの欠落コンテンツを検出すると、NORM_NACK メッセージを使用して修復リクエストを開始します。受信者は、送信者の最新の objectId::fecPayloadId 送信位置と、通常はその送信位置より前のコンテンツに対する NACK _only_ を追跡することに注意してください。受信側は、NORM_NACK メッセージを生成する前にランダム バックオフ タイムアウトをスケジュールし、修復要求が満たされない場合は適切な時間待ってから NORM_NACK を繰り返します。
4) The sender aggregates repair requests from the receivers and logically "rewinds" its transmit position to send appropriate repair messages. The sender sends repairs for the earliest ordinal transmit position first and maintains this ordinal repair transmission sequence. Previously untransmitted FEC parity content for the applicable FEC coding block is used for repair transmissions to the greatest extent possible. If the sender exhausts its available FEC parity content on multiple repair cycles for the same coding block, it resorts to an explicit repair strategy (possibly using parity content) to complete repairs. (The use of explicit repair is expected to be an exception in general protocol operation, but the possibility does exist for extreme conditions). The sender immediately assumes transmission of new content once it has sent pending repairs.
4) 送信側は受信側からの修復リクエストを集約し、送信位置を論理的に「巻き戻し」て適切な修復メッセージを送信します。送信者は、最初に最も早い順序の送信位置の修復を送信し、この順序の修復送信シーケンスを維持します。該当する FEC コーディング ブロックの以前に送信されなかった FEC パリティ コンテンツは、可能な限り修復送信に使用されます。送信者が同じコーディング ブロックに対する複数の修復サイクルで利用可能な FEC パリティ コンテンツを使い果たす場合、明示的な修復戦略 (おそらくパリティ コンテンツを使用) に頼って修復を完了します。(明示的な修復の使用は、一般的なプロトコル操作では例外であることが予想されますが、極端な条件ではその可能性が存在します)。送信者は、保留中の修復を送信すると、すぐに新しいコンテンツの送信を想定します。
5) The sender transmits NORM_CMD(FLUSH) messages when it reaches the end of enqueued transmit content and pending repairs. Receivers respond to the NORM_CMD(FLUSH) messages with NORM_NACK transmissions (following the same suppression backoff timeout strategy as for data) if they require further repair.
5) 送信者は、キューに入れられた送信コンテンツと保留中の修復の終わりに達すると、NORM_CMD(FLUSH) メッセージを送信します。受信機は、さらなる修復が必要な場合、NORM_NACK 送信で NORM_CMD(FLUSH) メッセージに応答します (データの場合と同じ抑制バックオフ タイムアウト戦略に従います)。
6) The sender transmissions are subject to rate control limits determined by congestion control mechanisms. In the baseline NORM-CC operation, each sender in a NormSession maintains its own independent congestion control state. Receivers provide congestion control feedback in NORM_NACK and NORM_ACK messages. NORM_ACK feedback for congestion control purposes is governed using a suppression mechanism similar to that for NORM_NACK messages.
6) 送信側の送信は、輻輳制御メカニズムによって決定されるレート制御制限の対象となります。ベースライン NORM-CC 動作では、NormSession 内の各送信側は独自の独立した輻輳制御状態を維持します。受信機は、NORM_NACK および NORM_ACK メッセージで輻輳制御フィードバックを提供します。輻輳制御を目的とした NORM_ACK フィードバックは、NORM_NACK メッセージの場合と同様の抑制メカニズムを使用して管理されます。
While this overall concept is relatively simple, there are details to each of these aspects that need to be addressed for successful, efficient, robust, and scalable NORM protocol operation.
この全体的な概念は比較的単純ですが、効率的で堅牢かつスケーラブルな NORM プロトコルの運用を成功させるためには、これらの各側面に対処する必要がある詳細があります。
Upon startup, the NORM sender immediately begins sending NORM_CMD(CC) messages to collect round trip timing and other information from the potential group. If NORM-CC congestion control operation is enabled, the NORM-CC Rate header extension MUST be included in these messages. Congestion control operation SHALL be observed at all times when operating in the general Internet. Even if congestion control operation is disabled at the sender, it may be desirable to use the NORM_CMD(CC) messaging to collect feedback from the group using the baseline NORM-CC feedback mechanisms. This proactive feedback collection can be used to establish a GRTT estimate prior to data transmission and potential NACK operation.
起動すると、NORM 送信側は直ちに NORM_CMD(CC) メッセージの送信を開始し、潜在的なグループからラウンド トリップ タイミングおよびその他の情報を収集します。NORM-CC 輻輳制御動作が有効な場合、NORM-CC レート ヘッダ拡張がこれらのメッセージに含まれなければなりません (MUST)。輻輳制御動作は、一般的なインターネットで動作する場合には常に監視されるものとします。送信側で輻輳制御操作が無効になっている場合でも、NORM_CMD(CC) メッセージングを使用して、ベースライン NORM-CC フィードバック メカニズムを使用してグループからフィードバックを収集することが望ましい場合があります。このプロアクティブなフィードバック収集を使用して、データ送信および潜在的な NACK 動作の前に GRTT 推定を確立できます。
In some cases, applications may wish for the sender to also proceed with data transmission immediately. In other cases, the sender may wish to defer data transmission until it has received some feedback or request from the receiver set indicating that receivers are indeed present. Note, in some applications (e.g., web push), this indication may come out-of-band with respect to the multicast session via other means. As noted, the periodic transmission of NORM_CMD(CC) messages may precede actual data transmission in order to have an initial GRTT estimate.
場合によっては、アプリケーションは送信側にもデータ送信を直ちに続行することを要求することがあります。他の場合には、送信者は、受信者セットから受信者が実際に存在していることを示す何らかのフィードバックまたは要求を受信するまで、データ送信を延期したい場合がある。一部のアプリケーション (Web プッシュなど) では、この表示は他の手段を介してマルチキャスト セッションに関して帯域外で送信される場合があることに注意してください。前述したように、初期 GRTT 推定値を取得するために、NORM_CMD(CC) メッセージの定期的な送信が実際のデータ送信に先立って行われる場合があります。
With inclusion of the OPTIONAL NORM FEC Object Transmission Information Header Extension, the NORM protocol sender message headers can contain all information necessary to prepare receivers for subsequent reliable reception. This includes FEC coding parameters, the sender NormSegmentSize, and other information. If this header extension is not used, it is presumed that receivers have received the FEC Object Transmission Information via other means. Additionally, applications may leverage the use of NORM_INFO messages associated with the session data objects in the session to provide application-specific context information for the session and data being transmitted. These mechanisms allow for operation with minimal pre-coordination among the senders and receivers.
オプションの NORM FEC オブジェクト送信情報ヘッダー拡張を含めることで、NORM プロトコルの送信側メッセージ ヘッダーには、受信側がその後の信頼性の高い受信を準備するために必要なすべての情報を含めることができます。これには、FEC コーディング パラメータ、送信者の NormSegmentSize、およびその他の情報が含まれます。このヘッダー拡張が使用されない場合、受信機は他の手段で FEC オブジェクト送信情報を受信したと推定されます。さらに、アプリケーションは、セッション内のセッション データ オブジェクトに関連付けられた NORM_INFO メッセージの使用を利用して、セッションおよび送信されるデータに関するアプリケーション固有のコンテキスト情報を提供する場合があります。これらのメカニズムにより、送信者と受信者間の事前調整を最小限に抑えた動作が可能になります。
The NORM sender begins segmenting application-enqueued data into NORM_DATA segments and transmitting it to the group. The segmentation algorithm is described in Section 5.1.1. The rate of transmission is controlled via congestion control mechanisms or is a fixed rate if desired for closed network operations. The receivers participating in the multicast group provide feedback to the sender as needed. When the sender reaches the end of data it has enqueued for transmission or any pending repairs, it transmits a series of NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT. Receivers may respond to these NORM_CMD(FLUSH) messages with additional repair requests. A protocol parameter "NORM_ROBUST_FACTOR" determines the number of flush messages sent. If receivers request repair, the repair is provided and flushing occurs again at the end of repair transmission. The sender may attach an OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing the NormNodeIds for receivers from which it expects explicit positive acknowledgment of reception. The NORM_CMD(FLUSH) message may be also used for this optional function any time prior to the end of data enqueued for transmission with the NORM_CMD(FLUSH) messages multiplexed with ongoing data transmissions. The OPTIONAL NORM positive acknowledgment procedure is described in Section 5.5.3.
NORM 送信側は、アプリケーションのキューに入れられたデータを NORM_DATA セグメントにセグメント化し、グループに送信し始めます。セグメンテーション アルゴリズムについては、セクション 5.1.1 で説明します。送信速度は輻輳制御メカニズムによって制御されるか、閉じたネットワーク操作で必要な場合は固定速度になります。マルチキャスト グループに参加している受信者は、必要に応じて送信者にフィードバックを提供します。送信者は、送信または保留中の修復のためにキューに入れられたデータの終わりに到達すると、一連の NORM_CMD(FLUSH) メッセージを 2*GRTT ごとに 1 つの割合で送信します。受信機は、追加の修復要求でこれらの NORM_CMD(FLUSH) メッセージに応答する場合があります。プロトコル パラメータ「NORM_ROBUST_FACTOR」によって、送信されるフラッシュ メッセージの数が決まります。受信機が修復を要求した場合、修復が提供され、修復送信の終了時に再びフラッシングが発生します。送信者は、受信の明示的な肯定応答を期待する受信者の NormNodeId を含むオプションの「acking_node_list」を NORM_CMD(FLUSH) に添付できます。NORM_CMD(FLUSH) メッセージは、進行中のデータ送信と多重化された NORM_CMD(FLUSH) メッセージによる送信のためにキューに入れられたデータが終了する前であれば、いつでもこのオプション機能に使用できます。OPTIONAL 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 that appropriate NACKs can be constructed to request repair of missing data. NORM FEC coding blocks are comprised of multi-byte symbols which are transmitted in the payload of NORM_DATA messages. Each NORM_DATA message contains one source or encoding symbol and the NormSegmentSize sender parameter defines the maximum symbol size in bytes. The FEC encoding type and associated parameters govern the source block size (number of source symbols per coding block). NORM senders and receivers use these FEC parameters, along with the NormSegmentSize and transport object size to compute the source block structure for transport objects. These parameters are provided in the FEC Transmission Information for each object. The algorithm given below is used to compute a source block structure such that all source blocks are as close to being equal length as possible. This helps avoid the performance disadvantages of "short" FEC blocks. Note this algorithm applies only to the statically-sized NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where the object size is fixed and predetermined. For NORM_OBJECT_STREAM objects, the object is segmented according to the maximum source block length given in the FEC Transmission Information, unless the FEC Payload ID indicates an alternative size for a given block.
NORM の送信側と受信側は、欠落データの修復を要求するために適切な NACK を構築できるように、共通のアルゴリズムを使用してトランスポート データを FEC エンコード ブロックとシンボルに論理的に分割する必要があります。NORM FEC コーディング ブロックは、NORM_DATA メッセージのペイロードで送信されるマルチバイト シンボルで構成されます。各 NORM_DATA メッセージには 1 つのソース シンボルまたはエンコード シンボルが含まれており、NormSegmentSize 送信側パラメータは最大シンボル サイズをバイト単位で定義します。FEC エンコーディング タイプと関連パラメータは、ソース ブロック サイズ (コーディング ブロックあたりのソース シンボルの数) を制御します。NORM の送信側と受信側は、これらの FEC パラメーターを NormSegmentSize およびトランスポート オブジェクトのサイズとともに使用して、トランスポート オブジェクトのソース ブロック構造を計算します。これらのパラメータは、各オブジェクトの FEC 送信情報で提供されます。以下に示すアルゴリズムは、すべてのソース ブロックが可能な限り同じ長さに近づくようにソース ブロック構造を計算するために使用されます。これは、「短い」FEC ブロックによるパフォーマンス上の欠点を回避するのに役立ちます。このアルゴリズムは、オブジェクト サイズが固定され事前に決定されている、静的なサイズの NORM_OBJECT_DATA および NORM_OBJECT_FILE トランスポート オブジェクト タイプにのみ適用されることに注意してください。NORM_OBJECT_STREAM オブジェクトの場合、FEC ペイロード ID が特定のブロックの代替サイズを示していない限り、オブジェクトは FEC 送信情報で指定された最大ソース ブロック長に従ってセグメント化されます。
The NORM block segmentation algorithm is defined as follows. For a transport object of a given length (L_obj) in bytes, a first number of FEC source blocks (N_large) is delineated of a larger block size (B_large), and a second number of source blocks (N_small) is delineated of a smaller block size (B_small). Given the maximum FEC source block size (B_max) and the sender's NormSegmentSize, the block segmentation for a given NORM transport object is determined as follows: Inputs:
NORM ブロック分割アルゴリズムは次のように定義されます。バイト単位で指定された長さ (L_obj) のトランスポート オブジェクトの場合、最初の数の FEC ソース ブロック (N_large) はより大きなブロック サイズ (B_large) で描写され、2 番目の数のソース ブロック (N_small) はより小さなブロック サイズで描写されます。ブロックサイズ (B_small)。最大 FEC ソース ブロック サイズ (B_max) と送信者の NormSegmentSize を考慮して、特定の NORM トランスポート オブジェクトのブロック セグメント化は次のように決定されます。
B_max = Maximum source block length (i.e., maximum number of source symbols per source block)
B_max = ソース ブロックの最大長 (つまり、ソース ブロックあたりのソース シンボルの最大数)
L_sym = Encoding symbol length in bytes (i.e., NormSegmentSize)
L_sym = バイト単位のエンコードシンボル長 (つまり、NormSegmentSize)
L_obj = Object length in bytes
Outputs:
出力:
N_total = The total number of source blocks into which the transport object is partitioned.
N_total = トランスポート オブジェクトが分割されるソース ブロックの総数。
N_large = Number of larger source blocks (first set of blocks)
N_large = より大きなソース ブロックの数 (最初のブロック セット)
B_large = Size (in encoding symbols) of the larger source blocks
B_large = 大きいソース ブロックのサイズ (エンコード シンボル内)
N_small = Number of smaller source blocks (second set of blocks)
N_small = より小さいソース ブロックの数 (ブロックの 2 番目のセット)
B_small = Size (in encoding symbols) of the smaller source blocks
B_small = 小さいソース ブロックのサイズ (エンコード シンボル内)
L_final = Length (in bytes) of the last source symbol of the last source block (All other symbols are of length L_sym).
L_final = 最後のソース ブロックの最後のソース シンボルの長さ (バイト単位) (他のすべてのシンボルの長さは L_sym です)。
Algorithm:
アルゴリズム：
1) The total number of source symbols in the transport object is computed as: S_total = L_obj/L_sym [rounded up to the nearest integer]
1) トランスポート オブジェクト内のソース シンボルの総数は次のように計算されます: S_total = L_obj/L_sym [最も近い整数に切り上げ]
2) The transport object is partitioned into N_total source blocks, where: N_total = S_total/B_max [rounded up to the nearest integer]
2) トランスポート オブジェクトは N_total ソース ブロックに分割されます。ここで、N_total = S_total/B_max [最も近い整数に切り上げ]
3) The average length of a source block is computed as: B_ave = S_total/N_total (this may be non-integer)
3) ソース ブロックの平均長は次のように計算されます: B_ave = S_total/N_total (これは非整数の場合があります)
4) The size of the first set of larger blocks is computed as: B_large = B_ave [rounded up to the nearest integer] (Note it will always be the case that B_large <= B_max)
4) 大きいブロックの最初のセットのサイズは次のように計算されます: B_large = B_ave [最も近い整数に切り上げられます] (常に B_large <= B_max であることに注意してください)
5) The size of the second set of smaller blocks is computed as:
B_small = B_ave [rounded down to the nearest integer] (Note if
B_ave is an integer B_small = B_large; otherwise B_small = B_large
- 1)
6) The fractional part of B_ave is computed as: B_fraction = B_ave - B_small
6) B_ave の小数部は次のように計算されます: B_fraction = B_ave - B_small
7) The number of larger source blocks is computed as: N_large = B_fraction * N_total (Note N_large is an integer in the range 0 through N_total - 1)
7) より大きなソース ブロックの数は次のように計算されます: N_large = B_fraction * N_total (N_large は 0 ～ N_total - 1 の範囲の整数であることに注意してください)
8) The number of smaller source blocks is computed as: N_small = N_total - N_large
8) 小さいソース ブロックの数は次のように計算されます: N_small = N_total - N_large
9) Each of the first N_large source blocks consists of B_large source
symbols. Each of the remaining N_small source blocks consists of
B_small source symbols. All symbols are L_sym bytes in length
except for the final source symbol of the final source block which
is of length (in bytes):
L_final = L_obj - (N_large*B_large + N_small*B_small - 1) * L_sym
The NORM protocol is designed such that receivers may join and leave the group at will. However, some applications may be constrained such that receivers need to be members of the group prior to start of data transmission. NORM applications may use different policies to constrain the impact of new receivers joining the group in the middle of a session. For example, a useful implementation policy is for new receivers joining the group to limit or avoid repair requests for transport objects already in progress. The NORM sender implementation may wish to impose additional constraints to limit the ability of receivers to disrupt reliable multicast performance by joining, leaving, and rejoining the group often. Different receiver "join policies" may be appropriate for different applications and/or scenarios. For general purpose operation, default policy where receivers are allowed to request repair only for coding blocks with a NormTransportId and FEC coding block number greater than or equal to the first non-repair NORM_DATA or NORM_INFO message received upon joining the group is RECOMMENDED. For objects of type NORM_OBJECT_STREAM it is RECOMMENDED that the join policy constrain receivers to start reliable reception at the current FEC coding block for which non-repair content is received.
NORM プロトコルは、受信者が自由にグループに参加したり脱退したりできるように設計されています。ただし、アプリケーションによっては、データ送信を開始する前に受信者がグループのメンバーである必要があるなどの制約がある場合があります。NORM アプリケーションは、セッションの途中でグループに参加する新しい受信者の影響を制限するために、異なるポリシーを使用する場合があります。たとえば、グループに参加する新しい受信者が、すでに進行中のトランスポート オブジェクトの修復要求を制限または回避するための実装ポリシーが便利です。NORM 送信側の実装では、受信側がグループに頻繁に参加、脱退、および再参加することで信頼性の高いマルチキャスト パフォーマンスを妨害する能力を制限する追加の制約を課すことを望む場合があります。異なる受信者の「結合ポリシー」は、異なるアプリケーションおよび/またはシナリオに適している場合があります。汎用操作の場合、グループへの参加時に受信した最初の非修復 NORM_DATA または NORM_INFO メッセージ以上の NormTransportId および FEC コーディング ブロック番号を持つコーディング ブロックに対してのみ受信者が修復を要求できるデフォルト ポリシーが推奨されます。NORM_OBJECT_STREAM タイプのオブジェクトの場合、結合ポリシーは、非修復コンテンツが受信される現在の FEC コーディング ブロックで信頼性の高い受信を開始するように受信者を制約することが推奨されます。
When the receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACKing procedure. The NACKing procedure SHALL be initiated _only_ at FEC coding block boundaries, NormObject boundaries, and upon receipt of a NORM_CMD(FLUSH) message.
受信者は、送信者の NORM 送信からデータが欠落していることを検出すると、NACKing プロシージャを開始します。NACKing 手順は、FEC コーディング ブロック境界、NormObject 境界で、NORM_CMD(FLUSH) メッセージの受信時にのみ開始されるものとします (SHALL)。
The NACKing procedure begins with a random backoff timeout. The duration of the backoff timeout is chosen using the "RandomBackoff" algorithm described in the NORM Building Block document [4] using (Ksender*GRTTsender) for the "maxTime" parameter and the sender advertised group size (GSIZEsender) as the "groupSize" parameter. NORM senders provide values for GRTTsender, Ksender and GSIZEsender via the "grtt", "backoff", and "gsize" fields of transmitted messages. The GRTTsender value is determined by the sender based on feedback it has received from the group while the Ksender and GSIZEsender values may determined by application requirements and expectations or ancillary information. The backoff factor "Ksender" MUST be greater than one to provide for effective feedback suppression. A value of K = 4 is RECOMMENDED for the Any Source Multicast (ASM) model while a value of K = 6 is RECOMMENDED for Single Source Multicast (SSM) operation.
NACKing プロシージャは、ランダムなバックオフ タイムアウトから始まります。バックオフ タイムアウトの期間は、NORM Building Block ドキュメント [4] で説明されている「RandomBackoff」アルゴリズムを使用して選択されます。使用するのは、「maxTime」パラメーターとして (Ksender*GRTTsender) を使用し、「groupSize」として送信側がアドバタイズするグループ サイズ (GSIZEsender) を使用します。パラメータ。NORM 送信者は、送信メッセージの「grtt」、「backoff」、および「gsize」フィールドを介して、GRTTsender、Ksender、および GSIZEsender の値を提供します。GRTTsender 値は、グループから受け取ったフィードバックに基づいて送信者によって決定されますが、Ksender 値と GSIZEsender 値は、アプリケーションの要件と期待値、または補助情報によって決定される可能性があります。効果的なフィードバック抑制を実現するには、バックオフ係数「Ksender」は 1 より大きくなければなりません。Any Source Multicast (ASM) モデルの場合は K = 4 の値が推奨され、Single Source Multicast (SSM) 動作の場合は K = 6 の値が推奨されます。
Thus:
したがって：
T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
To avoid the possibility of NACK implosion in the case of sender or network failure during SSM operation, the receiver SHALL automatically suppress its NACK and immediately enter the "holdoff" period described below when T_backoff is greater than (Ksender-1)*GRTTsender. Otherwise, the backoff period is entered and the receiver MUST accumulate external pending repair state from NORM_NACK messages and NORM_CMD(REPAIR_ADV) messages received. At the end of the backoff time, the receiver SHALL generate a NORM_NACK message only if the following conditions are met:
SSM 動作中に送信者またはネットワーク障害が発生した場合の NACK 爆縮の可能性を回避するために、受信者は自動的に NACK を抑制し、T_backoff が (Ksender-1)*GRTTsender よりも大きい場合には、すぐに後述の「ホールドオフ」期間に入るものとします (SHALL)。それ以外の場合は、バックオフ期間に入り、受信者は受信した NORM_NACK メッセージと NORM_CMD(REPAIR_ADV) メッセージから外部保留修復状態を蓄積しなければなりません (MUST)。バックオフ時間の終了時に、受信者は以下の条件が満たされる場合にのみ NORM_NACK メッセージを生成するものとします (SHALL)。
1) The sender's current transmit position (in terms of objectId::fecPayloadId) exceeds the earliest repair position of the receiver.
1) 送信者の現在の送信位置 (objectId::fecPayloadId に関して) は、受信者の最も古い修復位置を超えています。
2) The repair state accumulated from NORM_NACK and NORM_CMD(REPAIR_ADV) messages do not equal or supersede the receiver's repair needs up to the sender transmission position at the time the NACK procedure (backoff timeout) was initiated.
2) NORM_NACK および NORM_CMD(REPAIR_ADV) メッセージから蓄積された修復状態は、NACK プロシージャ (バックオフ タイムアウト) が開始された時点の送信側の送信位置までの受信側の修復ニーズと同等または優先されません。
If these conditions are met, the receiver immediately generates a NORM_NACK message when the backoff timeout expires. Otherwise, the receiver's NACK is considered to be "suppressed" and the message is not sent. At this time, the receiver begins a "holdoff" period during which it constrains itself to not reinitiate the NACKing process. The purpose of this timeout is to allow the sender worst-case time to respond to the repair needs before the receiver requests repair again. The value of this "holdoff" timeout (T_rcvrHoldoff) as described in [4] is:
これらの条件が満たされる場合、受信側はバックオフ タイムアウトが期限切れになるとすぐに NORM_NACK メッセージを生成します。それ以外の場合、受信者の NACK は「抑制」されているとみなされ、メッセージは送信されません。この時点で、受信機は、NACK プロセスを再開しないように自分自身を制限する「ホールドオフ」期間を開始します。このタイムアウトの目的は、受信者が再度修復を要求する前に、送信者が修復ニーズに応答するための最悪の場合の時間を確保することです。[4] で説明されているこの「ホールドオフ」タイムアウト (T_rcvrHoldoff) の値は次のとおりです。
T_rcvrHoldoff =(Ksender+2)*GRTTsender
The NORM_NACK message contains repair request content beginning with lowest ordinal repair position of the receiver up through the coding block prior to the most recently heard ordinal transmission position for the sender. If the size of the NORM_NACK content exceeds the sender's NormSegmentSize, the NACK content is truncated so that the receiver only generates a single NORM_NACK message per NACK cycle for a given sender. In summary, a single NACK message is generated containing the receiver's lowest ordinal repair needs.
NORM_NACK メッセージには、受信者の最も低い順序の修復位置から始まり、送信者に対して最後に聞いた順序の送信位置に至るまでのコーディング ブロックまでの修復要求コンテンツが含まれています。NORM_NACK コンテンツのサイズが送信者の NormSegmentSize を超える場合、NACK コンテンツは切り詰められ、受信者は特定の送信者に対して NACK サイクルごとに 1 つの NORM_NACK メッセージのみを生成します。要約すると、受信者の通常の最小限の修復ニーズを含む単一の NACK メッセージが生成されます。
For each partially-received FEC coding block requiring repair, the receiver SHALL, on its _first_ repair attempt for the block, request the parity portion of the FEC coding block beginning with the lowest ordinal _parity_ "encoding_symbol_id" (i.e., "encoding_symbol_id" = "source_block_len") and request the number of FEC symbols corresponding to its data segment erasure count for the block. On _subsequent_ repair cycles for the same coding block, the receiver SHALL request only those repair symbols from the first set it has not yet received up to the remaining erasure count for that applicable coding block. Note that the sender may have provided other different, additional parity segments for other receivers that could also be used to satisfy the local receiver's erasure-filling needs. In the case where the erasure count for a partially-received FEC coding block exceeds the maximum number of parity symbols available from the sender for the block (as indicated by the NORM_DATA "fec_num_parity" field), the receiver SHALL request all available parity segments plus the ordinally highest missing data segments required to satisfy its total erasure needs for the block. The goal of this strategy is for the overall receiver set to request a lowest common denominator set of repair symbols for a given FEC coding block. This allows the sender to construct the most efficient repair transmission segment set and enables effective NACK suppression among the receivers even with uncorrelated packet loss. This approach also requires no synchronization among the receiver set in their repair requests for the sender.
修復を必要とする部分的に受信された各 FEC コーディング ブロックについて、受信者は、そのブロックに対する最初の修復試行時に、最も低い序数の _parity_ "encoding_symbol_id" (つまり、 "encoding_symbol_id" = ") で始まる FEC コーディング ブロックのパリティ部分を要求するものとします(SHALL)。source_block_len") を使用して、ブロックのデータ セグメント消去カウントに対応する FEC シンボルの数を要求します。同じコーディングブロックに対する後続の修復サイクルでは、受信機は、まだ受信していない最初のセットから該当するコーディングブロックの残りの消去カウントまでの修復シンボルのみを要求するものとします(SHALL)。送信者は、ローカル受信者の消去充填ニーズを満たすために使用できる、他の受信者に別の異なる追加のパリティ セグメントを提供している可能性があることに注意してください。部分的に受信した 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 コーディング ブロックまたは全体が欠落した NormObject の場合、NORM 受信側は、NORM_NACK_BLOCK または NORM_NACK_OBJECT フラグが適切に設定された修復リクエストを構築します。NORM_INFO の再送信要求は、対応する修復要求に NORM_NACK_INFO フラグを設定することで実行されます。
The principle goal of the sender is to make forward progress in the transmission of data its application has enqueued. However, the sender must occasionally "rewind" its logical transmission point to satisfy the repair needs of receivers who have NACKed. Aggregation of multiple NACKs is used to determine an optimal repair strategy when a NACK event occurs. Since receivers initiate the NACK process on coding block or object boundaries, there is some loose degree of synchronization of the repair process even when receivers experience uncorrelated data loss.
送信側の主な目標は、アプリケーションがキューに入れているデータの送信を前進させることです。ただし、送信者は、NACK を受信した受信者の修復ニーズを満たすために、論理送信ポイントを時折「巻き戻す」必要があります。複数の NACK の集約は、NACK イベントが発生したときに最適な修復戦略を決定するために使用されます。受信機はコーディング ブロックまたはオブジェクトの境界で NACK プロセスを開始するため、受信機で相関のないデータ損失が発生した場合でも、修復プロセスの同期はある程度緩やかになります。
When a sender is in its normal state of transmitting new data and receives a NACK, it begins a procedure to accumulate NACK repair state from NORM_NACK messages before beginning repair transmissions. Note that this period of aggregating repair state does _not_ interfere with its ongoing transmission of new data.
送信者が新しいデータを送信する通常の状態にあり、NACK を受信すると、修復送信を開始する前に、NORM_NACK メッセージから NACK 修復状態を蓄積する手順を開始します。この修復状態の集約期間は、進行中の新しいデータの送信を「妨げない」ことに注意してください。
As described in [4], the period of time during which the sender aggregates NORM_NACK messages is equal to:
[4] で説明されているように、送信者が NORM_NACK メッセージを集約する期間は次のとおりです。
T_sndrAggregate = (Ksender+1)*GRTT
where "Ksender" is the same backoff scaling value used by the receivers, and "GRTT" is the sender's current estimate of the group's greatest round-trip time.
ここで、「Ksender」は受信側で使用されるのと同じバックオフ スケーリング値、「GRTT」は送信側によるグループの最大往復時間の現在の推定値です。
When this period ends, the sender "rewinds" by incorporating the accumulated repair state into its pending transmission state and begins transmitting repair messages. After pending repair transmissions are completed, the sender continues with new transmissions of any enqueued data. Also, at this point in time, the sender begins a "holdoff" timeout during which time the sender constrains itself from initiating a new repair aggregation cycle, even if NORM_NACK messages arrive. As described in [4], the value of this sender "holdoff" period is:
この期間が終了すると、送信者は蓄積された修復状態を送信保留状態に組み込むことによって「巻き戻し」、修復メッセージの送信を開始します。保留中の修復送信が完了すると、送信者はキューに入れられたデータの新しい送信を続行します。また、この時点で、送信者は「ホールドオフ」タイムアウトを開始します。その間、送信者は、たとえ NORM_NACK メッセージが到着したとしても、新しい修復集約サイクルを開始することを抑制します。[4] で説明されているように、この送信者の「ホールドオフ」期間の値は次のとおりです。
T_sndrHoldoff = (1*GRTT)
If additional NORM_NACK messages are received during this sender "holdoff" period, the sender will immediately incorporate these "late messages" into its pending transmission state ONLY if the NACK content is ordinally greater than the sender's current transmission position. This "holdoff" time allows worst case time for the sender to propagate its current transmission sequence position to the group, thus avoiding redundant repair transmissions. After the holdoff timeout expires, a new NACK accumulation period can be begun (upon arrival of a NACK) in concert with the pending repair and new data transmission. Recall that receivers are not to initiate the NACK repair process until the sender's logical transmission position exceeds the lowest ordinal position of their repair needs. With the 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 the receivers use a strategy to request a lowest common denominator of explicit repair (including parity content) in the formation of their NORM_NACK messages. Before falling back to explicitly satisfying different receivers' repair needs, the sender can make use of the general erasure-filling capability of FEC-generated parity segments. The sender can determine the maximum erasure filling needs for individual FEC coding blocks from the NORM_NACK messages received during the repair aggregation period. Then, if the sender has a sufficient number (less than or equal to the maximum erasure count) of previously unsent parity segments available for the applicable coding blocks, the sender can transmit these in lieu of the specific packets the receiver set has requested. Only after exhausting its supply of "fresh" (unsent) parity segments for a given coding block should the sender resort to explicit transmission of the receiver set's repair needs. In general, if a sufficiently powerful FEC code is used, the need for explicit repair will be an exception, and the fulfillment of reliable multicast can be accomplished quite efficiently. However, the ability to resort to explicit repair allows the protocol to be reliable under even very extreme circumstances.
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 that limit new receivers from joining the reliable transmission when only repair transmissions have been received. Additionally, the sender SHOULD additionally flag NORM_DATA transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT flag.
修復送信として送信された NORM_DATA メッセージには、NORM_FLAG_REPAIR フラグが付けられるものとします (SHALL)。これにより、受信者は、修復送信のみが受信された場合に、新しい受信者が信頼性のある送信に参加することを制限するポリシーに従うことができます。さらに、送信者は、NORM_FLAG_EXPLICIT フラグを使用して、明示的修復として送信された NORM_DATA 送信にさらにフラグを付ける必要があります (SHOULD)。
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 be required to conduct repair state accumulation for sub-routes in a manner similar to the sender's repair state accumulation in order to have sufficient information to perform the sub-casting. Additionally, the intermediate systems could perform additional NORM_NACK suppression/aggregation as it conducts this repair state accumulation for NORM repair cycles. The detail of this type of operation are beyond the scope of this document, but this information is provided for possible future consideration.
NORM エンド システムの受信者は NORM_FLAG_EXPLICIT フラグを利用しませんが、このメッセージ送信ステータスは、NORM プロトコルのパフォーマンスを「支援」したい中間システムによって利用される可能性があります。このようなシステムが相互逆方向パス マルチキャスト ルーティングに関して適切に配置されている場合、特定の FEC コーディング ブロックに対するマルチキャスト ルーティング サブツリーの消去充填ニーズを満たすのに十分な数の非明示的パリティ修復のみをサブキャストする必要があります。送信者が明示的修復に頼った場合、中間システムはすべての明示的修復パケットを、特定のコーディング ブロックの修復がまだ必要なルーティング ツリーの部分にサブキャストする必要があります。中間システムは、サブキャストを実行するのに十分な情報を得るために、送信者の修復状態の蓄積と同様の方法でサブルートの修復状態の蓄積を実行する必要があることに注意してください。さらに、中間システムは、NORM 修復サイクルでこの修復状態の蓄積を実行するときに、追加の 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. The "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) message SHALL begin with the lowest "object_transport_id" from the invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) transmission. Lower ordinal invalid "object_transport_ids" should be included only while the NORM_CMD(SQUELCH) payload is less than the sender's NormSegmentSize parameter.
送信者がサポートしなくなったデータの修復のための NORM_NACK メッセージを受信した場合、送信者は NORM_CMD(SQUELCH) メッセージを生成して修復ウィンドウを通知し、無効なデータの追加の NACK が受信者に送信されないようにします。NORM_CMD(SQUELCH) メッセージの送信速度は、2*GRTT ごとに 1 回に制限されます。NORM_CMD(SQUELCH) メッセージの "invalid_object_list" (該当する場合) は、最後の NORM_CMD(SQUELCH) 送信以降に受信した無効な NORM_NACK メッセージの最も低い "object_transport_id" で始まるものとします (SHALL)。NORM_CMD(SQUELCH) ペイロードが送信者の NormSegmentSize パラメーターより小さい場合にのみ、下位の無効な "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. The NORM_CMD(REPAIR_ADV) message is multicast to the receiver set by the sender. The payload portion of this message has content in the same format as the NORM_NACK receiver message payload. Receivers are then able to perform feedback suppression in the same manner as with NORM_NACK messages directly received from other receivers. Note the sender does not merely retransmit NACK content it receives, but instead transmits a representation of its aggregated repair state. The transmission of NORM_CMD(REPAIR_ADV) messages are subject to the sender transmit rate limit and NormSegmentSize limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum size, receivers SHALL consider the maximum ordinal transmission position value embedded in the message as the senders "current" transmission position and implicitly suppress requests for ordinally higher repair. For congestion control operation, the sender may also need to provide information so that dynamic congestion control feedback can be suppressed as needed among receivers. This document specifies the NORM-CC Feedback Header Extension that is applied for 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_CMD(REPAIR_ADV) メッセージは、送信者が設定した受信者にマルチキャストされます。このメッセージのペイロード部分には、NORM_NACK 受信メッセージ ペイロードと同じ形式のコンテンツが含まれています。受信機は、他の受信機から直接受信した NORM_NACK メッセージと同じ方法でフィードバック抑制を実行できます。送信者は受信した NACK コンテンツを単に再送信するだけではなく、その代わりに集約された修復状態の表現を送信することに注意してください。NORM_CMD(REPAIR_ADV) メッセージの送信は、送信側の送信レート制限と NormSegmentSize 制限の影響を受けます。NORM_CMD(REPAIR_ADV) メッセージが最大サイズの場合、受信者はメッセージに埋め込まれた最大順序送信位置値を送信側の「現在の」送信位置と見なし、通常より高い修復要求を暗黙的に抑制するものとします (SHALL)。輻輳制御動作の場合、送信側は、受信側の間で必要に応じて動的な輻輳制御フィードバックを抑制できるように情報を提供する必要がある場合もあります。この文書は、ベースライン NORM-CC 動作に適用される NORM-CC フィードバック ヘッダー拡張を指定します。NORM 実装内で他の輻輳制御メカニズムが使用されている場合は、他のヘッダ拡張が定義される可能性があります。この目的でどのようなコンテンツ形式が使用される場合でも、可能な限り最大限の抑制状態が受信機セットに確実に伝達されるようにする必要があります。
In addition to the principal function of data content transmission and repair, there are some other protocol mechanisms that help NORM to adapt to network conditions and play fairly with other coexistent protocols.
データ コンテンツの送信と修復という主な機能に加えて、NORM がネットワーク状態に適応し、他の共存プロトコルと公平に連携するのに役立つプロトコル メカニズムがいくつかあります。
For NORM receivers to appropriately scale backoff timeouts and the senders to use proper corresponding timeouts, the participants must agree on a common timeout basis. Each NORM sender monitors the round-trip time of active receivers and determines the group greatest round-trip time (GRTT). The sender advertises this GRTT estimate in every message it transmits so that receivers have this value available for scaling their timers. To measure the current GRTT, the sender periodically sends NORM_CMD(CC) messages that contain a locally generated timestamp. Receivers are expected to record this timestamp along with the time the NORM_CMD(CC) message is received. Then, when the receivers generate feedback messages to the sender, an adjusted version of the sender timestamp is embedded in the feedback message (NORM_NACK or NORM_ACK). The adjustment adds the amount of time the receiver held the timestamp before generating its response. Upon receipt of this adjusted timestamp, the sender is able to calculate the round-trip time to that receiver.
NORM 受信側がバックオフ タイムアウトを適切に調整し、送信側が適切な対応するタイムアウトを使用するには、参加者が共通のタイムアウト ベースで合意する必要があります。各 NORM 送信側は、アクティブな受信側の往復時間を監視し、グループ最大往復時間 (GRTT) を決定します。送信者は送信するすべてのメッセージでこの GRTT 推定値をアドバタイズするため、受信者はこの値をタイマーのスケーリングに利用できます。現在の GRTT を測定するために、送信者はローカルで生成されたタイムスタンプを含む NORM_CMD(CC) メッセージを定期的に送信します。受信者は、NORM_CMD(CC) メッセージの受信時刻とともにこのタイムスタンプを記録することが期待されます。その後、受信者が送信者へのフィードバック メッセージを生成すると、送信者のタイムスタンプの調整されたバージョンがフィードバック メッセージ (NORM_NACK または NORM_ACK) に埋め込まれます。この調整により、受信機が応答を生成する前にタイムスタンプを保持していた時間が追加されます。この調整されたタイムスタンプを受信すると、送信者は受信者までの往復時間を計算できます。
The round-trip time for each receiver is fed into an algorithm that weights and smoothes the values for a conservative estimate of the GRTT. The algorithm and methodology are described in the NORM Building Block document [4] in the section entitled "One-to-Many Sender GRTT Measurement". A conservative estimate helps feedback suppression at a small cost in overall protocol repair delay. The sender's current estimate of GRTT is advertised in the "grtt" field found in all NORM sender messages. The advertised GRTT is also limited to a minimum of the nominal inter-packet transmission time given the sender's current transmission rate and system clock granularity. The reason for this additional limit is to keep the receiver somewhat "event driven" by making sure the sender has had adequate time to generate any response to repair requests from receivers given transmit rate limitations due to congestion control or configuration.
各受信機の往復時間は、GRTT の控えめな推定値の重み付けと平滑化を行うアルゴリズムに入力されます。アルゴリズムと方法論は、NORM Building Block 文書 [4] の「One-to-Many Sender GRTT Measurement」というタイトルのセクションで説明されています。控えめな推定値は、全体的なプロトコル修復遅延の少ないコストでフィードバック抑制に役立ちます。送信者の現在の GRTT 推定値は、すべての NORM 送信者メッセージにある「grtt」フィールドで通知されます。アドバタイズされる GRTT は、送信者の現在の送信速度とシステム クロック粒度を考慮した場合の公称パケット間送信時間の最小値にも制限されます。この制限を追加する理由は、輻輳制御または構成による送信レート制限を考慮して、送信側が受信側からの修復要求に対する応答を生成するのに十分な時間を確保できるようにすることで、受信側をある程度「イベント駆動型」に保つためです。
When the NORM-CC Rate header extension is present in NORM_CMD(CC) messages, the receivers respond to NORM_CMD(CC) messages as described in Section 5.5.2, "NORM Congestion Control Operation". The NORM_CMD(CC) messages are periodically generated by the sender as described for congestion control operation. This provides for proactive, but controlled, feedback from the group in the form of NORM_ACK messages. This provides for GRTT feedback even if no NORM_NACK messages are being sent. If operating without congestion control in a closed network, the NORM_CMD(CC) messages may be sent periodically without the NORM-CC Rate header extension. In this case, receivers will only provide GRTT measurement feedback when NORM_NACK messages are generated since no NORM_ACK messages are generated. In this case, the NORM_CMD(CC) messages may be sent less frequently, perhaps as little as once per minute, to conserve network capacity. Note that the NORM-CC Rate header extension may also be used proactively solicit RTT feedback from the receiver group per congestion control operation even though the sender may not be conducting congestion control rate adjustment. NORM operation without congestion control should be considered only in closed networks.
NORM-CC レート ヘッダー拡張が NORM_CMD(CC) メッセージに存在する場合、受信機はセクション5.5.2「NORM 輻輳制御動作」で説明されているように NORM_CMD(CC) メッセージに応答します。NORM_CMD(CC) メッセージは、輻輳制御動作で説明したように、送信側によって定期的に生成されます。これにより、NORM_ACK メッセージの形式で、グループからの積極的かつ制御されたフィードバックが提供されます。これにより、NORM_NACK メッセージが送信されていない場合でも、GRTT フィードバックが提供されます。閉域ネットワークで輻輳制御なしで動作している場合、NORM_CMD(CC) メッセージは NORM-CC レート ヘッダー拡張なしで定期的に送信される可能性があります。この場合、受信機は、NORM_ACK メッセージが生成されないため、NORM_NACK メッセージが生成された場合にのみ GRTT 測定フィードバックを提供します。この場合、ネットワーク容量を節約するために、NORM_CMD(CC) メッセージの送信頻度が低くなり、おそらく 1 分に 1 回程度送信されることがあります。NORM-CC レート ヘッダー拡張は、送信者が輻輳制御レート調整を行っていない場合でも、輻輳制御操作ごとに受信者グループからの RTT フィードバックを積極的に求めるために使用される場合もあることに注意してください。輻輳制御を行わない NORM 動作は、閉じたネットワークでのみ考慮する必要があります。
This section describes baseline congestion control operation for the NORM protocol (NORM-CC). The supporting NORM message formats and approach described here are an adaptation of the equation-based TCP-Friendly Multicast Congestion Control (TFMCC) approach described in [19]. This congestion control scheme is REQUIRED for operation within the general Internet unless the NORM implementation is adapted to use another IETF-sanctioned reliable multicast congestion control mechanism (e.g., PGMCC [20]). With this TFMCC-based approach, the transmissions of NORM senders are controlled in a rate-based manner as opposed to window-based congestion control algorithms as in TCP. However, it is possible that the NORM protocol message set may alternatively be used to support a window-based multicast congestion control scheme such as PGMCC. The details of that alternative may be described separately or in a future revision of this document. In either case (rate-based TFMCC or window-based PGMCC), successful control of sender transmission depends upon collection of sender-to-receiver packet loss estimates and RTTs to identify the congestion control bottleneck path(s) within the multicast topology and adjust the sender rate accordingly. The receiver with loss and RTT estimates that correspond to the lowest result transmission rate is identified as the "current limiting receiver" (CLR).
このセクションでは、NORM プロトコル (NORM-CC) のベースライン輻輳制御動作について説明します。ここで説明するサポートする NORM メッセージ形式とアプローチは、[19] で説明されている方程式ベースの TCP フレンドリー マルチキャスト輻輳制御 (TFMCC) アプローチを適応させたものです。この輻輳制御スキームは、NORM 実装が別の IETF 認可の信頼できるマルチキャスト輻輳制御メカニズム (例: PGMCC [20]) を使用するように適合されていない限り、一般のインターネット内での動作に必須です。この TFMCC ベースのアプローチでは、NORM 送信側の送信は、TCP のようなウィンドウ ベースの輻輳制御アルゴリズムとは対照的に、レート ベースの方法で制御されます。ただし、代わりに NORM プロトコル メッセージ セットを使用して、PGMCC などのウィンドウベースのマルチキャスト輻輳制御方式をサポートすることも可能です。その代替案の詳細については、別途、またはこのドキュメントの将来の改訂版で説明される可能性があります。いずれの場合（レートベースの TFMCC またはウィンドウベースの PGMCC）でも、送信側の送信制御が成功するかどうかは、送信側から受信側のパケット損失推定値と RTT を収集して、マルチキャスト トポロジ内の輻輳制御のボトルネック パスを特定し、調整するかどうかにかかっています。それに応じて送信者のレートも変わります。最低の結果伝送レートに対応する損失と RTT 推定値を持つ受信機は、「電流制限受信機」(CLR) として識別されます。
As described in [21], a steady-state sender transmission rate, to be "friendly" with competing TCP flows can be calculated as:
[21] で説明されているように、競合する TCP フローと「友好的」である定常状態の送信側送信速度は次のように計算できます。
S
Rsender = --------------------------------------------------------------
tRTT * (sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p *
(1 + 32*(p^2)))
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) として送信者によって決定できます)。
tRTT = The RTT estimate of the current "current limiting receiver" (CLR).
tRTT = 現在の「電流制限受信機」(CLR) の RTT 推定値。
p = The loss event fraction of the CLR.
p = CLR の損失イベントの割合。
To support congestion control feedback collection and operation, the NORM sender periodically transmits NORM_CMD(CC) command messages. NORM_CMD(CC) messages are multiplexed with NORM data and repair transmissions and serve several purposes:
輻輳制御フィードバックの収集と操作をサポートするために、NORM 送信側は NORM_CMD(CC) コマンド メッセージを定期的に送信します。NORM_CMD(CC) メッセージは NORM データおよび修復送信と多重化され、いくつかの目的を果たします。
1) Stimulate explicit feedback from the general receiver set to collect congestion control information.
1) 輻輳制御情報を収集するために、一般的な受信機セットからの明示的なフィードバックを刺激します。
2) Communicate state to the receiver set on the sender's current congestion control status including details of the CLR.
2) CLR の詳細を含む、送信側の現在の輻輳制御ステータスに設定された状態を受信側に通信します。
3) Initiate rapid (immediate) feedback from the CLR in order to closely track the dynamics of congestion control for that current "worst path" in the group multicast topology.
3) グループ マルチキャスト トポロジ内の現在の「最悪のパス」に対する輻輳制御のダイナミクスを厳密に追跡するために、CLR からの迅速な (即時的な) フィードバックを開始します。
The format of the NORM_CMD(CC) message is describe in Section 4.2.3 of this document. The NORM_CMD(CC) message contains information to allow measurement of RTTs, to inform the group of the congestion control CLR, and to provide feedback of individual RTT measurements to the receivers in the group. The NORM_CMD(CC) also provides for exciting feedback from OPTIONAL "potential limiting receiver" (PLR) nodes that may be determined administratively or possibly algorithmically based on congestion control feedback. PLR nodes are receivers that have been identified to have potential for (perhaps soon) becoming the CLR and thus immediate, up-to-date feedback is beneficial for congestion control performance. The details of PLR selection are not discussed in this document.
NORM_CMD(CC) メッセージのフォーマットについては、この文書のセクション 4.2.3 で説明されています。NORM_CMD(CC) メッセージには、RTT の測定を許可し、輻輳制御 CLR をグループに通知し、グループ内の受信機に個々の RTT 測定値のフィードバックを提供するための情報が含まれています。NORM_CMD(CC) は、輻輳制御フィードバックに基づいて管理的に、または場合によってはアルゴリズム的に決定できるオプションの「潜在的制限受信機」(PLR) ノードからの刺激的なフィードバックも提供します。PLR ノードは、(おそらくすぐに) CLR になる可能性があると特定された受信機であるため、即時の最新のフィードバックは輻輳制御のパフォーマンスにとって有益です。PLR 選択の詳細については、この文書では説明しません。
The NORM_CMD(CC) message is transmitted periodically by the sender along with its normal data transmission. Note that the repeated transmission of NORM_CMD(CC) messages may be initiated some time before transmission of user data content at session startup. This may be done to collect some estimation of the current state of the multicast topology with respect to group and individual RTT and congestion control state.
NORM_CMD(CC) メッセージは、通常のデータ送信とともに送信者によって定期的に送信されます。NORM_CMD(CC) メッセージの繰り返し送信は、セッション開始時のユーザー データ コンテンツの送信より少し前に開始される可能性があることに注意してください。これは、グループおよび個別の RTT および輻輳制御状態に関するマルチキャスト トポロジの現在の状態の推定値を収集するために行われる場合があります。
A NORM_CMD(CC) message is immediately transmitted at sender startup. The interval of subsequent NORM_CMD(CC) message transmission is determined as follows:
NORM_CMD(CC) メッセージは、送信側の起動時に直ちに送信されます。後続の NORM_CMD(CC) メッセージ送信の間隔は次のように決定されます。
1) By default, the interval is set according to the current sender GRTT estimate. A startup GRTT of 0.5 seconds is recommended when no feedback has yet been received from the group.
1) デフォルトでは、間隔は現在の送信者の GRTT 推定に従って設定されます。グループからフィードバックをまだ受け取っていない場合は、開始 GRTT を 0.5 秒にすることをお勧めします。
2) If a CLR has been identified (based on previous receiver feedback), the interval is the RTT between the sender and CLR.
2) CLR が（以前の受信者のフィードバックに基づいて）識別されている場合、間隔は送信者と CLR の間の RTT になります。
3) Additionally, if the interval of nominal data message transmission is greater than the GRTT or RTT_clr interval, the NORM_CMD(CC) interval is set to this greater value. This ensures that the transmission of this control message is not done to the exclusion of user data transmission.
3) さらに、公称データ メッセージ送信の間隔が GRTT または RTT_clr 間隔より大きい場合、NORM_CMD(CC) 間隔はこのより大きい値に設定されます。これにより、この制御メッセージの送信がユーザー データの送信を除いて行われないことが保証されます。
The NORM_CMD(CC) "cc_sequence" field is incremented with each transmission of a NORM_CMD(CC) command. The greatest "cc_sequence" recently received by receivers is included in their feedback to the sender. This allows the sender to determine the "age" of feedback to assist in congestion avoidance.
NORM_CMD(CC) の「cc_sequence」フィールドは、NORM_CMD(CC) コマンドが送信されるたびにインクリメントされます。受信者が最近受信した最大の「cc_sequence」が、送信者へのフィードバックに含まれます。これにより、送信者はフィードバックの「経過時間」を判断して、輻輳回避に役立てることができます。
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 may be empty if the sender has not yet received any feedback from the group. If the sender has received feedback, the list will minimally contain an entry identifying the CLR. A NORM_FLAG_CC_CLR flag value is provided for the "cc_flags" field to identify the CLR entry. It is RECOMMENDED that the CLR entry be the first in the list for implementation efficiency. Additional entries in the list are used to provide sender-measured individual RTT estimates to receivers in the group. The number of additional entries in this list is dependent upon the percentage of control traffic the sender application is willing to send with respect to user data message transmissions. More entries in the list may allow the sender to be more responsive to congestion control dynamics. The length of the list may be dynamically determined according to the current transmission rate and scheduling of NORM_CMD(CC) messages. The maximum length of the list corresponds to the sender's NormSegmentSize parameter for the session. The inclusion of additional entries in the list based on receiver feedback are prioritized with following rules:
「cc_node_list」には、受信機とその現在の輻輳制御状態 (状態「フラグ」、「rtt」、および「損失」推定値) を識別するエントリのリストが含まれています。送信者がグループからフィードバックをまだ受け取っていない場合、リストは空になる可能性があります。送信者がフィードバックを受信した場合、リストには CLR を識別するエントリが最小限含まれます。NORM_FLAG_CC_CLR フラグ値は、CLR エントリを識別するために「cc_flags」フィールドに提供されます。実装効率を高めるために、CLR エントリをリストの先頭にすることが推奨されます。リスト内の追加のエントリは、送信者が測定した個々の RTT 推定値をグループ内の受信者に提供するために使用されます。このリスト内の追加エントリの数は、送信側アプリケーションがユーザー データ メッセージ送信に関して送信する制御トラフィックのパーセンテージによって異なります。リスト内のエントリが増えると、送信側は輻輳制御のダイナミクスにさらに応答できるようになります。リストの長さは、現在の伝送速度およびNORM_CMD(CC)メッセージのスケジューリングに従って動的に決定され得る。リストの最大長は、セッションの送信者の NormSegmentSize パラメータに対応します。受信者のフィードバックに基づいてリストに追加のエントリを含める場合、次のルールに従って優先順位が付けられます。
1) Receivers that have not yet been provided RTT feedback get first priority. Of these, those with the greatest loss fraction receive precedence for list inclusion.
1) RTT フィードバックがまだ提供されていない受信者が最優先されます。これらのうち、最大の損失率を持つものがリストに含められる際に優先されます。
2) Secondly, receivers that have previously been provided RTT are included with receivers yielding the lowest calculated congestion rate getting precedence.
2) 第 2 に、以前に RTT が提供された受信機には、計算された輻輳率が最も低い受信機が優先されます。
There are "cc_flag" values in addition to NORM_FLAG_CC_CLR that are used for other congestion control functions. The NORM_FLAG_CC_PLR flag value is used to mark additional receivers from that the sender would like to have immediate, non-suppressed feedback. These may be receivers that the sender algorithmically identified as potential future CLRs or that have been pre-configured as potential congestion control points in the network. The NORM_FLAG_CC_RTT indicates the validity of the "cc_rtt" field for the associated receiver node. Normally, this flag will be set since the receivers in the list will typically be receivers from which the sender has received feedback. However, in the case that the NORM sender has been pre-configured with a set of PLR nodes, feedback from those receivers may not yet have been collected and thus the "cc_rtt" and "cc_rate" fields do not contain valid values when this flag is not set.
NORM_FLAG_CC_CLR に加えて、他の輻輳制御機能に使用される「cc_flag」値があります。NORM_FLAG_CC_PLR フラグ値は、送信者が即時の非抑制フィードバックを必要とする追加の受信者をマークするために使用されます。これらは、送信者が潜在的な将来の CLR としてアルゴリズム的に識別した受信機、またはネットワーク内の潜在的な輻輳制御ポイントとして事前設定された受信機である可能性があります。NORM_FLAG_CC_RTT は、関連する受信ノードの「cc_rtt」フィールドの有効性を示します。通常、リスト内の受信者は送信者がフィードバックを受信した受信者であるため、このフラグが設定されます。ただし、NORM 送信側が一連の PLR ノードで事前設定されている場合、それらの受信側からのフィードバックがまだ収集されていない可能性があるため、このフラグがオンの場合、「cc_rtt」および「cc_rate」フィールドには有効な値が含まれません。は設定されていません。
Receivers explicitly respond to NORM_CMD(CC) messages in the form of a NORM_ACK(RTT) message. The goal of the congestion control feedback is to determine the receivers with the lowest congestion control rates. Receivers that are marked as CLR or PLR nodes in the NORM_CMD(CC) "cc_node_list" immediately provide feedback in the form of a NORM_ACK to this message. When a NORM_CMD(CC) is received, non-CLR or non-PLR nodes initiate random feedback backoff timeouts similar to that used when the receiver initiates a repair cycle (see Section 5.3) in response to detection of data loss. The backoff timeout for the congestion control response is generated as follows:
受信側は、NORM_ACK(RTT) メッセージの形式で NORM_CMD(CC) メッセージに明示的に応答します。輻輳制御フィードバックの目的は、輻輳制御レートが最も低い受信機を決定することです。NORM_CMD(CC)「cc_node_list」内で CLR または PLR ノードとしてマークされている受信機は、NORM_ACK の形式でこのメッセージに直ちにフィードバックを提供します。NORM_CMD(CC) が受信されると、非 CLR または非 PLR ノードは、データ損失の検出に応じて受信機が修復サイクル (セクション 5.3 を参照) を開始するときに使用されるものと同様のランダム フィードバック バックオフ タイムアウトを開始します。輻輳制御応答のバックオフ タイムアウトは次のように生成されます。
T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender)
The "RandomBackoff()" algorithm provides a truncated exponentially distributed random number and is described in the NORM Building Block document [4]. The same backoff factor K = Ksender MAY be used as with NORM_NACK suppression. However, in cases where the application purposefully specifies a very small Ksender backoff factor to minimize the NACK repair process latency (trading off group size scalability), it may still be desirable to maintain a larger backoff factor for congestion control feedback, since there may often be a larger volume of congestion control feedback than NACKs in many cases and congestion control feedback latency may be tolerable where reliable delivery latency is not. As previously noted, a backoff factor value of K = 4 is generally recommended for ASM operation and K = 6 for SSM operation. A receiver SHALL cancel the backoff timeout and thus its pending transmission of a NORM_ACK(RTT) message under the following conditions:
「RandomBackoff()」アルゴリズムは、切り捨てられた指数関数的に分散された乱数を提供し、NORM Building Block ドキュメント [4] で説明されています。NORM_NACK 抑制と同じバックオフ係数 K = Ksender を使用してもよい(MAY)。ただし、アプリケーションが NACK 修復プロセスの待ち時間を最小限に抑えるために (グループ サイズのスケーラビリティと引き換えに) 非常に小さな Ksender バックオフ係数を意図的に指定している場合でも、輻輳制御フィードバック用に大きなバックオフ係数を維持することが望ましい場合があります。多くの場合、NACK よりも大量の輻輳制御フィードバックが発生し、信頼性の高い配信遅延が保証されない場合でも、輻輳制御フィードバックの遅延は許容できる場合があります。前述したように、通常、ASM 動作にはバックオフ係数値 K = 4 が推奨され、SSM 動作には K = 6 が推奨されます。受信者は、以下の条件下でバックオフ タイムアウトをキャンセルし、保留中の NORM_ACK(RTT) メッセージの送信をキャンセルするものとします (SHALL)。
1) The receiver generates another feedback message (NORM_NACK or other NORM_ACK) before the congestion control feedback timeout expires,
1) 受信機は、輻輳制御フィードバック タイムアウトが期限切れになる前に、別のフィードバック メッセージ (NORM_NACK または他の NORM_ACK) を生成します。
2) A NORM_CMD(CC) or other receiver feedback with an ordinally greater "cc_sequence" field value is received before the congestion control feedback timeout expires (this is similar to the TFMCC feedback round number),
2) NORM_CMD(CC) または通常より大きな「cc_sequence」フィールド値を持つ他の受信機フィードバックが、輻輳制御フィードバック タイムアウトが期限切れになる前に受信されます (これは TFMCC フィードバック ラウンド数に似ています)。
3) When the T_backoff is greater than 1*GRTT. This prevents NACK implosion in the event of sender or network failure,
3) T_backoff が 1*GRTT より大きい場合。これにより、送信者またはネットワーク障害が発生した場合の NACK の爆発が防止されます。
4) "Suppressing" congestion control feedback is heard from another receiver (in a NORM_ACK or NORM_NACK) or via a NORM_CMD(REPAIR_ADV) message from the sender. The local receiver's feedback is "suppressed" if the rate of the competing feedback (Rfb) is sufficiently close to or less than the local receiver's calculated rate (Rcalc). The local receiver's feedback is canceled when:
4) 「抑制」輻輳制御フィードバックは、別の受信者 (NORM_ACK または NORM_NACK) から、または送信者からの NORM_CMD(REPAIR_ADV) メッセージを介して受信されます。競合するフィードバックのレート (Rfb) がローカル受信機の計算されたレート (Rcalc) に十分近いかそれよりも小さい場合、ローカル受信機のフィードバックは「抑制」されます。ローカル受信機のフィードバックは、次の場合にキャンセルされます。
Rcalc > (0.9 * Rfb)
Rcalc > (0.9 * Rfb)
Also note receivers that have not yet received an RTT measurement from the sender are suppressed only by other receivers that have not yet measured RTT. Additionally, receivers whose RTT estimate has "aged" considerably (i.e., they haven't been included in the NORM_CMD(CC) "cc_node_list" in a long time) may wish to compete as a receiver with no prior RTT measurement after some expiration period.
また、送信者から RTT 測定値をまだ受信していない受信者は、RTT をまだ測定していない他の受信者によってのみ抑制されることに注意してください。さらに、RTT 推定値がかなり「古くなった」受信機 (つまり、長い間 NORM_CMD(CC) の「cc_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) メッセージを生成して送信者とグループにフィードバックを提供するものとします(SHALL)。このメッセージは、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 the "cc_sequence" value from that command in the applicable NORM_ACK or NORM_NACK message fields. For NORM-CC operation, any generated feedback message SHALL also contain the NORM-CC Feedback header extension. The receiver provides its current "cc_rate" estimate, "cc_loss" estimate, "cc_rtt" if known, and any applicable "cc_flags" via this header extension.
(この NORM_ACK(RTT) メッセージを含む) フィードバックが生成されるたびに、受信側は、最後に受信した NORM_CMD(CC) メッセージからの送信側タイムスタンプの調整されたバージョンと、そのコマンドからの「cc_sequence」値を該当する NORM_ACK または NORM_NACK メッセージに含めます。田畑。NORM-CC 動作の場合、生成されたフィードバック メッセージには NORM-CC フィードバック ヘッダー拡張も含まれるものとします (SHALL)。受信機は、現在の「cc_rate」推定値、「cc_loss」推定値、既知の場合は「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 is used when the receiver has not yet measured its individual RTT).
スロー スタート中 (受信者が送信者からの損失をまだ検出していないとき)、受信者は、送信者からの測定レートの 2 倍に等しい値を「cc_rate」フィールドに使用します。定常状態の輻輳制御動作の場合、受信機の「cc_rate」値は、現在の損失イベント推定値と送信機<->受信機の RTT 情報を使用した式に基づく値から得られます。(GRTT は、受信機が個別の 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」フィールドに含めるものとします (SHALL)。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:
輻輳制御フィードバック メッセージが生成された後、またはフィードバックが抑制されると、非 CLR 受信機は「ホールドオフ」タイムアウト期間を開始します。この期間中は、たとえ NORM_CMD(CC) メッセージが送信側から受信されたとしても、輻輳制御フィードバックの提供を抑制します。送信者 (受信が CLR または PLR ノードとしてマークされる場合を除く)。このホールドオフ タイムアウト (T_ccHoldoff) 期間の値は次のとおりです。
T_ccHoldoff = (K*GRTT)
Thus, non-CLR receivers are constrained to providing explicit congestion control feedback once per K*GRTT intervals. Note, however, that as the session progresses, different receivers will be responding to different NORM_CMD(CC) messages and there will be relatively continuous feedback of congestion control information while the sender is active.
したがって、非 CLR 受信機は、K*GRTT 間隔ごとに 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 [19], the estimation of parameters (loss and RTT) for the CLR will generally constrain the rate changes possible within acceptable bounds. For rate increases, the sender SHALL observe a maximum rate of increase of one packet per RTT at all times during steady-state operation.
定常状態の動作中、送信側は、現在選択されている CLR からのフィードバックによって示される速度に送信速度を直接調整します。[19] に記載されているように、CLR のパラメータ (損失と RTT) の推定は、一般に、許容可能な範囲内で可能なレート変更を制限します。レート増加の場合、送信者は定常状態動作中常に RTT あたり 1 パケットの最大増加レートを観察するものとします (SHALL)。
The sender processes congestion control feedback from the receivers and selects the CLR based on the lowest rate receiver. Receiver rates are either determined directly from the slow start "cc_rate" provided by the receiver in the NORM-CC Feedback header extension or by performing the equation-based calculation using individual RTT and loss estimates ("cc_loss") as feedback is received.
送信側は、受信側からの輻輳制御フィードバックを処理し、最低レートの受信側に基づいて CLR を選択します。受信機のレートは、NORM-CC フィードバック ヘッダー拡張で受信機によって提供されるスロー スタート「cc_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 can use the "cc_rtt" value provided in the NORM-CC Feedback header extension as the receiver's previous RTT measurement (RTT_rcvrPrev) to smooth according to:
送信者は、フィードバック メッセージに含まれる「grtt_response」タイムスタンプを使用して、受信者の現在の RTT (RTT_rcvrNew) を計算できます。応答内の「cc_rtt」値が無効な場合、送信者は単にこの RTT_rcvrNew 値を受信者の現在の RTT (RTT_rcvr) として使用します。非 CLR および非 PLR 受信者の場合、送信者は、受信者の以前の 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 that if a PLR is "promoted" to CLR status, the smoothed estimate can be continued.
「RTT_clrNew」は、CLR から受信したフィードバック メッセージ内のタイムスタンプから計算された新しい RTT です。RTT_clr は、最初に受信したフィードバック メッセージで RTT_clrNew に初期化されます。送信側でも同じ手順が PLR 受信側に適用され、PLR が CLR ステータスに「昇格」した場合、平滑化された推定を継続できることに注意してください。
There are some additional periods besides steady-state operation that need to be considered in NORM-CC operation. These periods are:
NORM-CC 動作では、定常状態動作以外にも考慮する必要がある追加の期間がいくつかあります。これらの期間は次のとおりです。
1) during session startup,
1) セッションの開始時に、
2) when no feedback is received from the CLR, and 3) when the sender has a break in data transmission.
2) CLR からフィードバックが受信されない場合、および 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:
セッションの開始中、輻輳制御操作は、公平な帯域幅共有に迅速に近づくために「スロースタート」手順を観察するものとします(SHALL)。初期の送信者の起動速度は次のように仮定されます。
Rinitial = MIN(NormSegmentSize / GRTT, NormSegmentSize) bytes/second.
Rinitial = MIN(NormSegmentSize / GRTT, NormSegmentSize) バイト/秒。
The rate is increased only when feedback is received from the receiver set. The "slow start" phase proceeds until any receiver provides feedback indicating that loss has occurred. Rate increase during slow start is applied as:
レートは、受信機セットからフィードバックを受信した場合にのみ増加します。「スロースタート」フェーズは、いずれかの受信機が損失が発生したことを示すフィードバックを提供するまで続行します。スロースタート中のレート増加は次のように適用されます。
Rnew = Rrecv_min
where "Rrecv_min" is the minimum reported receiver rate in the "cc_rate" field of congestion control feedback messages received from the group. Note that during "slow start", receivers use two times their measured rate from the sender in the "cc_rate" field of their feedback. Rate increase adjustment is limited to once per GRTT during slow start.
ここで、「Rrecv_min」は、グループから受信した輻輳制御フィードバック メッセージの「cc_rate」フィールドで報告される最小受信速度です。「スロー スタート」中、受信者はフィードバックの「cc_rate」フィールドで送信者からの測定レートの 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 that the sender should not select it as the CLR. When the CLR changes to a lower rate receiver, the sender should immediately adjust to the new lower rate. The sender is limited to increasing its rate at one additional packet per RTT towards any new, higher CLR rate.
CLR または受信側がグループから脱退する場合、送信側が CLR として選択すべきでないことを示すために、輻輳制御フィードバック メッセージに NORM_FLAG_CC_LEAVE を設定します。CLR がより低いレートの受信者に変更されると、送信者は直ちに新しいより低いレートに調整する必要があります。送信者は、新しいより高い CLR レートに向けて、RTT ごとに 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.
送信者は、現在の「cc_sequence」値 (Seq_sender) と CLR から受信した最後の「cc_sequence」値 (Seq_clr) を比較することにより、CLR から受信したフィードバックの「経過時間」も追跡する必要があります。新しいフィードバックがなく CLR フィードバックの「経過時間」が増加すると、送信者は輻輳回避策として RTT_clr ごとに 1 回レートを下げ始めます(SHALL)。
The following algorithm is used to determine the decrease in sender rate (Rsender bytes/sec) as the CLR feedback, unexpectedly, excessively ages:
次のアルゴリズムは、CLR フィードバックが予想外に過度に古くなったときの送信速度 (送信バイト/秒) の減少を決定するために使用されます。
Age = Seq_sender - Seq_clr;
if (Age > 4) Rsender = Rsender * 0.5;
This rate reduction is limited to the lower bound on NORM transmission rate. After NORM_ROBUST_FACTOR consecutive NORM_CMD(CC) rounds without any feedback from the CLR, the sender SHOULD assume the CLR has left the group and pick the receiver with the next lowest rate as the new CLR. Note this assumes that the sender does not have explicit knowledge that the CLR intentionally left the group. If no receiver feedback is received, the sender MAY wish to withhold further transmissions of NORM_DATA segments and maintain NORM_CMD(CC) transmissions only until feedback is detected. After such a CLR timeout, the sender will be transmitting with a minimal rate and should return to slow start as described here for a break in data transmission.
このレート削減は、NORM 伝送レートの下限に制限されます。CLR からのフィードバックがない NORM_ROBUST_FACTOR 連続の NORM_CMD(CC) ラウンドの後、送信者は CLR がグループを離れたと仮定し、次に低いレートの受信者を新しい CLR として選択する必要があります (SHOULD)。これは、送信者が CLR が意図的にグループから脱退したという明示的な知識を持っていないことを前提としていることに注意してください。受信側フィードバックが受信されない場合、送信側は NORM_DATA セグメントのさらなる送信を保留し、フィードバックが検出されるまでのみ NORM_CMD(CC) 送信を維持したいと考えてもよい(MAY)。このような CLR タイムアウトの後、送信者は最小レートで送信することになり、データ送信の中断についてはここで説明するようにスロー スタートに戻る必要があります。
When the sender has a break in its data transmission, it can continue to probe the group with NORM_CMD(CC) messages to maintain RTT collection from the group. This will enable the sender to quickly determine an appropriate CLR upon data transmission restart. However, the sender should exponentially reduce its target rate to be used for transmission restart as time since the break elapses. The target rate SHOULD be recalculated once per RTT_clr as:
送信者は、データ送信が中断した場合でも、グループからの RTT 収集を維持するために NORM_CMD(CC) メッセージを使用してグループを調査し続けることができます。これにより、送信者はデータ送信再開時に適切な CLR を迅速に決定できるようになります。ただし、送信者は、中断が経過してから時間が経つにつれて、送信再開に使用する目標レートを指数関数的に下げる必要があります。ターゲットレートは、RTT_clr ごとに次のように再計算されるべきです (SHOULD)。
Rsender = Rsender * 0.5;
If the minimum NORM rate is reached, the sender should set the NORM_FLAG_START flag in its NORM_CMD(CC) messages upon restart and the group should observer "slow start" congestion control procedures until any receiver experiences a new loss event.
最小 NORM レートに達した場合、送信者は再起動時に 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 that are left to be defined by the application. One predefined acknowledgment type is the NORM_ACK_FLUSH type. This acknowledgment is used to determine if receivers have achieved completion of reliable reception up through a specific logical transmission point with respect to the sender's sequence of transmission. The NORM_ACK_FLUSH acknowledgment may be used to assist in application flow control when the sender has information on a portion of the receiver set. Another predefined acknowledgment type is NORM_ACK(CC), which is used to explicitly provide congestion control feedback in response to NORM_CMD(CC) messages transmitted by the sender for NORM-CC operation. Note the NORM_ACK(CC) response does NOT follow the positive acknowledgment procedure described here. The NORM_CMD(ACK_REQ) and NORM_ACK messages contain an "ack_type" field to identify the type of acknowledgment requested and provided. A range of "ack_type" values is provided for application-defined use. While the application is responsible for initiating the acknowledgment request and interprets application-defined "ack_type" values, the acknowledgment procedure 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_FLUSH タイプです。この確認応答は、受信者が送信者の送信シーケンスに関して特定の論理送信ポイントまでの信頼できる受信を完了したかどうかを判断するために使用されます。NORM_ACK_FLUSH 確認応答は、送信者が受信者セットの一部に関する情報を持っている場合に、アプリケーション フロー制御を支援するために使用できます。もう 1 つの事前定義済み確認応答タイプは NORM_ACK(CC) です。これは、NORM-CC 動作のために送信側によって送信された NORM_CMD(CC) メッセージに応答して輻輳制御フィードバックを明示的に提供するために使用されます。NORM_ACK(CC) 応答は、ここで説明する肯定応答手順に従っていないことに注意してください。NORM_CMD(ACK_REQ) および NORM_ACK メッセージには、要求および提供された確認応答のタイプを識別する「ack_type」フィールドが含まれています。アプリケーション定義の使用のために、一連の「ack_type」値が提供されます。アプリケーションは確認応答要求を開始し、アプリケーション定義の「ack_type」値を解釈する責任を負いますが、NORM トランスポートで利用可能なタイミングと送信スケジュール情報を利用するために、確認応答手順はプロトコル実装内で実行されるべきです(SHOULD)。
The NORM positive acknowledgment procedure uses polling by the sender to query the receiver group for response. Note this polling procedure is not intended to scale to very large receiver groups, but could be used in large group setting to query a critical subset of the group. Either the NORM_CMD(ACK_REQ), or when applicable, the NORM_CMD(FLUSH) message is used for polling and contains a list of NormNodeIds for receivers that should respond to the command. The list of receivers providing acknowledgment is determined by the source application with "a priori" knowledge of participating nodes or via some other application-level mechanism.
NORM 肯定応答手順では、送信者によるポーリングを使用して、受信者グループに応答を問い合わせます。このポーリング手順は、非常に大規模な受信者グループに拡張することを目的としたものではありませんが、大規模なグループ設定でグループの重要なサブセットをクエリするために使用できることに注意してください。NORM_CMD(ACK_REQ)、または該当する場合は NORM_CMD(FLUSH) メッセージがポーリングに使用され、コマンドに応答する受信機の NormNodeId のリストが含まれます。確認応答を提供する受信者のリストは、参加ノードの「先験的」知識を備えたソース アプリケーションによって、またはその他のアプリケーション レベルのメカニズムによって決定されます。
The ACK process is initiated by the sender that generates NORM_CMD(FLUSH) or NORM_CMD(ACK_REQ) messages in periodic "rounds". For NORM_ACK_FLUSH requests, the NORM_CMD(FLUSH) contain a "object_transport_id" and "fec_payload_id" denoting the watermark transmission point for which acknowledgment is requested. This watermark transmission point is "echoed" in the corresponding fields of the NORM_ACK(FLUSH) message sent by the receiver in response. NORM_CMD(ACK_REQ) messages contain an "ack_id" field which is similarly "echoed" in response so that the sender may match the response to the appropriate request.
ACK プロセスは、周期的な「ラウンド」で NORM_CMD(FLUSH) または NORM_CMD(ACK_REQ) メッセージを生成する送信者によって開始されます。NORM_ACK_FLUSH 要求の場合、NORM_CMD(FLUSH) には、確認応答が要求されるウォーターマーク送信ポイントを示す「object_transport_id」と「fec_payload_id」が含まれます。このウォーターマーク送信ポイントは、応答として受信側によって送信される NORM_ACK(FLUSH) メッセージの対応するフィールドに「エコー」されます。NORM_CMD(ACK_REQ) メッセージには、送信者が適切な要求に対する応答を照合できるように、応答として同様に「エコー」される「ack_id」フィールドが含まれています。
In response to the NORM_CMD(ACK_REQ), the listed receivers randomly spread NORM_ACK messages uniformly in time over a window of (1*GRTT). These NORM_ACK messages are typically unicast to the sender. (Note that NORM_ACK(CC) messages SHALL be multicast or unicast in the same manner as NORM_NACK messages).
NORM_CMD(ACK_REQ) に応答して、リストされた受信者は、(1*GRTT) のウィンドウにわたって NORM_ACK メッセージを時間内にランダムに均一に拡散します。これらの NORM_ACK メッセージは通常、送信者にユニキャストされます。(NORM_ACK(CC) メッセージは、NORM_NACK メッセージと同じようにマルチキャストまたはユニキャストであることに注意してください)。
The ACK process is self-limiting and avoids ACK implosion in that:
ACK プロセスは自己制限的であり、次の点で ACK の爆縮を回避します。
1) Only a single NORM_CMD(ACK_REQ) message is generated once per (2*GRTT), and,
1) 単一の NORM_CMD(ACK_REQ) メッセージのみが (2*GRTT) ごとに 1 回生成されます。
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」のサイズは、肯定応答プロセスのラウンドごとに送信者の NormSegmentSize 設定の最大値に制限されます。
Because the size of the included list is limited to the sender's NormSegmentSize setting, multiple NORM_CMD(ACK_REQ) rounds may be required to achieve responses from all receivers specified. The content of the attached NormNodeId list will be dynamically updated as this process progresses and NORM_ACK responses are received from the specified receiver set. As the sender receives valid responses (i.e., matching watermark point or "ack_id") from receivers, it SHALL eliminate those receivers from the subsequent NORM_CMD(ACK_REQ) message "acking_node_list" and add in any pending receiver NormNodeIds while keeping within the NormSegmentSize limitation of the list size. Each receiver is queried a maximum number of times (NORM_ROBUST_FACTOR, by default). Receivers not responding within this number of repeated requests are removed from the payload list to make room for other potential receivers pending acknowledgment. The transmission of the NORM_CMD(ACK_REQ) is repeated until no further responses are required or until the repeat threshold is exceeded for all pending receivers. The transmission of NORM_CMD(ACK_REQ) or NORM_CMD(FLUSH) messages to conduct the positive acknowledgment process is multiplexed with ongoing sender data transmissions. However, the NORM_CMD(FLUSH) positive acknowledgment process may be interrupted in response to negative acknowledgment repair requests (NACKs) received from receivers during the acknowledgment period. The NORM_CMD(FLUSH) positive acknowledgment process is restarted for receivers pending acknowledgment once any the repairs have been transmitted.
含まれるリストのサイズは送信者の NormSegmentSize 設定に制限されるため、指定されたすべての受信者からの応答を達成するには複数回の NORM_CMD(ACK_REQ) ラウンドが必要になる場合があります。添付された NormNodeId リストの内容は、このプロセスが進行し、指定された受信セットから NORM_ACK 応答が受信されるにつれて動的に更新されます。送信者が受信者から有効な応答（つまり、一致するウォーターマークポイントまたは「ack_id」）を受信すると、後続の NORM_CMD(ACK_REQ) メッセージ「acking_node_list」からそれらの受信者を削除し、NormSegmentSize の制限内に保ちながら、保留中の受信者の NormNodeIds を追加するものとします (SHALL)。リストのサイズ。各受信者は最大回数クエリされます (デフォルトでは NORM_ROBUST_FACTOR)。この反復リクエスト数以内に応答しない受信者は、確認を保留している他の潜在的な受信者のためのスペースを確保するために、ペイロード リストから削除されます。NORM_CMD(ACK_REQ) の送信は、それ以上の応答が必要なくなるまで、または保留中のすべての受信機について反復しきい値を超えるまで繰り返されます。肯定応答プロセスを実行するための NORM_CMD(ACK_REQ) または NORM_CMD(FLUSH) メッセージの送信は、進行中の送信側データ送信と多重化されます。ただし、NORM_CMD(FLUSH) 肯定応答プロセスは、肯定応答期間中に受信機から受信した否定応答修復要求 (NACK) に応答して中断される場合があります。NORM_CMD(FLUSH) 肯定応答プロセスは、修復が送信されると、肯定応答が保留中の受信機に対して再開されます。
In the case of NORM_CMD(FLUSH) commands with an attached "acking_node_list", receivers will not ACK until they have received complete transmission of all data up to and including the given watermark transmission point. All receivers SHALL interpret the watermark point provided in the request NACK for repairs if needed as for NORM_CMD(FLUSH) commands with no attached "acking_node_list".
「acking_node_list」が添付された NORM_CMD(FLUSH) コマンドの場合、受信側は、指定されたウォーターマーク送信ポイントまでのすべてのデータの送信が完了するまで ACK を返しません。すべての受信者は、「acking_node_list」が添付されていない NORM_CMD(FLUSH) コマンドと同様に、必要に応じて修復のための要求 NACK で提供されたウォーターマーク ポイントを解釈するものとします (SHALL)。
NORM sender messages contain a "gsize" field that is a representation of the group size and is used in scaling random backoff timer ranges. The use of the group size estimate within the NORM protocol does not require a precise estimation and works reasonably well if the estimate is within an order of magnitude of the actual group size. By default, the NORM sender group size estimate may be administratively configured. Also, given the expected scalability of the NORM protocol for general use, a default value of 10,000 is recommended for use as the group size estimate.
NORM 送信側メッセージには、グループ サイズを表す「gsize」フィールドが含まれており、ランダム バックオフ タイマー範囲のスケーリングに使用されます。NORM プロトコル内でグループ サイズ推定値を使用する場合、正確な推定値は必要なく、推定値が実際のグループ サイズの 1 桁以内であれば十分に機能します。デフォルトでは、NORM 送信者グループ サイズの推定値は管理的に構成できます。また、一般的な用途での NORM プロトコルの予想されるスケーラビリティを考慮して、グループ サイズの見積もりとしてデフォルト値 10,000 を使用することをお勧めします。
It is possible that group size may be algorithmically approximated from the volume of congestion control feedback messages which follow the exponentially weighted random backoff. However, the specification of such an algorithm is currently beyond the scope of this document.
グループ サイズは、指数関数的に重み付けされたランダム バックオフに続く輻輳制御フィードバック メッセージの量からアルゴリズム的に近似できる可能性があります。ただし、そのようなアルゴリズムの仕様は、現時点ではこのドキュメントの範囲を超えています。
The same security considerations that apply to the NORM, and FEC Building Blocks also apply to the NORM protocol. In addition to vulnerabilities that any IP and IP multicast protocol implementation may be generally subject to, the NACK-based feedback of NORM may be exploited by replay attacks which force the NORM sender to unnecessarily transmit repair information. This MAY be addressed by network layer IP security implementations that guard against this potential security exploitation. It is RECOMMENDED that such IP security mechanisms be used when available. Another possible approach is for NORM senders to use the "sequence" field from the NORM Common Message Header to detect replay attacks. This can be accomplished if the NORM packets are cryptographically protected and the sender is willing to maintain state on receivers which are NACKing. A cache of receiver state may provide some protection against replay attacks. Note that the "sequence" field of NORM messages should be incremented with independent values for different destinations (e.g., group-addressed versus unicast-addressed messages versus "receiver" messages). Thus, the congestion control loss estimation function of the "sequence" field can be preserved for sender messages when receiver messages are unicast to the sender. The NORM protocol is compatible with the use of the IP security (IPsec) architecture described in [22]. It is important to note that while NORM does leverage FEC-based repair for scalability, this does not alone guarantee integrity of received data. Application-level integrity-checking of data content is highly RECOMMENDED.
NORM および FEC ビルディング ブロックに適用されるのと同じセキュリティ上の考慮事項が、NORM プロトコルにも適用されます。IP および IP マルチキャスト プロトコルの実装が一般に影響を受ける可能性がある脆弱性に加えて、NORM の NACK ベースのフィードバックは、NORM 送信者に不必要に修復情報の送信を強制するリプレイ攻撃によって悪用される可能性があります。これは、この潜在的なセキュリティ悪用を防ぐネットワーク層 IP セキュリティ実装によって対処できます (MAY)。利用可能な場合には、そのような IP セキュリティメカニズムを使用することが推奨されます。もう 1 つの可能なアプローチは、NORM 送信者が NORM 共通メッセージ ヘッダーの「シーケンス」フィールドを使用してリプレイ攻撃を検出することです。これは、NORM パケットが暗号的に保護されており、送信者が NACK を送信している受信者の状態を維持する意思がある場合に実現できます。受信機状態のキャッシュは、リプレイ攻撃に対する何らかの保護を提供する可能性があります。NORM メッセージの「シーケンス」フィールドは、さまざまな宛先 (グループ アドレス指定メッセージ、ユニキャスト アドレス指定メッセージ、「受信者」メッセージなど) に応じて独立した値でインクリメントされる必要があることに注意してください。したがって、受信メッセージが送信側にユニキャストされる場合、「シーケンス」フィールドの輻輳制御損失推定機能を送信側メッセージに対して保存することができます。NORM プロトコルは、[22] で説明されている IP セキュリティ (IPsec) アーキテクチャの使用と互換性があります。NORM はスケーラビリティのために FEC ベースの修復を利用しますが、これだけでは受信データの整合性が保証されないことに注意することが重要です。データコンテンツのアプリケーションレベルの整合性チェックを強く推奨します。
No information in this specification is currently subject to IANA registration. However, several Header Extensions are defined within this document. If/when additional Header Extensions are developed, the first RFC MUST establish an IANA registry for them, with a "Specification Required" policy [6] and all Header Extensions, including those in the present document, MUST be registered thereafter. Additionally, building blocks components used by NORM may introduce additional IANA considerations. In particular, the FEC Building Block used by NORM does require IANA registration of the FEC codecs used. The registration instructions for FEC codecs are provided in [5].
現在、この仕様の情報は IANA 登録の対象にはなりません。ただし、このドキュメント内ではいくつかのヘッダ拡張が定義されています。追加のヘッダ拡張が開発された場合、最初の RFC は「仕様要求」ポリシー [6] を備えた IANA レジストリを確立しなければならず (MUST)、本文書に含まれるものを含むすべてのヘッダ拡張はその後登録されなければなりません (MUST)。さらに、NORM によって使用されるビルディング ブロック コンポーネントには、IANA に関する追加の考慮事項が導入される可能性があります。特に、NORM で使用される FEC ビルディング ブロックでは、使用される FEC コーデックの IANA 登録が必要です。FEC コーデックの登録手順は [5] に記載されています。
The present NORM protocol is seen as useful tool for the reliable data transfer over generic IP multicast services. It is not the intention of the authors to suggest it is suitable for supporting all envisioned multicast reliability requirements. NORM provides a 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 のようなプロトコルは、大規模な受信機グループにサービスを提供する気象衛星圧縮画像更新や汎用 Web コンテンツの信頼性の高い「プッシュ」アプリケーションなど、大量のデータ配布アプリケーション向けに 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 misordering. Hybrid proactive/reactive FEC-based repairing improve protocol performance in some multicast scenarios. A sender-only repair approach often makes additional engineering sense in asymmetric networks. NORM's unicast feedback capability may be suitable for use in asymmetric networks or in networks where only unidirectional multicast routing/delivery service exists. Asymmetric architectures supporting multicast delivery are likely to make up an important portion of the future Internet structure (e.g., DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer will be an important capability for servicing large groups of subscribed receivers.
さらに、このフレームワーク アプローチには、非対称およびワイヤレス インターネットワーク アプリケーションでの一括転送にとって魅力的な設計機能がいくつかあります。NORM は、ネットワーク構造に関係なく、パケット損失、遅延、および順序付けの誤りが多い環境でも正常に動作できます。ハイブリッド プロアクティブ/リアクティブ FEC ベースの修復により、一部のマルチキャスト シナリオにおけるプロトコル パフォーマンスが向上します。送信者のみの修復アプローチは、多くの場合、非対称ネットワークにおいて追加のエンジニアリング意味を持ちます。NORM のユニキャスト フィードバック機能は、非対称ネットワークや、一方向のマルチキャスト ルーティング/配信サービスのみが存在するネットワークでの使用に適している可能性があります。マルチキャスト配信をサポートする非対称アーキテクチャは、将来のインターネット構造 (DBS/ケーブル/PSTN ハイブリッドなど) の重要な部分を構成する可能性が高く、効率的で信頼性の高い大容量データ転送は、加入している受信者の大規模なグループにサービスを提供するための重要な機能となるでしょう。
The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh, Toni Paila, Michael Luby, and Joerg Widmer for their valuable input and comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early input into this document.
著者らは、この文書に関する貴重な意見とコメントをくださった Rick Jones、Vincent Roca、Rod Walsh、Toni Paila、Michael Luby、Joerg Widmer に感謝の意を表します。著者らはまた、この仕様の開発を支援してくれた RMT ワーキング グループの議長である Roger Kermode と Lorenzo Vicisano、およびこの文書への早期の意見提供に対して Sally Floyd に感謝したいと思います。
[1] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[1] Kermode, R. および L. Vicisano、「高信頼性マルチキャスト トランスポート (RMT) ビルディング ブロックおよびプロトコルのインスタンス化ドキュメントの作成者ガイドライン」、RFC 3269、2002 年 4 月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering, S.、「IP マルチキャスト用のホスト拡張」、STD 5、RFC 1112、1989 年 8 月。
[4] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[4] Adamson, B.、Bormann, C.、Handley, M.、および J. Macker、「NACK (Negative-Acknowledgment)-Oriented Reliable Multicast (NORM) Building Blocks」、RFC 3941、2004 年 11 月。
[5] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[5] Luby, M.、Vicisano, L.、Gemmell, J.、Rizzo, L.、Handley, M.、および J. Crowcroft、「前方誤り訂正 (FEC) ビルディング ブロック」、RFC 3452、2002 年 12 月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten, T. および H. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998 年 10 月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley、M. および V. Jacobson、「SDP: セッション記述プロトコル」、RFC 2327、1998 年 4 月。
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[8] Handley, M.、Perkins, C.、および E. Whelan、「セッション アナウンスメント プロトコル」、RFC 2974、2000 年 10 月。
[9] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", In Proc. INFOCOM, San Francisco CA, October 1993.
[9] S. Pingali、D. Towsley、J. Kurase、「送信者開始型と受信者開始型の信頼できるマルチキャスト プロトコルの比較」、Proc.INFOCOM、カリフォルニア州サンフランシスコ、1993 年 10 月。
[10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[10] Luby, M.、Vicisano, L.、Gemmell, J.、Rizzo, L.、Handley, M.、および J. Crowcroft、「信頼性の高いマルチキャストにおける前方誤り訂正 (FEC) の使用」、RFC 3453、2002 年 12 月。
[11] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol (MDP) Toolkit", Proc. IEEE MILCOM 99, October 1999.
[11] Macker, J. および B. Adamson、「マルチキャスト普及プロトコル (MDP) ツールキット」、Proc.IEEE MILCOM 99、1999 年 10 月。
[12] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", Proc. IEEE INFOCOMM, p. 964, March/April 1998.
[12] Nonnenmacher、J. および E. Biersack、「最適なマルチキャスト フィードバック」、Proc.IEEE 情報通信、p.964、1998 年 3 月または 4 月。
[13] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002.
[13] J. Macker、B. Adamson、「Nack Oriented Reliable Multicast (NORM) Feedback の定量的予測」、Proc.IEEE MILCOM 2002、2002 年 10 月。
[14] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[14] H.W.ホルブルック、「マルチキャストのチャネル モデル」、Ph.D.学位論文、スタンフォード大学コンピュータ サイエンス学部、カリフォルニア州スタンフォード、2001 年 8 月。
[15] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOMM 98', September 1998.
[15] D. Gossink、J. Macker、「チャネル推定による信頼性の高いマルチキャストと統合パリティ再送信」、IEEE GLOBECOMM 98'、1998 年 9 月。
[16] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[16] Whetten, B.、Vicisano, L.、Kermode, R.、Handley, M.、Floyd, S.、および M. Luby、「1 対多のバルクデータ転送のための信頼できるマルチキャスト トランスポート ビルディング ブロック」、RFC 3048、2001年1月。
[17] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[17] Mankin, A.、Romanow, A.、Bradner, S.、および V. Paxson、「信頼性の高いマルチキャスト トランスポートおよびアプリケーション プロトコルを評価するための IETF 基準」、RFC 2357、1998 年 6 月。
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[18] Schulzrinne, H.、Casner, S.、Frederick, R.、および V. Jacobson、「RTP: リアルタイム アプリケーションのためのトランスポート プロトコル」、STD 64、RFC 3550、2003 年 7 月。
[19] J. Widmer and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, August 2001.
[19] J. Widmer および M. Handley、「Extending Equation-Based Congestion Control to Multicast Applications」、Proc ACM SIGCOMM 2001、サンディエゴ、2001 年 8 月。
[20] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[20] L. Rizzo、「pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme」、Proc ACM SIGCOMM 2000、ストックホルム、2000 年 8 月。
[21] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
[21] J. Padhye、V. Firoiu、D. Towsley、および J. Kurase、「TCP スループットのモデリング: シンプルなモデルとその経験的検証」、Proc ACM SIGCOMM 1998。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
Brian Adamson Naval Research Laboratory Washington, DC, USA, 20375
ブライアン・アダムソン海軍研究所、ワシントン 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 ブレーメン、ドイツ
EMail: cabo@tzi.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
Mark Handley コンピューター サイエンス学科 ユニバーシティ カレッジ ロンドン Gower Street London WC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC, USA, 20375
ジョー・マッカー海軍研究所、ワシントン DC、米国、20375
EMail: macker@itd.nrl.navy.mil
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。