[要約] RFC 3208は、PGM Reliable Transport Protocolの仕様を定義しており、マルチキャスト通信における信頼性の高いデータ転送を提供することを目的としています。
Network Working Group T. Speakman
Request for Comments: 3208 Cisco Systems
Category: Experimental J. Crowcroft
UCL
J. Gemmell
Microsoft
D. Farinacci
Procket Networks
S. Lin
Juniper Networks
D. Leshchiner
TIBCO Software
M. Luby
Digital Fountain
T. Montgomery
Talarian Corporation
L. Rizzo
University of Pisa
A. Tweedly
N. Bhaskar
R. Edmonstone
R. Sumanasekera
L. Vicisano
Cisco Systems
December 2001
PGM Reliable Transport Protocol Specification
PGM信頼できる輸送プロトコル仕様
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.
実用的な一般的なマルチキャスト（PGM）は、複数のソースから複数の受信機への順序付けまたは順序のない、重複していないマルチキャストデータ配信を必要とするアプリケーション向けの信頼性の高いマルチキャストトランスポートプロトコルです。PGMは、グループ内の受信者が送信と修理からすべてのデータパケットを受信するか、回復不可能なデータパケットの損失を検出できることを保証します。PGMは、基本的な信頼性要件を備えたマルチキャストアプリケーションの実行可能なソリューションとして特に意図されています。その中心的な設計目標は、スケーラビリティとネットワーク効率を十分に考慮して、操作のシンプルさです。
Table of Contents
目次
1. Introduction and Overview .................................. 3
2. Architectural Description .................................. 9
3. Terms and Concepts ......................................... 12
4. Procedures - General ....................................... 18
5. Procedures - Sources ....................................... 19
6. Procedures - Receivers ..................................... 22
7. Procedures - Network Elements .............................. 27
8. Packet Formats ............................................. 31
9. Options .................................................... 40
10. Security Considerations .................................... 56
11. Appendix A - Forward Error Correction ...................... 58
12. Appendix B - Support for Congestion Control ................ 72
13. Appendix C - SPM Requests .................................. 79
14. Appendix D - Poll Mechanism ................................ 82
15. Appendix E - Implosion Prevention .......................... 92
16. Appendix F - Transmit Window Example ....................... 98
17 Appendix G - Applicability Statement ....................... 103
18. Abbreviations .............................................. 105
19. Acknowledgments ............................................ 106
20. References ................................................. 106
21. Authors' Addresses.......................................... 108
22. Full Copyright Statement ................................... 111
Nota Bene:
Nota Bene：
The publication of this specification is intended to freeze the definition of PGM in the interest of fostering both ongoing and prospective experimentation with the protocol. The intent of that experimentation is to provide experience with the implementation and deployment of a reliable multicast protocol of this class so as to be able to feed that experience back into the longer-term standardization process underway in the Reliable Multicast Transport Working Group of the IETF. Appendix G provides more specific detail on the scope and status of some of this experimentation. Reports of experiments include [16-23]. Additional results and new experimentation are encouraged.
この仕様の公開は、プロトコルを使用して進行中および前向き実験の両方を促進するために、PGMの定義を凍結することを目的としています。その実験の目的は、IETFの信頼できるマルチキャスト輸送ワーキンググループで進行中の長期標準化プロセスにその経験を供給できるように、このクラスの信頼できるマルチキャストプロトコルの実装と展開の経験を提供することです。。付録Gでは、この実験の一部の範囲とステータスに関するより具体的な詳細を提供します。実験の報告には[16-23]が含まれます。追加の結果と新しい実験が奨励されます。
A variety of reliable protocols have been proposed for multicast data delivery, each with an emphasis on particular types of applications, network characteristics, or definitions of reliability ([1], [2], [3], [4]). In this tradition, Pragmatic General Multicast (PGM) is a reliable transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers.
さまざまな信頼できるプロトコルがマルチキャストデータ配信に提案されており、それぞれが特定のタイプのアプリケーション、ネットワーク特性、または信頼性の定義に重点を置いています（[1]、[2]、[3]、[4]）。この伝統では、実用的な一般的なマルチキャスト（PGM）は、複数のソースから複数のレシーバーへの順序付けまたは秩序化されていない、複製されていないマルチキャストデータ配信を必要とするアプリケーション向けの信頼できる輸送プロトコルです。
PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements rather than as a comprehensive solution for multicast applications with sophisticated ordering, agreement, and robustness requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.
PGMは、洗練された注文、合意、堅牢性要件を備えたマルチキャストアプリケーションの包括的なソリューションとしてではなく、基本的な信頼性要件を備えたマルチキャストアプリケーションの実行可能なソリューションとして特に意図されています。その中心的な設計目標は、スケーラビリティとネットワーク効率を十分に考慮して、操作のシンプルさです。
PGM has no notion of group membership. It simply provides reliable multicast data delivery within a transmit window advanced by a source according to a purely local strategy. Reliable delivery is provided within a source's transmit window from the time a receiver joins the group until it departs. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM supports any number of sources within a multicast group, each fully identified by a globally unique Transport Session Identifier (TSI), but since these sources/sessions operate entirely independently of each other, this specification is phrased in terms of a single source and extends without modification to multiple sources.
PGMにはグループメンバーシップの概念はありません。純粋にローカルな戦略に従って、ソースによって進められた送信ウィンドウ内で信頼できるマルチキャストデータ配信を提供するだけです。信頼できる配達は、レシーバーがグループに参加するまでに出発するまで、ソースの送信ウィンドウ内で提供されます。PGMは、グループ内の受信者が送信と修理からすべてのデータパケットを受信するか、回復不可能なデータパケットの損失を検出できることを保証します。PGMはマルチキャストグループ内の任意の数のソースをサポートしており、それぞれがグローバルに一意のトランスポートセッション識別子（TSI）によって完全に識別されますが、これらのソース/セッションは互いに完全に独立して動作するため、この仕様は単一のソースで表現され、拡張されています。複数のソースを変更することなく。
More specifically, PGM is not intended for use with applications that depend either upon acknowledged delivery to a known group of recipients, or upon total ordering amongst multiple sources.
より具体的には、PGMは、既知の受信者グループへの承認された配信のいずれか、または複数のソース間の合計注文のいずれかに依存するアプリケーションで使用することを目的としていません。
Rather, PGM is best suited to those applications in which members may join and leave at any time, and that are either insensitive to unrecoverable data packet loss or are prepared to resort to application recovery in the event. Through its optional extensions, PGM provides specific mechanisms to support applications as disparate as stock and news updates, data conferencing, low-delay real-time video transfer, and bulk data transfer.
むしろ、PGMは、メンバーがいつでも参加して出発するアプリケーションに最適であり、回復不可能なデータパケット損失に敏感であるか、イベントでのアプリケーションの回復に頼る準備ができています。PGMは、オプションの拡張機能を通じて、ストックやニュースの更新、データ会議、低遅延のリアルタイムビデオ転送、バルクデータ転送と同じように異なるアプリケーションをサポートするための特定のメカニズムを提供します。
In the following text, transport-layer originators of PGM data packets are referred to as sources, transport-layer consumers of PGM data packets are referred to as receivers, and network-layer entities in the intervening network are referred to as network elements.
次のテキストでは、PGMデータパケットの輸送層創始者はソースと呼ばれ、PGMデータパケットの輸送層消費者は受信機と呼ばれ、介入ネットワークのネットワーク層エンティティはネットワーク要素と呼ばれます。
Unless otherwise specified, the term "repair" will be used to indicate both the actual retransmission of a copy of a missing packet or the transmission of an FEC repair packet.
特に指定されていない限り、「修理」という用語は、欠落しているパケットのコピーの実際の再送信またはFEC修理パケットの送信の両方を示すために使用されます。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [14] and indicate requirement levels for compliant PGM implementations.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [14]で説明されているように解釈され、準拠したPGM実装の要件レベルを示します。
PGM runs over a datagram multicast protocol such as IP multicast [5]. In the normal course of data transfer, a source multicasts sequenced data packets (ODATA), and receivers unicast selective negative acknowledgments (NAKs) for data packets detected to be missing from the expected sequence. Network elements forward NAKs PGM-hop-by-PGM-hop to the source, and confirm each hop by multicasting a NAK confirmation (NCF) in response on the interface on which the NAK was received. Repairs (RDATA) may be provided either by the source itself or by a Designated Local Repairer (DLR) in response to a NAK.
PGMは、IPマルチキャストなどのデータグラムマルチキャストプロトコルを実行します[5]。データ転送の通常のコースでは、ソースマルチキャストがデータパケットをシーケンスしたデータパケット（ODATA）と、予想されるシーケンスから欠落していると検出されたデータパケットの受信機ユニキャスト選択的否定的承認（NAK）。ネットワーク要素は、NAKが受信されたインターフェイスに応じて、NAK確認（NCF）をマルチリキャストすることにより、pgm-hop-by-pgm-hopをソースに転送し、各ホップを確認します。修理（RDATA）は、NAKに応じて、ソース自体または指定されたローカル修理業者（DLR）によって提供される場合があります。
Since NAKs provide the sole mechanism for reliability, PGM is particularly sensitive to their loss. To minimize NAK loss, PGM defines a network-layer hop-by-hop procedure for reliable NAK forwarding.
NAKSは信頼性の唯一のメカニズムを提供するため、PGMはその損失に特に敏感です。NAKの損失を最小限に抑えるために、PGMは信頼できるNAK転送のネットワーク層ホップバイホップ手順を定義します。
Upon detection of a missing data packet, a receiver repeatedly unicasts a NAK to the last-hop PGM network element on the distribution tree from the source. A receiver repeats this NAK until it receives a NAK confirmation (NCF) multicast to the group from that PGM network element. That network element responds with an NCF to the first occurrence of the NAK and any further retransmissions of that same NAK from any receiver. In turn, the network element repeatedly forwards the NAK to the upstream PGM network element on the reverse of the distribution path from the source of the original data packet until it also receives an NCF from that network element. Finally, the source itself receives and confirms the NAK by multicasting an NCF to the group.
欠落しているデータパケットを検出すると、レシーバーは、ソースから分布ツリー上のラストホップPGMネットワーク要素にnakを繰り返しユニカストします。受信者は、そのPGMネットワーク要素からグループにNAK確認（NCF）マルチキャストを受信するまで、このNAKを繰り返します。そのネットワーク要素は、NAKの最初の発生にNCFで応答し、あらゆるレシーバーからの同じNAKのさらなる再送信があります。次に、ネットワーク要素は、そのネットワーク要素からNCFも受信するまで、元のデータパケットのソースから分布パスの逆の上流のPGMネットワーク要素にNAKを繰り返し転送します。最後に、ソース自体は、NCFをグループにマルチリキャストすることにより、NAKを受け取り、確認します。
While NCFs are multicast to the group, they are not propagated by PGM network elements since they act as hop-by-hop confirmations.
NCFはグループのマルチキャストですが、ホップバイホップの確認として機能するため、PGMネットワーク要素によって伝播されません。
To avoid NAK implosion, PGM specifies procedures for subnet-based NAK suppression amongst receivers and NAK elimination within network elements. The usual result is the propagation of just one copy of a given NAK along the reverse of the distribution path from any network with directly connected receivers to a source.
NAKの爆発を避けるために、PGMは、ネットワーク要素内のサブネットベースのNAK抑制とNAK排除の手順を指定します。通常の結果は、直接接続されたレシーバーを使用して、任意のネットワークから任意のネットワークの逆に沿って、特定のNAKの1つのコピーのみの伝播です。
The net effect is that unicast NAKs return from a receiver to a source on the reverse of the path on which ODATA was forwarded, that is, on the reverse of the distribution tree from the source. More specifically, they return through exactly the same sequence of PGM network elements through which ODATA was forwarded, but in reverse. The reasons for handling NAKs this way will become clear in the discussion of constraining repairs, but first it's necessary to describe the mechanisms for establishing the requisite source path state in PGM network elements.
最終的な効果は、ユニキャストNAKが受信機からソースに戻り、Odataが転送されたパスの逆、つまりソースからの分布ツリーの逆に戻ることです。より具体的には、Odataが転送されたが逆に、PGMネットワーク要素のまったく同じシーケンスを介して戻ります。この方法でNAKを処理する理由は、修理の制約の議論で明らかになりますが、最初にPGMネットワーク要素で必要なソースパス状態を確立するためのメカニズムを説明する必要があります。
To establish source path state in PGM network elements, the basic data transfer operation is augmented by Source Path Messages (SPMs) from a source, periodically interleaved with ODATA. SPMs function primarily to establish source path state for a given TSI in all PGM network elements on the distribution tree from the source. PGM network elements use this information to address returning unicast NAKs directly to the upstream PGM network element toward the source, and thereby insure that NAKs return from a receiver to a source on the reverse of the distribution path for the TSI.
PGMネットワーク要素でソースパス状態を確立するために、基本的なデータ転送操作は、ソースからのソースパスメッセージ（SPM）によって拡張され、定期的にOdataとインターリーブされます。SPMSは、主に、ソースからの分布ツリー上のすべてのPGMネットワーク要素で、特定のTSIのソースパス状態を確立するように機能します。PGMネットワーク要素は、この情報を使用して、Unicast NAKを上流のPGMネットワーク要素に直接ソースに向けて直接扱い、それにより、NAKがTSIの分布パスの逆にレシーバーからソースに戻ることを保証します。
SPMs are sent by a source at a rate that serves to maintain up-to-date PGM neighbor information. In addition, SPMs complement the role of DATA packets in provoking further NAKs from receivers, and maintaining receive window state in the receivers.
SPMは、最新のPGM近隣情報を維持するのに役立つレートでソースによって送信されます。さらに、SPMは、受信機からさらにNAKを引き起こし、受信機の受信ウィンドウ状態を維持することにおけるデータパケットの役割を補完します。
As a further efficiency, PGM specifies procedures for the constraint of repairs by network elements so that they reach only those network segments containing group members that did not receive the original transmission. As NAKs traverse the reverse of the ODATA path (upward), they establish repair state in the network elements which is used in turn to constrain the (downward) forwarding of the corresponding RDATA.
さらなる効率として、PGMは、ネットワーク要素による修理の制約の手順を指定して、元の送信を受け取らないグループメンバーを含むネットワークセグメントのみに到達するようにします。NaksがOdataパス（上向き）の逆を横断すると、対応するrdataの（下向きの）転送を制約するために使用されるネットワーク要素に修復状態を確立します。
Besides procedures for the source to provide repairs, PGM also specifies options and procedures that permit designated local repairers (DLRs) to announce their availability and to redirect repair requests (NAKs) to themselves rather than to the original source. In addition to these conventional procedures for loss recovery through selective ARQ, Appendix A specifies Forward Error Correction (FEC) procedures for sources to provide and receivers to request general error correcting parity packets rather than selective retransmissions.
ソースが修理を提供する手順に加えて、PGMは、指定されたローカル修理業者（DLR）が可用性を発表し、元のソースではなく修理要求（NAK）を自分自身にリダイレクトすることを許可するオプションと手順を指定します。選択的ARQによる損失回復のためのこれらの従来の手順に加えて、付録Aは、ソースを提供するためのフォワードエラー補正（FEC）手順を指定し、受信機は選択的再送信ではなくパリティパケットを修正する一般的なエラーを要求します。
Finally, since PGM operates without regular return traffic from receivers, conventional feedback mechanisms for transport flow and congestion control cannot be applied. Appendix B specifies a TCP-friendly, NE-based solution for PGM congestion control, and cites a reference to a TCP-friendly, end-to-end solution for PGM congestion control.
最後に、PGMは受信機からの定期的なリターントラフィックなしで動作するため、輸送の流れと輻輳制御のための従来のフィードバックメカニズムを適用できません。付録Bは、PGM輻輳制御用のTCPフレンドリーなNEベースのソリューションを指定し、PGM輻輳制御用のTCPフレンドリーなエンドツーエンドソリューションへの参照を引用しています。
In its basic operation, PGM relies on a purely rate-limited transmission strategy in the source to bound the bandwidth consumed by PGM transport sessions and to define the transmit window maintained by the source.
基本的な操作では、PGMは、PGM輸送セッションで消費された帯域幅をバインドし、ソースによって維持されている送信ウィンドウを定義するために、ソース内の純粋に制限された伝送戦略に依存しています。
PGM defines four basic packet types: three that flow downstream (SPMs, DATA, NCFs), and one that flows upstream (NAKs).
PGMは4つの基本的なパケットタイプを定義します。3つは、下流（SPM、データ、NCFS）と上流（NAKS）を流れる3つです。
PGM has been designed to serve that broad range of multicast applications that have relatively simple reliability requirements, and to do so in a way that realizes the much advertised but often unrealized network efficiencies of multicast data transfer. The usual impediments to realizing these efficiencies are the implosion of negative and positive acknowledgments from receivers to sources, repair latency from the source, and the propagation of repairs to disinterested receivers.
PGMは、比較的単純な信頼性要件を持つ幅広いマルチキャストアプリケーションにサービスを提供するように設計されており、マルチキャストデータ転送の多くの宣伝されているがしばしば未実現ネットワーク効率を実現する方法でそうするように設計されています。これらの効率を実現するための通常の障害は、受信者からソースへの否定的および肯定的な承認の崩壊、ソースからの潜時の修復、および無関心な受信者への修理の伝播です。
1.2.1. Reliability.
1.2.1. 信頼性。
Reliable data delivery across an unreliable network is conventionally achieved through an end-to-end protocol in which a source (implicitly or explicitly) solicits receipt confirmation from a receiver, and the receiver responds positively or negatively. While the frequency of negative acknowledgments is a function of the reliability of the network and the receiver's resources (and so, potentially quite low), the frequency of positive acknowledgments is fixed at at least the rate at which the transmit window is advanced, and usually more often.
信頼性の低いネットワーク全体での信頼できるデータ配信は、ソースが（暗黙的または明示的に）受信者からの領収書の確認を求め、レシーバーが積極的または否定的に応答するエンドツーエンドのプロトコルを通じて従来で達成されます。否定的な承認の頻度は、ネットワークと受信機のリソースの信頼性の関数ですが（そして、潜在的に非常に低い）、正の認識の頻度は少なくとも送信ウィンドウが進行する速度で固定され、通常は通常固定されています。より頻繁に。
Negative acknowledgments primarily determine repairs and reliability. Positive acknowledgments primarily determine transmit buffer management.
否定的な承認は、主に修理と信頼性を決定します。肯定的な謝辞は、主に送信バッファー管理を決定します。
When these principles are extended without modification to multicast protocols, the result, at least for positive acknowledgments, is a burden of positive acknowledgments transmitted to the source that quickly threatens to overwhelm it as the number of receivers grows. More succinctly, ACK implosion keeps ACK-based reliable multicast protocols from scaling well.
これらの原則がマルチキャストプロトコルの変更なしで拡張される場合、少なくとも肯定的な承認のために、結果は、受信者の数が増えるにつれてそれを圧倒するとすぐに脅迫される肯定的な承認の負担です。さらに簡潔に言えば、ACKの爆発により、ACKベースの信頼性の高いマルチキャストプロトコルが適切にスケーリングされなくなります。
One of the goals of PGM is to get as strong a definition of reliability as possible from as simple a protocol as possible. ACK implosion can be addressed in a variety of effective but complicated ways, most of which require re-transmit capability from other than the original source.
PGMの目標の1つは、可能な限り単純なAプロトコルからできるだけ強力な信頼性の定義を得ることです。ACKの爆発は、さまざまな効果的で複雑な方法で対処できます。そのほとんどは、元のソース以外からの再送信機能を必要とします。
An alternative is to dispense with positive acknowledgments altogether, and to resort to other strategies for buffer management while retaining negative acknowledgments for repairs and reliability. The approach taken in PGM is to retain negative acknowledgments, but to dispense with positive acknowledgments and resort instead to timeouts at the source to manage transmit resources.
別の方法は、肯定的な承認を完全に分配し、修理と信頼性のために否定的な承認を維持しながら、バッファ管理のための他の戦略に頼ることです。PGMで採用されたアプローチは、否定的な承認を保持することですが、肯定的な承認を省き、代わりに送信リソースを管理するためにソースのタイムアウトにリゾートすることです。
The definition of reliability with PGM is a direct consequence of this design decision. PGM guarantees that a receiver either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss.
PGMによる信頼性の定義は、この設計上の決定の直接的な結果です。PGMは、受信者が送信および修理からすべてのデータパケットを受信するか、回復不可能なデータパケット損失を検出できることを保証します。
PGM includes strategies for repeatedly provoking NAKs from receivers, and for adding reliability to the NAKs themselves. By reinforcing the NAK mechanism, PGM minimizes the probability that a receiver will detect a missing data packet so late that the packet is unavailable for repair either from the source or from a designated local repairer (DLR). Without ACKs and knowledge of group membership, however, PGM cannot eliminate this possibility.
PGMには、レシーバーからNAKを繰り返し引き起こす戦略、およびNAK自体に信頼性を追加するための戦略が含まれています。NAKメカニズムを強化することにより、PGMは、受信機が欠落データパケットを検出する可能性を最小限に抑えます。ただし、ACKとグループメンバーシップの知識がなければ、PGMはこの可能性を排除することはできません。
A second consequence of eliminating ACKs is that knowledge of group membership is neither required nor provided by the protocol. Although a source may receive some PGM packets (NAKs for instance) from some receivers, the identity of the receivers does not figure in the processing of those packets. Group membership MAY change during the course of a PGM transport session without the knowledge of or consequence to the source or the remaining receivers.
ACKを排除することの2番目の結果は、グループメンバーシップの知識がプロトコルによって必要でも提供されていないことです。ソースは一部の受信機からいくつかのPGMパケット（たとえばNAK）を受信する場合がありますが、受信機の身元はそれらのパケットの処理には把握されていません。グループメンバーシップは、ソースまたは残りのレシーバーの知識や結果なしに、PGM輸送セッションの過程で変更される場合があります。
While PGM avoids the implosion of positive acknowledgments simply by dispensing with ACKs, the implosion of negative acknowledgments is addressed directly.
PGMは、ACKを分配するだけで肯定的な承認の崩壊を回避しますが、否定的な承認の崩壊は直接対処されます。
Receivers observe a random back-off prior to generating a NAK during which interval the NAK is suppressed (i.e. it is not sent, but the receiver acts as if it had sent it) by the receiver upon receipt of a matching NCF. In addition, PGM network elements eliminate duplicate NAKs received on different interfaces on the same network element.
受信機は、NAKが抑制される間隔を生成する前にランダムバックオフを観察します（つまり、送信されませんが、受信機はそれを送信したかのように動作します）。さらに、PGMネットワーク要素は、同じネットワーク要素の異なるインターフェイスで受信された重複したNAKを排除します。
The combination of these two strategies usually results in the source receiving just a single NAK for any given lost data packet.
これらの2つの戦略の組み合わせにより、通常、ソースは、特定の失われたデータパケットに対して単一のNAKのみを受け取ります。
Whether a repair is provided from a DLR or the original source, it is important to constrain that repair to only those network segments containing members that negatively acknowledged the original transmission rather than propagating it throughout the group. PGM specifies procedures for network elements to use the pattern of NAKs to define a sub-tree within the group upon which to forward the corresponding repair so that it reaches only those receivers that missed it in the first place.
DLRまたは元のソースから修理が提供されるかどうかにかかわらず、グループ全体で伝播するのではなく、元の送信を否定的に認めたメンバーを含むネットワークセグメントのみにその修理を制約することが重要です。PGMは、ネットワーク要素の手順を指定して、NAKのパターンを使用してグループ内のサブツリーを定義し、対応する修理を転送して、そもそも見逃したレシーバーのみに到達するようにします。
PGM is designed to achieve the greatest improvement in reliability (as compared to the usual UDP) with the least complexity. As a result, PGM does NOT address conference control, global ordering amongst multiple sources in the group, nor recovery from network partitions.
PGMは、複雑さが最小の信頼性（通常のUDPと比較して）の最大の改善を達成するように設計されています。その結果、PGMは会議管理、グループ内の複数のソース間のグローバル注文、ネットワークパーティションからの回復に対処しません。
PGM is designed to function, albeit with less efficiency, even when some or all of the network elements in the multicast tree have no knowledge of PGM. To that end, all PGM data packets can be conventionally multicast routed by non-PGM network elements with no loss of functionality, but with some inefficiency in the propagation of RDATA and NCFs.
PGMは、マルチキャストツリーの一部またはすべてのネットワーク要素にPGMの知識がない場合でも、効率が低いにもかかわらず、機能するように設計されています。そのために、すべてのPGMデータパケットは、機能を損なうことなく非PGMネットワーク要素によって従来的にマルチキャストルーティングできますが、RDATAおよびNCFSの伝播にはある程度の非効率性があります。
In addition, since NAKs are unicast to the last-hop PGM network element and NCFs are multicast to the group, NAK/NCF operation is also consistent across non-PGM network elements. Note that for NAK suppression to be most effective, receivers should always have a PGM network element as a first hop network element between themselves and every path to every PGM source. If receivers are several hops removed from the first PGM network element, the efficacy of NAK suppression may degrade.
さらに、NAKSはラストホップPGMネットワーク要素のユニキャストであり、NCFはグループのマルチキャストであるため、NAK/NCF操作は非PGMネットワーク要素間でも一貫しています。NAK抑制が最も効果的であるためには、受信機は常に自分自身とすべてのPGMソースへのすべてのパスの間の最初のホップネットワーク要素としてPGMネットワーク要素を持つ必要があることに注意してください。受信機が最初のPGMネットワーク要素からいくつかのホップが削除されている場合、NAK抑制の有効性は劣化する場合があります。
In addition to the basic data transfer operation described above, PGM specifies several end-to-end options to address specific application requirements. PGM specifies options to support fragmentation, late joining, redirection, Forward Error Correction (FEC), reachability, and session synchronization/termination/reset. Options MAY be appended to PGM data packet headers only by their original transmitters. While they MAY be interpreted by network elements, options are neither added nor removed by network elements.
上記の基本的なデータ転送操作に加えて、PGMは特定のアプリケーション要件に対処するためのいくつかのエンドツーエンドオプションを指定します。PGMは、断片化、遅い結合、リダイレクト、フォワードエラー補正（FEC）、到達可能性、セッションの同期/終了/リセットをサポートするオプションを指定します。オプションは、元の送信機によってのみPGMデータパケットヘッダーに追加される場合があります。それらはネットワーク要素によって解釈される可能性がありますが、オプションはネットワーク要素によって追加されたり削除されたりしません。
All options are receiver-significant (i.e., they must be interpreted by receivers). Some options are also network-significant (i.e., they must be interpreted by network elements).
すべてのオプションは、受信者有意です（つまり、レシーバーによって解釈する必要があります）。いくつかのオプションもネットワーク有意です（つまり、ネットワーク要素で解釈する必要があります）。
Fragmentation MAY be used in conjunction with data packets to allow a transport-layer entity at the source to break up application-layer data packets into multiple PGM data packets to conform with the maximum transmission unit (MTU) supported by the network layer.
断片化をデータパケットと組み合わせて使用して、ソースの輸送層エンティティがアプリケーション層データパケットを複数のPGMデータパケットに分割して、ネットワークレイヤーでサポートされる最大送信ユニット（MTU）に準拠できるようにすることができます。
Late joining allows a source to indicate whether or not receivers may request all available repairs when they initially join a particular transport session.
遅く参加することで、ソースは、特定の輸送セッションに最初に参加するときに、受信機が利用可能なすべての修理を要求できるかどうかを示すことができます。
Redirection MAY be used in conjunction with Poll Responses to allow a DLR to respond to normal NCFs or POLLs with a redirecting POLR advertising its own address as an alternative re-transmitter to the original source.
リダイレクトは、ポーリングの回答と併せて使用され、DLRが通常のNCFまたはポーリングに応答して、リダイレクトPOLRが独自の住所を元のソースに代わる再送信機として宣伝することを可能にします。
FEC techniques MAY be applied by receivers to use source-provided parity packets rather than selective retransmissions to effect loss recovery.
FEC手法は、受信機が選択したパリティパケットを使用して選択的な再送信ではなく、損失回復を実現するために適用できます。
As an end-to-end transport protocol, PGM specifies packet formats and procedures for sources to transmit and for receivers to receive data. To enhance the efficiency of this data transfer, PGM also specifies packet formats and procedures for network elements to improve the reliability of NAKs and to constrain the propagation of repairs. The division of these functions is described in this section and expanded in detail in the next section.
エンドツーエンドのトランスポートプロトコルとして、PGMは、送信ソースと受信機がデータを受信するためのパケット形式と手順を指定します。このデータ転送の効率を高めるために、PGMは、NAKの信頼性を改善し、修理の伝播を制約するために、ネットワーク要素のパケット形式と手順も指定します。これらの関数の分割については、このセクションで説明し、次のセクションで詳細に拡張されています。
Data Transmission
データ送信
Sources multicast ODATA packets to the group within the transmit window at a given transmit rate.
ソース特定の送信速度で送信ウィンドウ内のグループにマルチキャストODATAパケット。
Source Path State
ソースパス状態
Sources multicast SPMs to the group, interleaved with ODATA if present, to establish source path state in PGM network elements.
SOURCES MULTICAST SPMSはグループになり、PGMネットワーク要素でソースパス状態を確立するために、存在する場合はOdataとインターリーブします。
NAK Reliability
Nakの信頼性
Sources multicast NCFs to the group in response to any NAKs they receive.
受信したNAKに応じて、グループにマルチキャストNCFをソースに送信します。
Repairs
修理
Sources multicast RDATA packets to the group in response to NAKs received for data packets within the transmit window.
ソース送信ウィンドウ内のデータパケットに対して受信したNAKSに応じて、グループにマルチキャストRDATAパケットをグループに送信します。
Transmit Window Advance
ウィンドウアドバンスを送信します
Sources MAY advance the trailing edge of the window according to one of a number of strategies. Implementations MAY support automatic adjustments such as keeping the window at a fixed size in bytes, a fixed number of packets or a fixed real time duration. In addition, they MAY optionally delay window advancement based on NAK-silence for a certain period. Some possible strategies are outlined later in this document.
情報源は、多くの戦略の1つに従って、窓の後縁を前進させる場合があります。実装は、ウィンドウをバイトの固定サイズに保つ、固定数のパケット数、または固定リアルタイム期間などの自動調整をサポートする場合があります。さらに、特定の期間にわたってNak-Silenceに基づいて窓の進歩をオプションで遅らせることができます。いくつかの可能な戦略は、このドキュメントの後半で概説されています。
Source Path State
ソースパス状態
Receivers use SPMs to determine the last-hop PGM network element for a given TSI to which to direct their NAKs.
受信機はSPMSを使用して、NAKを指示するために特定のTSIの最終ホップPGMネットワーク要素を決定します。
Data Reception
データ受信
Receivers receive ODATA within the transmit window and eliminate any duplicates.
受信機は送信ウィンドウ内でODATAを受け取り、重複を排除します。
Repair Requests
リクエストの修理
Receivers unicast NAKs to the last-hop PGM network element (and MAY optionally multicast a NAK with TTL of 1 to the local group) for data packets within the receive window detected to be missing from the expected sequence. A receiver MUST repeatedly transmit a given NAK until it receives a matching NCF.
レシーバーユニキャストNAKSは、予想されるシーケンスから欠落していると検出された受信ウィンドウ内のデータパケットのデータパケットについて、最終ホップPGMネットワーク要素（オプションで1のTTLを1のTTLでマルチキャストA NAK）にユニカストします。レシーバーは、一致するNCFを受信するまで、特定のNAKを繰り返し送信する必要があります。
NAK Suppression
Nak抑制
Receivers suppress NAKs for which a matching NCF or NAK is received during the NAK transmit back-off interval.
NAK送信バックオフ間隔中に一致するNCFまたはNAKが受信されるNAKを抑制します。
Receive Window Advance
ウィンドウアドバンスを受け取ります
Receivers immediately advance their receive windows upon receipt of any PGM data packet or SPM within the transmit window that advances the receive window.
受信機は、受信ウィンドウを受信ウィンドウ内のPGMデータパケットまたはSPMを受信すると、受信ウィンドウを受信するとすぐにウィンドウを進めます。
Network elements forward ODATA without intervention.
ネットワーク要素は、介入なしでodataを前進させます。
Source Path State
ソースパス状態
Network elements intercept SPMs and use them to establish source path state for the corresponding TSI before multicast forwarding them in the usual way.
ネットワーク要素はSPMを傍受し、それらを使用して対応するTSIのソースパス状態を確立してから、通常の方法でそれらを転送します。
NAK Reliability
Nakの信頼性
Network elements multicast NCFs to the group in response to any NAK they receive. For each NAK received, network elements create repair state recording the transport session identifier, the sequence number of the NAK, and the input interface on which the NAK was received.
ネットワーク要素が受け取ったNAKに応じて、NCFをグループにマルチキャストします。受信した各NAKについて、ネットワーク要素は、輸送セッション識別子、NAKのシーケンス番号、およびNAKを受信した入力インターフェイスを記録する修理状態を作成します。
Constrained NAK Forwarding
制約されたNAK転送
Network elements repeatedly unicast forward only the first copy of any NAK they receive to the upstream PGM network element on the distribution path for the TSI until they receive an NCF in response. In addition, they MAY optionally multicast this NAK upstream with TTL of 1.
ネットワーク要素は、TSIの分布パス上の上流のPGMネットワーク要素の最初のコピーのみを繰り返しUnicast Forwardで、NCFを受け取るまでNCFを受け取ります。さらに、彼らはオプションでこのNAK上流を1のTTLでマルチキャストすることができます。
Nota Bene: Once confirmed by an NCF, network elements discard NAK packets; NAKs are NOT retained in network elements beyond this forwarding operation, but state about the reception of them is stored.
Nota Bene：NCFによって確認されると、ネットワーク要素はNAKパケットを破棄します。NAKSは、この転送操作を超えてネットワーク要素に保持されていませんが、それらの受信については保存されています。
NAK Elimination
Nak Elimination
Network elements discard exact duplicates of any NAK for which they already have repair state (i.e., that has been forwarded either by themselves or a neighboring PGM network element), and respond with a matching NCF.
ネットワーク要素は、既に修復状態（つまり、それ自体または隣接するPGMネットワーク要素のいずれかによって転送されている）を既に持っているNAKの正確な複製を破棄し、一致するNCFで応答します。
Constrained RDATA Forwarding
制約付きrdata転送
Network elements use NAKs to maintain repair state consisting of a list of interfaces upon which a given NAK was received, and they forward the corresponding RDATA only on these interfaces.
ネットワーク要素は、NAKを使用して、特定のNAKが受信されたインターフェイスのリストで構成される修理状態を維持し、これらのインターフェイスでのみ対応するrdataを転送します。
NAK Anticipation
Nakの期待
If a network element hears an upstream NCF (i.e., on the upstream interface for the distribution tree for the TSI), it establishes repair state without outgoing interfaces in anticipation of responding to and eliminating duplicates of the NAK that may arrive from downstream.
ネットワーク要素が上流のNCFを聞く場合（つまり、TSIの分布ツリーのアップストリームインターフェイスで）、下流から到着する可能性のあるNAKの重複に応答して排除することを見越して、発信インターフェイスなしで修理状態を確立します。
Before proceeding from the preceding overview to the detail in the subsequent Procedures, this section presents some concepts and definitions that make that detail more intelligible.
前の概要から後続の手順の詳細まで進む前に、このセクションでは、その詳細をよりわかりやすくするいくつかの概念と定義について説明します。
Every PGM packet is identified by a:
すべてのPGMパケットは、次のことによって識別されます。
TSI transport session identifier
TSI輸送セッション識別子
TSIs MUST be globally unique, and only one source at a time may act as the source for a transport session. (Note that repairers do not change the TSI in any RDATA they transmit). TSIs are composed of the concatenation of a globally unique source identifier (GSI) and a source-assigned data-source port.
TSISはグローバルに一意でなければならず、一度に1つのソースのみが輸送セッションのソースとして機能する可能性があります。（修理業者は、送信するrdataでTSIを変更しないことに注意してください）。TSIは、グローバルに一意のソース識別子（GSI）とソースが割り当てられたデータソースポートの連結で構成されています。
Since all PGM packets originated by receivers are in response to PGM packets originated by a source, receivers simply echo the TSI heard from the source in any corresponding packets they originate.
受信機によって起源があるすべてのPGMパケットは、ソースが起源とするPGMパケットに応答しているため、受信機は、彼らが発生する対応するパケットのソースから聞いたTSIが単にエコーするだけです。
Since all PGM packets originated by network elements are in response to PGM packets originated by a receiver, network elements simply echo the TSI heard from the receiver in any corresponding packets they originate.
ネットワーク要素によって起源があるすべてのPGMパケットは、受信機が起源するPGMパケットに応答しているため、ネットワーク要素は、それらが発生する対応するパケットで受信機から聞いたTSIが単にエコーするだけです。
PGM uses a circular sequence number space from 0 through ((2**32) - 1) to identify and order ODATA packets. Sources MUST number ODATA packets in unit increments in the order in which the corresponding application data is submitted for transmission. Within a transmit or receive window (defined below), a sequence number x is "less" or "older" than sequence number y if it numbers an ODATA packet preceding ODATA packet y, and a sequence number y is "greater" or "more recent" than sequence number x if it numbers an ODATA packet subsequent to ODATA packet x.
PGMは、0から（（2 ** 32）-1）の円形シーケンス番号スペースを使用して、ODATAパケットを識別および順序付けします。ソースは、対応するアプリケーションデータが送信用に送信される順序で、ユニットの増分でODATAパケットを番号にする必要があります。送信または受信ウィンドウ内（以下に定義）内で、シーケンス番号xは、odataパケットyの前にodataパケットを数字し、シーケンス番号yが「大きい」または「より多く」を番号で数字する場合、シーケンス番号yよりも「少ない」または「古い」です。最近の「シーケンス番号xよりも、odataパケットxに続いてodataパケットを番号付けする場合。
The description of the operation of PGM rests fundamentally on the definition of the source-maintained transmit window. This definition in turn is derived directly from the amount of transmitted data (in seconds) a source retains for repair (TXW_SECS), and the maximum transmit rate (in bytes/second) maintained by a source to regulate its bandwidth utilization (TXW_MAX_RTE).
PGMの操作の説明は、ソースメンテナンスされた送信ウィンドウの定義に基本的にかかっています。この定義は、送信されたデータの量（数秒）から直接導き出されます。ソースは修復（TXW_SECS）のために保持され、帯域幅の利用を調節するためにソースによって維持される最大送信速度（TXW_MAX_RTE）です。
In terms of sequence numbers, the transmit window is the range of sequence numbers consumed by the source for sequentially numbering and transmitting the most recent TXW_SECS of ODATA packets. The trailing (or left) edge of the transmit window (TXW_TRAIL) is defined as the sequence number of the oldest data packet available for repair from a source. The leading (or right) edge of the transmit window (TXW_LEAD) is defined as the sequence number of the most recent data packet a source has transmitted.
シーケンス番号の観点から、送信ウィンドウは、Odataパケットの最新のTXW_SECを順次番号付けおよび送信するためにソースによって消費されるシーケンス番号の範囲です。送信ウィンドウ（TXW_TRAIL）の末尾（または左）は、ソースから修理できる最古のデータパケットのシーケンス番号として定義されます。送信ウィンドウ（TXW_LEAD）の主要な（または右）エッジは、ソースが送信した最新のデータパケットのシーケンス番号として定義されます。
The size of the transmit window in sequence numbers (TXW_SQNS) (i.e., the difference between the leading and trailing edges plus one) MUST be no greater than half the PGM sequence number space less one.
シーケンス番号（TXW_SQNS）の送信ウィンドウのサイズ（つまり、先行エッジとトレーリングエッジ1の差）は、PGMシーケンス番号スペースの半分以下でなければなりません。
When TXW_TRAIL is equal to TXW_LEAD, the transmit window size is one. When TXW_TRAIL is equal to TXW_LEAD plus one, the transmit window size is empty.
TXW_TRAILがTXW_LEADに等しい場合、送信ウィンドウサイズは1つです。TXW_TRAILがTXW_Lead Plus 1に等しい場合、送信ウィンドウサイズは空です。
The receive window at the receivers is determined entirely by PGM packets from the source. That is, a receiver simply obeys what the source tells it in terms of window state and advancement.
受信機の受信ウィンドウは、ソースからのPGMパケットによって完全に決定されます。つまり、レシーバーは、ソースがウィンドウの状態と進歩の観点からそれを伝えることに従うだけです。
For a given transport session identified by a TSI, a receiver maintains:
TSIによって識別された特定の輸送セッションについて、受信者は次のことを維持します。
RXW_TRAIL the sequence number defining the trailing edge of the receive window, the sequence number (known from data packets and SPMs) of the oldest data packet available for repair from the source
RXW_TRAIL受信ウィンドウのトレーリングエッジを定義するシーケンス番号、ソースから修理できる最古のデータパケットのシーケンス番号（データパケットとSPMSから知られています）
RXW_LEAD the sequence number defining the leading edge of the receive window, the greatest sequence number of any received data packet within the transmit window
RXW_LEAD受信ウィンドウの最先端を定義するシーケンス番号、送信ウィンドウ内の受信したデータパケットの最大シーケンス番号
The receive window is the range of sequence numbers a receiver is expected to use to identify receivable ODATA.
受信ウィンドウは、受信者が受信可能odataを識別するために使用するシーケンス番号の範囲です。
A data packet is described as being "in" the receive window if its sequence number is in the receive window.
データパケットは、そのシーケンス番号が受信ウィンドウ内にある場合、受信ウィンドウに「内」であると説明されています。
The receive window is advanced by the receiver when it receives an SPM or ODATA packet within the transmit window that increments RXW_TRAIL. Receivers also advance their receive windows upon receipt of any PGM data packet within the receive window that advances the receive window.
受信ウィンドウは、RXW_TRAILを増加させる送信ウィンドウ内のSPMまたはODATAパケットを受信すると、受信機によって進められます。また、受信者は、受信ウィンドウ内のPGMデータパケットを受信したウィンドウ内のWindowを受信すると、受信ウィンドウを受信します。
To establish the repair state required to constrain RDATA, it's essential that NAKs return from a receiver to a source on the reverse of the distribution tree from the source. That is, they must return through the same sequence of PGM network elements through which the ODATA was forwarded, but in reverse. There are two reasons for this, the less obvious one being by far the more important.
RDATAを制約するために必要な修理状態を確立するには、NAKSがソースから配布ツリーの逆のソースにレシーバーからソースに戻ることが不可欠です。つまり、Odataが転送されたが逆に、同じPGMネットワーク要素のシーケンスを介して戻る必要があります。これには2つの理由がありますが、それほど明白ではないほど重要ではありません。
The first and obvious reason is that RDATA is forwarded on the same path as ODATA and so repair state must be established on this path if it is to constrain the propagation of RDATA.
最初の明白な理由は、rdataがOdataと同じ経路に転送されるため、Rdataの伝播を制約するためには、この経路に修復状態を確立する必要があることです。
The second and less obvious reason is that in the absence of repair state, PGM network elements do NOT forward RDATA, so the default behavior is to discard repairs. If repair state is not properly established for interfaces on which ODATA went missing, then receivers on those interfaces will continue to NAK for lost data and ultimately experience unrecoverable data loss.
2番目でそれほど明白な理由は、修理状態がない場合、PGMネットワーク要素がRDATAを転送しないため、デフォルトの動作は修理を破棄することであるためです。ODATAが行方不明になったインターフェイスに対して修復状態が適切に確立されていない場合、それらのインターフェイスの受信機は、データの損失のためにnakを継続し、最終的に回復できないデータ損失を経験します。
The principle function of SPMs is to provide the source path state required for PGM network elements to forward NAKs from one PGM network element to the next on the reverse of the distribution tree for the TSI, establishing repair state each step of the way. This source path state is simply the address of the upstream PGM network element on the reverse of the distribution tree for the TSI. That upstream PGM network element may be more than one subnet hop away. SPMs establish the identity of the upstream PGM network element on the distribution tree for each TSI in each group in each PGM network element, a sort of virtual PGM topology. So although NAKs are unicast addressed, they are NOT unicast routed by PGM network elements in the conventional sense. Instead PGM network elements use the source path state established by SPMs to direct NAKs PGM-hop-by-PGM-hop toward the source. The idea is to constrain NAKs to the pure PGM topology spanning the more heterogeneous underlying topology of both PGM and non-PGM network elements.
SPMSの主な関数は、PGMネットワーク要素に必要なソースパス状態を提供して、TSIの分布ツリーの逆にあるPGMネットワーク要素から次のNAKを転送し、修理状態を確立します。このソースパス状態は、単にTSIの分布ツリーの逆にある上流のPGMネットワーク要素のアドレスです。そのアップストリームPGMネットワーク要素は、複数のサブネットホップアウェイになる可能性があります。SPMは、各PGMネットワーク要素の各グループの各TSIの分布ツリーに上流のPGMネットワーク要素のIDを確立します。これは、仮想PGMトポロジの一種です。したがって、NAKはユニキャストに対処されていますが、従来の意味でPGMネットワーク要素によってルーティングされているユニキャストではありません。代わりに、PGMネットワーク要素は、SPMSによって確立されたソースパス状態を使用して、NAKS PGM-HOP-BY-PGM-HOPをソースに向けます。アイデアは、PGMネットワーク要素と非PGMネットワーク要素の両方のより不均一な根本トポロジにまたがる純粋なPGMトポロジーにNAKを制限することです。
The result is repair state in every PGM network element between the receiver and the source so that the corresponding RDATA is never discarded by a PGM network element for lack of repair state.
その結果、受信機とソースの間のすべてのPGMネットワーク要素に修復状態が生じ、対応するRDATAが修理状態がないためにPGMネットワーク要素によって廃棄されることはありません。
SPMs also maintain transmit window state in receivers by advertising the trailing and leading edges of the transmit window (SPM_TRAIL and SPM_LEAD). In the absence of data, SPMs MAY be used to close the transmit window in time by advancing the transmit window until SPM_TRAIL is equal to SPM_LEAD plus one.
また、SPMは、送信ウィンドウ（SPM_TRAILおよびSPM_LEAD）の後続のエッジを宣伝することにより、受信機の送信ウィンドウ状態を維持します。データがない場合、SPM_Lead Plusに等しくなるまで送信ウィンドウを進めることにより、SPMSを使用して送信ウィンドウを閉じることができます。
This section just provides enough short-hand to make the Procedures intelligible. For the full details of packet contents, please refer to Packet Formats below.
このセクションでは、手順をわかりやすくするのに十分な短い手を提供します。パケットコンテンツの詳細については、以下のパケット形式を参照してください。
SPMs are transmitted by sources to establish source-path state in PGM network elements, and to provide transmit-window state in receivers.
SPMはソースによって送信され、PGMネットワーク要素にソースパス状態を確立し、受信機に送信ウィンドウ状態を提供します。
SPMs are multicast to the group and contain:
SPMはグループにマルチキャストであり、含まれています。
SPM_TSI the source-assigned TSI for the session to which the SPM corresponds
SPM_TSI SPMが対応するセッションのソース割り当てTSI
SPM_SQN a sequence number assigned sequentially by the source in unit increments and scoped by SPM_TSI
SPM_SQNユニットの増分でソースによって順次割り当てられ、SPM_TSIによってスコープされたシーケンス番号
Nota Bene: this is an entirely separate sequence than is used to number ODATA and RDATA.
Nota Bene：これは、Odataとrdataの番号を付けるために使用されるよりも完全に別々のシーケンスです。
SPM_TRAIL the sequence number defining the trailing edge of the source's transmit window (TXW_TRAIL)
SPM_TRAILソースの送信ウィンドウ（TXW_TRAIL）の後縁を定義するシーケンス番号
SPM_LEAD the sequence number defining the leading edge of the source's transmit window (TXW_LEAD)
SPM_LEADソースの送信ウィンドウの最先端を定義するシーケンス番号（TXW_LEAD）
SPM_PATH the network-layer address (NLA) of the interface on the PGM network element on which the SPM is forwarded
SPM_PATH SPMが転送されるPGMネットワーク要素のインターフェイスのネットワーク層アドレス（NLA）
ODATA packets are transmitted by sources to send application data to receivers.
ODATAパケットはソースによって送信され、アプリケーションデータを受信機に送信します。
ODATA packets are multicast to the group and contain:
Odataパケットはグループにマルチキャストであり、
OD_TSI the globally unique source-assigned TSI
OD_TSIグローバルにユニークなソース割り当てTSI
OD_TRAIL the sequence number defining the trailing edge of the source's transmit window (TXW_TRAIL)
OD_TRAILソースの送信ウィンドウ（TXW_TRAIL）の後縁を定義するシーケンス番号
OD_TRAIL makes the protocol more robust in the face of lost SPMs. By including the trailing edge of the transmit window on every data packet, receivers that have missed any SPMs that advanced the transmit window can still detect the case, recover the application, and potentially re-synchronize to the transport session.
OD_TRAILは、失われたSPMSに直面してプロトコルをより堅牢にします。すべてのデータパケットに送信ウィンドウの後縁を含めることにより、送信ウィンドウを進めたSPMSを見逃したレシーバーは、ケースを検出し、アプリケーションを回復し、潜在的に輸送セッションに再同期する可能性があります。
OD_SQN a sequence number assigned sequentially by the source in unit increments and scoped by OD_TSI
OD_SQNユニットの増分でソースによって順次割り当てられ、OD_TSIによってスコープされたシーケンス番号
RDATA packets are repair packets transmitted by sources or DLRs in response to NAKs.
RDATAパケットは、NAKに応じてソースまたはDLRによって送信される修理パケットです。
RDATA packets are multicast to the group and contain:
rdataパケットはグループにマルチキャストであり、
RD_TSI OD_TSI of the ODATA packet for which this is a repair
これが修理であるodataパケットのrd_tsi od_tsi
RD_TRAIL the sequence number defining the trailing edge of the source's transmit window (TXW_TRAIL). This is updated to the most current value when the repair is sent, so it is not necessarily the same as OD_TRAIL of the ODATA packet for which this is a repair
RD_TRAILソースの送信ウィンドウ（TXW_TRAIL）の後縁を定義するシーケンス番号。これは、修理が送信されたときに最新の値に更新されるため、これが修理であるODATAパケットのOD_TRAILと必ずしも同じではありません
RD_SQN OD_SQN of the ODATA packet for which this is a repair
これが修理であるodataパケットのrd_sqn od_sqn
NAKs are transmitted by receivers to request repairs for missing data packets.
NAKSは、欠落データパケットの修理を要求するために受信機によって送信されます。
NAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:
NAKSはソースへのユニキャスト（PGM-HOP-BY-PGM-HOP）であり、
NAK_TSI OD_TSI of the ODATA packet for which a repair is requested
修理が要求されるodataパケットのnak_tsi od_tsi
NAK_SQN OD_SQN of the ODATA packet for which a repair is requested
修理が要求されるodataパケットのnak_sqn od_sqn
NAK_SRC the unicast NLA of the original source of the missing ODATA.
NAK_SRC欠落しているODATAの元のソースのユニキャストNLA。
NAK_GRP the multicast group NLA
Nak_grpマルチキャストグループNLA
NNAKs are transmitted by a DLR that receives NAKs redirected to it by either receivers or network elements to provide flow-control feed-back to a source.
NNAKは、レシーバーまたはネットワーク要素によってリダイレクトされたNAKを受信するDLRによって送信され、ソースにフローコントロールフィードバックを提供します。
NNAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:
NNAKはソースにUnicast（PGM-Hop-by-PGM-Hop）であり、
NNAK_TSI NAK_TSI of the corresponding re-directed NAK.
NNAK_TSI NAK_TSI対応するリダイレクトNAKのNAK_TSI。
NNAK_SQN NAK_SQN of the corresponding re-directed NAK.
NNAK_SQN NAK_SQN対応する再指向NAKのNAK_SQN。
NNAK_SRC NAK_SRC of the corresponding re-directed NAK.
対応するリダイレクトNAKのNNAK_SRC NAK_SRC。
NNAK_GRP NAK_GRP of the corresponding re-directed NAK.
対応するリダイレクトNAKのNNAK_GRP NAK_GRP。
NCFs are transmitted by network elements and sources in response to NAKs.
NCFは、NAKに応じてネットワーク要素とソースによって送信されます。
NCFs are multicast to the group and contain:
NCFはグループにマルチキャストであり、
NCF_TSI NAK_TSI of the NAK being confirmed
NAKのNCF_TSI NAK_TSIが確認されています
NCF_SQN NAK_SQN of the NAK being confirmed
NAKのNCF_SQN NAK_SQNが確認されています
NCF_SRC NAK_SRC of the NAK being confirmed
NAKのNCF_SRC NAK_SRCが確認されています
NCF_GRP NAK_GRP of the NAK being confirmed
NAKのNCF_GRP NAK_GRPが確認されています
OPT_LENGTH 0x00 - Option's Length
opt_length 0x00-オプションの長さ
OPT_FRAGMENT 0x01 - Fragmentation
opt_fragment 0x01-断片化
OPT_NAK_LIST 0x02 - List of NAK entries
opt_nak_list 0x02 -nakエントリのリスト
OPT_JOIN 0x03 - Late Joining
opt_join 0x03-遅い結合
OPT_REDIRECT 0x07 - Redirect
opt_redirect 0x07-リダイレクト
OPT_SYN 0x0D - Synchronization
opt_syn 0x0d-同期
OPT_FIN 0x0E - Session Fin receivers, conventional feedbackish
opt_fin 0x0e-セッションフィンレシーバー、従来のフィードバック
OPT_RST 0x0F - Session Reset
OPT_RST 0x0F-セッションリセット
OPT_PARITY_PRM 0x08 - Forward Error Correction Parameters
opt_parity_prm 0x08-フォワードエラー補正パラメーター
OPT_PARITY_GRP 0x09 - Forward Error Correction Group Number
opt_parity_grp 0x09-フォワードエラー補正グループ番号
OPT_CURR_TGSIZE 0x0A - Forward Error Correction Group Size
opt_curr_tgsize 0x0a-フォワードエラー補正グループサイズ
OPT_CR 0x10 - Congestion Report
OPT_CR 0x10-混雑レポート
OPT_CRQST 0x11 - Congestion Report Request
opt_crqst 0x11-混雑レポートリクエスト
OPT_NAK_BO_IVL 0x04 - NAK Back-Off Interval
opt_nak_bo_ivl 0x04 -nakバックオフ間隔
OPT_NAK_BO_RNG 0x05 - NAK Back-Off Range
opt_nak_bo_rng 0x05 -nakバックオフ範囲
OPT_NBR_UNREACH 0x0B - Neighbor Unreachable
opt_nbr_unreach 0x0b-隣人が到達できない
OPT_PATH_NLA 0x0C - Path NLA
opt_path_nla 0x0c -path nla
OPT_INVALID 0x7F - Option invalidated
opt_invalid 0x7f-オプションが無効です
Since SPMs, NCFs, and RDATA must be treated conditionally by PGM network elements, they must be distinguished from other packets in the chosen multicast network protocol if PGM network elements are to extract them from the usual switching path.
PGMネットワーク要素が通常のスイッチングパスからそれらを抽出する場合、SPM、NCF、およびRDATAはPGMネットワーク要素によって条件付きで扱われる必要があるため、選択したマルチキャストネットワークプロトコルの他のパケットと区別する必要があります。
The most obvious way for network elements to achieve this is to examine every packet in the network for the PGM transport protocol and packet types. However, the overhead of this approach is costly for high-performance, multi-protocol network elements. An alternative, and a requirement for PGM over IP multicast, is that SPMs, NCFs, and RDATA MUST be transmitted with the IP Router Alert Option [6]. This option gives network elements a network-layer indication that a packet should be extracted from IP switching for more detailed processing.
ネットワーク要素がこれを達成するための最も明白な方法は、PGM輸送プロトコルとパケットタイプのネットワーク内のすべてのパケットを調べることです。ただし、このアプローチのオーバーヘッドは、高性能のマルチプロトコルネットワーク要素に費用がかかります。IPマルチキャストを介したPGMの代替案および要件は、SPM、NCFS、およびRDATAをIPルーターアラートオプション[6]で送信する必要があることです。このオプションは、ネットワーク要素に、より詳細な処理のためにIPスイッチングからパケットを抽出する必要があることをネットワーク層の表示を提供します。
Since PGM relies on a purely rate-limited transmission strategy in the source to bound the bandwidth consumed by PGM transport sessions, an assortment of techniques is assembled here to make that strategy as conservative and robust as possible. These techniques are the minimum REQUIRED of a PGM source.
PGMは、PGM輸送セッションで消費される帯域幅をバインドするために、ソース内の純粋な料金制限送信戦略に依存しているため、この戦略を可能な限り保守的で堅牢なものにするために、さまざまなテクニックがここに組み立てられます。これらの手法は、PGMソースに必要な最小限です。
A source MUST number ODATA packets in the order in which they are submitted for transmission by the application. A source MUST transmit ODATA packets in sequence and only within the transmit window beginning with TXW_TRAIL at no greater a rate than TXW_MAX_RTE.
ソースは、アプリケーションによって送信用に提出される順序でOdataパケットを番号にする必要があります。ソースは、odataパケットを順番に送信する必要があり、txw_max_rteよりも大きなレートでtxw_trailから始まる送信ウィンドウ内でのみです。
TXW_MAX_RTE is typically the maximum cumulative transmit rate of SPM, ODATA, and RDATA. Different transmission strategies MAY define TXW_MAX_RTE as appropriate for the implementation.
TXW_MAX_RTEは、通常、SPM、ODATA、およびRDATAの最大累積送信率です。さまざまな伝送戦略では、実装に適したTXW_MAX_RTEを定義する場合があります。
To regulate its transmit rate, a source MUST use a token bucket scheme or any other traffic management scheme that yields equivalent behavior. A token bucket [7] is characterized by a continually sustainable data rate (the token rate) and the extent to which the data rate may exceed the token rate for short periods of time (the token bucket size). Over any arbitrarily chosen interval, the number of bytes the source may transmit MUST NOT exceed the token bucket size plus the product of the token rate and the chosen interval.
送信率を調整するには、ソースはトークンバケットスキームまたは同等の動作を生成するその他のトラフィック管理スキームを使用する必要があります。トークンバケット[7]は、継続的に持続可能なデータレート（トークンレート）と、データレートが短期間（トークンバケットサイズ）のトークンレートを超える範囲によって特徴付けられます。任意に選択された間隔で、ソースが送信できるバイト数とトークンバケットサイズとトークンレートの積と選択された間隔を超えてはなりません。
In addition, a source MUST bound the maximum rate at which successive packets may be transmitted using a leaky bucket scheme drained at a maximum transmit rate, or equivalent mechanism.
さらに、ソースは、最大送信速度または同等のメカニズムで排出される漏れやすいバケットスキームを使用して、連続したパケットを送信できる最大速度を拘束する必要があります。
To preserve the logic of PGM's transmit window, a source MUST strictly prioritize sending of pending NCFs first, pending SPMs second, and only send ODATA or RDATA when no NCFs or SPMs are pending. The priority of RDATA versus ODATA is application dependent. The sender MAY implement weighted bandwidth sharing between RDATA and ODATA. Note that strict prioritization of RDATA over ODATA may stall progress of ODATA if there are receivers that keep generating NAKs so as to always have RDATA pending (e.g. a steady stream of late joiners with OPT_JOIN). Strictly prioritizing ODATA over RDATA may lead to a larger portion of receivers getting unrecoverable losses.
PGMの送信ウィンドウのロジックを保持するには、ソースは、最初に保留中のNCFの送信を厳密に優先順位付けする必要があります。rdataとodataの優先順位は、アプリケーションに依存します。送信者は、rdataとodataの間で加重帯域幅共有を実装できます。ODATAよりもRDATAの厳密な優先順位付けは、常にrdataが保留中のNAKを生成し続けるレシーバーがある場合、ODATAの進行を停止する可能性があることに注意してください（たとえば、OPT_JOINで後期ジョイナーの安定したストリーム）。RDATAよりもODATAを厳密に優先順位付けすると、レシーバーの大部分が回復できない損失を得る可能性があります。
Interleaved with ODATA and RDATA, a source MUST transmit SPMs at a rate at least sufficient to maintain current source path state in PGM network elements. Note that source path state in network elements does not track underlying changes in the distribution tree from a source until an SPM traverses the altered distribution tree. The consequence is that NAKs may go unconfirmed both at receivers and amongst network elements while changes in the underlying distribution tree take place.
OdataとRdataとインターリーブして、ソースは、PGMネットワーク要素で現在のソースパス状態を維持するのに少なくとも十分な速度でSPMを送信する必要があります。ネットワーク要素のソースパス状態は、SPMが変更された分布ツリーを通過するまで、ソースから分布ツリーの根本的な変更を追跡しないことに注意してください。その結果、NAKはレシーバーとネットワーク要素の両方で未確認になり、基礎となる配布ツリーの変更が行われます。
In the absence of data to transmit, a source SHOULD transmit SPMs at a decaying rate in order to assist early detection of lost data, to maintain current source path state in PGM network elements, and to maintain current receive window state in the receivers.
送信するデータがない場合、ソースは、失われたデータの早期検出を支援し、PGMネットワーク要素の現在のソースパス状態を維持し、受信機の現在の受信ウィンドウ状態を維持するために、減衰速度でSPMを送信する必要があります。
In this scheme [8], a source maintains an inter-heartbeat timer IHB_TMR which times the interval between the most recent packet (ODATA, RDATA, or SPM) transmission and the next heartbeat transmission. IHB_TMR is initialized to a minimum interval IHB_MIN after the transmission of any data packet. If IHB_TMR expires, the source transmits a heartbeat SPM and initializes IHB_TMR to double its previous value. The transmission of consecutive heartbeat SPMs doubles IHB each time up to a maximum interval IHB_MAX. The transmission of any data packet initializes IHB_TMR to IHB_MIN once again. The effect is to provoke prompt detection of missing packets in the absence of data to transmit, and to do so with minimal bandwidth overhead.
このスキーム[8]では、ソースは、最新のパケット（ODATA、RDATA、またはSPM）伝送と次のハートビート伝送の間隔を測定する頻度のあるハートビートタイマーIHB_TMRを維持しています。IHB_TMRは、データパケットの送信後に最小間隔IHB_MINに初期化されます。IHB_TMRが期限切れになった場合、ソースはハートビートSPMを送信し、IHB_TMRを初期化して以前の値を2倍にします。連続したハートビートSPMの送信は、最大間隔IHB_MAXまでの毎回IHBを2倍にします。データパケットの送信は、IHB_TMRをIHB_MINに再び初期化します。効果は、送信するデータがない場合に欠落したパケットの迅速な検出を引き起こし、最小限の帯域幅のオーバーヘッドでそれを行うことです。
Ambient and heartbeat SPMs are described as driven by separate timers in this specification to highlight their contrasting functions. Ambient SPMs are driven by a count-down timer that expires regularly while heartbeat SPMs are driven by a count-down timer that keeps being reset by data, and the interval of which changes once it begins to expire. The ambient SPM timer is just counting down in real-time while the heartbeat timer is measuring the inter-data-packet interval.
アンビエントとハートビートSPMは、この仕様の別々のタイマーによって駆動され、対照的な機能を強調すると説明されています。アンビエントSPMは、定期的に期限切れになるカウントダウンタイマーによって駆動されますが、ハートビートSPMはデータによってリセットされ続けるカウントダウンタイマーによって駆動され、その間隔は期限切れになると変化します。Ambient SPMタイマーは、ハートビートタイマーがDATAパケット間隔を測定している間、リアルタイムでカウントダウンしています。
In the presence of data, no heartbeat SPMs will be transmitted since the transmission of data keeps setting the IHB_TMR back to its initial value. At the same time however, ambient SPMs MUST be interleaved into the data as a matter of course, not necessarily as a heartbeat mechanism. This ambient transmission of SPMs is REQUIRED to keep the distribution tree information in the network current and to allow new receivers to synchronize with the session.
データの存在下では、データの送信によりIHB_TMRを初期値に戻し続けるため、ハートビートSPMは送信されません。ただし、同時に、必ずしもハートビートメカニズムとしてではなく、当然のことながら、アンビエントSPMをデータにインターリーズする必要があります。このSPMの周囲の送信は、ネットワークの電流内の配布ツリー情報を保持し、新しい受信機がセッションと同期できるようにするために必要です。
An implementation SHOULD de-couple ambient and heartbeat SPM timers sufficiently to permit them to be configured independently of each other.
実装では、アンビエントとハートビートのSPMタイマーを十分に配分して、互いに独立して構成できるようにする必要があります。
A source MUST immediately multicast an NCF in response to any NAK it receives. The NCF is REQUIRED since the alternative of responding immediately with RDATA would not allow other PGM network elements on the same subnet to do NAK anticipation, nor would it allow DLRs on the same subnet to provide repairs. A source SHOULD be able to detect a NAK storm and adopt countermeasure to protect the network against a denial of service. A possible countermeasure is to send the first NCF immediately in response to a NAK and then delay the generation of further NCFs (for identical NAKs) by a small interval, so that identical NCFs are rate-limited, without affecting the ability to suppress NAKs.
ソースは、受信するNAKに応じてNCFを直ちにマルチキャストする必要があります。NCFは、RDATAで直ちに応答する代替手段では、同じサブネット上の他のPGMネットワーク要素がNAKの予想を実行できないため、同じサブネットのDLRが修理を提供することも許可されていないためです。ソースは、NAKストームを検出し、サービスの拒否からネットワークを保護するために対策を採用できる必要があります。考えられる対策は、NAKに応答して最初のNCFを直ちに送信し、その後、NAKを抑制する能力に影響を与えることなく、同一のNCFがレート制限されるように、さらにNCFの生成（同一のNAK）を小さな間隔で遅らせることです。
After multicasting an NCF in response to a NAK, a source MUST then multicast RDATA (while respecting TXW_MAX_RTE) in response to any NAK it receives for data packets within the transmit window.
NAKに応じてNCFをマルチリキャストした後、ソースは、送信ウィンドウ内のデータパケットに対して受信するNAKに応答して、TXW_MAX_RTEを尊重しながら）をマルチキャストRDATA（TXW_MAX_RTEを尊重しながら）する必要があります。
In the interest of increasing the efficiency of a particular RDATA packet, a source MAY delay RDATA transmission to accommodate the arrival of NAKs from the whole loss neighborhood. This delay SHOULD not exceed twice the greatest propagation delay in the loss neighborhood.
特定のRDATAパケットの効率を高めるために、ソースはRDATA伝送を遅らせて、損失近隣全体からのNAKの到着に対応する場合があります。この遅延は、損失近隣の最大の伝播遅延を2倍超えてはなりません。
Initial data reception
初期データ受信
A receiver SHOULD initiate data reception beginning with the first data packet it receives within the advertised transmit window. This packet's sequence number (ODATA_SQN) temporarily defines the trailing edge of the transmit window from the receiver's perspective. That is, it is assigned to RXW_TRAIL_INIT within the receiver, and until the trailing edge sequence number advertised in subsequent packets (SPMs or ODATA or RDATA) increments past RXW_TRAIL_INIT, the receiver MUST only request repairs for sequence numbers subsequent to RXW_TRAIL_INIT. Thereafter, it MAY request repairs anywhere in the transmit window. This temporary restriction on repair requests prevents receivers from requesting a potentially large amount of history when they first begin to receive a given PGM transport session.
受信者は、広告送信ウィンドウ内で受信した最初のデータパケットから始まるデータ受信を開始する必要があります。このパケットのシーケンス番号（ODATA_SQN）は、受信者の視点から送信ウィンドウの後縁を一時的に定義します。つまり、レシーバー内のRXW_TRAIL_INITに割り当てられ、後続のパケット（SPMSまたはODATAまたはRDATA）で宣伝されているトレーリングエッジシーケンス番号がRXW_TRAIL_INITを過ぎて増加するまで、RXW_TRAIL_INITに続くシーケンス番号の修理のみを要求する必要があります。その後、送信ウィンドウのどこにでも修理を要求する場合があります。修理リクエストのこの一時的な制限により、受信者は、特定のPGM輸送セッションの受信を開始したときに、潜在的に大量の履歴を要求することができなくなります。
Note that the JOIN option, discussed later, MAY be used to provide a different value for RXW_TRAIL_INIT.
後で説明する結合オプションは、RXW_TRAIL_INITに異なる値を提供するために使用できることに注意してください。
Receiving and discarding data packets
データパケットの受信と破棄
Within a given transport session, a receiver MUST accept any ODATA or RDATA packets within the receive window. A receiver MUST discard any data packet that duplicates one already received in the transmit window. A receiver MUST discard any data packet outside of the receive window.
特定のトランスポートセッション内で、受信者は受信ウィンドウ内のODATAまたはRDATAパケットを受け入れる必要があります。受信者は、送信ウィンドウですでに受信したものを複製するデータパケットを破棄する必要があります。受信者は、受信ウィンドウの外側のデータパケットを破棄する必要があります。
Contiguous data
隣接するデータ
Contiguous data is comprised of those data packets within the receive window that have been received and are in the range from RXW_TRAIL up to (but not including) the first missing sequence number in the receive window. The most recently received data packet of contiguous data defines the leading edge of contiguous data.
隣接するデータは、受信されたウィンドウ内のこれらのデータパケットで構成され、RXW_TRAILから受信ウィンドウの最初の欠落シーケンス番号まで（ただし含まない）範囲にあります。連続データの最近受け取ったデータパケットは、隣接するデータの最先端を定義します。
As its default mode of operation, a receiver MUST deliver only contiguous data packets to the application, and it MUST do so in the order defined by those data packets' sequence numbers. This provides applications with a reliable ordered data flow.
デフォルトの操作モードとして、受信者はアプリケーションに連続データパケットのみを配信する必要があり、それらのデータパケットのシーケンス番号で定義された順序でそれを行う必要があります。これにより、アプリケーションが信頼できる順序付けられたデータフローを提供します。
Non contiguous data
非連続データ
PGM receiver implementations MAY optionally provide a mode of operation in which data is delivered to an application in the order received. However, the implementation MUST only deliver complete application protocol data units (APDUs) to the application. That is, APDUs that have been fragmented into different TPDUs MUST be reassembled before delivery to the application.
PGMレシーバーの実装は、オプションで、データが受信された順序でアプリケーションに配信される操作モードを提供する場合があります。ただし、実装では、完全なアプリケーションプロトコルデータユニット（APDU）のみをアプリケーションに配信する必要があります。つまり、異なるTPDUに断片化されたAPDUは、アプリケーションに配信する前に再組み立てする必要があります。
Receivers MUST receive and sequence SPMs for any TSI they are receiving. An SPM is in sequence if its sequence number is greater than that of the most recent in-sequence SPM and within half the PGM number space. Out-of-sequence SPMs MUST be discarded.
受信機は、受信しているTSIに対してSPMを受信し、シーケンスする必要があります。SPMは、そのシーケンス番号が最新のシーケンスSPMのシーケンス数よりも大きく、PGM数スペースの半分以内である場合、SPMは順番にあります。シーケンス外SPMSを破棄する必要があります。
For each TSI, receivers MUST use the most recent SPM to determine the NLA of the upstream PGM network element for use in NAK addressing. A receiver MUST NOT initiate repair requests until it has received at least one SPM for the corresponding TSI.
各TSIについて、受信機は最新のSPMを使用して、NAKアドレス指定で使用するために上流のPGMネットワーク要素のNLAを決定する必要があります。受信者は、対応するTSIに対して少なくとも1つのSPMを受け取るまで修理要求を開始してはなりません。
Since SPMs require per-hop processing, it is likely that they will be forwarded at a slower rate than data, and that they will arrive out of sync with the data stream. In this case, the window information that the SPMs carry will be out of date. Receivers SHOULD expect this to be the case and SHOULD detect it by comparing the packet lead and trail values with the values the receivers have stored for lead and trail. If the SPM packet values are less, they SHOULD be ignored, but the rest of the packet SHOULD be processed as normal.
SPMはホップごとの処理が必要なため、データよりも遅い速度で転送され、データストリームと同期しないように到着する可能性があります。この場合、SPMSが運ぶウィンドウ情報は時代遅れになります。受信機はこれが事実であることを期待する必要があり、パケットリードとトレイルの値をレシーバーがリードとトレイルのために保存した値と比較することにより、それを検出する必要があります。SPMパケット値が少ない場合は無視する必要がありますが、残りのパケットは通常どおり処理する必要があります。
Detecting missing data packets
欠落データパケットの検出
Receivers MUST detect gaps in the expected data sequence in the following manners:
レシーバーは、次のマナーで予想されるデータシーケンスのギャップを検出する必要があります。
by comparing the sequence number on the most recently received ODATA or RDATA packet with the leading edge of contiguous data
最近受信した最近のODATAまたはRDATAパケットのシーケンス番号を、隣接データの最先端と比較することにより
by comparing SPM_LEAD of the most recently received SPM with the leading edge of contiguous data
最近受信したSPMのSPM_LEADを隣接データの最先端と比較することにより
In both cases, if the receiver has not received all intervening data packets, it MAY initiate selective NAK generation for each missing sequence number.
どちらの場合も、受信機が介在するすべてのデータパケットを受信していない場合、欠落している各シーケンス番号の選択的NAK生成を開始する場合があります。
In addition, a receiver may detect a single missing data packet by receiving an NCF or multicast NAK for a data packet within the transmit window which it has not received. In this case it MAY initiate selective NAK generation for the said sequence number.
さらに、受信者は、受信していない送信ウィンドウ内のデータパケットのNCFまたはマルチキャストNAKを受信して、単一の欠落データパケットを検出する場合があります。この場合、上記のシーケンス番号の選択的NAK生成を開始する場合があります。
In all cases, receivers SHOULD temper the initiation of NAK generation to account for simple mis-ordering introduced by the network. A possible mechanism to achieve this is to assume loss only after the reception of N packets with sequence numbers higher than those of the (assumed) lost packets. A possible value for N is 2. This method SHOULD be complemented with a timeout based mechanism that handles the loss of the last packet before a pause in the transmission of the data stream. The leading edge field in SPMs SHOULD also be taken into account in the loss detection algorithm.
すべての場合において、受信機はNAK世代の開始を緩和して、ネットワークによって導入された単純な誤用順を説明する必要があります。これを達成する可能性のあるメカニズムは、（想定されている）紛失したパケットよりも高いシーケンス番号を持つNパケットを受信した後にのみ損失を想定することです。nの可能性のある値は2です。この方法は、データストリームの送信が一時停止する前に最後のパケットの損失を処理するタイムアウトベースのメカニズムで補完する必要があります。SPMSの最先端フィールドも、損失検出アルゴリズムで考慮する必要があります。
Generating NAKs
Naksの生成
NAK generation follows the detection of a missing data packet and is the cycle of:
Nak Generationは、欠落しているデータパケットの検出に従い、次のサイクルです。
waiting for a random period of time (NAK_RB_IVL) while listening for matching NCFs or NAKs
NCFSまたはNAKのマッチングを聞いている間、ランダムな期間（NAK_RB_IVL）を待っています
transmitting a NAK if a matching NCF or NAK is not heard
一致するNCFまたはNAKが聞こえない場合はNAKを送信します
waiting a period (NAK_RPT_IVL) for a matching NCF and recommencing NAK generation if the matching NCF is not received
一致するNCFの期間（NAK_RPT_IVL）を待って、一致するNCFを受信していない場合はNAK生成を推奨します
waiting a period (NAK_RDATA_IVL) for data and recommencing NAK generation if the matching data is not received
データの期間（nak_rdata_ivl）を待機し、一致するデータが受信されない場合はNAK生成を推奨します
The entire generation process can be summarized by the following state machine:
世代全体のプロセスは、次の状態マシンによって要約できます。
|
| detect missing tpdu
| - clear data retry count
| - clear NCF retry count
V
matching NCF |--------------------------|
<---------------| BACK-OFF_STATE | <----------------------
| | start timer(NAK_RB_IVL) | ^ ^
| | | | |
| |--------------------------| | |
| matching | | timer expires | |
| NAK | | - send NAK | |
| | | | |
| V V | |
| |--------------------------| | |
| | WAIT_NCF_STATE | | |
| matching NCF | start timer(NAK_RPT_IVL) | | |
|<--------------| |------------> |
| |--------------------------| timer expires |
| | | ^ - increment NCF |
| NAK_NCF_RETRIES | | | retry count |
| exceeded | | | |
| V ----------- |
| Cancelation matching NAK |
| - restart timer(NAK_RPT_IVL) |
| |
| |
V |--------------------------| |
--------------->| WAIT_DATA_STATE |----------------------->
|start timer(NAK_RDATA_IVL)| timer expires
| | - increment data
|--------------------------| retry count
| | ^
NAK_DATA_RETRIES | | |
exceeded | | |
| -----------
| matching NCF or NAK
V - restart timer(NAK_RDATA_IVL)
Cancellation
In any state, receipt of matching RDATA or ODATA completes data recovery and successful exit from the state machine. State transition stops any running timers.
いずれの州でも、一致するRDATAまたはODATAの受領は、データの回復と状態マシンからの成功した出口を完了します。状態移行は、実行中のタイマーを停止します。
In any state, if the trailing edge of the window moves beyond the sequence number, data recovery for that sequence number terminates.
どの状態でも、ウィンドウの後縁がシーケンス番号を超えて移動する場合、そのシーケンス番号のデータ回復が終了します。
During NAK_RB_IVL a NAK is said to be pending. When awaiting data or an NCF, a NAK is said to be outstanding.
nak_rb_ivlの間、Nakは保留中であると言われています。データまたはNCFを待っているとき、NAKは傑出していると言われています。
Backing off NAK transmission
NAKトランスミッションを後押しします
Before transmitting a NAK, a receiver MUST wait some interval NAK_RB_IVL chosen randomly over some time period NAK_BO_IVL. During this period, receipt of a matching NAK or a matching NCF will suspend NAK generation. NAK_RB_IVL is counted down from the time a missing data packet is detected.
NAKを送信する前に、レシーバーは、ある期間にわたってランダムに選択されたいくつかのインターバルNAK_RB_IVLを待機する必要があります。NAK_BO_IVL。この期間中、一致するNAKまたは一致するNCFの受領はNAK世代を停止します。NAK_RB_IVLは、欠損データパケットが検出された時からカウントダウンされます。
A value for NAK_BO_IVL learned from OPT_NAK_BO_IVL (see 16.4.1 below) MUST NOT be used by a receiver (i.e., the receiver MUST NOT NAK) unless either NAK_BO_IVL_SQN is zero, or the receiver has seen POLL_RND == 0 for POLL_SQN =< NAK_BO_IVL_SQN within half the sequence number space.
OPT_NAK_BO_IVLから学習したNAK_BO_IVLの値（以下16.4.1を参照）は、NAK_BO_IVL_SQNがゼロでない限り、受信者（つまり、受信者はNAKではない）が使用しないでください。シーケンス番号スペースの半分以内。
When a parity NAK (Appendix A, FEC) is being generated, the back-off interval SHOULD be inversely biased with respect to the number of parity packets requested. This way NAKs requesting larger numbers of parity packets are likely to be sent first and thus suppress other NAKs. A NAK for a given transmission group suppresses another NAK for the same transmission group only if it is requesting an equal or larger number of parity packets.
パリティNAK（付録A、FEC）が生成される場合、要求されたパリティパケットの数に関して、バックオフ間隔を反比例して偏っている必要があります。このようにして、より多くのパリティパケットを要求するNAKSが最初に送信される可能性が高いため、他のNAKを抑制します。特定の伝送グループのNAKは、同じ数のパリティパケットを要求している場合にのみ、同じトランスミッショングループの別のNAKを抑制します。
When a receiver has to transmit a sequence of NAKs, it SHOULD transmit the NAKs in order from oldest to most recent.
レシーバーが一連のNAKを送信する必要がある場合、NAKを最古から最新のものに順番に送信する必要があります。
Suspending NAK generation
NAK世代の一時停止
Suspending NAK generation just means waiting for either NAK_RB_IVL, NAK_RPT_IVL or NAK_RDATA_IVL to pass. A receiver MUST suspend NAK generation if a duplicate of the NAK is already pending from this receiver or the NAK is already outstanding from this or another receiver.
NAK世代を停止するということは、NAK_RB_IVL、NAK_RPT_IVL、またはNAK_RDATA_IVLが合格するのを待つことを意味します。NAKの重複がこのレシーバーからすでに保留中である場合、またはNAKがこのまたは別のレシーバーからすでに顕著である場合、受信機はNAK世代を中断する必要があります。
NAK suppression
Nak抑制
A receiver MUST suppress NAK generation and wait at least NAK_RDATA_IVL before recommencing NAK generation if it hears a matching NCF or NAK during NAK_RB_IVL. A matching NCF must match NCF_TSI with NAK_TSI, and NCF_SQN with NAK_SQN.
NAKの生成を抑制し、NAKの生成を推奨する前に、NAK_RDATA_IVLを少なくともNAK_RDATA_IVLを待つ必要があります。一致するNCFは、NCF_TSIとNAK_TSI、NCF_SQNをNAK_SQNと一致させる必要があります。
Transmitting a NAK
Nakを送信します
Upon expiry of NAK_RB_IVL, a receiver MUST unicast a NAK to the upstream PGM network element for the TSI specifying the transport session identifier and missing sequence number. In addition, it MAY multicast a NAK with TTL of 1 to the group, if the PGM parent is not directly connected. It also records both the address of the source of the corresponding ODATA and the address of the group in the NAK header.
NAK_RB_IVLの有効期限は、受信者は、トランスポートセッション識別子と欠落シーケンス番号を指定するTSIの上流のPGMネットワーク要素にNAKをユニカストする必要があります。さらに、PGMの親が直接接続されていない場合、TTLをグループに1のNAKをマルチキャストする場合があります。また、対応するODATAのソースのアドレスとNAKヘッダーのグループのアドレスの両方を記録します。
It MUST repeat the NAK at a rate governed by NAK_RPT_IVL up to NAK_NCF_RETRIES times while waiting for a matching NCF. It MUST then wait NAK_RDATA_IVL before recommencing NAK generation. If it hears a matching NCF or NAK during NAK_RDATA_IVL, it MUST wait anew for NAK_RDATA_IVL before recommencing NAK generation (i.e. matching NCFs and NAKs restart NAK_RDATA_IVL).
NAK_RPT_IVLによって支配された速度でNAKを繰り返す必要があります。Nak Generationを推奨する前に、nak_rdata_ivlを待つ必要があります。NAK_RDATA_IVL中に一致するNCFまたはNAKが聞こえる場合は、NAK生成を推奨する前にNAK_RDATA_IVLを新たに待つ必要があります（つまり、NCFSとNAKS RESTART NAK_RDATA_IVL）。
Completion of NAK generation
NAK世代の完了
NAK generation is complete only upon the receipt of the matching RDATA (or even ODATA) packet at any time during NAK generation.
Nak世代は、NAK世代のいつでも一致するRDATA（またはODATA）パケットを受け取ったときにのみ完了します。
Cancellation of NAK generation
NAK世代のキャンセル
NAK generation is cancelled upon the advancing of the receive window so as to exclude the matching sequence number of a pending or outstanding NAK, or NAK_DATA_RETRIES / NAK_NCF_RETRIES being exceeded. Cancellation of NAK generation indicates unrecoverable data loss.
NAK世代は、保留中または未払いのNAKまたはNAK_DATA_RETRIES / NAK_NCF_RETRIESを超えている一致シーケンス番号を除外するために、受信ウィンドウの進行時にキャンセルされます。NAK世代のキャンセルは、回復できないデータ損失を示します。
Receiving NCFs and multicast NAKs
NCFSおよびマルチキャストNAKを受信します
A receiver MUST discard any NCFs or NAKs it hears for data packets outside the transmit window or for data packets it has received. Otherwise they are treated as appropriate for the current repair state.
受信者は、送信ウィンドウの外側のデータパケットまたは受信したデータパケットについて、聞こえるNCFまたはNAKを破棄する必要があります。それ以外の場合は、現在の修理状態に適しているように扱われます。
Upon receipt of an in-sequence SPM, a network element records the Source Path Address SPM_PATH with the multicast routing information for the TSI. If the receiving network element is on the same subnet as the forwarding network element, this address will be the same as the address of the immediately upstream network element on the distribution tree for the TSI. If, however, non-PGM network elements intervene between the forwarding and the receiving network elements, this address will be the address of the first PGM network element across the intervening network elements.
シーケンスSPMを受け取ると、ネットワーク要素は、TSIのマルチキャストルーティング情報にソースパスアドレスSPM_PATHを記録します。受信ネットワーク要素が転送ネットワーク要素と同じサブネット上にある場合、このアドレスはTSIの分布ツリー上のすぐに上流のネットワーク要素のアドレスと同じになります。ただし、転送と受信ネットワーク要素の間に非PGMネットワーク要素が介入した場合、このアドレスは、介在するネットワーク要素全体の最初のPGMネットワーク要素のアドレスになります。
The network element then forwards the SPM on each outgoing interface for that TSI. As it does so, it encodes the network address of the outgoing interface in SPM_PATH in each copy of the SPM it forwards.
ネットワーク要素は、そのTSIの各発信インターフェイスでSPMを転送します。そうするように、それはそれが転送するSPMの各コピーのSPM_PATHの送信インターフェイスのネットワークアドレスをエンコードします。
Network elements MUST immediately transmit an NCF in response to any unicast NAK they receive. The NCF MUST be multicast to the group on the interface on which the NAK was received.
ネットワーク要素は、受け取ったユニキャストNAKに応じて、すぐにNCFを送信する必要があります。NCFは、NAKが受信されたインターフェイス上のグループにマルチキャストでなければなりません。
Nota Bene: In order to avoid creating multicast routing state for PGM network elements across non-PGM-capable clouds, the network-header source address of NCFs transmitted by network elements MUST be set to the ODATA source's NLA, not the network element's NLA as might be expected.
Nota Bene：非PGM対応クラウドにわたるPGMネットワーク要素のマルチキャストルーティング状態の作成を避けるために、ネットワーク要素によって送信されるNCFSのネットワークヘッダーソースアドレスは、ネットワークソースのNLAに設定する必要があります。予想されるかもしれません。
Network elements should be able to detect a NAK storm and adopt counter-measure to protect the network against a denial of service. A possible countermeasure is to send the first NCF immediately in response to a NAK and then delay the generation of further NCFs (for identical NAKs) by a small interval, so that identical NCFs are rate-limited, without affecting the ability to suppress NAKs.
ネットワーク要素は、NAKストームを検出し、サービスの拒否からネットワークを保護するために対策を採用できるはずです。考えられる対策は、NAKに応答して最初のNCFを直ちに送信し、その後、NAKを抑制する能力に影響を与えることなく、同一のNCFがレート制限されるように、さらにNCFの生成（同一のNAK）を小さな間隔で遅らせることです。
Simultaneously, network elements MUST establish repair state for the NAK if such state does not already exist, and add the interface on which the NAK was received to the corresponding repair interface list if the interface is not already listed.
同時に、ネットワーク要素は、そのような状態がまだ存在しない場合はNAKの修理状態を確立する必要があり、インターフェイスがまだリストされていない場合は、NAKが対応する修復インターフェイスリストにNAKを受信したインターフェイスを追加する必要があります。
The NAK forwarding procedures for network elements are quite similar to those for receivers, but three important differences should be noted.
ネットワーク要素のNAK転送手順は、レシーバーのNAKフォワーディング手順と非常に似ていますが、3つの重要な違いに注意する必要があります。
First, network elements do NOT back off before forwarding a NAK (i.e., there is no NAK_BO_IVL) since the resulting delay of the NAK would compound with each hop. Note that NAK arrivals will be randomized by the receivers from which they originate, and this factor in conjunction with NAK anticipation and elimination will combine to forestall NAK storms on subnets with a dense network element population.
まず、NAKを転送する前にネットワーク要素が後退しません（つまり、NAK_BO_IVLはありません）。NAKの到着は、それらが発生するレシーバーによってランダム化され、NAKの予想と排除と併せてこの要因が組み合わさって、サブネットのNAKストームを密なネットワーク要素集団を囲むことになります。
Second, network elements do NOT retry confirmed NAKs if RDATA is not seen; they simply discard the repair state and rely on receivers to re-request the repair. This approach keeps the repair state in the network elements relatively ephemeral and responsive to underlying routing changes.
第二に、rdataが見られない場合、ネットワーク要素はNAKを再試行しません。彼らは単に修理状態を廃棄し、レシーバーに依存して修理を再追跡します。このアプローチは、ネットワーク要素内の修理状態を比較的短命で、基礎となるルーティングの変更に応答します。
Third, note that ODATA does NOT cancel NAK forwarding in network elements since it is switched by network elements without transport-layer intervention.
第三に、ODATAは、輸送層の介入なしにネットワーク要素によって切り替えられているため、ネットワーク要素のNAK転送をキャンセルしないことに注意してください。
Nota Bene: Once confirmed by an NCF, network elements discard NAK packets; they are NOT retained in network elements beyond this forwarding operation.
Nota Bene：NCFによって確認されると、ネットワーク要素はNAKパケットを破棄します。これらは、この転送操作を超えてネットワーク要素に保持されていません。
NAK forwarding requires that a network element listen to NCFs for the same transport session. NAK forwarding also requires that a network element observe two time out intervals for any given NAK (i.e., per NAK_TSI and NAK_SQN): NAK_RPT_IVL and NAK_RDATA_IVL.
NAK転送では、ネットワーク要素が同じトランスポートセッションでNCFを聴くことを要求します。NAK転送では、ネットワーク要素が特定のNAK（すなわち、NAK_TSIおよびNAK_SQNごと）に対して2つのタイムアウト間隔を観察することも必要です：NAK_RPT_IVLおよびNAK_RDATA_IVL。
The NAK repeat interval NAK_RPT_IVL, limits the length of time for which a network element will repeat a NAK while waiting for a corresponding NCF. NAK_RPT_IVL is counted down from the transmission of a NAK. Expiry of NAK_RPT_IVL cancels NAK forwarding (due to missing NCF).
NAKリピート間隔NAK_RPT_IVLは、対応するNCFを待っている間にネットワーク要素がNAKを繰り返す時間の長さを制限します。Nak_rpt_ivlは、Nakの送信からカウントダウンされます。NAK_RPT_IVLの有効期限は、NAK転送をキャンセルします（NCFが欠落しているため）。
The NAK RDATA interval NAK_RDATA_IVL, limits the length of time for which a network element will wait for the corresponding RDATA. NAK_RDATA_IVL is counted down from the time a matching NCF is received. Expiry of NAK_RDATA_IVL causes the network element to discard the corresponding repair state (due to missing RDATA).
Nak rdata間隔nak_rdata_ivlは、ネットワーク要素が対応するrdataを待機する時間の長さを制限します。NAK_RDATA_IVLは、一致するNCFが受信された時からカウントダウンされます。nak_rdata_ivlの有効期限は、ネットワーク要素が対応する修復状態を破棄します（rdataが欠落しているため）。
During NAK_RPT_IVL, a NAK is said to be pending. During NAK_RDATA_IVL, a NAK is said to be outstanding.
NAK_RPT_IVLの間、NAKは保留中と言われています。nak_rdata_ivlの間、Nakは傑出していると言われています。
A Network element MUST forward NAKs only to the upstream PGM network element for the TSI.
ネットワーク要素は、TSIの上流のPGMネットワーク要素にのみNAKを転送する必要があります。
A network element MUST repeat a NAK at a rate of NAK_RPT_RTE for an interval of NAK_RPT_IVL until it receives a matching NCF. A matching NCF must match NCF_TSI with NAK_TSI, and NCF_SQN with NAK_SQN.
ネットワーク要素は、一致するNCFを受信するまで、NAK_RPT_IVLの間隔に対してNAK_RPT_RTEのレートでNAKを繰り返す必要があります。一致するNCFは、NCF_TSIとNAK_TSI、NCF_SQNをNAK_SQNと一致させる必要があります。
Upon reception of the corresponding NCF, network elements MUST wait at least NAK_RDATA_IVL for the corresponding RDATA. Receipt of the corresponding RDATA at any time during NAK forwarding cancels NAK forwarding and tears down the corresponding repair state in the network element.
対応するNCFを受信すると、ネットワーク要素は、少なくともNAK_RDATA_IVLを対応するRDATAを待つ必要があります。NAK転送中にいつでも対応するRDATAの受領は、NAKの転送をキャンセルし、ネットワーク要素の対応する修理状態を取り壊します。
Two NAKs duplicate each other if they bear the same NAK_TSI and NAK_SQN. Network elements MUST discard all duplicates of a NAK that is pending.
同じNak_tsiとNak_sqnを持つ場合、2つのNAKが互いに複製します。ネットワーク要素は、保留中のNAKのすべての複製を破棄する必要があります。
Once a NAK is outstanding, network elements MUST discard all duplicates of that NAK for NAK_ELIM_IVL. Upon expiry of NAK_ELIM_IVL, network elements MUST suspend NAK elimination for that TSI/SQN until the first duplicate of that NAK is seen after the expiry of NAK_ELIM_IVL. This duplicate MUST be forwarded in the usual manner. Once this duplicate NAK is outstanding, network elements MUST once again discard all duplicates of that NAK for NAK_ELIM_IVL, and so on. NAK_RDATA_IVL MUST be reset each time a NAK for the corresponding TSI/SQN is confirmed (i.e., each time NAK_ELIM_IVL is reset). NAK_ELIM_IVL MUST be some small fraction of NAK_RDATA_IVL.
Nakが傑出していれば、ネットワーク要素は、Nak_elim_ivlのNakのすべての複製を破棄する必要があります。nak_elim_ivlの有効期限が切れば、ネットワーク要素は、Nak_elim_ivlの有効期限の後にそのNakの最初の複製が見られるまで、そのTSI/SQNのNak排除を停止する必要があります。この複製は、通常の方法で転送する必要があります。この重複したNakが傑出していれば、ネットワーク要素は、Nak_elim_ivlなどのNakのすべての複製を再度破棄する必要があります。NAK_RDATA_IVLは、対応するTSI/SQNのNAKが確認されるたびにリセットする必要があります（つまり、NAK_ELIM_IVLがリセットされるたびに）。nak_elim_ivlは、nak_rdata_ivlのわずかな割合でなければなりません。
NAK_ELIM_IVL acts to balance implosion prevention against repair state liveness. That is, it results in the elimination of all but at most one NAK per NAK_ELIM_IVL thereby allowing repeated NAKs to keep the repair state alive in the PGM network elements.
nak_elim_ivlは、再現防止の修復状態の描写とのバランスをとるように行動します。つまり、NAK_ELIM_IVLごとに最大1つのNAKを除いて、すべてのNAKを除くすべてを除去することにより、繰り返されるNAKがPGMネットワーク要素で修復状態を生かし続けることができます。
An unsolicited NCF is one that is received by a network element when the network element has no corresponding pending or outstanding NAK. Network elements MUST process unsolicited NCFs differently depending on the interface on which they are received.
未承諾のNCFは、ネットワーク要素に対応する保留中または未解決のNAKがない場合、ネットワーク要素によって受信されるものです。ネットワーク要素は、受信したインターフェイスに応じて、未承諾のNCFを異なる方法で処理する必要があります。
If the interface on which an NCF is received is the same interface the network element would use to reach the upstream PGM network element, the network element simply establishes repair state for NCF_TSI and NCF_SQN without adding the interface to the repair interface list, and discards the NCF. If the repair state already exists, the network element restarts the NAK_RDATA_IVL and NAK_ELIM_IVL timers and discards the NCF.
NCFが受信されるインターフェイスが同じインターフェイスである場合、ネットワーク要素がアップストリームPGMネットワーク要素に到達するために使用する場合、ネットワーク要素は、修理インターフェイスリストにインターフェイスを追加せずにNCF_TSIおよびNCF_SQNの修理状態を確立し、廃棄します。NCF。修理状態が既に存在する場合、ネットワーク要素はNAK_RDATA_IVLとNAK_ELIM_IVLタイマーを再起動し、NCFを破棄します。
If the interface on which an NCF is received is not the same interface the network element would use to reach the upstream PGM network element, the network element does not establish repair state and just discards the NCF.
NCFが受信されるインターフェイスが同じインターフェイスではない場合、ネットワーク要素が上流のPGMネットワーク要素に到達するために使用する場合、ネットワーク要素は修理状態を確立せず、NCFを破棄します。
Anticipated NAKs permit the elimination of any subsequent matching NAKs from downstream. Upon establishing anticipated repair state, network elements MUST eliminate subsequent NAKs only for a period of NAK_ELIM_IVL. Upon expiry of NAK_ELIM_IVL, network elements MUST suspend NAK elimination for that TSI/SQN until the first duplicate of that NAK is seen after the expiry of NAK_ELIM_IVL. This duplicate MUST be forwarded in the usual manner. Once this duplicate NAK is outstanding, network elements MUST once again discard all duplicates of that NAK for NAK_ELIM_IVL, and so on. NAK_RDATA_IVL MUST be reset each time a NAK for the corresponding TSI/SQN is confirmed (i.e., each time NAK_ELIM_IVL is reset). NAK_ELIM_IVL must be some small fraction of NAK_RDATA_IVL.
予想されるNAKSにより、下流からその後の一致するNAKの排除が可能になります。予想される修復状態を確立すると、ネットワーク要素は、NAK_ELIM_IVLの期間のみ、後続のNAKを排除する必要があります。nak_elim_ivlの有効期限が切れば、ネットワーク要素は、Nak_elim_ivlの有効期限の後にそのNakの最初の複製が見られるまで、そのTSI/SQNのNak排除を停止する必要があります。この複製は、通常の方法で転送する必要があります。この重複したNakが傑出していれば、ネットワーク要素は、Nak_elim_ivlなどのNakのすべての複製を再度破棄する必要があります。NAK_RDATA_IVLは、対応するTSI/SQNのNAKが確認されるたびにリセットする必要があります（つまり、NAK_ELIM_IVLがリセットされるたびに）。nak_elim_ivlは、nak_rdata_ivlのわずかな割合でなければなりません。
Network elements MAY implement local procedures for withholding NAK confirmations for receivers detected to be reporting excessive loss. The result of these procedures would ultimately be unrecoverable data loss in the receiver.
ネットワーク要素は、過度の損失を報告していることが検出された受信機のNAK確認を差し控えるためのローカル手順を実装する場合があります。これらの手順の結果は、最終的に受信者の回復不能なデータ損失になります。
A PGM network element uses the source and group addresses (NLAs) contained in the transport header to find the state for the corresponding TSI, looks up the corresponding upstream PGM network element's address, uses it to re-address the (unicast) NAK, and unicasts it on the upstream interface for the distribution tree for the TSI.
PGMネットワーク要素は、トランスポートヘッダーに含まれるソースおよびグループアドレス（NLA）を使用して対応するTSIの状態を見つけ、対応するアップストリームPGMネットワーク要素のアドレスを調べ、それを使用して（Unicast）Nakを再アドレスし、TSIの配布ツリーの上流インターフェイスでユニキャストします。
Network elements MUST maintain repair state for each interface on which a given NAK is received at least once. Network elements MUST then use this list of interfaces to constrain the forwarding of the corresponding RDATA packet only to those interfaces in the list. An RDATA packet corresponds to a NAK if it matches NAK_TSI and NAK_SQN.
ネットワーク要素は、特定のNAKが少なくとも1回受信される各インターフェイスの修理状態を維持する必要があります。ネットワーク要素は、このインターフェイスのリストを使用して、対応するrdataパケットの転送をリスト内のこれらのインターフェイスにのみ制約する必要があります。rdataパケットは、nak_tsiとnak_sqnと一致する場合、NAKに対応します。
Network elements MUST maintain this repair state only until either the corresponding RDATA is received and forwarded, or NAK_RDATA_IVL passes after forwarding the most recent instance of a given NAK. Thereafter, the corresponding repair state MUST be discarded.
ネットワーク要素は、対応するrdataが受信および転送されるか、特定のNAKの最新のインスタンスを転送した後にnak_rdata_ivlが通過するまでのみ、この修理状態を維持する必要があります。その後、対応する修復状態を破棄する必要があります。
Network elements SHOULD discard and not forward RDATA packets for which they have no repair state. Note that the consequence of this procedure is that, while it constrains repairs to the interested subset of the network, loss of repair state precipitates further NAKs from neglected receivers.
ネットワーク要素は、修理状態がないRDATAパケットを廃棄し、転送する必要はありません。この手順の結果は、ネットワークの関心のあるサブセットの修理を制約している一方で、修復状態の喪失は無視された受信機からさらなるNAKを沈殿させることです。
All of the packet formats described in this section are transport-layer headers that MUST immediately follow the network-layer header in the packet. Only data packet headers (ODATA and RDATA) may be followed in the packet by application data. For each packet type, the network-header source and destination addresses are specified in addition to the format and contents of the transport layer header. Recall from General Procedures that, for PGM over IP multicast, SPMs, NCFs, and RDATA MUST also bear the IP Router Alert Option.
このセクションで説明したすべてのパケット形式は、パケットのネットワーク層ヘッダーをすぐに追跡する必要がある輸送層ヘッダーです。パケットでは、アプリケーションデータがパケットに従うことができます。各パケットタイプについて、輸送層ヘッダーの形式と内容に加えて、ネットワークヘッダーソースと宛先アドレスが指定されています。IPマルチキャストを超えるPGMの場合、SPMS、NCFS、およびRDATAもIPルーターアラートオプションを担当する必要がある一般的な手順を思い出してください。
For PGM over IP, the IP protocol number is 113.
IP上のPGMの場合、IPプロトコル番号は113です。
In all packets the descriptions of Data-Source Port, Data-Destination Port, Type, Options, Checksum, Global Source ID (GSI), and Transport Service Data Unit (TSDU) Length are:
すべてのパケットで、データソースポート、データ照明ポート、タイプ、オプション、チェックサム、グローバルソースID（GSI）、およびトランスポートサービスデータユニット（TSDU）の長さの説明は次のとおりです。
Data-Source Port:
データソースポート：
A random port number generated by the source. This port number MUST be unique within the source. Source Port together with Global Source ID forms the TSI.
ソースによって生成されたランダムポート番号。このポート番号は、ソース内で一意でなければなりません。ソースポートとグローバルソースIDがTSIを形成します。
Data-Destination Port:
データ照明ポート：
A globally well-known port number assigned to the given PGM application.
指定されたPGMアプリケーションに割り当てられた世界的に有名なポート番号。
Type:
タイプ：
The high-order two bits of the Type field encode a version number, 0x0 in this instance. The low-order nibble of the type field encodes the specific packet type. The intervening two bits (the low-order two bits of the high-order nibble) are reserved and MUST be zero.
このインスタンスでは、タイプフィールドの高次2ビットはバージョン番号0x0をエンコードします。タイプフィールドの低次のニブルは、特定のパケットタイプをエンコードします。介在する2ビット（高次のニブルの低次の2ビット）は予約されており、ゼロでなければなりません。
Within the low-order nibble of the Type field:
タイプフィールドの低次のニブル内：
values in the range 0x0 through 0x3 represent SPM-like packets (i.e., session-specific, sourced by a source, periodic),
0x0から0x3の範囲の値は、SPMのようなパケットを表します（つまり、セッション固有の、ソースによってソース、周期的）、
values in the range 0x4 through 0x7 represent DATA-like packets (i.e., data and repairs),
0x4〜0x7の範囲の値は、データのようなパケット（つまり、データと修理）を表します。
values in the range 0x8 through 0xB represent NAK-like packets (i.e., hop-by-hop reliable NAK forwarding procedures),
0x8〜0xBの範囲の値は、NAKのようなパケットを表します（つまり、ホップバイホップ信頼できるNAK転送手順）、
and values in the range 0xC through 0xF represent SPMR-like packets (i.e., session-specific, sourced by a receiver, asynchronous).
0xcから0xfの範囲の値は、SPMRのようなパケットを表します（つまり、セッション固有の、レシーバーによって供給され、非同期）。
Options:
オプション：
This field encodes binary indications of the presence and significance of any options. It also directly encodes some options.
このフィールドは、オプションの存在と重要性のバイナリ指標をエンコードします。また、いくつかのオプションを直接エンコードします。
bit 0 set => One or more Option Extensions are present
ビット0セット=> 1つ以上のオプション拡張機能が存在します
bit 1 set => One or more Options are network-significant
ビット1セット=> 1つ以上のオプションはネットワーク有意です
Note that this bit is clear when OPT_FRAGMENT and/or OPT_JOIN are the only options present.
opt_fragmentおよび/またはopt_joinが唯一のオプションである場合、このビットは明確であることに注意してください。
bit 6 set => Packet is a parity packet for a transmission group of variable sized packets (OPT_VAR_PKTLEN). Only present when OPT_PARITY is also present.
ビット6 set =>パケットは、可変サイズのパケット（opt_var_pktlen）の伝送グループのパリティパケットです。opt_parityも存在する場合にのみ存在します。
bit 7 set => Packet is a parity packet (OPT_PARITY)
ビット7 set =>パケットはパリティパケット（opt_parity）です
Bits are numbered here from left (0 = MSB) to right (7 = LSB).
ここでは、左（0 = MSB）から右（7 = LSB）にビットがあります。
All the other options (option extensions) are encoded in extensions to the PGM header.
他のすべてのオプション（オプション拡張機能）は、PGMヘッダーの拡張機能でエンコードされています。
Checksum:
チェックサム：
This field is the usual 1's complement of the 1's complement sum of the entire PGM packet including header.
このフィールドは、ヘッダーを含むPGMパケット全体の1の補数合計の通常の1の補体です。
The checksum does not include a network-layer pseudo header for compatibility with network address translation. If the computed checksum is zero, it is transmitted as all ones. A value of zero in this field means the transmitter generated no checksum.
チェックサムには、ネットワークレイヤーの擬似ヘッダーは、ネットワークアドレスの変換と互換性があります。計算されたチェックサムがゼロの場合、それはすべてのものとして送信されます。このフィールドのゼロの値は、送信機がチェックサムを生成しなかったことを意味します。
Note that if any entity between a source and a receiver modifies the PGM header for any reason, it MUST either recompute the checksum or clear it. The checksum is mandatory on data packets (ODATA and RDATA).
ソースとレシーバーの間のエンティティが何らかの理由でPGMヘッダーを変更する場合、チェックサムを再計算するか、それをクリアする必要があることに注意してください。チェックサムは、データパケット（ODATAおよびRDATA）で必須です。
Global Source ID:
グローバルソースID：
A globally unique source identifier. This ID MUST NOT change throughout the duration of the transport session. A RECOMMENDED identifier is the low-order 48 bits of the MD5 [9] signature of the DNS name of the source. Global Source ID together with Data-Source Port forms the TSI.
グローバルに一意のソース識別子。このIDは、輸送セッションの期間中ずっと変更してはなりません。推奨される識別子は、ソースのDNS名のMD5 [9]の署名の低次の48ビットです。グローバルソースIDとデータソースポートがTSIを形成します。
TSDU Length:
TSDUの長さ：
The length in octets of the transport data unit exclusive of the transport header.
トランスポートヘッダーを除く輸送データユニットのオクテットの長さ。
Note that those who require the TPDU length must obtain it from sum of the transport header length (TH) and the TSDU length. TH length is the sum of the size of the particular PGM packet header (type_specific_size) plus the length of any options that might be present.
TPDUの長さを必要とする人は、輸送ヘッダー長（TH）とTSDUの長さの合計からそれを取得する必要があることに注意してください。THの長さは、特定のPGMパケットヘッダー（Type_specific_size）のサイズの合計と、存在する可能性のあるオプションの長さです。
Address Family Indicators (AFIs) are as specified in [10].
アドレスファミリインジケーター（AFI）は[10]で指定されているとおりです。
SPMs are sent by a source to establish source path state in network elements and to provide transmit window state to receivers.
SPMはソースによって送信され、ネットワーク要素にソースパス状態を確立し、レシーバーにウィンドウ状態を送信します。
The network-header source address of an SPM is the unicast NLA of the entity that originates the SPM.
SPMのネットワークヘッダーソースアドレスは、SPMを発信するエンティティのユニキャストNLAです。
The network-header destination address of an SPM is a multicast group NLA.
SPMのネットワークヘッダー宛先アドレスは、マルチキャストグループNLAです。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPM's Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trailing Edge Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leading Edge Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Option Extensions when present ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:
SPM_SPORT
SPM_SPORT
Data-Source Port, together with SPM_GSI forms SPM_TSI
SPM_GSIとともに、データソースポートがSPM_TSIを形成します
Destination Port:
宛先ポート：
SPM_DPORT
spm_dport
Data-Destination Port
データ照射ポート
Type:
タイプ：
SPM_TYPE = 0x00
Global Source ID:
グローバルソースID：
SPM_GSI
SPM_GSI
Together with SPM_SPORT forms SPM_TSI
SPM_SPORTフォームSPM_TSIと一緒に
SPM's Sequence Number
SPMのシーケンス番号
SPM_SQN
SPM_SQN
The sequence number assigned to the SPM by the source.
ソースによってSPMに割り当てられたシーケンス番号。
Trailing Edge Sequence Number:
トレーリングエッジシーケンス番号：
SPM_TRAIL
SPM_TRAIL
The sequence number defining the current trailing edge of the source's transmit window (TXW_TRAIL).
ソースの送信ウィンドウ（TXW_TRAIL）の現在のトレイルエッジを定義するシーケンス番号。
Leading Edge Sequence Number:
リーディングエッジシーケンス番号：
SPM_LEAD
SPM_LEAD
The sequence number defining the current leading edge of the source's transmit window (TXW_LEAD).
ソースの送信ウィンドウ（TXW_LEAD）の現在のリーディングエッジを定義するシーケンス番号。
If SPM_TRAIL == 0 and SPM_LEAD == 0x80000000, this indicates that no window information is present in the packet.
SPM_TRAIL == 0およびSPM_LEAD == 0x80000000の場合、これはパケットにウィンドウ情報が存在しないことを示します。
Path NLA:
パスNLA：
SPM_PATH
SPM_PATH
The NLA of the interface on the network element on which this SPM was forwarded. Initialized by a source to the source's NLA, rewritten by each PGM network element upon forwarding.
このSPMが転送されたネットワーク要素上のインターフェイスのNLA。ソースによってソースのNLAに初期化され、転送時に各PGMネットワーク要素によって書き換えられました。
Data packets carry application data from a source or a repairer to receivers.
データパケットは、ソースまたは修理業者から受信機へのアプリケーションデータを伝達します。
ODATA:
odata：
Original data packets transmitted by a source.
ソースによって送信された元のデータパケット。
RDATA:
rdata：
Repairs transmitted by a source or by a designated local repairer (DLR) in response to a NAK.
NAKに応じて、ソースまたは指定されたローカル修理業者（DLR）によって送信される修理。
The network-header source address of a data packet is the unicast NLA of the entity that originates the data packet.
データパケットのネットワークヘッダーソースアドレスは、データパケットを発信するエンティティのユニキャストNLAです。
The network-header destination address of a data packet is a multicast group NLA.
データパケットのネットワークヘッダー宛先アドレスは、マルチキャストグループNLAです。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trailing Edge Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Extensions when present ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+- ...
Source Port:
ソースポート：
OD_SPORT, RD_SPORT
OD_SPORT、RD_SPORT
Data-Source Port, together with Global Source ID forms:
データソースポート、グローバルソースIDフォーム：
OD_TSI, RD_TSI
OD_TSI、RD_TSI
Destination Port:
宛先ポート：
OD_DPORT, RD_DPORT
od_dport、rd_dport
Data-Destination Port
データ照射ポート
Type:
タイプ：
OD_TYPE = 0x04 RD_TYPE = 0x05
OD_TYPE = 0x04 RD_TYPE = 0x05
Global Source ID:
グローバルソースID：
OD_GSI, RD_GSI
OD_GSI、RD_GSI
Together with Source Port forms:
ソースポートフォームと一緒に：
OD_TSI, RD_TSI
OD_TSI、RD_TSI
Data Packet Sequence Number:
データパケットシーケンス番号：
OD_SQN, RD_SQN
OD_SQN、RD_SQN
The sequence number originally assigned to the ODATA packet by the source.
ソースによって元々Odataパケットに割り当てられたシーケンス番号。
Trailing Edge Sequence Number:
トレーリングエッジシーケンス番号：
OD_TRAIL, RD_TRAIL
OD_TRAIL、RD_TRAIL
The sequence number defining the current trailing edge of the source's transmit window (TXW_TRAIL). In RDATA, this MAY not be the same as OD_TRAIL of the ODATA packet for which it is a repair.
ソースの送信ウィンドウ（TXW_TRAIL）の現在のトレイルエッジを定義するシーケンス番号。RDATAでは、これは修理であるODATAパケットのOD_TRAILと同じではない場合があります。
Data:
データ：
Application data.
アプリケーションデータ。
NAK:
ナック：
Negative Acknowledgments are sent by receivers to request the repair of an ODATA packet detected to be missing from the expected sequence.
否定的な謝辞は、予想されるシーケンスから欠落していると検出されたODATAパケットの修理を要求するために、受信機によって送信されます。
N-NAK:
n-nak：
Null Negative Acknowledgments are sent by DLRs to provide flow control feedback to the source of ODATA for which the DLR has provided the corresponding RDATA.
null否定的な承認は、DLRが対応するRDATAを提供したODATAのソースにフロー制御フィードバックを提供するためにDLRによって送信されます。
The network-header source address of a NAK is the unicast NLA of the entity that originates the NAK. The network-header source address of NAK is rewritten by each PGM network element with its own.
NAKのネットワークヘッダーソースアドレスは、NAKを発信するエンティティのユニキャストNLAです。NAKのネットワークヘッダーソースアドレスは、独自のPGMネットワーク要素ごとに書き換えられます。
The network-header destination address of a NAK is initialized by the originator of the NAK (a receiver) to the unicast NLA of the upstream PGM network element known from SPMs. The network-header destination address of a NAK is rewritten by each PGM network element with the unicast NLA of the upstream PGM network element to which this NAK is forwarded. On the final hop, the network-header destination address of a NAK is rewritten by the PGM network element with the unicast NLA of the original source or the unicast NLA of a DLR.
NAKのネットワークヘッダー宛先アドレスは、NAK（レシーバー）のオリジネーターによって初期化され、SPMSから知られている上流のPGMネットワーク要素のユニキャストNLAに初期化されます。NAKのネットワークヘッダー宛先アドレスは、このNAKが転送される上流のPGMネットワーク要素のユニキャストNLAを使用して、各PGMネットワーク要素によって書き換えられます。最終ホップでは、NAKのネットワークヘッダー宛先アドレスは、元のソースのユニキャストNLAまたはDLRのユニキャストNLAを使用してPGMネットワーク要素によって書き換えられます。
NCF:
NCF：
NAK Confirmations are sent by network elements and sources to confirm the receipt of a NAK.
NAKの確認は、NAKの受領を確認するためにネットワーク要素とソースによって送信されます。
The network-header source address of an NCF is the ODATA source's NLA, not the network element's NLA as might be expected.
NCFのネットワークヘッダーソースアドレスは、予想される場合のネットワーク要素のNLAではなく、ODATAソースのNLAです。
The network-header destination address of an NCF is a multicast group NLA.
NCFのネットワークヘッダー宛先アドレスは、マルチキャストグループNLAです。
Note that in NAKs and N-NAKs, unlike the other packets, the field SPORT contains the Data-Destination port and the field DPORT contains the Data-Source port. As a general rule, the content of SPORT/DPORT is determined by the direction of the flow: in packets which travel down-stream SPORT is the port number chosen in the data source (Data-Source Port) and DPORT is the data destination port number (Data-Destination Port). The opposite holds for packets which travel upstream. This makes DPORT the protocol endpoint in the recipient host, regardless of the direction of the packet.
NAKSとN-NAKでは、他のパケットとは異なり、フィールドスポーツにはデータ照射ポートが含まれており、フィールドDポートにはデータソースポートが含まれています。一般的なルールとして、スポーツ/Dポートの内容はフローの方向によって決定されます。ダウンストリームスポーツを移動するパケット内は、データソース（データソースポート）で選択されたポート番号であり、DPortはデータ宛先ポートです。番号（データ照射ポート）。反対のものは、上流に移動するパケットの場合にはなります。これにより、パケットの方向に関係なく、受信者ホストのプロトコルエンドポイントになります。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Option Extensions when present ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
Source Port:
ソースポート：
NAK_SPORT, NNAK_SPORT
nak_sport、nnak_sport
Data-Destination Port
データ照射ポート
NCF_SPORT
NCF_SPORT
Data-Source Port, together with Global Source ID forms NCF_TSI
データソースポート、グローバルソースIDフォームNCF_TSI
Destination Port:
宛先ポート：
NAK_DPORT, NNAK_DPORT
nak_dport、nnak_dport
Data-Source Port, together with Global Source ID forms:
データソースポート、グローバルソースIDフォーム：
NAK_TSI, NNAK_TSI
nak_tsi、nnak_tsi
NCF_DPORT
NCF_DPORT
Data-Destination Port
データ照射ポート
Type:
タイプ：
NAK_TYPE = 0x08 NNAK_TYPE = 0x09
nak_type = 0x08 nnak_type = 0x09
NCF_TYPE = 0x0A
Global Source ID:
グローバルソースID：
NAK_GSI, NNAK_GSI, NCF_GSI
Nak_gsi、nnak_gsi、ncf_gsi
Together with Data-Source Port forms
データソースポートフォームと一緒に
NAK_TSI, NNAK_TSI, NCF_TSI
Nak_tsi、nnak_tsi、ncf_tsi
Requested Sequence Number:
要求されたシーケンス番号：
NAK_SQN, NNAK_SQN
Nak_sqn、nnak_sqn
NAK_SQN is the sequence number of the ODATA packet for which a repair is requested.
NAK_SQNは、修理が要求されるODATAパケットのシーケンス番号です。
NNAK_SQN is the sequence number of the RDATA packet for which a repair has been provided by a DLR.
NNAK_SQNは、DLRによって修復が提供されたRDATAパケットのシーケンス番号です。
NCF_SQN
NCF_SQN
NCF_SQN is NAK_SQN from the NAK being confirmed.
NCF_SQNは、確認されているNAKのNAK_SQNです。
Source NLA:
ソースNLA：
NAK_SRC, NNAK_SRC, NCF_SRC
Nak_Src、NNAK_SRC、NCF_SRC
The unicast NLA of the original source of the missing ODATA.
不足しているOdataの元のソースのユニキャストNLA。
Multicast Group NLA:
マルチキャストグループNLA：
NAK_GRP, NNAK_GRP, NCF_GRP
Nak_grp、nnak_grp、ncf_grp
The multicast group NLA. NCFs MAY bear OPT_REDIRECT and/or OPT_NAK_LIST
マルチキャストグループNLA。NCFSは、opt_redirectおよび/またはopt_nak_listを負担する場合があります
PGM specifies several end-to-end options to address specific application requirements. PGM specifies options to support fragmentation, late joining, and redirection.
PGMは、特定のアプリケーション要件に対処するためのいくつかのエンドツーエンドオプションを指定します。PGMは、断片化、遅い結合、およびリダイレクトをサポートするオプションを指定します。
Options MAY be appended to PGM data packet headers only by their original transmitters. While they MAY be interpreted by network elements, options are neither added nor removed by network elements.
オプションは、元の送信機によってのみPGMデータパケットヘッダーに追加される場合があります。それらはネットワーク要素によって解釈される可能性がありますが、オプションはネットワーク要素によって追加されたり削除されたりしません。
Options are all in the TLV style, or Type, Length, Value. The Type field is contained in the first byte, where bit 0 is the OPT_END bit, followed by 7 bits of type. The OPT_END bit MUST be set in the last option in the option list, whichever that might be. The Length field is the total length of the option in bytes, and directly follows the Type field. Following the Length field are 5 reserved bits, the OP_ENCODED flag, the 2 Option Extensibility bits OPX and the OP_ENCODED_NULL flag. Last are 7 bits designated for option specific information which may be defined on a per-option basis. If not defined for a particular option, they MUST be set to 0.
オプションはすべてTLVスタイル、またはタイプ、長さ、値です。タイプフィールドは最初のバイトに含まれています。ここで、ビット0はOPT_ENDビットで、その後7ビットのタイプが続きます。OPT_ENDビットは、オプションリストの最後のオプションで設定する必要があります。長さフィールドは、バイト内のオプションの全長であり、型フィールドに直接従います。長さのフィールドに続くのは、5つの予約ビット、OP_ENCODEDフラグ、2オプション拡張性ビットOPX、OP_ENCODED_NULLフラグです。最後に、オプションごとに定義できるオプション固有の情報に指定された7ビットです。特定のオプションで定義されていない場合は、0に設定する必要があります。
The Option Extensibility bits dictate the desired treatment of an option if it is unknown to the network element processing it.
オプションの拡張性ビットは、それがそれを処理するネットワーク要素に知られていない場合、オプションの目的の処理を決定します。
Nota Bene: Only network elements pay any attention to these bits.
Nota Bene：ネットワーク要素のみがこれらのビットに注意を払います。
The OPX bits are defined as follows:
OPXビットは次のように定義されています。
00 - Ignore the option
00-オプションを無視します
01 - Invalidate the option by changing the type to OPT_INVALID = 0x7F
01 -opt_invalid = 0x7fにタイプを変更してオプションを無効にします
10 - Discard the packet
10-パケットを破棄します
11 - Unsupported, and reserved for future use
11-サポートされておらず、将来の使用のために予約されています
Some options present in data packet (ODATA and RDATA) are strictly associated with the packet content (PGM payload), OPT_FRAGMENT being an example. These options must be preserved even when the data packet that would normally contain them is not received, but its the payload is recovered though the use of FEC. PGM specifies a mechanism to accomplish this that uses the F (OP_ENCODED) and U (OP_ENCODED_NULL) bits in the option common header. OP_ENCODED and OP_ENCODED_NULL MUST be normally set to zero except when the option is used in FEC packets to preserve original options. See Appendix A for details.
データパケット（ODATAおよびRDATA）に存在するいくつかのオプションは、パケットコンテンツ（PGMペイロード）に厳密に関連付けられており、OPT_FRAGMENTは例です。これらのオプションは、通常それらを含むデータパケットが受信されない場合でも保存する必要がありますが、そのペイロードはFECの使用で回復します。PGMは、オプション共通ヘッダーでF（op_encoded）およびu（op_encoded_null）ビットを使用するこれを達成するためのメカニズムを指定します。op_encodedおよびop_encoded_nullは、オプションがFECパケットで使用されて元のオプションを保持する場合を除き、通常ゼロに設定する必要があります。詳細については、付録Aを参照してください。
There is a limit of 16 options per packet.
パケットごとに16のオプションの制限があります。
General Option Format
一般的なオプション形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U|Opt. Specific|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
When option extensions are appended to the standard PGM header, the extensions MUST be preceded by an option extension length field specifying the total length of all option extensions.
オプション拡張機能が標準のPGMヘッダーに追加される場合、拡張機能の前に、すべてのオプション拡張機能の合計長さを指定するオプション拡張長フィールドが必要です。
In addition, the presence of the options MUST be encoded in the Options field of the standard PGM header before the Checksum is computed.
さらに、チェックサムが計算される前に、オプションの存在を標準のPGMヘッダーのオプションフィールドにエンコードする必要があります。
All network-significant options MUST be appended before any exclusively receiver-significant options.
すべてのネットワーク有意なオプションは、排他的に受信者が重要なオプションの前に追加する必要があります。
To provide an indication of the end of option extensions, OPT_END (0x80) MUST be set in the Option Type field of the trailing option extension.
オプション拡張機能の終了を示すために、OPT_END（0x80）をトレーリングオプション拡張子のオプションタイプフィールドに設定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Total length of all options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x00
オプションタイプ= 0x00
Option Length = 4 octets
オプション長= 4オクテット
Total length of all options
すべてのオプションの全長
The total length in octets of all option extensions including OPT_LENGTH.
opt_lengthを含むすべてのオプション拡張機能のオクテットの総長さ。
OPT_LENGTH is NOT network-significant.
Opt_Lengthはネットワーク有意ではありません。
Fragmentation allows transport-layer entities at a source to break up application protocol data units (APDUs) into multiple PGM data packets (TPDUs) to conform with the MTU supported by the network layer. The fragmentation option MAY be applied to ODATA and RDATA packets only.
フラグメンテーションにより、ソースの輸送層エンティティは、アプリケーションプロトコルデータユニット（APDU）を複数のPGMデータパケット（TPDU）に分割して、ネットワークレイヤーでサポートされているMTUに準拠することができます。フラグメンテーションオプションは、ODATAおよびRDATAパケットのみに適用できます。
Architecturally, the accumulation of TSDUs into APDUs is applied to TPDUs that have already been received, duplicate eliminated, and contiguously sequenced by the receiver. Thus APDUs MAY be reassembled across increments of the transmit window.
建築的には、apdusへのtsdusの蓄積は、既に受信され、複製された複製、およびレシーバーによって連続的にシーケンスされたtpdusに適用されます。したがって、APDUは、送信ウィンドウの増分間で再組み立てされる可能性があります。
OPT_FRAG_OFF the offset of the fragment from the beginning of the APDU
opt_frag_off apduの初めからのフラグメントのオフセット
OPT_FRAG_LEN the total length of the original APDU
OPT_FRAG_LEN元のAPDUの全長
A source fragments APDUs into a contiguous series of fragments no larger than the MTU supported by the network layer. A source sequentially and uniquely assigns OD_SQNs to these fragments in the order in which they occur in the APDU. A source then sets OPT_FRAG_OFF to the value of the offset of the fragment in the original APDU (where the first byte of the APDU is at offset 0, and OPT_FRAG_OFF numbers the first byte in the fragment), and set OPT_FRAG_LEN to the value of the total length of the original APDU.
ソースは、ネットワークレイヤーによってサポートされているMTUよりも大きい一連のフラグメントの連続的なシリーズにApdusを断片化します。ソースは、APDUで発生する順序でこれらのフラグメントにOD_SQNSを順次かつ一意に割り当てます。ソースは、OPT_FRAG_OFFを元のAPDUのフラグメントのオフセットの値に設定します（APDUの最初のバイトはオフセット0であり、OPT_FRAG_OFFはフラグメントの最初のバイトを数字）し、OPT_FRAG_LENを設定します。元のAPDUの全長。
Receivers detect and accumulate fragmented packets until they have received an entire contiguous sequence of packets comprising an APDU. This sequence begins with the fragment bearing OPT_FRAG_OFF of 0, and terminates with the fragment whose length added to its OPT_FRAG_OFF is OPT_FRAG_LEN.
受信機は、APDUを含むパケットの隣接するシーケンス全体を受け取るまで、断片化されたパケットを検出および蓄積します。このシーケンスは、0のopt_frag_offをベアリングするフラグメントから始まり、その長さがopt_frag_offに追加されたフラグメントで終了します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x01
オプションタイプ= 0x01
Option Length = 12 octets
オプション長= 12オクテット
First Sequence Number
最初のシーケンス番号
Sequence Number of the PGM DATA/RDATA packet containing the first fragment of the APDU.
APDUの最初のフラグメントを含むPGMデータ/RDATAパケットのシーケンス番号。
Offset
オフセット
The byte offset of the fragment from the beginning of the APDU (OPT_FRAG_OFF).
APDU（opt_frag_off）の開始からのフラグメントのバイトオフセット。
Length
長さ
The total length of the original APDU (OPT_FRAG_LEN).
元のAPDU（opt_frag_len）の総長さ。
OPT_FRAGMENT is NOT network-significant.
Opt_Fragmentはネットワーク有意ではありません。
The NAK List option MAY be used in conjunction with NAKs to allow receivers to request transmission for more than one sequence number with a single NAK packet. The option is limited to 62 listed NAK entries. The NAK list MUST be unique and duplicate free. It MUST be ordered, and MUST consist of either a list of selective or a list of parity NAKs. In general, network elements, sources and receivers must process a NAK list as if they had received individual NAKs for each sequence number in the list. The procedures for each are outlined in detail earlier in this document. Clarifications and differences are detailed here.
NAKリストオプションは、NAKSと組み合わせて使用して、レシーバーが単一のNAKパケットを使用して複数のシーケンス番号の送信を要求できるようにすることができます。オプションは、62のリストされたNAKエントリに制限されています。NAKリストは一意であり、無料で複製する必要があります。注文する必要があり、選択的なNAKのリストまたはリストのいずれかで構成する必要があります。一般に、ネットワーク要素、ソース、および受信機は、リスト内の各シーケンス番号に対して個々のNAKを受け取ったかのようにNAKリストを処理する必要があります。それぞれの手順については、このドキュメントの前半で詳しく説明します。明確化と違いについて詳しく説明しています。
A list of sequence numbers for which retransmission is requested.
再送信が要求されるシーケンス番号のリスト。
Receivers MAY append the NAK List option to a NAK to indicate that they wish retransmission of a number of RDATA.
受信者は、NAKリストオプションをNAKに追加して、多くのRDATAの再送信を希望することを示す場合があります。
Receivers SHOULD proceed to back off NAK transmission in a manner consistent with the procedures outlined for single sequence number NAKs. Note that the repair of each separate sequence number will be completed upon receipt of a separate RDATA packet.
受信機は、単一のシーケンス番号NAKの概説された手順と一致する方法でNAK送信を後退させる必要があります。個別のシーケンス番号の修理は、個別のRDATAパケットを受け取ると完了することに注意してください。
Reception of an NCF or multicast NAK containing the NAK List option suspends generation of NAKs for all sequence numbers within the NAK list, as well as the sequence number within the NAK header.
NAKリストオプションを含むNCFまたはマルチキャストNAKの受信は、NAKリスト内のすべてのシーケンス番号のNAKの生成と、NAKヘッダー内のシーケンス番号を停止します。
Network elements MUST immediately respond to a NAK with an identical NCF containing the same NAK list as the NAK itself.
ネットワーク要素は、NAK自体と同じNAKリストを含む同一のNCFを持つNAKにすぐに応答する必要があります。
Network elements MUST forward a NAK containing a NAK List option if any one sequence number specified by the NAK (including that in the main NAK header) is not currently outstanding. That is, it MUST forward the NAK, if any one sequence number does not have an elimination timer running for it. The NAK must be forwarded intact.
ネットワーク要素は、NAKによって指定された1つのシーケンス番号（メインNAKヘッダーを含む）が現在未払いではない場合、NAKリストオプションを含むNAKを転送する必要があります。つまり、1つのシーケンス番号に排除タイマーが実行されていない場合は、NAKを転送する必要があります。NAKはそのまま転送する必要があります。
Network elements MUST eliminate a NAK containing the NAK list option only if all sequence numbers specified by the NAK (including that in the main NAK header) are outstanding. That is, they are all running an elimination timer.
ネットワーク要素は、NAKによって指定されたすべてのシーケンス番号（メインNAKヘッダーを含む）が傑出している場合にのみ、NAKリストオプションを含むNAKを排除する必要があります。つまり、それらはすべてエリミネーションタイマーを実行しています。
Upon receipt of an unsolicited NCF containing the NAK list option, a network element MUST anticipate data for every sequence number specified by the NAK as if it had received an NCF for every sequence number specified by the NAK.
NAKリストオプションを含む未承諾NCFを受信すると、ネットワーク要素は、NAKによって指定されたすべてのシーケンス番号に対してNCFを受信したかのようにNAKによって指定されたすべてのシーケンス番号のデータを予測する必要があります。
A source MUST immediately respond to a NAK with an identical NCF containing the same NAK list as the NAK itself.
ソースは、NAK自体と同じNAKリストを含む同一のNCFを持つNAKに直ちに応答する必要があります。
It MUST then multicast RDATA (while respecting TXW_MAX_RTE) for every requested sequence number.
次に、要求されたシーケンス番号ごとに（TXW_MAX_RTEを尊重しながら）RDATAをマルチキャストする必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Sequence Number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Sequence Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x02
オプションタイプ= 0x02
Option Length = 4 + (4 * number of SQNs) octets
Requested Sequence Number
要求されたシーケンス番号
A list of up to 62 additional sequence numbers to which the NAK applies.
NAKが適用する最大62の追加シーケンス番号のリスト。
OPT_NAK_LIST is network-significant.
opt_nak_listはネットワーク有意です。
Late joining allows a source to bound the amount of repair history receivers may request when they initially join a particular transport session.
遅く参加することで、ソースは修理履歴レシーバーが最初に特定の輸送セッションに参加したときに要求できる量をバインドできます。
This option indicates that receivers that join a transport session in progress MAY request repair of all data as far back as the given minimum sequence number from the time they join the transport session. The default is for receivers to receive data only from the first packet they receive and onward.
このオプションは、進行中のトランスポートセッションに参加する受信者が、輸送セッションに参加する時間から与えられた最小シーケンス番号まで、すべてのデータの修理を要求することができることを示しています。デフォルトは、受信者が受信した最初のパケットからのみデータを受信することです。
OPT_JOIN_MIN the minimum sequence number for repair
OPT_JOIN_MIN修理の最小シーケンス番号
If a PGM packet (ODATA, RDATA, or SPM) bears OPT_JOIN, a receiver MAY initialize the trailing edge of the receive window (RXW_TRAIL_INIT) to the given Minimum Sequence Number and proceeds with normal data reception.
PGMパケット（ODATA、RDATA、またはSPM）がOPT_JOINを使用する場合、受信者は受信ウィンドウ（RXW_TRAIL_INIT）の末尾エッジを指定された最小シーケンス番号に初期化し、通常のデータ受信に進みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x03
オプションタイプ= 0x03
Option Length = 8 octets
オプション長= 8オクテット
Minimum Sequence Number
最小シーケンス番号
The minimum sequence number defining the initial trailing edge of the receive window for a late joining receiver.
遅延結合レシーバーの受信ウィンドウの最初の末尾エッジを定義する最小シーケンス番号。
OPT_JOIN is NOT network-significant.
OPT_JOINはネットワーク有意ではありません。
Redirection MAY be used by a designated local repairer (DLR) to advertise its own address as an alternative to the original source, for requesting repairs.
指定されたローカル修理業者（DLR）がリダイレクトを使用して、修理を要求するために、元のソースの代替として独自の住所を宣伝することができます。
These procedures allow a PGM Network Element to use a DLR that is one PGM hop from it either upstream or downstream in the multicast distribution tree. The former are referred to as upstream DLRs. The latter are referred to as off-tree DLRs. Off-Tree because even though they are downstream of the point of loss, they might not lie on the subtree affected by the loss.
これらの手順により、PGMネットワーク要素は、マルチキャスト分布ツリーの上流または下流の1つのPGMホップであるDLRを使用できます。前者は上流のDLRと呼ばれます。後者は、トリーオフツリーDLRと呼ばれます。オフツリーは、損失のポイントの下流であっても、損失の影響を受けたサブツリーに嘘をつかない可能性があるためです。
A DLR MUST receive any PGM sessions for which it wishes to provide retransmissions. A DLR SHOULD respond to NCFs or POLLs sourced by its PGM parent with a redirecting POLR response packet containing an OPT_REDIRECT which provides its own network layer address. Recipients of redirecting POLRs MAY then direct NAKs for subsequent ODATA sequence numbers to the DLR rather than to the original source. In addition, DLRs that receive redirected NAKs for which they have RDATA MUST send a NULL NAK to provide flow control to the original source without also provoking a repair from that source.
DLRは、再送信を提供したいPGMセッションを受信する必要があります。DLRは、独自のネットワークレイヤーアドレスを提供するOPT_REDIRECTを含むリダイレクトPOLR応答パケットを使用して、PGM親によって供給されたNCFSまたは投票に応答する必要があります。リダイレクトPOLRSの受信者は、元のソースではなく、DLRに後続のODATAシーケンス番号のNAKを誘導することができます。さらに、RDATAを持っているリダイレクトNAKを受け取ったDLRは、そのソースからの修理を引き起こすことなく、元のソースにフロー制御を提供するためにnull nakを送信する必要があります。
OPT_REDIR_NLA the DLR's own unicast network-layer address to which recipients of the redirecting POLR MAY direct subsequent NAKs for the corresponding TSI.
opt_redir_nlaリダイレクトPOLRの受信者が対応するTSIのその後のNAKを指示するDLR独自のユニキャストネットワーク層アドレス。
A DLR MUST receive any PGM sessions for which it wishes to provide a source of repairs. In addition to acting as an ordinary PGM receiver, a DLR MAY then respond to NCFs or relevant POLLs sourced by parent network elements (or even by the source itself) by sending a POLR containing an OPT_REDIRECT providing its own network-layer address.
DLRは、修理のソースを提供したいPGMセッションを受け取る必要があります。通常のPGMレシーバーとして行動することに加えて、DLRは、独自のネットワークレイヤーアドレスを提供するOPT_REDIRECTを含むPOLRを送信することにより、親ネットワーク要素（またはソース自体によって）を送信するNCFまたは関連する投票に応答する場合があります。
If a DLR can provide FEC repairs it MUST denote this by setting OPT_PARITY in the PGM header of its POLR response.
DLRがFEC修復を提供できる場合、POLR応答のPGMヘッダーにOPT_PARITYを設定することにより、これを示す必要があります。
If the NCF completes NAK transmission initiated by the DLR itself, the DLR MUST NOT send a redirecting POLR.
NCFがDLR自体によって開始されたNAK伝送を完了した場合、DLRはリダイレクトPOLRを送信してはなりません。
When a DLR receives an NCF from its upstream PGM parent, it SHOULD send a redirecting POLR, multicast to the group. The DLR SHOULD record that it is acting as an upstream DLR for the said session. Note that this POLR MUST have both the data source's source address and the router alert option in its network header.
上流のPGM親からDLRがNCFを受信すると、グループにマルチキャストをリダイレクトするPOLRを送信する必要があります。DLRは、上記のセッションの上流DLRとして機能していることを記録する必要があります。このPOLRには、ネットワークヘッダーにデータソースのソースアドレスとルーターアラートオプションの両方が必要であることに注意してください。
An upstream DLR MUST act as an ordinary PGM source in responding to any NAK it receives (i.e., directed to it). That is, it SHOULD respond first with a normal NCF and then RDATA as usual. In addition, an upstream DLR that receives redirected NAKs for which it has RDATA MUST send a NULL NAK to provide flow control to the original source. If it cannot provide the RDATA it forwards the NAK to the upstream PGM neighbor as usual.
上流のDLRは、受け取るNAK（つまり、それに向けられた）に応答する際に、通常のPGMソースとして機能する必要があります。つまり、最初に通常のNCFで応答し、次に通常どおりRDATAで応答する必要があります。さらに、RDATAを搭載したリダイレクトNAKを受信する上流のDLRは、元のソースにフロー制御を提供するためにnull nakを送信する必要があります。rdataを提供できない場合は、通常どおり上流のPGM隣人にNakを転送します。
Nota Bene: In order to propagate on exactly the same distribution tree as ODATA, RDATA and POLR packets transmitted by DLRs MUST bear the ODATA source's NLA as the network-header source address, not the DLR's NLA as might be expected.
NOTA BENE：DLRSによって送信されたOdata、Rdata、およびPolrパケットとまったく同じ分布ツリーを伝播するためには、DLRのNLAではなく、NLAのNLAを産出する必要があります。
A DLR that receives a POLL with sub-type PGM_POLL_DLR MUST respond with a unicast redirecting POLR if it provides the appropriate service. The DLR SHOULD respond using the rules outlined for polling in Appendix D of this text. If the DLR responds, it SHOULD record that it is acting as an off-tree DLR for the said session.
サブタイプのPGM_POLL_DLRを使用して投票を受けるDLRは、適切なサービスを提供する場合、ユニキャストリダイレクトPOLRで応答する必要があります。DLRは、このテキストの付録Dに投票するために概説されているルールを使用して応答する必要があります。DLRが応答した場合、上記のセッションのトゥリーオフツリーDLRとして機能していることを記録する必要があります。
An off-tree DLR acts in a special way in responding to any NAK it receives (i.e., directed to it). It MUST respond to a NAK directed to it from its parent by unicasting an NCF and RDATA to its parent. The parent will then forward the RDATA down the distribution tree. The DLR uses its own and the parent's NLA addresses in the network header for the source and destination respectively. The unicast NCF and RDATA packets SHOULD not have the router alert option. In all other ways the RDATA header should be "as if" the packet had come from the source.
トゥリーオフツリーDLRは、受け取るNAK（つまり、それに向けられた）に応答するために特別な方法で動作します。親にNCFとrdataをユニカストすることにより、親からそれに向けられたNAKに応答する必要があります。その後、親はrdataを分布ツリーに転送します。DLRは、それぞれソースと宛先にネットワークヘッダーで独自と親のNLAアドレスを使用します。Unicast NCFおよびRDATAパケットには、ルーターアラートオプションがないようにしてください。他のすべての方法で、rdataヘッダーは、パケットがソースから届いたかのように「」でなければなりません。
Again, an off-tree DLR that receives redirected NAKs for which it has RDATA MUST originate a NULL NAK to provide flow control to the original source. It MUST originate the NULL NAK before originating the RDATA. This must be done to reduce the state held in the network element.
繰り返しますが、RDATAを備えたリダイレクトされたNAKを受信するオフツリーDLRは、元のソースにフロー制御を提供するためにnull nakを発信する必要があります。rdataを発信する前に、null nakを発信する必要があります。これは、ネットワーク要素に保持されている状態を減らすために行う必要があります。
If it cannot provide the RDATA for a given NAK, an off-tree DLR SHOULD confirm the NAK with a unicast NCF as normal, then immediately send a NAK for the said data packet back to its parent.
特定のNAKにRDATAを提供できない場合、トゥリーオフツリーDLRは、通常どおりユニキャストNCFを使用してNAKを確認する必要があります。その後、そのデータパケットのNAKをすぐに親に返送します。
Note that it is possible for a DLR to provide service to its parent and to downstream network elements simultaneously. A downstream loss coupled with a loss for the same data on some other part of the distribution tree served by its parent could cause this. In this case it may provide both upstream and off-tree functionality simultaneously.
DLRが親と下流のネットワーク要素に同時にサービスを提供できることに注意してください。親が提供する分布ツリーの他の部分に関する同じデータの損失と相まって、下流の損失はこれを引き起こす可能性があります。この場合、上流とオフツリーの両方の機能を同時に提供する場合があります。
Note that a DLR differentiates between NAKs from an NE downstream or from its parent by comparing the network-header source address of the NAK with it's upstream PGM parent's NLA. The DLR knows the parent's NLA from the session's SPM messages.
DLRは、NAKのネットワークヘッダーソースアドレスを上流のPGM親のNLAと比較することにより、NEの下流またはその親からNAKを区別することに注意してください。DLRは、セッションのSPMメッセージから親のNLAを知っています。
When a PGM router receives notification of a loss via a NAK, it SHOULD first try to use a known DLR to recover the loss. If such a DLR is not known it SHOULD initiate DLR discovery. DLR discovery may occur in two ways. If there are upstream DLRs, the NAK transmitted by this router to its PGM parent will trigger their discovery, via a redirecting POLR. Also, a network element SHOULD initiate a search for off-tree DLRs using the PGM polling mechanism, and the sub-type PGM_POLL_DLR.
PGMルーターがNAKを介して損失の通知を受信する場合、最初に既知のDLRを使用して損失を回復するようにする必要があります。そのようなDLRがわからない場合は、DLR発見を開始する必要があります。DLR発見は2つの方法で発生する場合があります。上流のDLRがある場合、このルーターからPGM親に送信されたNAKは、リダイレクトPOLRを介して発見をトリガーします。また、ネットワーク要素は、PGMポーリングメカニズムとサブタイプのPGM_POLL_DLRを使用して、オフツリーDLRの検索を開始する必要があります。
If a DLR can provide FEC repairs it will denote this by setting OPT_PARITY in the PGM header of its POLR response. A network element SHOULD only direct parity NAKs to a DLR that can provide FEC repairs.
DLRがFEC修復を提供できる場合、POLR応答のPGMヘッダーにOPT_PARITYを設定することにより、これを示します。ネットワーク要素は、FECの修理を提供できるDLRにParity NAKを誘導する必要があります。
When it can, a network element SHOULD use upstream DLRs.
可能であれば、ネットワーク要素は上流のDLRを使用する必要があります。
Upon receiving a redirecting POLR, network elements SHOULD record the redirecting information for the TSI, and SHOULD redirect subsequent NAKs for the same TSI to the network address provided in the redirecting POLR rather than to the PGM neighbor known via the SPMs. Note, however, that a redirecting POLR is NOT regarded as matching the NAK that provoked it, so it does not complete the transmission of that NAK. Only a normal matching NCF can complete the transmission of a NAK.
リダイレクトPOLRを受信すると、ネットワーク要素はTSIのリダイレクト情報を記録し、SPMSを介して既知のPGM隣接ではなく、リダイレクトPOLRで提供されるネットワークアドレスに同じTSIの後続のNAKをリダイレクトする必要があります。ただし、リダイレクトPOLRは、それを引き起こしたNAKと一致するものとは見なされていないため、そのNAKの送信は完了しないことに注意してください。通常のNCFのみがNAKの送信を完了できます。
For subsequent NAKs, if the network element has recorded redirection information for the corresponding TSI, it MAY change the destination network address of those NAKs and attempt to transmit them to the DLR. No NAK for a specific SQN SHOULD be sent to an off-tree DLR if a NAK for the SQN has been seen on the interface associated with the DLR. Instead the NAK SHOULD be forwarded upstream. Subsequent NAKs for different SQNs MAY be forwarded to the said DLR (again assuming no NAK for them has been seen on the interface to the DLR).
その後のNAKの場合、ネットワーク要素が対応するTSIのリダイレクト情報を記録した場合、それらのNAKの宛先ネットワークアドレスを変更し、それらをDLRに送信しようとする可能性があります。SQNのNAKがDLRに関連付けられているインターフェイスで見られる場合、特定のSQNのNAKをオフツリーDLRに送信する必要はありません。代わりに、NAKは上流に転送する必要があります。異なるSQNSの後続のNAKは、前述のDLRに転送される場合があります（DLRへのインターフェースでそれらのNAKが見られないと仮定します）。
If a corresponding NCF is not received from the DLR within NAK_RPT_IVL, the network element MUST discard the redirecting information for the TSI and re-attempt to forward the NAK towards the PGM upstream neighbor.
対応するNCFがNAK_RPT_IVL内のDLRから受信されない場合、ネットワーク要素はTSIのリダイレクト情報を破棄し、NAKをPGMアップストリーム隣接に転送する必要があります。
If a NAK is received from the DLR for a requested SQN, the network element MUST discard the redirecting information for the SQN and re-attempt to forward the NAK towards the PGM upstream neighbor. The network element MAY still direct NAKs for different SQNs to the DLR.
要求されたSQNのDLRからNAKが受信された場合、ネットワーク要素はSQNのリダイレクト情報を破棄し、NAKをPGMの上流隣接に転送するために再攻撃する必要があります。ネットワーク要素は、DLRに異なるSQNSのNAKを依然として誘導する場合があります。
RDATA and NCFs from upstream DLRs will flow down the distribution tree. However, RDATA and NCFs from off-tree DLRs will be unicast to the network element. The network element will terminate the NCF, but MUST put the source's NLA and the group address into the network header and MUST add router alert before forwarding the RDATA packet to the distribution subtree.
上流のDLRからのrdataおよびNCFSは、分布ツリーを流れます。ただし、トリーオフツリーDLRのRDATAおよびNCFSは、ネットワーク要素のユニカストになります。ネットワーク要素はNCFを終了しますが、ソースのNLAとグループアドレスをネットワークヘッダーに配置する必要があり、RDATAパケットを配布サブツリーに転送する前にルーターアラートを追加する必要があります。
NULL NAKs from an off-tree DLR for an RDATA packet requested from that off-tree DLR MUST always be forwarded upstream. The network element can assume that these will arrive before the matching RDATA. Other NULL NAKs are forwarded only if matching repair state has not already been created. Network elements MUST NOT confirm or retry NULL NAKs and they MUST NOT add the receiving interface to the repair state. If a NULL NAK is used to initially create repair state, this fact must be recorded so that any subsequent non-NULL NAK will not be eliminated, but rather will be forwarded to provoke an actual repair. State created by a NULL NAK exists only for NAK_ELIM_IVL.
トゥリーオフツリーDLRのオフツリーDLRからのnull naksは、そのオフツリーDLRから要求されたRDATAパケットを常に上流に転送する必要があります。ネットワーク要素は、これらが一致するrdataの前に到着すると想定できます。他のNULL NAKは、一致する修理状態がまだ作成されていない場合にのみ転送されます。ネットワーク要素はNULL NAKを確認または再試行してはならず、受信インターフェイスを修理状態に追加してはなりません。null nakを使用して最初に修復状態を作成する場合、この事実を記録して、その後の非ヌルNAKが排除されず、実際の修理を引き起こすように転送されます。null nakによって作成された状態は、nak_elim_ivlのみで存在します。
These procedures are intended to be applied in instances where a receiver's first hop router on the reverse path to the source is not a PGM Network Element. So, receivers MUST ignore a redirecting POLR from a DLR on the same IP subnet that the receiver resides on, since this is likely to suffer identical loss to the receiver and so be useless. Therefore, these procedures are entirely OPTIONAL. A receiver MAY choose to ignore all redirecting POLRs since in cases where its first hop router on the reverse path is PGM capable, it would ignore them anyway. Also, note that receivers will never learn of off-tree DLRs.
これらの手順は、ソースへの逆パス上のレシーバーの最初のホップルーターがPGMネットワーク要素ではない場合に適用することを目的としています。したがって、受信者は、受信者と同じIPサブネットのDLRからのリダイレクトPOLRを無視する必要があります。したがって、これらの手順は完全にオプションです。レシーバーは、リバースパス上の最初のホップルーターがPGM対応である場合、とにかく無視するため、すべてのリダイレクトPOLRを無視することを選択できます。また、レシーバーはトリーオフツリーDLRを決して学習しないことに注意してください。
Upon receiving a redirecting POLR, receivers SHOULD record the redirecting information for the TSI, and MAY redirect subsequent NAKs for the same TSI to the network address provided in the redirecting POLR rather than to the PGM neighbor for the corresponding ODATA for which the receiver is requesting repair. Note, however, that a redirecting POLR is NOT regarded as matching the NAK that provoked it, so it does not complete the transmission of that NAK. Only a normal matching NCF can complete the transmission of a NAK.
Redirecting POLRを受信すると、受信機はTSIのリダイレクト情報を記録し、レシーバーが要求している対応するODATAに対してPGM隣接ではなく、リダイレクトPOLRで提供されるネットワークアドレスに同じTSIの後続のNAKをリダイレクトする必要があります。修理。ただし、リダイレクトPOLRは、それを引き起こしたNAKと一致するものとは見なされていないため、そのNAKの送信は完了しないことに注意してください。通常のNCFのみがNAKの送信を完了できます。
For subsequent NAKs, if the receiver has recorded redirection information for the corresponding TSI, it MAY change the destination network address of those NAKs and attempt to transmit them to the DLR. If a corresponding NCF is not received within NAK_RPT_IVL, the receiver MUST discard the redirecting information for the TSI and re-attempt to forward the NAK to the PGM neighbor for the original source of the missing ODATA.
その後のNAKの場合、受信者が対応するTSIのリダイレクト情報を記録した場合、それらのNAKの宛先ネットワークアドレスを変更し、それらをDLRに送信しようとする可能性があります。対応するNCFがNAK_RPT_IVL内で受信されない場合、受信者はTSIのリダイレクト情報を破棄し、不足しているODATAの元のソースのNAKをPGM隣人に転送する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLR's NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
Option Type = 0x07
オプションタイプ= 0x07
Option Length = 4 + NLA length
オプション長= 4 NLA長
DLR's NLA
DLRのNLA
The DLR's own unicast network address to which recipients of the redirecting POLR may direct subsequent NAKs.
リダイレクトPOLRの受信者がその後のNAKを指示する可能性のあるDLR独自のユニキャストネットワークアドレス。
OPT_REDIRECT is network-significant.
opt_redirectはネットワーク有意です。
The SYN option indicates the starting data packet for a session. It must only appear in ODATA or RDATA packets.
Synオプションは、セッションの開始データパケットを示します。Odataまたはrdataパケットにのみ表示する必要があります。
The SYN option MAY be used to provide a useful abstraction to applications that can simplify application design by providing stream start notification. It MAY also be used to let a late joiner to a session know that it is indeed late (i.e. it would not see the SYN option).
Synオプションは、ストリーム開始通知を提供することでアプリケーション設計を簡素化できるアプリケーションに有用な抽象化を提供するために使用できます。また、セッションの遅いジョイナーに実際に遅いことを知らせるためにも使用される場合があります（つまり、Synオプションが表示されません）。
Procedures for receivers are implementation dependent. A receiver MAY use the SYN to provide its applications with abstractions of the data stream.
受信機の手順は実装依存です。受信者は、Synを使用して、データストリームの抽象化をアプリケーションに提供する場合があります。
Sources MAY include OPT_SYN in the first data for a session. That is, they MAY include the option in:
ソースには、セッションの最初のデータにopt_synが含まれる場合があります。つまり、以下のオプションを含めることができます。
the first ODATA sent on a session by a PGM source
PGMソースによってセッションで送信された最初のOdata
any RDATA sent as a result of loss of this ODATA packet
このodataパケットの損失の結果として送信されたrdata
all FEC packets for the first transmission group; in this case it is interpreted as the first packet having the SYN
最初の送信グループのすべてのFECパケット。この場合、それはsynを持つ最初のパケットとして解釈されます
In an identical manner to sources, DLRs MUST provide OPT_SYN in any retransmitted data that is at the start of a session.
ソースと同一の方法で、DLRはセッションの開始時に再送信されたデータにopt_synを提供する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0D
オプションタイプ= 0x0d
Option Length = 4
オプション長= 4
OPT_SYN is NOT network-significant.
OPT_SYNはネットワーク有意ではありません。
This FIN option indicates the last data packet for a session and an orderly close down.
このFINオプションは、セッションの最後のデータパケットと秩序あるクローズダウンを示します。
The FIN option MAY be used to provide an abstraction to applications that can simplify application design by providing stream end notification.
FINオプションは、ストリームエンド通知を提供することでアプリケーション設計を簡素化できるアプリケーションに抽象化を提供するために使用できます。
This option MAY be present in the last data packet or transmission group for a session. The FIN PGM option MUST appear in every SPM sent after the last ODATA for a session. The SPM_LEAD sequence number in an SPM with the FIN option indicates the last known data successfully transmitted for the session.
このオプションは、セッションの最後のデータパケットまたは送信グループに存在する場合があります。FIN PGMオプションは、セッションのために最後のODATAの後に送信されたすべてのSPMに表示する必要があります。FINオプションを使用したSPMのSPM_LEADシーケンス番号は、セッションに正常に送信された最後の既知のデータを示します。
A receiver SHOULD use receipt of a FIN to let it know that it can tear down its data structures for the said session once a suitable time period has expired (TXW_SECS). It MAY still try to solicit retransmissions within the existing transmit window.
受信者は、FINの受領を使用して、適切な期間が失効したら、上記のセッションのデータ構造を取り壊すことができることを知らせる必要があります（TXW_SECS）。既存の送信ウィンドウ内の再送信を求めようとする場合があります。
Other than this, procedures for receivers are implementation dependent. A receiver MAY use the FIN to provide its applications with abstractions of the data stream and to inform its applications that the session is ending.
これ以外に、受信機の手順は実装依存です。受信者は、FINを使用して、データストリームの抽象化をアプリケーションに提供し、セッションが終了していることをアプリケーションに通知することができます。
9.7.2. OPT_FIN - Procedures - Sources
9.7.2. opt_fin-手順 - ソース
Sources MUST include OPT_FIN in every SPM sent after it has been determined that the application has closed gracefully. If a source is aware at the time of transmission that it is ending a session the source MAY include OPT_FIN in,
ソースは、アプリケーションが優雅に閉鎖されていると判断された後に送信されたすべてのSPMにopt_finを含める必要があります。ソースが送信時にセッションを終了していることを認識している場合、ソースにはopt_fin inが含まれる場合があります。
the last ODATA
最後のodata
any associated RDATAs for the last data
最後のデータの関連RDATA
FEC packets for the last transmission group; in this case it is interpreted as the last packet having the FIN
最後の伝送グループのFECパケット。この場合、FINを持つ最後のパケットとして解釈されます
When a source detects that it needs to send an OPT_FIN it SHOULD immediately send it. This is done either by appending it to the last data packet or transmission group or by immediately sending an SPM and resetting the SPM heartbeat timer (i.e. it does not wait for a timer to expire before sending the SPM). After sending an OPT_FIN, the session SHOULD not close and stop sending SPMs until after a time period equal to TXW_SECS.
ソースがOPT_FINを送信する必要があることを検出すると、すぐに送信する必要があります。これは、最後のデータパケットまたは送信グループに追加するか、すぐにSPMを送信してSPMのハートビートタイマーをリセットすることで行われます（つまり、SPMを送信する前にタイマーが期限切れになるのが待ちません）。OPT_FINを送信した後、セッションが閉じて、TXW_SECSに等しい期間が経過するまでSPMSの送信を停止する必要はありません。
In an identical manner to sources, DLRs MUST provide OPT_FIN in any retransmitted data that is at the end of a session.
ソースと同一の方法で、DLRはセッションの最後にある再送信データにopt_finを提供する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0E
オプションタイプ= 0x0e
Option Length = 4
オプション長= 4
OPT_FIN is NOT network-significant.
opt_finはネットワーク有意ではありません。
The RST option MAY appear in every SPM sent after an unrecoverable error is identified by the source. This acts to notify the receivers that the session is being aborted. This option MAY appear only in SPMs. The SPM_LEAD sequence number in an SPM with the RST option indicates the last known data successfully transmitted for the session.
RECOURVERのエラーがソースによって識別された後に送信されるすべてのSPMにRSTオプションが表示される場合があります。これは、セッションが中止されていることを受信者に通知するように機能します。このオプションは、SPMSでのみ表示される場合があります。RSTオプションを備えたSPMのSPM_LEADシーケンス番号は、セッションに正常に送信された最後の既知のデータを示します。
Receivers SHOULD treat the reception of OPT_RST in an SPM as an abort of the session.
受信者は、SPMでのOPT_RSTの受信をセッションの中止として扱う必要があります。
A receiver that receives an SPM with an OPT_RST with the N bit set SHOULD not send any more NAKs for the said session towards the source. If the N bit (see 9.8.5) is not set, the receiver MAY continue to try to solicit retransmit data within the current transmit window.
nビットセットを備えたOPT_RSTでSPMを受信したレシーバーは、そのセッションのためにソースに向かってこれ以上NAKを送信してはなりません。nビット（9.8.5を参照）が設定されていない場合、受信者は現在の送信ウィンドウ内の再送信データを求めようとし続けることがあります。
Sources SHOULD include OPT_RST in every SPM sent after it has been determined that an unrecoverable error condition has occurred. The N bit of the OPT_RST SHOULD only be sent if the source has determined that it cannot process NAKs for the session. The cause of the OPT_RST is set to an implementation specific value. If the error code is unknown, then the value of 0x00 is used. When a source detects that it needs to send an OPT_RST it SHOULD immediately send it. This is done by immediately sending an SPM and resetting the SPM heartbeat timer (i.e. it does not wait for a timer to expire before sending the SPM). After sending an OPT_RST, the session SHOULD not close and stop sending SPMs until after a time period equal to TXW_SECS.
ソースは、回復不能なエラー条件が発生したと判断された後に送信されたすべてのSPMにopt_rstを含める必要があります。OPT_RSTのNビットは、セッションのNAKを処理できないとソースが判断した場合にのみ送信する必要があります。OPT_RSTの原因は、実装固有の値に設定されます。エラーコードが不明の場合、0x00の値が使用されます。ソースがOPT_RSTを送信する必要があることを検出すると、すぐに送信する必要があります。これは、すぐにSPMを送信し、SPMのハートビートタイマーをリセットすることで行われます（つまり、SPMを送信する前にタイマーが期限切れになるのが待っていません）。OPT_RSTを送信した後、セッションは閉じて、TXW_SECSに等しい期間が経過するまでSPMSの送信を停止する必要はありません。
None.
なし。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U|N|Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0F
オプションタイプ= 0x0f
Option Length = 4
オプション長= 4
N bit
nビット
The N bit is set to 1 to indicate that NAKs for previous ODATA will go unanswered from the source. The application will tell the source to turn this bit on or off.
Nビットは1に設定されており、以前のODATAのNAKがソースから回答されていないことを示します。アプリケーションは、ソースにこのビットをオンまたはオフにするように指示します。
Error Code
エラーコード
The 6 bit error code field is used to forward an error code down to the receivers from the source.
6ビットエラーコードフィールドは、エラーコードをソースから受信機に転送するために使用されます。
The value of 0x00 indicates an unknown reset reason. Any other value indicates the application purposely aborted and gave a reason (the error code value) that may have meaning to the end receiver application. These values are entirely application dependent.
0x00の値は、未知のリセット理由を示します。その他の値は、アプリケーションが意図的に中止され、最終受信者アプリケーションに意味がある可能性のある理由（エラーコード値）を示しました。これらの値は完全にアプリケーションに依存します。
OPT_RST is NOT network-significant.
OPT_RSTはネットワーク有意ではありません。
In addition to the usual problems of end-to-end authentication, PGM is vulnerable to a number of security risks that are specific to the mechanisms it uses to establish source path state, to establish repair state, to forward NAKs, to identify DLRs, and to distribute repairs. These mechanisms expose PGM network elements themselves to security risks since network elements not only switch but also interpret SPMs, NAKs, NCFs, and RDATA, all of which may legitimately be transmitted by PGM sources, receivers, and DLRs. Short of full authentication of all neighboring sources, receivers, DLRs, and network elements, the protocol is not impervious to abuse.
エンドツーエンド認証の通常の問題に加えて、PGMは、ソースパス状態を確立し、修理状態を確立し、NAKを転送し、DLRを特定し、DLRを特定するために使用するメカニズムに固有の多くのセキュリティリスクに対して脆弱です。修理を配布します。ネットワーク要素はSPM、NAKS、NCFS、およびRDATAを解釈するだけでなく、PGMソース、レシーバー、DLRによって合法的に送信される可能性があるため、これらのメカニズムはPGMネットワーク要素をセキュリティリスクにさらします。近隣のすべてのソース、受信機、DLR、およびネットワーク要素の完全な認証がわずかであるため、プロトコルは乱用には影響を受けません。
So putting aside the problems of rogue PGM network elements for the moment, there are enough potential security risks to network elements associated with sources, receivers, and DLRs alone. These risks include denial of service through the exhausting of both CPU bandwidth and memory, as well as loss of (repair) data connectivity through the muddling of repair state.
したがって、今のところRogue PGMネットワーク要素の問題を除けば、ソース、レシーバー、およびDLRだけに関連するネットワーク要素に十分な潜在的なセキュリティリスクがあります。これらのリスクには、CPU帯域幅とメモリの両方の枯渇によるサービスの拒否、および修理状態の混乱による（修理）データ接続の喪失が含まれます。
False SPMs may cause PGM network elements to mis-direct NAKs intended for the legitimate source with the result that the requested RDATA would not be forthcoming.
誤ったSPMは、PGMネットワーク要素が正当なソースを目的としたNAKを誤った方向に誘導し、要求されたRDATAが近づかない結果です。
False NAKs may cause PGM network elements to establish spurious repair state that will expire only upon time-out and could lead to memory exhaustion in the meantime.
偽のNAKは、PGMネットワーク要素がタイムアウト時にのみ期限切れになり、その間にメモリの疲労につながる可能性のあるスプリアス修復状態を確立する可能性があります。
False NCFs may cause PGM network elements to suspend NAK forwarding prematurely (or to mis-direct NAKs in the case of redirecting POLRs) resulting eventually in loss of RDATA.
誤ったNCFは、PGMネットワーク要素がNAK転送を早期的に停止させる可能性があります（またはPOLRをリダイレクトする場合、NAKを誤った方向に導きます）により、最終的にRDATAの喪失が生じます。
False RDATA may cause PGM network elements to tear down legitimate repair state resulting eventually in loss of legitimate RDATA.
誤ったrdataは、PGMネットワーク要素に合法的な修復状態を取り壊す可能性があり、最終的には正当なRDATAの喪失になります。
The development of precautions for network elements to protect themselves against incidental or unsophisticated versions of these attacks is work outside of this spec and includes:
これらの攻撃の偶発的または洗練されていないバージョンから身を守るためのネットワーク要素の予防策の開発は、この仕様の外での作業であり、以下を含みます。
Damping of jitter in the value of either the network-header source address of SPMs or the path NLA in SPMs. While the network-header source address is expected to change seldom, the path NLA is expected to change occasionally as a consequence of changes in underlying multicast routing information.
SPMSのネットワークヘッダーソースアドレスまたはSPMSのパスNLAの値の値におけるジッターの減衰。ネットワークヘッドのソースアドレスはめったに変わることはないと予想されますが、根本的なマルチキャストルーティング情報の変更の結果として、NLAが時々変更されると予想されます。
The extension of NAK shedding procedures to control the volume, not just the rate, of confirmed NAKs. In either case, these procedures assist network elements in surviving NAK attacks at the expense of maintaining service. More efficiently, network elements may use the knowledge of TSIs and their associated transmit windows gleaned from SPMs to control the proliferation of repair state.
確認されたNAKのレートだけでなく、ボリュームを制御するためのNak Shedding手順の拡張。どちらの場合でも、これらの手順は、サービスを維持するためにNAK攻撃を生き延びたネットワーク要素を支援します。より効率的に、ネットワーク要素は、TSIの知識と、SPMから収集された関連する送信ウィンドウの知識を使用して、修復状態の増殖を制御する場合があります。
A three-way handshake between network elements and DLRs that would permit a network element to ascertain with greater confidence that an alleged DLR is identified by the alleged network-header source address, and is PGM conversant.
ネットワーク要素とDLRの間の3方向の握手により、ネットワーク要素が疑わしいDLRが疑いのあるネットワークヘッダーソースアドレスによって識別され、PGM Consentantであることをより高い自信を持って確認することができます。
The following procedures incorporate packet-level Reed Solomon Erasure correcting techniques as described in [11] and [12] into PGM. This approach to Forward Error Correction (FEC) is based upon the computation of h parity packets from k data packets for a total of n packets such that a receiver can reconstruct the k data packets out of any k of the n packets. The original k data packets are referred to as the Transmission Group, and the total n packets as the FEC Block.
次の手順には、[11]および[12]にPGMに説明されているように、パケットレベルのReed Solomon Solomon Erasure修正技術が組み込まれています。フォワードエラー補正（FEC）へのこのアプローチは、nパケットのnパケットのkデータパケットのHパリティパケットの計算に基づいて、受信者がnパケットの任意のkからkデータパケットを再構築できるようにします。元のKデータパケットは、伝送グループと呼ばれ、合計NパケットはFECブロックと呼ばれます。
These procedures permit any combination of pro-active FEC or on-demand FEC with conventional ARQ (selective retransmission) within a given TSI to provide any flavor of layered or integrated FEC. The two approaches can be used by the same or different receivers in a single transport session without conflict. Once provided by a source, the actual use of FEC or selective retransmission for loss recovery in the session is entirely at the discretion of the receivers. Note however that receivers SHOULD NOT ask for selective retransmissions when FEC is available, nevertheless sources MUST provide selective retransmissions in response to selective NAKs from the leading partial transmission group (i.e. the most recent transmission group, which is not yet full). For any group that is full, the source SHOULD provide FEC on demand in response to a selective NAK.
これらの手順では、特定のTSI内の従来のARQ（選択的再送信）との積極的なFECまたはオンデマンドFECの任意の組み合わせが、層状または統合されたFECのフレーバーを提供することを可能にします。2つのアプローチは、競合のない単一の輸送セッションで、同じまたは異なる受信機によって使用できます。ソースによって提供されると、セッションでの損失回収のためのFECの実際の使用または選択的再送信は、完全に受信者の裁量になります。ただし、FECが利用可能な場合、受信機は選択的な再送信を要求してはならないことに注意してください。それでも、ソースは、主要な部分伝送グループからの選択的NAK（つまり、まだ満たされていない最新の伝送グループ）からの選択的NAKに応答して選択的な再送信を提供する必要があります。いっぱいの任意のグループの場合、ソースは選択的なNAKに応じてFECオンデマンドを提供する必要があります。
Pro-active FEC refers to the technique of computing parity packets at transmission time and transmitting them as a matter of course following the data packets. Pro-active FEC is RECOMMENDED for providing loss recovery over simplex or asymmetric multicast channels over which returning repair requests is either impossible or costly. It provides increased reliability at the expense of bandwidth.
プロアクティブFECとは、伝送時にパリティパケットを計算し、当然のことながらデータパケットに従うように送信する手法を指します。積極的なFECは、リターンリクエストが不可能またはコストのいずれかであるシンプレックスまたは非対称マルチキャストチャネルを超える損失回復を提供するために推奨されます。帯域幅を犠牲にして信頼性を高めます。
On-demand FEC refers to the technique of computing parity packets at repair time and transmitting them only upon demand (i.e., receiver-based loss detection and repair request). On-demand FEC is RECOMMENDED for providing loss recovery of uncorrelated loss in very large receiver populations in which the probability of any single packet being lost is substantial. It provides equivalent reliability to selective NAKs (ARQ) at no more and typically less expense of bandwidth.
オンデマンドFECとは、修理時にパリティパケットを計算し、需要が発生した場合にのみ送信する技術（つまり、受信機ベースの損失検出および修理要求）を指します。オンデマンドFECは、単一のパケットが失われる可能性が大きい非常に大きな受信機集団で無相関損失の損失回収を提供するために推奨されます。これは、帯域幅の費用がこれ以上なく、帯域幅の費用が少なく、選択的NAK（ARQ）に同等の信頼性を提供します。
Selective NAKs are NAKs that request the retransmission of specific packets by sequence number corresponding to the sequence number of any data packets detected to be missing from the expected sequence (conventional ARQ). Selective NAKs can be used for recovering losses occurring in leading partial transmission groups, i.e. in the most recent transmission group, which is not yet full. The RECOMMENDED way of handling partial transmission groups, however, is for the data source to use variable-size transmission groups (see below).
選択的NAKは、予想されるシーケンス（従来のARQ）から欠落していると検出されたデータパケットのシーケンス番号に対応するシーケンス番号で特定のパケットの再送信を要求するNAKです。選択的NAKは、主要な部分伝送グループ、つまり最新の伝送グループで発生する損失の回復に使用できます。ただし、部分的な伝送グループを処理する推奨方法は、データソースが可変サイズの伝送グループを使用することです（以下を参照）。
Parity NAKs are NAKs that request the transmission of a specific number of parity packets by count corresponding to the count of the number of data packets detected to be missing from a group of k data packets (on-demand FEC).
パリティNAKは、Kデータパケットのグループ（オンデマンドFEC）のグループから欠落していると検出されたデータパケットの数の数に対応するカウントにより、特定の数のパリティパケットの伝送を要求するNAKです。
The objective of these procedures is to incorporate these FEC techniques into PGM so that:
これらの手順の目的は、これらのFEC技術をPGMに組み込むことです。
sources MAY provide parity packets either pro-actively or on-demand, interchangeably within the same TSI,
ソースは、同じTSI内で互換性があり、互換性があり、需要が高いパケットを提供する場合があります。
receivers MAY use either selective or parity NAKs interchangeably within the same TSI (however, in a session where on-demand parity is available receivers SHOULD only use parity NAKs).
受信機は、同じTSI内で選択的またはパリティNAKを互換性がある場合に使用できます（ただし、オンデマンドパリティが利用可能なセッションでは、受信者はパリティNAKのみを使用する必要があります）。
network elements maintain repair state based on either selective or parity NAKs in the same data structure, altering only search, RDATA constraint, and deletion algorithms in either case,
ネットワーク要素は、同じデータ構造内の選択的またはパリティNAKに基づいて修理状態を維持し、検索のみ、RDATA制約、および削除アルゴリズムのみを変更します。
and only OPTION additions to the basic packet formats are REQUIRED.
基本的なパケット形式へのオプションの追加のみが必要です。
Advertising FEC parameters in the transport session
トランスポートセッションでFECパラメーターを広告します
Sources add OPT_PARITY_PRM to SPMs to provide session-specific parameters such as the number of packets (TGSIZE == k) in a transmission group. This option lets receivers know how many packets there are in a transmission group, and it lets network elements sort repair state by transmission group number. This option includes an indication of whether pro-active and/or on-demand parity is available from the source.
ソースは、opt_parity_prmをSPMSに追加して、送信グループにパケット数（tgsize == k）などのセッション固有のパラメーターを提供します。このオプションにより、受信機が送信グループにあるパケットの数を知ることができ、ネットワーク要素は送信グループ番号ごとに修復状態をソートすることができます。このオプションには、積極的および/またはオンデマンドパリティがソースから利用できるかどうかを示すことが含まれています。
Distinguishing parity packets from data packets
パリティパケットをデータパケットと区別します
Sources send pro-active parity packets as ODATA (NEs do not forward RDATA unless a repair state is present) and on-demand parity packets as RDATA. A source MUST add OPT_PARITY to the ODATA/RDATA packet header of parity packets to permit network elements and receivers to distinguish them from data packets.
情報源は、積極的なパリティパケットをODATAとして送信します（修復状態が存在しない限り、NESはRDATAを転送しません）。ソースは、ParityパケットのODATA/RDATAパケットヘッダーにOPT_PARITYを追加して、ネットワーク要素とレシーバーがデータパケットと区別できるようにする必要があります。
Data and parity packet numbering
データとパリティパケットの番号付け
Parity packets MUST be calculated over a fixed number k of data packets known as the Transmission Group. Grouping of packets into transmission groups effectively partitions a packet sequence number into a high-order portion (TG_SQN) specifying the transmission group (TG), and a low-order portion (PKT_SQN) specifying the packet number (PKT-NUM in the range 0 through k-1) within that group. From an implementation point of view, it's handy if k, the TG size, is a power of 2. If so, then TG_SQN and PKT_SQN can be mapped side-by-side into the 32 bit SQN. log2(TGSIZE) is then the size in bits of PKT_SQN.
パリティパケットは、送信グループとして知られるデータパケットの固定数Kで計算する必要があります。送信グループへのパケットのグループ化パケットシーケンス番号を効果的に分割して、伝送グループ（TG）を指定する高次部分（TG_SQN）と、パケット番号（範囲0のPKT-Num）を指定する低次部分（PKT_SQN）を指定します。そのグループ内のk-1）を介して。実装の観点からは、TGサイズであるKが2のパワーである場合に便利です。もしそうなら、TG_SQNとPKT_SQNは32ビットSQNに並べてマッピングできます。log2（tgsize）は、pkt_sqnのビットのサイズです。
This mapping does not reduce the effective sequence number space since parity packets marked with OPT_PARITY allow the sequence space (PKT_SQN) to be completely reused in order to number the h parity packets, as long as h is not greater than k.
OPT_PARITYをマークしたパリティパケットにより、Hパリティパケットをkより大きくない限り、シーケンススペース（PKT_SQN）を完全に再利用できるようにするため、このマッピングは効果的なシーケンス番号スペースを削減しません。
In the case where h is greater than k, a source MUST add OPT_PARITY_GRP to any parity packet numbered j greater than k-1, specifying the number m of the group of k parity packets to which the packet belongs, where m is just the quotient from the integer division of j by k. Correspondingly, PKT-NUM for such parity packets is just j modulo k. In other words, when a source needs to generate more parity packets than there were original data packets (perhaps because of a particularly lossy line such that a receiver lost not only the original data but some of the parity RDATA as well), use the OPT_PARITY_GRP option in order to number and identify the transmission group of the extra packets that would exceed the normal sequential number space.
HがKよりも大きい場合、ソースはK-1より大きい番号Jにopt_parity_grpを追加する必要があります。kによるjの整数除算から。それに応じて、このようなパリティパケットのPKT-NumはJ Modulo kだけです。言い換えれば、ソースが元のデータパケットよりも多くのパリティパケットを生成する必要がある場合（おそらく、受信者が元のデータだけでなくパリティRDATAの一部も失ったように特に損失したラインのために）、opt_parity_grpを使用します）通常のシーケンシャル番号スペースを超える余分なパケットの送信グループを番号と識別するオプション。
Note that parity NAKs (and consequently their corresponding parity NCFs) MUST also contain the OPT_PARITY flag in the options field of the fixed header, and that in these packets, PKT_SQN MUST contain PKT_CNT, the number of missing packets, rather than PKT_NUM, the SQN of a specific missing packet. More on all this later.
パリティNAK（およびその結果、対応するパリティNCFS）には、固定ヘッダーのオプションフィールドにopt_parityフラグも含まれている必要があり、これらのパケットには、pkt_num、pkt_num、sqnではなくpkt_cnt、pkt_cntの数を含む必要があることに注意してください。特定の欠落パケットの。これについては後で詳しく説明します。
Variable Transmission Group Size
可変伝送グループサイズ
The transmission group size advertised in the OPT_PARITY_PRM option on SPMs MUST be a power of 2 and constant for the duration of the session. However, the actual transmission group size used MAY not be constant for the duration of the session, and MAY not be a power of 2. When a TG size different from the one advertised in OPT_PARITY_PRM is used, the TG size advertised in OPT_PARITY_PRM MUST be interpreted as specifying the maximum effective size of the TG.
SPMSのOPT_PARITY_PRMオプションで宣伝されている送信グループサイズは、セッションの期間中は2のパワーと一定のパワーでなければなりません。ただし、使用される実際の伝送グループサイズは、セッションの期間中は一定ではなく、2のパワーではない場合があります。OPT_PARITY_PRMで宣伝されているものとは異なるTGサイズが使用されている場合、OPT_PARITY_PRMで宣伝されているTGサイズはTGの最大有効サイズを指定するものとして解釈されます。
When the actual TG size is not a power of 2 or is smaller than the max TG size, there will be sparse utilization of the sequence number space since some of the sequence numbers that would have been consumed in numbering a maximum sized TG will not be assigned to packets in the smaller TG. The start of the next transmission group will always begin on the boundary of the maximum TG size as though each of the sequence numbers had been utilized.
実際のTGサイズが2のパワーではない、または最大TGサイズよりも小さい場合、最大サイズのTGの番号付けで消費されるシーケンス番号の一部はそうではないため、シーケンス番号スペースのスパース利用があります小さいTGのパケットに割り当てられています。次の伝送グループの開始は、それぞれのシーケンス番号が利用されているかのように、常に最大TGサイズの境界で開始されます。
When the source decides to use a smaller group size than that advertised in OPT_PARITY_PRM, it appends OPT_CURR_TGSIZE to the last data packet (ODATA) in the truncated transmission group. This lets the receiver know that it should not expect any more packets in this transmission group, and that it may start requesting repairs for any missing packets. If the last data packet itself went missing, the receiver will detect the end of the group when it receives a parity packet for the group, an SPM with SPM_LEAD equal to OD_SQN of the last data packet, or the first packet of the next group, whichever comes first. In addition, any parity packet from this TG will also carry the OPT_CURR_TGSIZE option as will any SPM sent with SPM_LEAD equal to OD_SQN of the last data packet.
ソースがOPT_PARITY_PRMで宣伝されているものよりも小さなグループサイズを使用することを決定すると、切り捨てられた伝送グループの最後のデータパケット（ODATA）にopt_curr_tgsizeを追加します。 これにより、レシーバーは、この送信グループにこれ以上のパケットを期待してはならず、欠落しているパケットの修理を要求し始める可能性があることを知らせることができます。 最後のデータパケット自体が欠落した場合、レシーバーはグループのパリティパケットを受信すると、グループの終了、最後のデータパケットのOD_SQNに等しいSPMを持つSPM、または次のグループの最初のパケットを検出します。 いずれか早い方。 さらに、このTGからのパリティパケットは、最後のデータパケットのOD_SQNに等しいSPM_LEADで送信されるSPMと同様に、OPT_CURR_TGSIZEオプションも搭載されます。
Variable TSDU length
可変TSDU長
If a non constant TSDU length is used within a given transmission group, the size of parity packets in the corresponding FEC block MUST be equal to the size of the largest original data packet in the block. Parity packets MUST be computed by padding the original packets with zeros up to the size of the largest data packet. Note that original data packets are transmitted without padding.
特定の伝送グループ内で非定数TSDUの長さが使用されている場合、対応するFECブロック内のパリティパケットのサイズは、ブロック内の最大の元のデータパケットのサイズに等しくなければなりません。パリティパケットは、最大のデータパケットのサイズまでゼロを添加した元のパケットをパディングして計算する必要があります。元のデータパケットはパディングなしで送信されることに注意してください。
Receivers using a combination of original packets and FEC packets to rebuild missing packets MUST pad the original packets in the same way as the source does. The receiver MUST then feed the padded original packets plus the parity packets to the FEC decoder. The decoder produces the original packets padded with zeros up to the size of the largest original packet in the group. In order for the receiver to eliminate the padding on the reconstructed data packets, the original size of the packet MUST be known, and this is accomplished as follows:
不足しているパケットを再構築するために元のパケットとFECパケットの組み合わせを使用したレシーバーは、ソースと同じ方法で元のパケットをパッドする必要があります。レシーバーは、パッド入りの元のパケットとパリティパケットをFECデコーダーに送る必要があります。デコーダーは、グループ内の最大のオリジナルパケットのサイズまでゼロでパッド入りの元のパケットを生成します。受信機が再構築されたデータパケットのパディングを排除するためには、パケットの元のサイズを把握する必要があり、これは次のように達成されます。
The source, along with the packet payloads, encodes the TSDU length and appends the 2-byte encoded length to the padded FEC packets.
ソースは、パケットペイロードとともに、TSDUの長さをエンコードし、2バイトのエンコードされた長さをパッド入りのFECパケットに追加します。
Receivers pad the original packets that they received to the largest original packet size and then append the TSDU length to the padded packets. They then pass them and the FEC packets to the FEC decoder.
受信機は、最大の元のパケットサイズに受け取った元のパケットをパッドし、PADDEDパケットにTSDUの長さを追加します。次に、それらを渡し、FECパケットをFECデコーダーに渡します。
The decoder produces padded original packets with their original TSDU length appended. Receivers MUST now use this length to get rid of the padding.
デコーダーは、元のTSDU長さが追加されたパッド入りの元のパケットを生成します。レシーバーは、この長さを使用してパディングを取り除く必要があります。
A source that transmits variable size packets MUST take into account the fact that FEC packets will have a size equal to the maximum size of the original packets plus the size of the length field (2 bytes).
可変サイズのパケットを送信するソースは、FECパケットが元のパケットの最大サイズと長さフィールドのサイズ（2バイト）に等しいサイズになるという事実を考慮する必要があります。
If a fixed packet size is used within a transmission group, the encoded length is not appended to the parity packets. The presence of the fixed header option flag OPT_VAR_PKTLEN in parity packets allows receivers to distinguish between transmission groups with variable sized packets and fixed-size ones, and behave accordingly.
送信グループ内で固定パケットサイズが使用されている場合、エンコードされた長さはパリティパケットに追加されません。固定ヘッダーオプションフラグの存在Parityパケットのopt_var_pktlenにより、受信機は可変サイズのパケットと固定サイズのパケットを持つ伝送グループを区別し、それに応じて動作します。
Payload-specific options
ペイロード固有のオプション
Some options present in data packet (ODATA and RDATA) are strictly associated with the packet content (PGM payload), OPT_FRAGMENT being an example. These options must be preserved even when the data packet that would normally contain them is not received, but its the payload is recovered though the use of FEC.
データパケット（ODATAおよびRDATA）に存在するいくつかのオプションは、パケットコンテンツ（PGMペイロード）に厳密に関連付けられており、OPT_FRAGMENTは例です。これらのオプションは、通常それらを含むデータパケットが受信されない場合でも保存する必要がありますが、そのペイロードはFECの使用で回復します。
To achieve this, PGM encodes the content of these options in special options that are inserted in parity packets. Two flags present in the the option common-header are used for this process: bit F (OP_ENCODED) and bit U (OP_ENCODED_NULL).
これを達成するために、PGMは、パリティパケットに挿入された特別なオプションでこれらのオプションのコンテンツをエンコードします。オプションに存在する2つのフラグは、このプロセスに使用されます：ビットf（op_encoded）とビットu（op_encoded_null）。
Whenever at least one of the original packets of a TG contains a payload-specific option of a given type, the source MUST include an encoded version of that option type in all the parity packets it transmits. The encoded option is computed by applying FEC encoding to the whole option with the exception of the first three bytes of the option common-header (E, Option Type, Option Length, OP_ENCODED and OPX fields). The type, length and OPX of the encoded option are the same as the type, length and OPX in the original options. OP_ENCODED is set to 1 (all original option have OP_ENCODED = 0).
TGの元のパケットの少なくとも1つに、特定のタイプのペイロード固有のオプションが含まれている場合は、ソースに送信するすべてのパリティパケットにそのオプションタイプのエンコードされたバージョンを含める必要があります。エンコードされたオプションは、オプション共通ヘッダー（e、オプションタイプ、オプション長、OP_ENCODED、およびOPXフィールド）の最初の3バイトを除き、オプション全体にFECエンコードを適用することにより計算されます。エンコードされたオプションのタイプ、長さ、およびOPXは、元のオプションのタイプ、長さ、およびOPXと同じです。op_encodedは1に設定されています（すべてのオリジナルオプションにはop_encoded = 0があります）。
The encoding is performed using the same process that is used to compute the payload of the parity packet. i.e. the FEC encoder is fed with one copy of that option type for each original packet in the TG. If one (or more) original packet of the TG does not contain that option type, an all zeroes option is used for the encoding process. To be able to distinguish this "dummy" option from valid options with all-zeroes payload, OP_ENCODED_NULL is used. OP_ENCODED_NULL is set to 0 in all the original options, but the value of 1 is used in the encoding process if the option did not exist in the original packet. On the receiver side, all option with OP_ENCODED_NULL equal to 1 are discarded after decoding.
エンコードは、パリティパケットのペイロードを計算するために使用される同じプロセスを使用して実行されます。つまり、FECエンコーダーには、TGの元のパケットごとにそのオプションタイプのコピーが1つあります。TGの1つ（またはそれ以上）の元のパケットにそのオプションタイプが含まれていない場合、エンコーディングプロセスにAll Zeroesオプションが使用されます。この「ダミー」オプションをAll-Zeroes Payloadで有効なオプションと区別できるようにするには、op_encoded_nullが使用されます。OP_ENCODED_NULLはすべての元のオプションで0に設定されていますが、オプションが元のパケットに存在しなかった場合、1の値はエンコードプロセスで使用されます。受信側では、OP_ENCODED_NULLが1に等しいすべてのオプションがデコード後に破棄されます。
When a receiver recovers a missing packet using FEC repair packets, it MUST also recover payload-specific options, if any. The presence of these can be unequivocally detected through the presence of encoded options in parity packets (encoded options have OP_ENCODED set to 1). Receivers apply FEC-recovery to encoded options and possibly original options, as they do to recover packet payloads. The FEC decoding is applied to the whole option with the exception of the first three bytes of the option common-header (E, Option Type, Option Length, OP_ENCODED and OPX fields). Each decoded option is associated with the relative payload, unless OP_ENCODED_NULL turns out to be 1, in which case the decoded option is discarded.
受信者がFEC修理パケットを使用して欠落したパケットを回復する場合、もしあればペイロード固有のオプションを回復する必要があります。これらの存在は、パリティパケットにエンコードされたオプションが存在することで明確に検出できます（エンコードされたオプションには、OP_ENCODED SETが1に設定されています）。受信者は、パケットペイロードを回復するために行うように、エンコードされたオプションと場合によっては元のオプションにFEC回復を適用します。FECデコードは、オプション共通ヘッダー（E、オプションタイプ、オプション長、OP_ENCODED、およびOPXフィールド）の最初の3バイトを除き、オプション全体に適用されます。op_encoded_nullが1であることが判明しない限り、各デコードされたオプションは相対ペイロードに関連付けられています。この場合、デコードされたオプションが破棄されます。
The decoding MUST be performed using the 1st occurrence of a given option type in original/parity packets. If one or more original packets do not contain that option type, an option of the same type with zero value must be used. This option MUST have OP_ENCODED_NULL equal to 1.
デコードは、元の/パリティパケットの特定のオプションタイプの最初の発生を使用して実行する必要があります。1つ以上の元のパケットにそのオプションタイプが含まれていない場合、値がゼロの同じタイプのオプションを使用する必要があります。このオプションは、op_encoded_nullが1に等しい必要があります。
This section just provides enough short-hand to make the Procedures intelligible. For the full details of packet contents, please refer to Packet Formats below.
このセクションでは、手順をわかりやすくするのに十分な短い手を提供します。パケットコンテンツの詳細については、以下のパケット形式を参照してください。
OPT_PARITY indicated in pro-active (ODATA) and on-demand (RDATA) parity packets to distinguish them from data packets. This option is directly encoded in the "Option" field of the fixed PGM header
Pro-Active（ODATA）およびオンデマンド（RDATA）パリティパケットに示されているOpt_Parityは、データパケットと区別します。このオプションは、固定されたPGMヘッダーの「オプション」フィールドに直接エンコードされています
OPT_VAR_PKTLEN MAY be present in pro-active (ODATA) and on-demand (RDATA) parity packets to indicate that the corresponding transmission group is composed of variable size data packets. This option is directly encoded in the "Option" field of the fixed PGM header
opt_var_pktlenは、対応する伝送グループが可変サイズデータパケットで構成されていることを示すために、プロアクティブ（ODATA）およびオンデマンド（RDATA）パリティパケットに存在する場合があります。このオプションは、固定されたPGMヘッダーの「オプション」フィールドに直接エンコードされています
OPT_PARITY_PRM appended by sources to SPMs to specify session-specific parameters such as the transmission group size and the availability of pro-active and/or on-demand parity from the source
SPMSにソースによってアプリされたOPT_PARITY_PRMは、送信グループのサイズやソースからのプロアクティブおよび/またはオンデマンドパリティの可用性などのセッション固有のパラメーターを指定します
OPT_PARITY_GRP the number of the group (greater than 0) of h parity packets to which the parity packet belongs when more than k parity packets are provided by the source
opt_parity_grp kパリティパケットがソースによって提供されるときにパリティパケットが属するパリティパケットのグループの数（0より大きい）
OPT_CURR_TGSIZE appended by sources to the last data packet and any parity packets in a variable sized transmission group to indicate to the receiver the actual size of a transmission group. May also be appended to certain SPMs
ソースが最後のデータパケットと可変サイズの伝送グループのパリティパケットにソースによって追加されたOPT_CURR_TGSIZEは、送信グループの実際のサイズを受信者に示すためにアプリされます。特定のSPMに追加される場合もあります
NAK_TG_SQN the high-order portion of NAK_SQN specifying the transmission group for which parity packets are requested
nak_tg_sqnパリティパケットが要求される伝送グループを指定するNAK_SQNの高次部分
NAK_PKT_CNT the low-order portion of NAK_SQN specifying the number of missing data packets for which parity packets are requested
nak_pkt_cntパリティパケットが要求される欠落データパケットの数を指定するnak_sqnの低い部分
Nota Bene: NAK_PKT_CNT (and NCF_PKT_CNT) are 0-based counters, meaning that NAK_PKT_CNT = 0 means that 1 FEC RDATA is being requested, and in general NAK_PKT_CNT = k - 1 means that k FEC RDATA are being requested.
Nota Bene：Nak_pkt_cnt（およびncf_pkt_cnt）は0ベースのカウンターです。つまり、nak_pkt_cnt = 0は1 fec rdataが要求されていることを意味します。
NCF_TG_SQN the high-order portion of NCF_SQN specifying the transmission group for which parity packets were requested
NCF_TG_SQNパリティパケットが要求された伝送グループを指定するNCF_SQNの高次部分
NCF_PKT_CNT the low-order portion of NCF_SQN specifying the number of missing data packets for which parity packets were requested
ncf_pkt_cntパリティパケットが要求された欠損データパケットの数を指定するNCF_SQNの低次部分
Nota Bene: NCF_PKT_CNT (and NAK_PKT_CNT) are 0-based counters, meaning that NAK_PKT_CNT = 0 means that 1 FEC RDATA is being requested, and in general NAK_PKT_CNT = k - 1 means that k FEC RDATA are being requested.
NOTA BENE：NCF_PKT_CNT（およびNAK_PKT_CNT）は0ベースのカウンターです。つまり、NAK_PKT_CNT = 0は1 FEC RDATAが要求されていることを意味します。
RDATA_TG_SQN the high-order portion of RDATA_SQN specifying the transmission group to which the parity packet belongs
rdata_tg_sqnパリティパケットが属する伝送グループを指定するrdata_sqnの高次部分
RDATA_PKT_SQN the low-order portion of RDATA_SQN specifying the parity packet sequence number within the transmission group
RDATA_PKT_SQN送信グループ内のパリティパケットシーケンス番号を指定するRDATA_SQNの低次部分
ODATA_TG_SQN the high-order portion of ODATA_SQN specifying the transmission group to which the parity packet belongs
odata_tg_sqnパリティパケットが属する伝送グループを指定するodata_sqnの高次部分
ODATA_PKT_SQN the low-order portion of ODATA_SQN specifying the parity packet sequence number within the transmission group
ODATA_PKT_SQN送信グループ内のパリティパケットシーケンス番号を指定するODATA_SQNの低次部分
If a source elects to provide parity for a given transport session, it MUST first provide the transmission group size PARITY_PRM_TGS in the OPT_PARITY_PRM option of its SPMs. This becomes the maximum effective transmission group size in the event that the source elects to send smaller size transmission groups. If a source elects to provide proactive parity for a given transport session, it MUST set PARITY_PRM_PRO in the OPT_PARITY_PRM option of its SPMs. If a source elects to provide on-demand parity for a given transport session, it MUST set PARITY_PRM_OND in the OPT_PARITY_PRM option of its SPMs.
ソースが特定の輸送セッションにパリティを提供することを選択した場合、最初にSPMSのOPT_PARITY_PRMオプションで送信グループサイズPARITY_PRM_TGSを提供する必要があります。これは、ソースがより小さなサイズの伝送グループを送信することを選択した場合の最大有効伝送グループサイズになります。ソースが特定の輸送セッションに積極的なパリティを提供することを選択した場合、SPMSのOPT_PARITY_PRMオプションでPARITY_PRM_PROを設定する必要があります。ソースが特定の輸送セッションにオンデマンドパリティを提供することを選択した場合、SPMSのOPT_PARITY_PRMオプションにPARITY_PRM_ONDを設定する必要があります。
A source MUST send any pro-active parity packets for a given transmission group only after it has first sent all of the corresponding k data packets in that group. Pro-active parity packets MUST be sent as ODATA with OPT_PARITY in the fixed header.
ソースは、そのグループ内の対応するKデータパケットをすべて送信した後にのみ、特定の伝送グループに積極的なパリティパケットを送信する必要があります。固定ヘッダーにOPT_PARITYを使用して、積極的なパリティパケットをODATAとして送信する必要があります。
If a source elects to provide on-demand parity, it MUST respond to a parity NAK for a transmission group with a parity NCF. The source MUST complete the transmission of the k original data packets and the proactive parity packets, possibly scheduled, before starting the transmission of on-demand parity packets. Subsequently, the source MUST send the number of parity packets requested by that parity NAK. On-demand parity packets MUST be sent as RDATA with OPT_PARITY in the fixed header. Previously transmitted pro-active parity packets cannot be reused as on-demand parity packets, these MUST be computed with new, previously unused, indexes.
ソースがオンデマンドパリティを提供することを選択した場合、パリティNCFを持つ送信グループのパリティNAKに応答する必要があります。ソースは、オンデマンドパリティパケットの送信を開始する前に、おそらくスケジュールされたProactiveパリティパケットの送信を完了する必要があります。その後、ソースは、そのパリティNAKが要求したパリティパケットの数を送信する必要があります。オンデマンドパリティパケットは、固定ヘッダーにOPT_PARITYを使用してRDATAとして送信する必要があります。以前に送信されたプロアクティブパリティパケットは、オンデマンドパリティパケットとして再利用できません。これらは、以前に使用されていない新しいインデックスで計算する必要があります。
In either case, the source MUST provide selective retransmissions only in response to selective NAKs from the leading partial transmission group. For any group that is full, the source SHOULD provide FEC on demand in response to a selective retransmission request.
どちらの場合でも、ソースは、主要な部分伝送グループからの選択的NAKに応答してのみ、選択的な再送信を提供する必要があります。いっぱいの任意のグループの場合、ソースは選択的な再送信要求に応じてFECオンデマンドを提供する必要があります。
In the absence of data to transmit, a source SHOULD prematurely terminate the current transmission group by including OPT_CURR_TGSIZE to the last data packet or to any proactive parity packets provided.
送信するデータがない場合、ソースは、opt_curr_tgsizeを最後のデータパケットまたは提供されたプロアクティブパリティパケットに含めることにより、現在の伝送グループを早期に終了する必要があります。
If the last data packet has already been transmitted and there is no provision for sending proactive parity packets, an SPM with OPT_CURR_TGSIZE SHOULD be sent.
最後のデータパケットが既に送信されており、プロアクティブパリティパケットを送信するための規定がない場合は、OPT_CURR_TGSIZEを備えたSPMを送信する必要があります。
A source consolidates requests for on-demand parity in the same transmission group according to the following procedures. If the number of pending (i.e., unsent) parity packets from a previous request for on-demand parity packets is equal to or greater than NAK_PKT_CNT in a subsequent NAK, that subsequent NAK MUST be confirmed but MAY otherwise be ignored. If the number of pending (i.e., unsent) parity packets from a previous request for on-demand parity packets is less than NAK_PKT_CNT in a subsequent NAK, that subsequent NAK MUST be confirmed but the source need only increase the number of pending parity packets to NAK_PKT_CNT.
ソースは、以下の手順に従って、同じ伝送グループのオンデマンドパリティのリクエストを統合します。オンデマンドパリティパケットの以前のリクエストからの保留中の（つまり、無関係の）パリティパケットの数が、その後のNAKのNAK_PKT_CNT以上である場合、その後のNAKを確認する必要がありますが、それ以外の場合は無視される場合があります。オンデマンドパリティパケットの以前のリクエストからの保留中の（つまり、無関心な）パリティパケットの数がその後のNAKのNAK_PKT_CNTよりも少ない場合、その後のNAKを確認する必要がありますが、ソースは保留中のパリティパケットの数を増やすだけですnak_pkt_cnt。
When a source provides parity packets relative to a transmission group with variable sized packets, it MUST compute parity packets by padding the smaller original packets with zeroes out to the size of the largest of the original packets. The source MUST also append the encoded TSDU lengths at the end of any padding or directly to the end of the largest packet, and add the OPT_VAR_PKTLEN option as specified in the overview description.
ソースが可変サイズのパケットを備えたトランスミッショングループに比べてパリティパケットを提供する場合、ゼロが最大のオリジナルパケットのサイズまでゼロを備えた小さな元のパケットをパディングしてパリティパケットを計算する必要があります。また、ソースは、パディングの最後に、または最大のパケットの最後に直接エンコードされたTSDUの長さを追加し、概要の説明で指定されているようにopt_var_pktlenオプションを追加する必要があります。
When a source provides variable sized transmission groups, it SHOULD append the OPT_CURR_TGSIZE option to the last data packet in the shortened group, and it MUST append the OPT_CURR_TGSIZE option to any parity packets it sends within that group. In case the the last data packet is sent before a determination has been made to shorten the group and there is no provision for sending proactive parity packets, an SPM with OPT_CURR_TGSIZE SHOULD be sent. The source MUST also add OPT_CURR_TGSIZE to any SPM that it sends with SPM_LEAD equal to OD_SQN of the last data packet.
ソースが可変サイズの伝送グループを提供する場合、短縮グループの最後のデータパケットにopt_curr_tgsizeオプションを追加する必要があり、そのグループ内で送信するパリティパケットにopt_curr_tgsizeオプションを追加する必要があります。グループを短縮する決定が行われる前に最後のデータパケットが送信され、プロアクティブパリティパケットを送信する規定がない場合は、OPT_CURR_TGSIZEを備えたSPMを送信する必要があります。また、ソースは、opt_curr_tgsizeを最後のデータパケットのod_sqnに等しいspm_leadで送信する任意のSPMに追加する必要があります。
A receiver MUST NAK for the entire number of packets missing based on the maximum TG size, even if it already knows that the actual TG size is smaller. The source MUST take this into account and compute the number of packets effectively needed as the difference between NAK_PKT_CNT and an offset computed as the difference between the max TG size and the effective TG size.
レシーバーは、実際のTGサイズが小さくなっていることがすでにわかっていても、最大TGサイズに基づいて欠落しているパケットの全体の数をNAKする必要があります。ソースは、これを考慮に入れて、NAK_PKT_CNTとMAX TGサイズと有効なTGサイズの違いとして計算されたオフセットの違いとして効果的に必要なパケットの数を計算する必要があります。
If a receiver elects to make use of parity packets for loss recovery, it MUST first learn the transmission group size PARITY_PRM_TGS from OPT_PARITY_PRM in the SPMs for the TSI. The transmission group size is used by a receiver to determine the sequence number boundaries between transmission groups.
受信者が損失回復のためにパリティパケットを使用することを選択した場合、最初にTSIのSPMSのOPT_PARITY_PRMから送信グループサイズPARITY_PRM_TGSを学習する必要があります。トランスミッショングループのサイズは、受信機によって使用されて、伝送グループ間のシーケンス番号境界を決定します。
Thereafter, if PARITY_PRM_PRO is also set in the SPMs for the TSI, a receiver SHOULD use any pro-active parity packets it receives for loss recovery, and if PARITY_PRM_OND is also set in the SPMs for the TSI, it MAY solicit on-demand parity packets upon loss detection. If PARITY_PRM_OND is set, a receiver MUST NOT send selective NAKs, except in partial transmission groups if the source does not use the variable transmission-group size option. Parity packets are ODATA (pro-active) or RDATA (on-demand) packets distinguished by OPT_PARITY which lets receivers know that ODATA/RDATA_TG_SQN identifies the group of PARITY_PRM_TGS packets to which the parity may be applied for loss recovery in the corresponding transmission group, and that ODATA/RDATA_PKT_SQN is being reused to number the parity packets within that group. Receivers order parity packets and eliminate duplicates within a transmission group based on ODATA/RDATA_PKT_SQN and on OPT_PARITY_GRP if present.
その後、PARITY_PRM_PROがTSIのSPMSにも設定されている場合、受信者は損失回収のために受け取る積極的なパリティパケットを使用する必要があります。損失検出時のパケット。PARITY_PRM_ONDが設定されている場合、ソースが変数送信グループサイズオプションを使用しない場合、部分伝送グループを除き、受信者は選択的なNAKを送信してはなりません。パリティパケットは、ODATA/RDATA_PARITYで区別されるODATA（プロアクティブ）またはRDATA（オンデマンド）パケットです。そして、そのodata/rdata_pkt_sqnは、そのグループ内のパリティパケットを数えるために再利用されています。受信者は、odata/rdata_pkt_sqnおよびopt_parity_grpに基づいて、伝送グループ内のパリティパケットを注文および排除します。
To solicit on-demand parity packets, a receiver MUST send parity NAKs upon loss detection. For the purposes of soliciting on-demand parity, loss detection occurs at transmission group boundaries, i.e. upon receipt of the last data packet in a transmission group, upon receipt of any data packet in any subsequent transmission group, or upon receipt of any parity packet in the current or a subsequent transmission group.
オンデマンドパリティパケットを募るには、レシーバーは損失検出時にパリティNAKを送信する必要があります。オンデマンドパリティを勧誘する目的で、トランスミッショングループの境界で損失検出が発生します。つまり、送信グループの最後のデータパケットを受け取ったとき、後続の伝送グループでデータパケットを受け取るとき、またはパリティパケットの受領時に発生します。現在またはその後の伝送グループで。
A parity NAK is simply a NAK with OPT_PARITY and NAK_PKT_CNT set to the count of the number of packets detected to be missing from the transmission group specified by NAK_TG_SQN. Note that this constrains the receiver to request no more parity packets than there are data packets in the transmission group.
パリティNAKは、opt_parityとnak_pkt_cntを備えたNAKであり、NAK_TG_SQNによって指定された送信グループから欠落していると検出されたパケットの数の数に設定されています。これにより、受信機は、送信グループにデータパケットがあるよりもパリティパケットを要求しないように制約します。
A receiver SHOULD bias the value of NAK_BO_IVL for parity NAKs inversely proportional to NAK_PKT_CNT so that NAKs for larger losses are likely to be scheduled ahead of NAKs for smaller losses in the same receiver population.
受信者は、パリティNAKのNAK_BO_IVLの値にNAK_PKT_CNTに反比例するようにバイアスする必要があります。これにより、より大きな損失のNAKSが、同じ受信者集団の少ない損失のためにNAKSに先立ってスケジュールされる可能性があります。
A confirming NCF for a parity NAK is a parity NCF with NCF_PKT_CNT equal to or greater than that specified by the parity NAK.
パリティNAKのNCFを確認するのは、パリティNAKが指定したものと等しいNCF_PKT_CNTを備えたパリティNCFです。
A receiver's NAK_RDATA_IVL timer is not cancelled until all requested parity packets have been received.
レシーバーのNAK_RDATA_IVLタイマーは、要求されたすべてのパリティパケットが受信されるまでキャンセルされません。
In the absence of data (detected from SPMs bearing SPM_LEAD equal to RXW_LEAD) on non-transmission-group boundaries, receivers MAY resort to selective NAKs for any missing packets in that partial transmission group.
非伝送グループの境界でデータ（RXW_LEADに等しいSPM_LEADを持つSPMから検出）がない場合、受信機は、その部分伝送グループの欠落パケットの選択的NAKに頼ることができます。
When a receiver handles parity packets belonging to a transmission group with variable sized packets, (detected from the presence of the OPT_VAR_PKTLEN option in the parity packets), it MUST decode them as specified in the overview description and use the decoded TSDU length to get rid of the padding in the decoded packet.
受信者が、可変サイズのパケットを持つトランスミッショングループに属するパリティパケットを処理する場合（パリティパケットのopt_var_pktlenオプションの存在から検出）、概要の説明で指定されたようにそれらをデコードし、デコードされたTSDUの長さを使用して削除する必要があります。デコードされたパケットのパディングの。
If the source was using a variable sized transmission group via the OPT_CURR_TGSIZE, the receiver might learn this before having requested (and received) any retransmission. The above happens if it sees OPT_CURR_TGSIZE in the last data packet of the TG, in any proactive parity packet or in a SPM. If the receivers learns this and determines that it has missed one or more packets in the shortened transmission group, it MAY then NAK for them without waiting for the start of the next transmission group. Otherwise it will start NAKing at the start of the next transmission group.
ソースがOPT_CURR_TGSIZEを介して可変サイズの伝送グループを使用していた場合、受信者は再送信を要求（および受信）する前にこれを学習する場合があります。上記は、TGの最後のデータパケット、プロアクティブパリティパケット、またはSPMでopt_curr_tgsizeが表示される場合に発生します。レシーバーがこれを学習し、短縮伝送グループの1つ以上のパケットを逃したと判断した場合、次の送信グループの開始を待たずにそれらのためにNAKを使用する可能性があります。それ以外の場合は、次の伝送グループの開始時にネーキングを開始します。
In both cases, the receiver MUST NAK for the number of packets missing assuming that the size of the transmission group is the maximum effective transmission group. In other words, the receivers cannot exploit the fact that it might already know that the transmission group was smaller but MUST always NAK for the number of packets it believes are missing, plus the number of packets required to bring the total packets up to the maximum effective transmission group size.
どちらの場合も、受信機は、伝送グループのサイズが最大有効伝送グループであると仮定して、欠落しているパケットの数に対してNAKをnakする必要があります。言い換えれば、受信機は、送信グループが小さいことをすでに知っているかもしれないが、欠落していると思われるパケットの数と、合計パケットを最大まで上げるために必要なパケットの数については常にNAKをnakする必要があるという事実を活用することはできません。効果的な伝送グループサイズ。
After the first parity packet has been delivered to the receiver, the actual TG size is known to him, either because already known or because discovered via OPT_CURR_TGSIZE contained in the parity packet. Hence the receiver can decode the whole group as soon as the minimum number of parity packets needed is received.
最初のパリティパケットがレシーバーに配信された後、実際のTGサイズは、すでに知られているか、パリティパケットに含まれるOPT_CURR_TGSIZEを介して発見されたために彼に知られています。したがって、受信者は、必要なパリティパケットの最小数を受信するとすぐにグループ全体をデコードできます。
Pro-active parity packets (ODATA with OPT_PARITY) are switched by network elements without transport-layer intervention.
積極的なパリティパケット（OPT_PARITY付きODATA）は、輸送層の介入なしにネットワーク要素によって切り替えられます。
On-demand parity packets (RDATA with OPT_PARITY) necessitate modified request, confirmation and repair constraint procedures for network elements. In the context of these procedures, repair state is maintained per NAK_TSI and NAK_TG_SQN, and in addition to recording the interfaces on which corresponding NAKs have been received, records the largest value of NAK_PKT_CNT seen in corresponding NAKs on each interface. This value is referred to as the known packet count. The largest of the known packet counts recorded for any interface in the repair state for the transmit group or carried by an NCF is referred to as the largest known packet count.
オンデマンドパリティパケット（OPT_PARITY付きRDATA）には、ネットワーク要素の修正要求、確認、修理制約手順が必要です。これらの手順のコンテキストでは、修復状態はNAK_TSIおよびNAK_TG_SQNごとに維持され、対応するNAKが受信されたインターフェイスの記録に加えて、各インターフェイスの対応するNAKで見られるNAK_PKT_CNTの最大値を記録します。この値は、既知のパケットカウントと呼ばれます。送信グループの修理状態の任意のインターフェイスに記録された既知のパケット数の最大カウントまたはNCFによって運ばれるのは、最大の既知のパケットカウントと呼ばれます。
Upon receipt of a parity NAK, a network element responds with the corresponding parity NCF. The corresponding parity NCF is just an NCF formed in the usual way (i.e., a multicast copy of the NAK with the packet type changed), but with the addition of OPT_PARITY and with NCF_PKT_CNT set to the larger of NAK_PKT_CNT and the known packet count for the receiving interface. The network element then creates repair state in the usual way with the following modifications.
パリティNAKを受け取ると、ネットワーク要素は、対応するパリティNCFに応答します。対応するパリティNCFは、通常の方法で形成されたNCFにすぎません（つまり、パケットタイプが変更されたNAKのマルチキャストコピー）が、OPT_PARITYを追加し、NCF_PKT_CNTがNAK_PKT_CNTの大きさと既知のパケットカウントを使用して設定されています。受信インターフェイス。ネットワーク要素は、次の変更を加えて通常の方法で修理状態を作成します。
If repair state for the receiving interface does not exist, the network element MUST create it and additionally record NAK_PKT_CNT from the parity NAK as the known packet count for the receiving interface.
受信インターフェイスの修理状態が存在しない場合、ネットワーク要素はそれを作成し、パリティNAKからNAK_PKT_CNTを受信インターフェイスの既知のパケットカウントとしてさらに記録する必要があります。
If repair state for the receiving interface already exists, the network element MUST eliminate the NAK only if NAK_ELIM_IVL has not expired and NAK_PKT_CNT is equal to or less than the largest known packet count. If NAK_PKT_CNT is greater than the known packet count for the receiving interface, the network element MUST update the latter with the larger NAK_PKT_CNT.
受信インターフェイスの修理状態が既に存在する場合、NAK_ELIM_IVLが期限切れにならず、NAK_PKT_CNTが最大の既知のパケットカウントよりも等またはそれ以下の場合にのみ、ネットワーク要素をNAKを排除する必要があります。NAK_PKT_CNTが受信インターフェイスの既知のパケットカウントよりも大きい場合、ネットワーク要素は、より大きなNAK_PKT_CNTで後者を更新する必要があります。
Upon either adding a new interface or updating the known packet count for an existing interface, the network element MUST determine if NAK_PKT_CNT is greater than the largest known packet count. If so or if NAK_ELIM_IVL has expired, the network element MUST forward the parity NAK in the usual way with a value of NAK_PKT_CNT equal to the largest known packet count.
新しいインターフェイスを追加するか、既存のインターフェイスの既知のパケットカウントを更新すると、ネットワーク要素は、NAK_PKT_CNTが最大の既知のパケットカウントよりも大きいかどうかを判断する必要があります。その場合、またはnak_elim_ivlの有効期限が切れている場合、ネットワーク要素は、最大の既知のパケット数に等しいnak_pkt_cntの値で、通常の方法でパリティNAKを転送する必要があります。
Upon receipt of an on-demand parity packet, a network element MUST locate existing repair state for the corresponding RDATA_TSI and RDATA_TG_SQN. If no such repair state exists, the network element MUST discard the RDATA as usual.
オンデマンドパリティパケットを受け取ると、ネットワーク要素は、対応するRDATA_TSIおよびRDATA_TG_SQNの既存の修理状態を特定する必要があります。そのような修復状態が存在しない場合、ネットワーク要素は通常どおりrdataを破棄する必要があります。
If corresponding repair state exists, the largest known packet count MUST be decremented by one, then the network element MUST forward the RDATA on all interfaces in the existing repair state, and decrement the known packet count by one for each. Any interfaces whose known packet count is thereby reduced to zero MUST be deleted from the repair state. If the number of interfaces is thereby reduced to zero, the repair state itself MUST be deleted.
対応する修理状態が存在する場合、最大の既知のパケット数は1つによって減少する必要があります。ネットワーク要素は、既存の修理状態のすべてのインターフェイスのRDATAを転送し、既知のパケット数をそれぞれ1個減らさなければなりません。それにより、既知のパケット数がゼロに縮小されるインターフェイスは、修理状態から削除する必要があります。それにより、インターフェイスの数がゼロに減少した場合、修理状態自体を削除する必要があります。
Upon reception of a parity NCF, network elements MUST cancel pending NAK retransmission only if NCF_PKT_CNT is greater or equal to the largest known packet count. Network elements MUST use parity NCFs to anticipate NAKs in the usual way with the addition of recording NCF_PKT_CNT from the parity NCF as the largest known packet count with the anticipated state so that any subsequent NAKs received with NAK_PKT_CNT equal to or less than NCF_PKT_CNT will be eliminated, and any with NAK_PKT_CNT greater than NCF_PKT_CNT will be forwarded. Network elements which receive a parity NCF with NCF_PKT_CNT larger than the largest known packet count MUST also use it to anticipate NAKs, increasing the largest known packet count to reflect NCF_PKT_CNT (partial anticipation).
パリティNCFを受信すると、NCF_PKT_CNTが最大の既知のパケットカウントと等しく大きい場合にのみ、NAKの再送信を保留中にキャンセルする必要があります。ネットワーク要素は、パリティNCFSを使用して、予想される状態で最大の既知のパケットカウントとしてパリティNCFからNCF_PKT_CNTを記録することにより、通常の方法でNAKを予測するためにNAKSを予測する必要があります。、およびnak_pkt_cntがNCF_PKT_CNTよりも大きい場合は転送されます。NCF_PKT_CNTが最大の既知のパケットカウントよりも大きいパリティNCFを受信するネットワーク要素も、NAKSを予測するために使用する必要があり、NCF_PKT_CNT（部分的な予想）を反映する最大の既知のパケットカウントを増やす必要があります。
Parity NNAKs follow the usual elimination procedures with the exception that NNAKs are eliminated only if existing NAK state has a NAK_PKT_CNT greater than NNAK_PKT_CNT.
パリティNNAKSは、既存のNAK状態がNNAK_PKT_CNTよりも大きいNAK_PKT_CNTを持っている場合にのみ、NNAKが排除されることを除いて、通常の除去手順に従います。
Network elements must take extra precaution when the source is using a variable sized transmission group. Network elements learn that the source is using a TG size smaller than the maximum from OPT_CURR_TGSIZE in parity RDATAs or in SPMs. When this happens, they compute a TG size offset as the difference between the maximum TG size and the actual TG size advertised by OPT_CURR_TGSIZE. Upon reception of parity RDATA, the TG size offset is used to update the repair state as follows:
ソースが可変サイズの伝送グループを使用している場合、ネットワーク要素は追加の予防策を講じる必要があります。ネットワーク要素は、ソースがパリティrdatasまたはSPMSのopt_curr_tgsizeからの最大値よりも小さいtgサイズを使用していることを学びます。これが発生すると、最大TGサイズとOPT_CURR_TGSIZEによって宣伝されている実際のTGサイズの差としてTGサイズのオフセットを計算します。パリティRDATAを受信すると、TGサイズのオフセットを使用して、次のように修理状態を更新します。
Any interface whose known packet count is reduced to the TG size offset is deleted from the repair state.
既知のパケット数がTGサイズのオフセットに削減されるインターフェイスは、修理状態から削除されます。
This replaces the normal rule for deleting interfaces that applies when the TG size is equal to the maximum TG size.
これにより、TGサイズが最大TGサイズに等しい場合に適用されるインターフェイスを削除するための通常のルールに置き換えられます。
A DLR with the ability to provide FEC repairs MUST indicate this by setting the OPT_PARITY bit in the redirecting POLR. It MUST then process any redirected FEC NAKs in the usual way.
FEC修復を提供する機能を備えたDLRは、リダイレクトPOLRにOPT_PARITYビットを設定することにより、これを示す必要があります。次に、通常の方法でリダイレクトされたFEC NAKを処理する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |P O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmission Group Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x08
オプションタイプ= 0x08
Option Length = 8 octets
オプション長= 8オクテット
P-bit (PARITY_PRM_PRO)
p-bit（parity_prm_pro）
Indicates when set that the source is providing pro-active parity packets.
ソースが積極的なパリティパケットを提供していることを設定することを示します。
O-bit (PARITY_PRM_OND)
o-bit（parity_prm_ond）
Indicates when set that the source is providing on-demand parity packets.
ソースがオンデマンドパリティパケットを提供していることを設定することを示します。
At least one of PARITY_PRM_PRO and PARITY_PRM_OND MUST be set.
PARITY_PRM_PROとPARITY_PRM_ONDの少なくとも1つを設定する必要があります。
Transmission Group Size (PARITY_PRM_TGS)
トランスミッショングループサイズ（parity_prm_tgs）
The number of data packets in the transmission group over which the parity packets are calculated. If a variable transmission group size is being used, then this becomes the maximum effective transmission group size across the session.
パリティパケットが計算される伝送グループ内のデータパケットの数。可変伝送グループサイズが使用されている場合、これはセッション全体で最大の有効伝送グループサイズになります。
OPT_PARITY_PRM MAY be appended only to SPMs.
opt_parity_prmは、SPMSにのみ追加される場合があります。
OPT_PARITY_PRM is network-significant.
opt_parity_prmはネットワーク有意です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parity Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x09
オプションタイプ= 0x09
Option Length = 8 octets
オプション長= 8オクテット
Parity Group Number (PRM_GROUP)
パリティグループ番号（PRM_GROUP）
The number of the group of k parity packets amongst the h parity packets within the transmission group to which the parity packet belongs, where the first k parity packets are in group zero. PRM_GROUP MUST NOT be zero.
パリティパケットが属する送信グループ内のHパリティパケットの間のKパリティパケットのグループの数。最初のKパリティパケットがグループゼロにあります。PRM_GROUPはゼロである必要はありません。
OPT_PARITY_GRP MAY be appended only to parity packets.
opt_parity_grpは、パリティパケットにのみ追加できます。
OPT_PARITY_GRP is NOT network-significant.
opt_parity_grpはネットワーク有意ではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actual Transmission Group Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0A
オプションタイプ= 0x0a
Option Length = 8 octets
オプション長= 8オクテット
Actual Transmission Group Size (PRM_ATGSIZE)
実際のトランスミッショングループサイズ（PRM_ATGSIZE）
The actual number of data packets in this transmission group. This MUST be less than or equal to the maximum transmission group size PARITY_PRM_TGS in OPT_PARITY_PRM.
この送信グループの実際のデータパケット数。これは、opt_parity_prmの最大伝送グループサイズparity_prm_tgs以下でなければなりません。
OPT_CURR_TGSIZE MAY be appended to data and parity packets (ODATA or RDATA) and to SPMs.
opt_curr_tgsizeは、データとパリティパケット（odataまたはrdata）およびSPMに追加される場合があります。
OPT_CURR_TGSIZE is network-significant except when appended to ODATA.
opt_curr_tgsizeは、odataに追加された場合を除き、ネットワーク有意です。
A source MUST implement strategies for congestion avoidance, aimed at providing overall network stability, fairness among competing PGM flows, and some degree of fairness towards coexisting TCP flows [13]. In order to do this, the source must be provided with feedback on the status of the network in terms of traffic load. This appendix specifies NE procedures that provide such feedback to the source in a scalable way. (An alternative TCP-friendly scheme for congestion control that does not require NE support can be found in [16]).
ソースは、全体的なネットワークの安定性、競合するPGMフローの間の公平性、および共存するTCPフローに対するある程度の公平性を提供することを目的とした混雑回避のための戦略を実装する必要があります[13]。これを行うには、ソースに、トラフィック負荷の観点からネットワークのステータスに関するフィードバックを提供する必要があります。この付録は、スケーラブルな方法でそのようなフィードバックをソースに提供するNE手順を指定します。（NEサポートを必要としない輻輳制御のための代替TCPに優しいスキームは、[16]に記載されています）。
The procedures specified in this section enable the collection and selective forwarding of three types of feedback to the source:
このセクションで指定された手順により、ソースへの3種類のフィードバックの収集と選択的転送が可能になります。
o Worst link load as measured in network elements.
o ネットワーク要素で測定された最悪のリンク負荷。
o Worst end-to-end path load as measured in network elements.
o ネットワーク要素で測定された最悪のエンドツーエンドパスロード。
o Worst end-to-end path load as reported by receivers.
o 受信機によって報告されている最悪のエンドツーエンドパスロード。
This specification defines in detail NE procedures, receivers procedures and packet formats. It also defines basic procedures in receivers for generating congestion reports. This specification does not define the procedures used by PGM sources to adapt their transmission rates in response of congestion reports. Those procedures depend upon the specific congestion control scheme.
この仕様では、NE手順、受信手順、パケット形式の詳細を定義します。また、輻輳レポートを生成するためのレシーバーの基本的な手順を定義します。この仕様では、PGMソースが使用する手順を定義して、輻輳レポートの応答に透過率を適応させます。これらの手順は、特定の輻輳制御スキームに依存します。
PGM defines a header option that PGM receivers may append to NAKs (OPT_CR). OPT_CR carries congestion reports in NAKs that propagate upstream towards the source.
PGMは、PGM受信機がNAKS（OPT_CR）に追加できるヘッダーオプションを定義します。OPT_CRは、ソースに向かって上流に伝播するNAKSでの輻輳レポートを掲載しています。
During the process of hop-by-hop reverse NAK forwarding, NEs examine OPT_CR and possibly modify its contents prior to forwarding the NAK upstream. Forwarding CRs also has the side effect of creating congestion report state in the NE. The presence of OPT_CR and its contents also influences the normal NAK suppression rules. Both the modification performed on the congestion report and the additional suppression rules depend on the content of the congestion report and on the congestion report state recorded in the NE as detailed below.
NESは、ホップバイホップのリバースNAK転送の過程で、NAKを上流に転送する前にOPT_CRを調べ、そのコンテンツを変更する可能性があります。転送CRSには、NEに混雑報告状態を作成する副作用もあります。OPT_CRとその内容の存在は、通常のNAK抑制ルールにも影響します。混雑報告書と追加の抑制ルールの両方が実行された修正の両方が、輻輳レポートの内容と、以下に詳述したNEに記録されている輻輳レポート状態に依存します。
OPT_CR contains the following fields:
OPT_CRには次のフィールドが含まれています。
OPT_CR_NE_WL Reports the load in the worst link as detected though NE internal measurements
opt_cr_ne_wlは、内部測定で検出された最悪のリンクで負荷を報告します
OPT_CR_NE_WP Reports the load in the worst end-to-end path as detected though NE internal measurements
opt_cr_ne_wpは、内部測定で検出された最悪のエンドツーエンドパスで負荷を報告します
OPT_CR_RX_WP Reports the load in the worst end-to-end path as detected by receivers
OPT_CR_RX_WPは、受信機によって検出された最悪のエンドツーエンドパスでの負荷を報告します
A load report is either a packet drop rate (as measured at an NE's interfaces) or a packet loss rate (as measured in receivers). Its value is linearly encoded in the range 0-0xFFFF, where 0xFFFF represents a 100% loss/drop rate. Receivers that send a NAK bearing OPT_CR determine which of the three report fields are being reported.
負荷レポートは、パケットドロップレート（NEのインターフェイスで測定）またはパケット損失率（受信機で測定）のいずれかです。その値は、0-0xffffの範囲で直線的にエンコードされており、0xffffは100％の損失/ドロップレートを表します。NAKベアリングOPT_CRを送信する受信機は、3つのレポートフィールドのどれが報告されているかを決定します。
OPT_CR also contains the following fields:
OPT_CRには、次のフィールドも含まれています。
OPT_CR_NEL A bit indicating that OPT_CR_NE_WL is being reported.
opt_cr_nelは、opt_cr_ne_wlが報告されていることを少し示しています。
OPT_CR_NEP A bit indicating that OPT_CR_NE_WP is being reported.
opt_cr_nep opt_cr_ne_wpが報告されていることを少し示します。
OPT_CR_RXP A bit indicating that OPT_CR_RX_WP is being reported.
opt_cr_rxpは、opt_cr_rx_wpが報告されていることを少し示しています。
OPT_CR_LEAD A SQN in the ODATA space that serves as a temporal reference for the load report values. This is initialized by receivers with the leading edge of the transmit window as known at the moment of transmitting the NAK. This value MAY be advanced in NEs that modify the content of OPT_CR.
OPT_CR_LEADロードレポート値の時間的参照として機能するODATAスペースのSQN。これは、NAKを送信した瞬間に知られているように、送信ウィンドウの前端を持つ受信機によって初期化されます。この値は、OPT_CRのコンテンツを変更するNESで進められる場合があります。
OPT_CR_RCVR The identity of the receiver that generated the worst OPT_CR_RX_WP.
opt_cr_rcvr最悪のopt_cr_rx_wpを生成した受信機の身元。
The complete format of the option is specified later.
オプションの完全な形式は後で指定されます。
To permit network elements to report worst link, receivers append OPT_CR to a NAK with bit OPT_CR_NEL set and OPT_CR_NE_WL set to zero. NEs receiving NAKs that contain OPT_CR_NE_WL process the option and update per-TSI state related to it as described below. The ultimate result of the NEs' actions ensures that when a NAK leaves a sub-tree, OPT_CR_NE_WL contains a congestion report that reflects the load of the worst link in that sub-tree. To achieve this, NEs rewrite OPT_CR_NE_WL with the worst value among the loads measured on the local (outgoing) links for the session and the congestion reports received from those links.
ネットワーク要素が最悪のリンクを報告できるようにするために、受信機はbit opt_cr_nelセットとopt_cr_ne_wlをゼロにbit opt_cr_ne_wlを使用してnakにopt_crを追加します。OPT_CR_NE_WLを含むNASを受信しているNESは、以下に説明するように、それに関連するTSI状態ごとにオプションと更新を処理します。NESのアクションの究極の結果は、NAKがサブツリーを離れると、OPT_CR_NE_WLがそのサブツリーの最悪のリンクの負荷を反映する渋滞レポートを含むことを保証します。これを達成するために、NESは、セッションのローカル（発信）リンクで測定された負荷と、それらのリンクから受け取った輻輳レポートで測定された負荷の中で最悪の値でOPT_CR_NE_WLを書き直します。
Note that the mechanism described in this sub-section does not permit the monitoring of the load on (outgoing) links at non-PGM-capable multicast routers. For this reason, NE-Based Worst Link Reports SHOULD be used in pure PGM topologies only. Otherwise, this mechanism might fail in detecting congestion. To overcome this limitation PGM sources MAY use a heuristic that combines NE-Based Worst Link Reports and Receiver-Based Reports.
このサブセクションで説明されているメカニズムは、非PGM対応マルチキャストルーターでの（発信）リンクの負荷の監視を許可しないことに注意してください。このため、NEベースの最悪のリンクレポートは、純粋なPGMトポロジのみで使用する必要があります。それ以外の場合、このメカニズムは混雑の検出に失敗する可能性があります。この制限を克服するために、PGMソースは、NEベースの最悪のリンクレポートとレシーバーベースのレポートを組み合わせたヒューリスティックを使用する場合があります。
To permit network elements to report a worst path, receivers append OPT_CR to a NAK with bit OPT_CR_NEP set and OPT_CR_NE_WP set to zero. The processing of this field is similar to that of OPT_CR_NE_WL with the difference that, on the reception of a NAK, the value of OPT_CR_NE_WP is adjusted with the load measured on the interface on which the NAK was received according to the following formula:
ネットワーク要素が最悪のパスを報告することを許可するために、受信者はbit opt_cr_nepセットとopt_cr_ne_wpセットをゼロにbit opt_cr_ne_wpでnakにopt_crを追加します。このフィールドの処理は、opt_cr_ne_wlの処理と類似しています。NAKの受信時に、opt_cr_ne_wpの値は、NAKが次の式に従って受信したインターフェイスで測定された負荷で調整されます。
OPT_CR_NE_WP = if_load + OPT_CR_NE_WP * (100% - if_loss_rate)
The worst among the adjusted OPT_CR_NE_WP is then written in the outgoing NAK. This results in a hop-by-hop accumulation of link loss rates into a path loss rate.
調整されたOPT_CR_NE_WPの中で最悪の事態は、発信NAKで記述されます。これにより、リンク損失率をパス損失率にホップバイホップ蓄積します。
As with OPT_CR_NE_WL, the congestion report in OPT_CR_NE_WP may be invalid if the multicast distribution tree includes non-PGM-capable routers.
OPT_CR_NE_WLと同様に、マルチキャスト分布ツリーに非PGM対応ルーターが含まれている場合、OPT_CR_NE_WPの混雑レポートは無効になる場合があります。
To report a packet loss rate, receivers append OPT_CR to a NAK with bit OPT_CR_RXP set and OPT_CR_RX_WP set to the packet loss rate. NEs receiving NAKs that contain OPT_CR_RX_WP process the option and update per-TSI state related to it as described below. The ultimate result of the NEs' actions ensures that when a NAK leaves a sub-tree, OPT_CR_RX_WP contains a congestion report that reflects the load of the worst receiver in that sub-tree. To achieve this, NEs rewrite OTP_CR_RE_WP with the worst value among the congestion reports received on its outgoing links for the session. In addition to this, OPT_CR_RCVR MUST contain the NLA of the receiver that originally measured the value of OTP_CR_RE_WP being forwarded.
パケットの損失率を報告するには、受信者はbit opt_cr_rxpセットを使用してopt_crをnakに追加し、opt_cr_rx_wpセットをパケット損失率に設定します。OPT_CR_RX_WPを含むNES受信NESは、以下に説明するように、それに関連するTSI状態ごとにオプションと更新を処理します。NESのアクションの究極の結果は、Nakがサブツリーを離れると、OPT_CR_RX_WPがそのサブツリーの最悪のレシーバーの負荷を反映する渋滞レポートを含むことを保証します。これを達成するために、NESは、セッションの発信リンクで受け取った渋滞レポートの中で最悪の値でOTP_CR_RE_WPを書き直します。これに加えて、OPT_CR_RCVRには、元々OTP_CR_RE_WPが転送される値を測定したレシーバーのNLAを含める必要があります。
To enable the generation of any type of congestion report, receivers MUST insert OPT_CR in each NAK they generate and provide the corresponding field (OPT_CR_NE_WL, OPT_CR_NE_WP, OPT_CR_RX_WP). The specific fields to be reported will be advertised to receivers in OPT_CRQST on the session's SPMs. Receivers MUST provide only those options requested in OPT_CRQST.
あらゆるタイプの混雑レポートの生成を有効にするには、受信者が生成する各NAKにOPT_CRを挿入し、対応するフィールド（OPT_CR_NE_WL、OPT_CR_NE_WP、OPT_CR_RX_WP）を提供する必要があります。報告される特定のフィールドは、セッションのSPMSでOPT_CRQSTの受信機に宣伝されます。受信者は、opt_crqstで要求されたオプションのみを提供する必要があります。
Receivers MUST initialize OPT_CR_NE_WL and OPT_CR_NE_WP to 0 and they MUST initialize OPT_CR_RCVR to their NLA. At the moment of sending the NAK, they MUST also initialize OPT_CR_LEAD to the leading edge of the transmission window.
受信者は、OPT_CR_NE_WLとOPT_CR_NE_WPを0に初期化する必要があり、OPT_CR_RCVRをNLAに初期化する必要があります。NAKを送信した時点では、opt_cr_leadを送信ウィンドウの先端に初期化する必要があります。
Additionally, if a receiver generates a NAK with OPT_CR with OPT_CR_RX_WP, it MUST initialize OPT_CR_RX_WP to the proper value, internally computed.
さらに、受信者がOPT_CR_RX_WPを使用してOPT_CRを使用してNAKを生成する場合、OPT_CR_RX_WPを適切な値に初期化し、内部的に計算する必要があります。
Network elements start processing each OPT_CR by selecting a reference SQN in the ODATA space. The reference SQN selected is the highest SQN known to the NE. Usually this is OPT_CR_LEAD contained in the NAK received.
ネットワーク要素は、ODATAスペースで参照SQNを選択して、各OPT_CRの処理を開始します。選択された参照SQNは、NEに知られている最高のSQNです。通常、これは受信したNAKに含まれるopt_cr_leadです。
They use the selected SQN to age the value of load measurement as follows:
選択したSQNを使用して、次のように負荷測定値を老化させます。
o locally measured load values (e.g. interface loads) are considered up-to-date
o ローカルで測定された負荷値（例：インターフェイス負荷）は最新と見なされます
o load values carried in OPT_CR are considered up-to-date and are not aged so as to be independent of variance in round-trip times from the network element to the receivers
o opt_crで運ばれる負荷値は最新と見なされ、ネットワーク要素から受信機への往復時間の分散とは無関係に老化していません
o old load values recorded in the NE are exponentially aged according to the difference between the selected reference SQN and the reference SQN associated with the old load value.
o NEに記録された古い負荷値は、選択された参照SQNと古い負荷値に関連付けられた参照SQNの違いに応じて指数関数的に熟成されます。
The exponential aging is computed so that a recorded value gets scaled down by a factor exp(-1/2) each time the expected inter-NAK time elapses. Hence the aging formula must include the current loss rate as follows:
指数老化が計算され、予想される時間間時間が経過するたびに、記録された値が係数exp（-1/2）によって縮小されるようにします。したがって、老化式には、次のように現在の損失率を含める必要があります。
aged_loss_rate = loss_rate * exp( - SQN_difference * loss_rate /
2)
Note that the quantity 1/loss_rate is the expected SQN_lag between two NAKs, hence the formula above can also be read as:
数量1/loss_rateは2つのNAKの間の予想されるSQN_LAGであるため、上記の式は次のように読むことができます。
aged_loss_rate = loss_rate * exp( - 1/2 * SQN_difference /
SQN_lag)
which equates to (loss_rate * exp(-1/2)) when the SQN_difference is equal to expected SQN_lag between two NAKs.
SQN_Differenceが2つのNAK間の予想されるSQN_LAGに等しい場合、（loss_rate * exp（-1/2））に相当します。
All the subsequent computations refer to the aged load values.
後続のすべての計算は、老化した負荷値を指します。
Network elements process OPT_CR by handling the three possible types of congestion reports independently.
ネットワーク要素は、3つの可能なタイプの輻輳レポートを個別に処理することにより、OPT_CRを処理します。
For each congestion report in an incoming NAK, a new value is computed to be used in the outgoing NAK:
入ってくるNAKの各輻輳レポートについて、新しい値が計算されます。
o The new value for OPT_CR_NE_WL is the maximum of the load measured on the outgoing interfaces for the session, the value of OPT_CR_NE_WL of the incoming NAK, and the value previously sent upstream (recorded in the NE). All these values are as obtained after the aging process.
o OPT_CR_NE_WLの新しい値は、セッションの発信インターフェイスで測定された負荷の最大値、着信NAKのOPT_CR_NE_WLの値、および以前に上流に送信された値（NEに記録）です。これらすべての値は、老化プロセスの後に得られたとおりです。
o The new value for OPT_CR_NE_WP is the maximum of the value previously sent upstream (after aging) and the value of OPT_CR_NE_WP in the incoming NAK adjusted with the load on the interface upon which the NAK was received (as described above).
o opt_cr_ne_wpの新しい値は、以前に上流（老化後）送られた値の最大値と、NAKが受信したインターフェイスの負荷で調整された入っているNAKのOPT_CR_NE_WPの値です（上記のように）。
o The new value for OPT_CR_RX_WP is the maximum of the value previously sent upstream (after aging) and the value of OPT_CR_RX_WP in the incoming NAK.
o OPT_CR_RX_WPの新しい値は、以前に上流（老化後）に送信された値の最大値と、着信NAKのOPT_CR_RX_WPの値です。
o If OPT_CR_RX_WP was selected from the incoming NAK, the new value for OPT_CR_RCVR is the one in the incoming NAK. Otherwise it is the value previously sent upstream.
o OPT_CR_RX_WPが着信NAKから選択された場合、OPT_CR_RCVRの新しい値は、受信NAKの新しい値です。それ以外の場合は、以前に上流で送信された値です。
o The new value for OPT_CR_LEAD is the reference SQN selected for the aging procedure.
o opt_cr_leadの新しい値は、老化手順に選択されたリファレンスSQNです。
Normal suppression rules hold to determine if a NAK should be forwarded upstream or not. However if any of the outgoing congestion reports has changed by more than 5% relative to the one previously sent upstream, this new NAK is not suppressed.
NAKを上流に転送するかどうかを判断するために、通常の抑制ルールが保持されます。ただし、発信渋滞レポートのいずれかが以前に上流に送られたものと比較して5％以上変更された場合、この新しいNAKは抑制されていません。
PGM routers monitor the load on all their outgoing links and record it in the form of per-interface loss rate statistics. "load" MUST be interpreted as the percentage of the packets meant to be forwarded on the interface that were dropped. Load statistics refer to the aggregate traffic on the links and not to PGM traffic only.
PGMルーターは、すべての発信リンクの負荷を監視し、インターフェイスごとの損失率統計の形式で記録します。「ロード」は、ドロップされたインターフェイスに転送されることを意図したパケットの割合として解釈する必要があります。負荷統計は、PGMトラフィックのみではなく、リンクの集計トラフィックを指します。
This document does not specify the algorithm to be used to collect such statistics, but requires that such algorithm provide both accuracy and responsiveness in the measurement process. As far as accuracy is concerned, the expected measurement error SHOULD be upper-limited (e.g. less than than 10%). As far as responsiveness is concerned, the measured load SHOULD converge to the actual value in a limited time (e.g. converge to 90% of the actual value in less than 200 milliseconds), when the instantaneous offered load changes. Whenever both requirements cannot be met at the same time, accuracy SHOULD be traded for responsiveness.
このドキュメントでは、そのような統計を収集するために使用されるアルゴリズムを指定するのではなく、そのようなアルゴリズムが測定プロセスで精度と応答性の両方を提供する必要があります。精度に関する限り、予想される測定誤差は上限に制限する必要があります（たとえば、10％未満）。応答性に関する限り、測定された負荷は、限られた時間で実際の値に収束する必要があります（たとえば、瞬時に荷重の変化を提供する場合、200ミリ秒未満で実際の値の90％に収束します）。両方の要件を同時に満たすことができないときはいつでも、応答性のために精度を取引する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| L P R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Report Reference SQN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NE Worst Link | NE Worst Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcvr Worst Path | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Worst Receiver's NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
Option Type = 0x10
オプションタイプ= 0x10
Option Length = 20 octets + NLA length
オプション長= 20オクテットNLA長
L OPT_CR_NEL bit : set indicates OPT_CR_NE_WL is being reported
l opt_cr_nelビット：セットはopt_cr_ne_wlが報告されていることを示します
P OPT_CR_NEP bit : set indicates OPT_CR_NE_WP is being reported
P opt_cr_nepビット：セットはopt_cr_ne_wpが報告されていることを示します
R OPT_CR_RXP bit : set indicates OPT_CR_RX_WP is being reported
r opt_cr_rxpビット：set opt_cr_rx_wpが報告されていることを示します
Congestion Report Reference SQN (OPT_CR_LEAD).
輻輳レポートリファレンスSQN（opt_cr_lead）。
A SQN in the ODATA space that serves as a temporal reference point for the load report values.
負荷レポート値の時間的基準点として機能するODATA空間のSQN。
NE Worst Link (OPT_CR_NE_WL).
ne最悪のリンク（opt_cr_ne_wl）。
Reports the load in the worst link as detected though NE internal measurements
NE内部測定で検出されたように、最悪のリンクの負荷を報告します
NE Worst Path (OPT_CR_NE_WP).
ne最悪のパス（opt_cr_ne_wp）。
Reports the load in the worst end-to-end path as detected though NE internal measurements
NE内部測定で検出された最悪のエンドツーエンドパスでの負荷を報告します
Rcvr Worst Path (OPT_CR_RX_WP).
RCVR最悪のパス（OPT_CR_RX_WP）。
Reports the load in the worst end-to-end path as detected by receivers
受信機によって検出された最悪のエンドツーエンドパスでの負荷を報告する
Worst Receiver's NLA (OPT_CR_RCVR).
最悪のレシーバーのNLA（opt_cr_rcvr）。
The unicast address of the receiver that generated the worst OPT_CR_RX_WP.
最悪のOPT_CR_RX_WPを生成した受信機のユニキャストアドレス。
OPT_CR MAY be appended only to NAKs.
opt_crはnaksにのみ追加される場合があります。
OPT-CR is network-significant.
OPT-CRはネットワーク有意です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| L P R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x11
オプションタイプ= 0x11
Option Length = 4 octets
オプション長= 4オクテット
L OPT_CRQST_NEL bit : set indicates OPT_CR_NE_WL is being requested
L opt_crqst_nelビット：セットはopt_cr_ne_wlが要求されていることを示します
P OPT_CRQST_NEP bit : set indicates OPT_CR_NE_WP is being requested
P opt_crqst_nepビット：set opt_cr_ne_wpが要求されていることを示します
R OPT_CRQST_RXP bit : set indicates OPT_CR_RX_WP is being requested
r opt_crqst_rxpビット：set opt_cr_rx_wpが要求されていることを示します
OPT_CRQST MAY be appended only to SPMs.
OPT_CRQSTは、SPMSのみに追加される場合があります。
OPT-CRQST is network-significant.
Opt-CRQSTはネットワーク有意です。
SPM Requests (SPMRs) MAY be used to solicit an SPM from a source in a non-implosive way. The typical application is for late-joining receivers to solicit SPMs directly from a source in order to be able to NAK for missing packets without having to wait for a regularly scheduled SPM from that source.
SPMリクエスト（SPMR）を使用して、非プロサイブ方法でソースからSPMを求めることができます。典型的なアプリケーションは、レシーバーが遅れているレシーバーが、そのソースから定期的にスケジュールされたSPMを待つことなく、パケットを欠落しているパケットをNAKできるように、ソースからSPMを直接勧誘することです。
Allowing for SPMR implosion protection procedures, a receiver MAY unicast an SPMR to a source to solicit the most current session, window, and path state from that source any time after the receiver has joined the group. A receiver may learn the TSI and source to which to direct the SPMR from any other PGM packet it receives in the group, or by any other means such as from local configuration or directory services. The receiver MUST use the usual SPM procedures to glean the unicast address to which it should direct its NAKs from the solicited SPM.
SPMRの爆発保護手順を可能にするレシーバーは、受信者がグループに参加した後でも、そのソースから最新のセッション、ウィンドウ、およびパス状態を募集するためにSPMRをソースにユニキャストすることができます。受信者は、グループ内で受信する他のPGMパケットからSPMRを指示するために、またはローカル構成やディレクトリサービスなどの他の手段でTSIとソースを学習できます。受信者は、通常のSPM手順を使用して、勧誘されたSPMからNAKを向けるユニキャストアドレスを収集する必要があります。
This section just provides enough short-hand to make the Procedures intelligible. For the full details of packet contents, please refer to Packet Formats below.
このセクションでは、手順をわかりやすくするのに十分な短い手を提供します。パケットコンテンツの詳細については、以下のパケット形式を参照してください。
SPMRs are transmitted by receivers to solicit SPMs from a source.
SPMRは、ソースからSPMを求めるために受信機によって送信されます。
SPMs are unicast to a source and contain:
SPMSはソースにユニキャストされ、以下が含まれています。
SPMR_TSI the source-assigned TSI for the session to which the SPMR corresponds
SPMR_TSI SPMRが対応するセッションのソース割り当てTSI
A source MUST respond immediately to an SPMR with the corresponding SPM rate limited to once per IHB_MIN per TSI. The corresponding SPM matches SPM_TSI to SPMR_TSI and SPM_DPORT to SPMR_DPORT.
ソースは、対応するSPMレートがTSIあたりIHB_MINごとに1回限定されたSPMRにすぐに応答する必要があります。対応するSPMは、SPM_TSIをSPMR_TSIに一致させ、SPM_DPORTはSPMR_DPORTに一致します。
To moderate the potentially implosive behavior of SPMRs at least on a densely populated subnet, receivers MUST use the following back-off and suppression procedure based on multicasting the SPMR with a TTL of 1 ahead of and in addition to unicasting the SPMR to the source. The role of the multicast SPMR is to suppress the transmission of identical SPMRs from the subnet.
少なくとも人口密度の高いサブネットでは、SPMRの潜在的に爆発的な動作を緩和するには、受信機は、SPMRの1人のTTLを使用してSPMRのマルチリキャストに基づいて、SPMRをソースにユニカストすることに加えて、以下のバックオフおよび抑制手順を使用する必要があります。マルチキャストSPMRの役割は、サブネットからの同一のSPMRの伝達を抑制することです。
More specifically, before unicasting a given SPMR, receivers MUST choose a random delay on SPMR_BO_IVL (~250 msecs) during which they listen for a multicast of an identical SPMR. If a receiver does not see a matching multicast SPMR within its chosen random interval, it MUST first multicast its own SPMR to the group with a TTL of 1 before then unicasting its own SPMR to the source. If a receiver does see a matching multicast SPMR within its chosen random interval, it MUST refrain from unicasting its SPMR and wait instead for the corresponding SPM.
より具体的には、特定のSPMRをユニカストする前に、受信機はSPMR_BO_IVL（〜250ミリ秒）でランダムな遅延を選択し、その間に同一のSPMRのマルチキャストを聴く必要があります。受信者が選択したランダム間隔内でマルチキャストSPMRが一致していない場合、最初に独自のSPMRをグループにマルチキャストし、その後、独自のSPMRをソースに固定する必要があります。受信者が選択したランダム間隔内で一致するマルチキャストSPMRが表示されている場合、SPMRをユニカストし、代わりに対応するSPMを待つ必要があります。
In addition, receipt of the corresponding SPM within this random interval SHOULD cancel transmission of an SPMR.
さらに、このランダム間隔内の対応するSPMの受信は、SPMRの送信をキャンセルする必要があります。
In either case, the receiver MUST wait at least SPMR_SPM_IVL before attempting to repeat the SPMR by choosing another delay on SPMR_BO_IVL and repeating the procedure above.
どちらの場合でも、受信者は、SPMR_BO_IVLで別の遅延を選択し、上記の手順を繰り返すことにより、SPMRを繰り返しようとする前に、少なくともSPMR_SPM_IVLを待つ必要があります。
The corresponding SPMR matches SPMR_TSI to SPMR_TSI and SPMR_DPORT to SPMR_DPORT. The corresponding SPM matches SPM_TSI to SPMR_TSI and SPM_DPORT to SPMR_DPORT.
対応するSPMRは、SPMR_TSIをSPMR_TSIに一致させ、SPMR_DPORTをSPMR_DPORTに一致させます。対応するSPMは、SPM_TSIをSPMR_TSIに一致させ、SPM_DPORTはSPMR_DPORTに一致します。
SPMR:
SPMR：
SPM Requests are sent by receivers to request the immediate transmission of an SPM for the given TSI from a source.
SPM要求は、ソースから指定されたTSIのSPMの即時送信を要求するために、受信機によって送信されます。
The network-header source address of an SPMR is the unicast NLA of the entity that originates the SPMR.
SPMRのネットワークヘッダーソースアドレスは、SPMRを発信するエンティティのユニキャストNLAです。
The network-header destination address of an SPMR is the unicast NLA of the source from which the corresponding SPM is requested.
SPMRのネットワークヘッダー宛先アドレスは、対応するSPMが要求されるソースのユニキャストNLAです。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Extensions when present ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
Source Port:
ソースポート：
SPMR_SPORT
SPMR_SPORT
Data-Destination Port
データ照射ポート
Destination Port:
宛先ポート：
SPMR_DPORT
spmr_dport
Data-Source Port, together with Global Source ID forms SPMR_TSI
データソースポート、グローバルソースIDフォームSPMR_TSI
Type:
タイプ：
SPMR_TYPE = 0x0C
Global Source ID:
グローバルソースID：
SPMR_GSI
SPMR_GSI
Together with Source Port forms
ソースポートフォームと一緒に
SPMR_TSI
SPMR_TSI
These procedures provide PGM network elements and sources with the ability to poll their downstream PGM neighbors to solicit replies in an implosion-controlled way.
これらの手順は、PGMネットワーク要素とソースに、下流のPGM隣人を投票して、弾力制御の方法で返信を求める機能を提供します。
Both general polls and specific polls are possible. The former provide a PGM (parent) node with a way to check if there are any PGM (children) nodes connected to it, both network elements and receivers, and to estimate their number. The latter may be used by PGM parent nodes to search for nodes with specific properties among its PGM children. An example of application for this is DLR discovery.
一般的な世論調査と特定の投票の両方が可能です。前者は、ネットワーク要素と受信機の両方に接続されているPGM（子供）ノードがあるかどうかを確認する方法を備えたPGM（親）ノードを提供し、その数を推定します。後者は、PGM親ノードによって使用されて、PGMの子供の間で特定の特性を持つノードを検索できます。これのアプリケーションの例は、DLR発見です。
Polling is implemented using two additional PGM packets:
ポーリングは、2つの追加のPGMパケットを使用して実装されます。
POLL a Poll Request that PGM parent nodes multicast to the group to perform the poll. Similarly to NCFs, POLL packets stop at the first PGM node they reach, as they are not forwarded by PGM network elements.
PGM親ノードがグループにマルチキャストを行い、投票を実行するという投票要求。NCFSと同様に、PGMネットワーク要素によって転送されないため、ポーリングパケットが到達する最初のPGMノードで停止します。
POLR a Poll Response that PGM children nodes (either network elements or receivers) use to reply to a Poll Request by addressing it to the NLA of the interface from which the triggering POLL was sent.
POLR PGM Childrenノード（ネットワーク要素または受信機）が、トリガーポーリングが送信されたインターフェイスのNLAに対処することにより、投票リクエストに返信するために使用する投票応答。
The polling mechanism dictates that PGM children nodes that receive a POLL packet reply to it only if certain conditions are satisfied and ignore the POLL otherwise. Two types of condition are possible: a random condition that defines a probability of replying for the polled child, and a deterministic condition. Both the random condition and the deterministic condition are controlled by the polling PGM parent node by specifying the probability of replying and defining the deterministic condition(s) respectively. Random-only poll, deterministic-only poll or a combination of the two are possible.
ポーリングメカニズムは、特定の条件が満たされ、それ以外の場合は世論調査を無視した場合にのみ、投票パケットの返信を受け取るPGM児童ノードを指示しています。2種類の状態が可能です。ポーリングされた子供に応答する確率を定義するランダムな条件と、決定論的条件です。ランダム条件と決定論的条件の両方は、それぞれ決定論的条件をそれぞれ応答および定義する確率を指定することにより、ポーリングPGM親ノードによって制御されます。ランダムのみの世論調査、決定論的のみの世論調査、または2つの組み合わせが可能です。
The random condition in polls allows the prevention of implosion of replies by controlling their number. Given a probability of replying P and assuming that each receiver makes an independent decision, the number of expected replies to a poll is P*N where N is the number of PGM children relative to the polling PGM parent. The polling node can control the number of expected replies by specifying P in the POLL packet.
世論調査のランダムな状態は、その数を制御することにより、返信の崩壊の防止を可能にします。Pにpに返信する確率が与えられ、各受信者が独立した決定を下すと仮定すると、投票に対する予想される返信の数はp*nで、nはポーリングPGM親と比較してPGM子供の数です。ポーリングノードは、ポーリングパケットでPを指定することにより、予想される応答の数を制御できます。
This section just provides enough short-hand to make the Procedures intelligible. For the full details of packet contents, please refer to Packet Formats below.
このセクションでは、手順をわかりやすくするのに十分な短い手を提供します。パケットコンテンツの詳細については、以下のパケット形式を参照してください。
POLL_SQN a sequence number assigned sequentially by the polling parent in unit increments and scoped by POLL_PATH and the TSI of the session.
Poll_sqnユニットの増分でポーリング親によって順次割り当てられ、Poll_PathとセッションのTSIによってスコープされたシーケンス番号。
POLL_ROUND a poll round sequence number. Multiple poll rounds are possible within a POLL_SQN.
Poll_roundポーリングラウンドシーケンス番号。Poll_sqn内で複数の投票ラウンドが可能です。
POLL_S_TYPE the sub-type of the poll request
poll_s_typeポーリングリクエストのサブタイプ
POLL_PATH the network-layer address (NLA) of the interface on the PGM network element or source on which the POLL is transmitted
Poll_path PGMネットワーク要素または投票が送信されるソース上のインターフェイスのネットワーク層アドレス（NLA）
POLL_BO_IVL the back-off interval that MUST be used to compute the random back-off time to wait before sending the response to a poll. POLL_BO_IVL is expressed in microseconds.
Poll_bo_ivlランダムバックオフ時間を計算するために使用する必要があるバックオフ間隔は、回答を投票に送信する前に待機します。Poll_bo_ivlはマイクロ秒で表されます。
POLL_RAND a random string used to implement the randomness in replying
Poll_rand応答でランダム性を実装するために使用されるランダムな文字列
POLL_MASK a bit-mask used to determine the probability of random replies
Poll_Maskランダム応答の確率を決定するために使用されるビットマスク
Poll request MAY also contain options which specify deterministic conditions for the reply. No options are currently defined.
投票要求には、返信の決定論的条件を指定するオプションも含まれている場合があります。現在、オプションは定義されていません。
POLR_SQN POLL_SQN of the poll request for which this is a reply
POLR_SQN POLL_SQN POLLリクエストはこれが返信です
POLR_ROUND POLL_ROUND of the poll request for which this is a reply
POLR_ROUND POLL_ROUND POLL REQUEST OF THE POLL REQUESHTIN
Poll response MAY also contain options. No options are currently defined.
世論調査にはオプションが含まれている場合があります。現在、オプションは定義されていません。
General Polls may be used to check for and count PGM children that are 1 PGM hop downstream of an interface of a given node. They have POLL_S_TYPE equal to PGM_POLL_GENERAL. PGM children that receive a general poll decide whether to reply to it only based on the random condition present in the POLL.
一般的な投票は、特定のノードのインターフェイスの下流1 pgmホップであるPGMの子供をチェックおよびカウントするために使用される場合があります。POLL_S_TYPEはPGM_POLL_GENERALに等しい。一般投票を受けたPGMの子供は、世論調査に存在するランダムな状態に基づいてのみ返信するかどうかを決定します。
To prevent response implosion, PGM parents that initiate a general poll SHOULD establish the probability of replying to the poll, P, so that the expected number of replies is contained. The expected number of replies is N * P, where N is the number of children. To be able to compute this number, PGM parents SHOULD already have a rough estimate of the number of children. If they do not have a recent estimate of this number, they SHOULD send the first poll with a very low probability of replying and increase it in subsequent polls in order to get the desired number of replies.
応答の爆発を防ぐために、一般的な投票を開始するPGMの親は、予想される返信数が含まれるように、投票Pに返信する確率を確立する必要があります。予想される応答数はn * pです。ここで、nは子供の数です。この数を計算できるようにするには、PGMの親はすでに子供の数の大まかな推定値を持っている必要があります。この数の最近の推定値がない場合は、最初の世論調査を非常に低い確率で返信する可能性が非常に低く、その後の世論調査でそれを増やして、望ましい数の返信を取得する必要があります。
To prevent poll-response implosion caused by a sudden increase in the children population occurring between two consecutive polls with increasing probability of replying, PGM parents SHOULD use poll rounds. Poll rounds allow PGM parents to "freeze" the size of the children population when they start a poll and to maintain it constant across multiple polls (with the same POLL_SQN but different POLL_ROUND). This works by allowing PGM children to respond to a poll only if its POLL_ROUND is zero or if they have previously received a poll with the same POLL_SQN and POLL_ROUND equal to zero.
2つの連続した世論調査の間で発生する子どもの人口の突然の増加によって引き起こされる世論調査の爆発を防ぐために、PGMの親は世論調査を使用する必要があります。投票ラウンドにより、PGMの親は、世論調査を開始するときに子供の人口のサイズを「フリーズ」し、複数の投票で一定に維持することができます（同じpoll_sqnが異なるpoll_round）。これは、POLL_ROUNDがゼロの場合、または以前に同じPOLL_SQNおよびPOLL_ROUNDがゼロに等しい投票を受けた場合にのみ、PGMの子供が投票に回答できるようにすることで機能します。
In addition to this PGM children MUST observe a random back-off in replying to a poll. This spreads out the replies in time and allows a PGM parent to abort the poll if too many replies are being received. To abort an ongoing poll a PGM parent MUST initiate another poll with different POLL_SQN. PGM children that receive a POLL MUST cancel any pending reply for POLLs with POLL_SQN different from the one of the last POLL received.
このPGMに加えて、子どもたちは世論調査への返信においてランダムなバックオフを観察する必要があります。これにより、回答が時間内に広がり、PGMの親があまりにも多くの返信が受け取られている場合は、投票を中止することができます。進行中の世論調査を中止するには、PGMの親は、異なるPoll_sqnで別の投票を開始する必要があります。世論調査を受けたPGMの子供は、投票の保留中の返信をキャンセルする必要があります。
For a given poll with probability of replying P, a PGM parent estimates the number of children as M / P, where M is the number of responses received. PGM parents SHOULD keep polling periodically and use some average of the result of recent polls as their estimate for the number of children.
Pに応答する可能性のある特定の世論調査では、PGM親は子供の数をm / pと推定します。ここで、mは受け取った応答の数です。PGMの親は、定期的に投票を続け、最近の世論調査の結果の平均を子供の数の推定として使用する必要があります。
Specific polls provide a way to search for PGM children that comply to specific requisites. As an example specific poll could be used to search for down-stream DLRs. A specific poll is characterized by a POLL_S_TYPE different from PGM_POLL_GENERAL. PGM children decide whether to reply to a specific poll or not based on the POLL_S_TYPE, on the random condition and on options possibly present in the POLL. The way options should be interpreted is defined by POLL_S_TYPE. The random condition MUST be interpreted as an additional condition to be satisfied. To disable the random condition PGM parents MUST specify a probability of replying P equal to 1.
特定の世論調査は、特定の必要条件に準拠するPGMの子供を検索する方法を提供します。例として、特定の投票を使用して、ダウンストリームDLRを検索できます。特定の投票は、PGM_POLL_GENERALとは異なるPOLL_S_TYPEによって特徴付けられます。PGMの子供は、Poll_s_type、ランダムな状態、およびおそらく投票に存在するオプションに基づいて、特定の投票に返信するかどうかを決定します。オプションを解釈する方法は、poll_s_typeによって定義されます。ランダムな条件は、満たすために追加の条件として解釈する必要があります。ランダムな状態を無効にするには、PGM親は1に等しいPに応答する確率を指定する必要があります。
PGM children MUST ignore a POLL packet if they do not understand POLL_S_TYPE. Some specific POLL_S_TYPE may also require that the children ignore a POLL if they do not fully understand all the PGM options present in the packet.
PGMの子供は、Poll_s_typeを理解していない場合、投票パケットを無視する必要があります。一部の特定のPoll_s_typeは、パケットに存在するすべてのPGMオプションを完全に理解していない場合、子供が世論調査を無視することを要求する場合があります。
A PGM parent (source or network element), that wants to poll the first PGM-hop children connected to one of its outgoing interfaces MUST send a POLL packet on that interface with:
発信インターフェイスのいずれかに接続された最初のPGM-HOPの子供を投票したいPGM親（ソースまたはネットワーク要素）は、次のインターフェースでポーリングパケットを送信する必要があります。
POLL_SQN equal to POLL_SQN of the last POLL sent incremented by one. If poll rounds are used, this must be equal to POLL_SQN of the last group of rounds incremented by one.
Poll_sqnは、1つずつ増加した最後の世論調査のPoll_sqnに等しくなりました。投票ラウンドを使用する場合、これは1つで増加したラウンドの最後のグループのPoll_sqnに等しくなければなりません。
POLL_ROUND The round of the poll. If the poll has a single round, this must be zero. If the poll has multiple rounds, this must be one plus the last POLL_ROUND for the same POLL_SQN, or zero if this is the first round within this POLL_SQN.
Poll_Round Pollのラウンド。投票に1回のラウンドがある場合、これはゼロでなければなりません。投票に複数のラウンドがある場合、これは1つに加えて、同じPoll_sqnの最後のpoll_round、またはこのpoll_sqn内の最初のラウンドである場合はゼロでなければなりません。
POLL_S_TYPE the type of the poll. For general poll use PGM_POLL_GENERAL
Poll_s_type投票のタイプ。一般的な投票には、pgm_poll_generalを使用します
POLL_PATH set to the NLA of the outgoing interface
Poll_Pathは、発信インターフェイスのNLAに設定されています
POLL_BO_IVL set to the wanted reply back-off interval. As far as the choice of this is concerned, using NAK_BO_IVL is usually a conservative option, however a smaller value MAY be used, if the number of expected replies can be determined with a good confidence or if a conservatively low probability of reply (P) is being used (see POLL_MASK next). When the number of expected replies is unknown, a large POLL_BO_IVL SHOULD be used, so that the poll can be effectively aborted if the number of replies being received is too large.
Poll_bo_ivlは、必要な返信バックオフインターバルに設定されています。これに関する限り、nak_bo_ivlを使用することは通常保守的なオプションですが、予想される応答の数を自信を持って決定できる場合、または控えめに低い返信の可能性（p）を決定できる場合、値が少ない場合があります。使用されています（Poll_Mask Nextを参照）。予想される返信の数が不明な場合、大規模なPoll_bo_ivlを使用する必要があります。そのため、受信されている返信の数が大きすぎると、投票を効果的に中止できます。
POLL_RAND MUST be a random string re-computed each time a new poll is sent on a given interface
Poll_randは、特定のインターフェイスに新しい投票が送信されるたびに、ランダムな文字列である必要があります。
POLL_MASK determines the probability of replying, P, according to the relationship P = 1 / ( 2 ^ B ), where B is the number of bits set in POLL_MASK [15]. If this is a deterministic poll, B MUST be 0, i.e. POLL_MASK MUST be a all-zeroes bit-mask.
Poll_maskは、関係p = 1 /（2 ^ b）の関係に従って応答の確率を決定します。ここで、BはPoll_mask [15]に設定されたビットの数です。これが決定論的投票である場合、Bは0でなければなりません。つまり、Poll_Maskは全ゼロビットマスクでなければなりません。
Nota Bene: POLLs transmitted by network elements MUST bear the ODATA source's network-header source address, not the network element's NLA. POLLs MUST also be transmitted with the IP
Nota Bene：ネットワーク要素によって送信される投票は、ネットワーク要素のNLAではなく、ODATAソースのネットワークヘッダーソースアドレスを負担する必要があります。また、世論調査にはIPを送信する必要があります
Router Alert Option [6], to be allow PGM network element to intercept them.
ルーターアラートオプション[6]、PGMネットワーク要素がそれらを傍受できるようにします。
A PGM parent that has started a poll by sending a POLL packet SHOULD wait at least POLL_BO_IVL before starting another poll. During this interval it SHOULD collect all the valid response (the one with POLR_SQN and POLR_ROUND matching with the outstanding poll) and process them at the end of the collection interval.
投票パケットを送信して投票を開始したPGM親は、別の投票を開始する前に、少なくともPoll_bo_ivlを待つ必要があります。この間隔では、すべての有効な応答（POLR_SQNとPOLR_ROUNDが未払いの投票と一致するもの）を収集し、コレクション間隔の最後に処理する必要があります。
A PGM parent SHOULD observe the rules mentioned in the description of general procedures, to prevent implosion of response. These rules should in general be observed both for generic polls and specific polls. The latter however can be performed using deterministic poll (with no implosion prevention) if the expected number of replies is known to be small. A PGM parent that issue a generic poll with the intent of estimating the children population size SHOULD use poll rounds to "freeze" the children that are involved in the measure process. This allows the sender to "open the door wider" across subsequent rounds (by increasing the probability of response), without fear of being flooded by late joiners. Note the use of rounds has the drawback of introducing additional delay in the estimate of the population size, as the estimate obtained at the end of a round-group refers to the condition present at the time of the first round.
PGMの親は、応答の崩壊を防ぐために、一般的な手順の説明に記載されている規則を遵守する必要があります。これらの規則は、一般に、一般的な世論調査と特定の世論調査の両方で観察されるべきです。ただし、後者は、予想される回答の数が小さいことがわかっている場合、決定論的な世論調査（爆発防止なし）を使用して実行できます。子どもの人口規模を推定する目的で一般的な世論調査を発行するPGM親は、投票ラウンドを使用して、測定プロセスに関与している子供を「フリーズ」する必要があります。これにより、送信者は、遅いジョイナーに浸水することを恐れることなく、その後のラウンドで（応答の可能性を高めることにより）「ドアを広く開く」ことができます。注ラウンドの使用には、ラウンドグループの終わりに得られた推定値が最初のラウンドの時点で存在する状態を指しているため、人口サイズの推定に追加の遅延を導入するという欠点があります。
A PGM parent that has started a poll SHOULD monitor the number of replies during the collection phase. If this become too large, the PGM parent SHOULD abort the poll by immediately starting a new poll (different POLL_SQN) and specifying a very low probability of replying.
投票を開始したPGM親は、収集段階での返信数を監視する必要があります。 これが大きすぎると、PGMの親は、すぐに新しい世論調査（異なるPoll_sqn）を開始し、応答の可能性が非常に低いことを指定することにより、投票を中止する必要があります。
When polling is being used to estimate the receiver population for the purpose of calculating NAK_BO_IVL, OPT_NAK_BO_IVL (see 16.4.1 below) MUST be appended to SPMs, MAY be appended to NCFs and POLLs, and in all cases MUST have NAK_BO_IVL_SQN set to POLL_SQN of the most recent complete round of polls, and MUST bear that round's corresponding derived value of NAK_BAK_IVL. In this way, OPT_NAK_BO_IVL provides a current value for NAK_BO_IVL at the same time as information is being gathered for the calculation of a future value of NAK_BO_IVL.
NAK_BO_IVLを計算する目的で受信機母集団を推定するためにポーリングが使用されている場合、OPT_NAK_BO_IVL（以下の16.4.1を参照）はSPMSに追加され、NCFSおよび世論調査に追加される必要があり、すべての場合、NAK_BO_IVL_SQNを投票に設定する必要があります。 投票の最新の完全なラウンドであり、NAK_BAK_IVLのラウンドに対応する派生価値を負わなければなりません。 このようにして、opt_nak_bo_ivlは、nak_bo_ivlの将来の値の計算のために情報が収集されていると同時に、NAK_BO_IVLの現在の値を提供します。
PGM receivers and network elements MUST compute a 32-bit random node identifier (RAND_NODE_ID) at startup time. When a PGM child (receiver or network element) receives a POLL it MUST use its RAND_NODE_ID to match POLL_RAND of incoming POLLs. The match is limited to the bits specified by POLL_MASK. If the incoming POLL contain a POLL_MASK made of all zeroes, the match is successful despite the content of POLL_RAND (deterministic reply). If the match fails, then the receiver or network element MUST discard the POLL without any further action, otherwise it MUST check the fields POLL_ROUND, POLL_S_TYPE and any PGM option included in the POLL to determine whether it SHOULD reply to the poll.
PGMレシーバーとネットワーク要素は、起動時に32ビットランダムノード識別子（rand_node_id）を計算する必要があります。PGMの子供（受信機またはネットワーク要素）が投票を受け取った場合、そのrand_node_idを使用して、世論調査のpoll_randを一致させる必要があります。試合は、Poll_maskで指定されたビットに限定されています。入ってくる世論調査にすべてのゼロで作られたPoll_maskが含まれている場合、Poll_rand（決定論的な返信）の内容にもかかわらず、試合は成功します。一致が失敗した場合、レシーバーまたはネットワーク要素は、それ以上のアクションなしで投票を破棄する必要があります。そうしないと、Poll_round、Poll_s_type、および投票に返信するかどうかを判断するために、Poll_s_type、およびPGMオプションを確認する必要があります。
If POLL_ROUND is non-zero and the PGM receiver has not received a previous poll with the same POLL_SQN and a zero POLL_ROUND, it MUST discard the poll without further action.
Poll_Roundがゼロ以外であり、PGMレシーバーが同じPoll_SQNとゼロPoll_Roundの以前の世論調査を受け取っていない場合、さらなるアクションなしで世論調査を破棄する必要があります。
If POLL_S_TYPE is equal to PGM_POLL_GENERAL, the PGM child MUST schedule a reply to the POLL despite the presence of PGM options on the POLL packet.
Poll_s_typeがPGM_POLL_GENERALに等しい場合、PGMの子供は、POLLパケットにPGMオプションが存在するにもかかわらず、投票への返信をスケジュールする必要があります。
If POLL_S_TYPE is different from PGM_POLL_GENERAL, the decision on whether a reply should be scheduled depends on the actual type and on the options possibly present in the POLL.
Poll_s_typeがPGM_POLL_GENERALとは異なる場合、返信をスケジュールする必要があるかどうかの決定は、実際のタイプと世論調査に存在する可能性のあるオプションによって異なります。
If POLL_S_TYPE is unknown to the recipient of the POLL, it MUST NOT reply and ignore the poll. Currently the only POLL_S_TYPE defined are PGM_POLL_GENERAL and PGM_POLL_DLR.
Poll_s_typeが世論調査の受信者に不明な場合、投票を返信して無視してはなりません。現在、定義されている唯一のPOLL_S_TYPEはPGM_POLL_GENERALとPGM_POLL_DLRです。
If a PGM receiver or network element has decided to reply to a POLL, it MUST schedule the transmission of a single POLR at a random time in the future. The random delay is chosen in the interval [0, POLL_BO_IVL]. POLL_BO_IVL is the one contained in the POLL received. When this timer expires, it MUST send a POLR using POLL_PATH of the received POLL as destination address. POLR_SQN MUST be equal to POLL_SQN and POLR_ROUND must be equal to POLL_ROUND. The POLR MAY contain PGM options according to the semantic of POLL_S_TYPE or the semantic of PGM options possibly present in the POLL. If POLL_S_TYPE is PGM_POLL_GENERAL no option is REQUIRED.
PGMレシーバーまたはネットワーク要素が世論調査に返信することを決定した場合、将来のランダムな時間に単一のPOLRの送信をスケジュールする必要があります。ランダム遅延は、間隔[0、poll_bo_ivl]で選択されます。Poll_bo_ivlは、受け取った世論調査に含まれるものです。このタイマーが期限切れになった場合、受信した投票のPoll_Pathを使用してPOLRを宛先アドレスとして送信する必要があります。polr_sqnはpoll_sqnと等しく、polr_roundはpoll_roundに等しくなければなりません。POLRには、POLL_S_TYPEのセマンティックまたは投票に存在するPGMオプションのセマンティックに応じてPGMオプションが含まれる場合があります。poll_s_typeがpgm_poll_generalの場合、オプションは不要です。
A PGM receiver or network element MUST cancel any pending transmission of POLRs if a new POLL is received with POLL_SQN different from POLR_SQN of the poll that scheduled POLRs.
PGMレシーバーまたはネットワーク要素は、POLL_SQNがPOLR_SQNとは異なるPOLR_SQNがスケジュールされたPOLR_SQNを使用して新しい世論調査を受け取った場合、POLRの保留中の送信をキャンセルする必要があります。
The POLL_S_TYPE values currently defined are:
現在定義されているPoll_s_Type値は次のとおりです。
PGM_POLL_GENERAL 0
PGM_POLL_GENERAL 0
PGM_POLL_DLR 1
PGM_POLL_DLR 1
The packet formats described in this section are transport-layer headers that MUST immediately follow the network-layer header in the packet.
このセクションで説明するパケット形式は、パケットのネットワーク層ヘッダーをすぐに追跡する必要がある輸送層ヘッダーです。
The descriptions of Data-Source Port, Data-Destination Port, Options, Checksum, Global Source ID (GSI), and TSDU Length are those provided in Section 8.
データソースポート、データ分配ポート、オプション、チェックサム、グローバルソースID（GSI）、およびTSDUの長さの説明は、セクション8に記載されているものです。
POLL are sent by PGM parents (sources or network elements) to initiate a poll among their first PGM-hop children.
投票は、PGMの親（ソースまたはネットワーク要素）によって送信され、最初のPGM-HOPの子供の間で投票を開始します。
POLLs are sent to the ODATA multicast group. The network-header source address of a POLL is the ODATA source's NLA. POLL MUST be transmitted with the IP Router Alert Option.
世論調査はOdataマルチキャストグループに送信されます。投票のネットワークヘッダーソースアドレスは、ODATAソースのNLAです。Pollは、IPルーターアラートオプションを使用して送信する必要があります。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POLL's Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POLL's Round | POLL's Sub-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLA AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path NLA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| POLL's Back-off Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Matching Bit-Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Extensions when present ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:
ソースポート：
POLL_SPORT
Poll_sport
Data-Source Port, together with POLL_GSI forms POLL_TSI
Data-Sourceポート、Poll_gsiフォームPoll_tsi
Destination Port:
宛先ポート：
POLL_DPORT
Poll_dport
Data-Destination Port
データ照射ポート
Type:
タイプ：
POLL_TYPE = 0x01
Global Source ID:
グローバルソースID：
POLL_GSI
Poll_gsi
Together with POLL_SPORT forms POLL_TSI
Poll_sportフォームPoll_tsiと一緒に
POLL's Sequence Number
Pollのシーケンス番号
POLL_SQN
Poll_sqn
The sequence number assigned to the POLL by the originator.
発信者によって投票に割り当てられたシーケンス番号。
POLL's Round
世論調査のラウンド
POLL_ROUND
Poll_round
The round number within the poll sequence number.
ポーリングシーケンス番号内のラウンド番号。
POLL's Sub-type
Pollのサブタイプ
POLL_S_TYPE
Poll_s_type
The sub-type of the poll request.
投票要求のサブタイプ。
Path NLA:
パスNLA：
POLL_PATH
Poll_Path
The NLA of the interface on the source or network element on which this POLL was forwarded.
この投票が転送されたソースまたはネットワーク要素上のインターフェイスのNLA。
POLL's Back-off Interval
世論調査のバックオフ間隔
POLL_BO_IVL
Poll_bo_ivl
The back-off interval used to compute a random back-off for the reply, expressed in microseconds.
マイクロ秒で表現された応答のランダムバックオフを計算するために使用されるバックオフ間隔。
Random String
ランダムな文字列
POLL_RAND
Poll_rand
A random string used to implement the random condition in replying.
応答でランダムな条件を実装するために使用されるランダムな文字列。
Matching Bit-Mask
一致するビットマスク
POLL_MASK
Poll_mask
A bit-mask used to determine the probability of random replies.
ランダム応答の確率を決定するために使用されるビットマスク。
POLR are sent by PGM children (receivers or network elements) to reply to a POLL.
POLRは、PGMの子供（受信機またはネットワーク要素）から投票に返信するために送信されます。
The network-header source address of a POLR is the unicast NLA of the entity that originates the POLR. The network-header destination address of a POLR is initialized by the originator of the POLL to the unicast NLA of the upstream PGM element (source or network element) known from the POLL that triggered the POLR.
POLRのネットワークヘッダーソースアドレスは、POLRを発信するエンティティのユニキャストNLAです。POLRのネットワークヘッダー宛先アドレスは、POLRを引き起こした世論調査から知られている上流のPGM要素（ソースまたはネットワーク要素）のユニキャストNLAへの投票の発信者によって初期化されます。
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 Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Source ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Global Source ID | TSDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POLR's Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POLR's Round | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Extensions when present ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:
ソースポート：
POLR_SPORT
polr_sport
Data-Destination Port
データ照射ポート
Destination Port:
宛先ポート：
POLR_DPORT
polr_dport
Data-Source Port, together with Global Source ID forms POLR_TSI
データソースポート、グローバルソースIDフォームPOLR_TSI
Type:
タイプ：
POLR_TYPE = 0x02
Global Source ID:
グローバルソースID：
POLR_GSI
polr_gsi
Together with POLR_DPORT forms POLR_TSI
POLR_DPORTフォームPOLR_TSIと一緒に
POLR's Sequence Number
POLRのシーケンス番号
POLR_SQN
polr_sqn
The sequence number (POLL_SQN) of the POLL packet for which this is a reply.
これが返信であるPoll Packetのシーケンス番号（Poll_sqn）。
POLR's Round
Polr's Round
POLR_ROUND
polr_round
The round number (POLL_ROUND) of the POLL packet for which this is a reply.
これが返信であるPoll Packetのラウンド番号（Poll_Round）。
These procedures are intended to prevent NAK implosion and to limit its extent in case of the loss of all or part of the suppressing multicast distribution tree. They also provide a means to adaptively tune the NAK back-off interval, NAK_BO_IVL.
これらの手順は、NAKの崩壊を防ぎ、抑制マルチキャスト分布ツリーのすべてまたは一部が失われた場合にその範囲を制限することを目的としています。また、NAKバックオフ間隔NAK_BO_IVLを適応的に調整する手段も提供します。
The PGM virtual topology is established and refreshed by SPMs. Between one SPM and the next, PGM nodes may have an out-of-date view of the PGM topology due to multicast routing changes, flapping, or a link/router failure. If any of the above happens relative to a PGM parent node, a potential NAK implosion problem arises because the parent node is unable to suppress the generation of duplicate NAKs as it cannot reach its children using NCFs. The procedures described below introduce an alternative way of performing suppression in this case. They also attempt to prevent implosion by adaptively tuning NAK_BO_IVL.
PGM仮想トポロジーは、SPMSによって確立され、更新されます。あるSPMと次のSPMの間で、PGMノードは、マルチキャストルーティングの変更、羽ばたき、またはリンク/ルーターの障害により、PGMトポロジの時代遅れのビューを持つ場合があります。上記のいずれかがPGM親ノードに比べて発生した場合、親ノードがNCFSを使用して子供に到達できないため、親ノードが重複したNAKの生成を抑制できないため、潜在的なNAK爆発の問題が発生します。以下に説明する手順では、この場合に抑制を実行する別の方法を紹介します。彼らはまた、NAK_BO_IVLを適応的に調整することにより、内破の防止を試みます。
Sources and network elements continuously monitor the number of duplicated NAKs received and use this observation to tune the NAK back-off interval (NAK_BO_IVL) for the first PGM-hop receivers connected to them. Receivers learn the current value of NAK_BO_IVL through OPT_NAK_BO_IVL appended to NCFs or SPMs.
ソースとネットワーク要素は、受信した重複したNAKの数を継続的に監視し、この観察結果を使用して、それらに接続された最初のPGM-HOPレシーバーのNAKバックオフ間隔（NAK_BO_IVL）を調整します。受信者は、NCFSまたはSPMSに追加されたOPT_NAK_BO_IVLを介してNAK_BO_IVLの現在の値を学習します。
For each TSI, sources and network elements advertise the value of NAK_BO_IVL that their first PGM-hop receivers should use. They advertise a separate value on all the outgoing interfaces for the TSI and keep track of the last values advertised.
各TSIについて、ソースとネットワーク要素は、最初のPGM-HOPレシーバーが使用するNAK_BO_IVLの価値を宣伝します。彼らは、TSIのすべての発信インターフェイスに個別の値を宣伝し、宣伝されている最後の値を追跡します。
For each interface and TSI, sources and network elements count the number of NAKs received for a specific repair state (i.e., per sequence number per TSI) from the time the interface was first added to the repair state list until the time the repair state is discarded. Then they use this number to tune the current value of NAK_BO_IVL as follows:
各インターフェイスとTSIについて、ソースとネットワーク要素について、特定の修復状態で受信したNAKの数（TSIあたりのシーケンス数）の数をカウントします。廃棄されました。次に、この番号を使用して、次のようにNAK_BO_IVLの現在の値を調整します。
Increase the current value NAK_BO_IVL when the first duplicate NAK is received for a given SQN on a particular interface.
特定のインターフェイスで特定のSQNに対して最初の重複NAKが受信された場合、現在の値NAK_BO_IVLを増やします。
Decrease the value of NAK_BO_IVL if no duplicate NAKs are received on a particular interface for the last NAK_PROBE_NUM measurements where each measurement corresponds to the creation of a new repair state.
各測定が新しい修理状態の作成に対応する最後のNAK_PROBE_NUM測定の特定のインターフェイスで重複したNAKが受信されない場合、NAK_BO_IVLの値を減少させます。
An upper and lower limit are defined for the possible value of NAK_BO_IVL at any time. These are NAK_BO_IVL_MAX and NAK_BO_IVL_MIN respectively. The initial value that should be used as a starting point to tune NAK_BO_IVL is NAK_BO_IVL_DEFAULT. The policies RECOMMENDED for increasing and decreasing NAK_BO_IVL are multiplying by two and dividing by two respectively.
上限と下限は、NAK_BO_IVLの可能性のある値に対していつでも定義されます。これらはそれぞれNak_bo_ivl_maxとNak_bo_ivl_minです。NAK_BO_IVLを調整するための出発点として使用する必要がある初期値は、NAK_BO_IVL_DEFAULTです。NAK_BO_IVLの増加と減少に推奨されるポリシーには、それぞれ2倍になり、それぞれ2倍に分割されています。
Sources and network elements advertise the current value of NAK_BO_IVL through the OPT_NAK_BO_IVL that they append to NCFs. They MAY also append OPT_NAK_BO_IVL to outgoing SPMs.
ソースとネットワーク要素は、NCFSに追加されたOPT_NAK_BO_IVLを介してNAK_BO_IVLの現在の値を宣伝しています。また、OPT_NAK_BO_IVLを発信SPMに追加することもできます。
In order to avoid forwarding the NAK_BO_IVL advertised by the parent, network elements must be able to recognize OPT_NAK_BO_IVL. Network elements that receive SPMs containing OPT_NAK_BO_IVL MUST either remove the option or over-write its content (NAK_BO_IVL) with the current value of NAK_BO_IVL for the outgoing interface(s), before forwarding the SPMs.
親によって宣伝されているNAK_BO_IVLの転送を避けるために、ネットワーク要素はOPT_NAK_BO_IVLを認識できる必要があります。OPT_NAK_BO_IVLを含むSPMSを受信するネットワーク要素は、SPMを転送する前に、OPT_BO_IVLを含むSPMSを受信します。
Sources MAY advertise the value of NAK_BO_IVL_MAX and NAK_BO_IVL_MIN to the session by appending a OPT_NAK_BO_RNG to SPMs.
ソースは、opt_nak_bo_rngをSPMSに追加することにより、Nak_bo_ivl_maxとnak_bo_ivl_minの値をセッションに宣伝する場合があります。
Receivers learn the value of NAK_BO_IVL to use through the option OPT_NAK_BO_IVL, when this is present in NCFs or SPMs. A value for NAK_BO_IVL learned from OPT_NAK_BO_IVL MUST NOT be used by a receiver unless either NAK_BO_IVL_SQN is zero, or the receiver has seen POLL_RND == 0 for POLL_SQN =< NAK_BO_IVL_SQN within half the sequence number space. The initial value of NAK_BO_IVL is set to NAK_BO_IVL_DEFAULT.
受信者は、NCFSまたはSPMSに存在する場合、オプションopt_nak_bo_ivlを介して使用するNAK_BO_IVLの値を学習します。opt_nak_bo_ivlから学習したnak_bo_ivlの値は、nak_bo_ivl_sqnがゼロであるか、レシーバーがpoll_rnd == 0のpoll_sqn = <nak_bo_vivl_sqnのシーケンス番号スペースの半分内でpoll_rnd == 0を見ていない限り、受信者が使用する必要はありません。NAK_BO_IVLの初期値は、NAK_BO_IVL_DEFAULTに設定されています。
Receivers that receive an SPM containing OPT_NAK_BO_RNG MUST use its content to set the local values of NAK_BO_IVL_MAX and NAK_BO_IVL_MIN.
OPT_NAK_BO_RNGを含むSPMを受信するレシーバーは、そのコンテンツを使用して、NAK_BO_IVL_MAXとNAK_BO_IVL_MINのローカル値を設定する必要があります。
Monitoring the number of duplicate NAKs provides a means to track indirectly the change in the size of first PGM-hop receiver population and adjust NAK_BO_IVL accordingly. Note that the number of duplicate NAKs for a given SQN is related to the number of first PGM-hop children that scheduled (or forwarded) a NAK and not to the absolute number of first PGM-hop children. This mechanism, however, does not work in the absence of packet loss, hence a large number of duplicate NAKs is possible after a period without NAKs, if many new receivers have joined the session in the meanwhile. To address this issue, PGM Sources and network elements SHOULD periodically poll the number of first PGM-hop children using the "general poll" procedures described in Appendix D. If the result of the polls shows that the population size has increased significantly during a period without NAKs, they SHOULD increase NAK_BO_IVL as a safety measure.
重複したNAKの数を監視すると、最初のPGM-HOP受信者集団のサイズの変化を間接的に追跡し、それに応じてNAK_BO_IVLを調整する手段が提供されます。特定のSQNの重複NAKの数は、NAKをスケジュール（または転送）した最初のPGM-HOP子供の数に関連しており、最初のPGM-HOPの子供の絶対数ではないことに注意してください。ただし、このメカニズムはパケット損失がない場合は機能しないため、多くの新しい受信機がその間にセッションに参加した場合、NAKSのない期間後に多数の重複したNAKが可能になります。この問題に対処するために、PGMソースとネットワーク要素は、付録Dで説明されている「一般投票」手順を使用して、最初のPGM-HOPの子供の数を定期的に投票する必要があります。世論調査の結果が期間中に人口規模が大幅に増加したことを示している場合NAKSがなければ、安全対策としてNAK_BO_IVLを増やす必要があります。
In some cases PGM (parent) network elements can promptly detect the loss of all or part of the suppressing multicast distribution tree (due to network failures or route changes) by checking their multicast connectivity, when they receive NAKs. In some other cases this is not possible as the connectivity problem might occur at some other non-PGM node downstream or might take time to reflect in the multicast routing table. To address these latter cases, PGM uses a simple heuristic: a failure is assumed for a TSI when the count of duplicated NAKs received for a repair state reaches the value DUP_NAK_MAX in one of the interfaces.
場合によっては、PGM（親）ネットワーク要素は、NAKを受け取ったときにマルチキャスト接続をチェックすることにより、マルチキャスト分布ツリーの抑制（ネットワーク障害またはルートの変更により）のすべてまたは一部の損失を迅速に検出できます。他の場合には、下流の他の非PGMノードで接続性の問題が発生するか、マルチキャストルーティングテーブルで反射するのに時間がかかる可能性があるため、これは不可能です。これらの後者のケースに対処するために、PGMは単純なヒューリスティックを使用します。修復状態で受信された重複したNAKのカウントがインターフェイスの1つでdup_nak_maxの値に達すると、TSIの障害が想定されます。
When a PGM source or network element detects or assumes a failure for which it looses multicast connectivity to down-stream PGM agents (either receivers or other network elements), it sends unicast NCFs to them in response to NAKs. Downstream PGM network elements which receive unicast NCFs and have multicast connectivity to the multicast session send special SPMs to prevent further NAKs until a regular SPM sent by the source refreshes the PGM tree.
PGMソースまたはネットワーク要素が、ダウンストリームPGMエージェント（受信機またはその他のネットワーク要素のいずれか）へのマルチキャスト接続を緩める障害を検出または仮定すると、NAKに応じてユニキャストNCFを送信します。ユニキャストNCFを受信し、マルチキャストセッションへのマルチキャスト接続を備えた下流のPGMネットワーク要素は、ソースから送信された通常のSPMがPGMツリーをリフレッシュするまで、さらなるNAKを防ぐために特別なSPMを送信します。
Procedures - Sources and Network Elements
手順 - ソースとネットワーク要素
PGM sources or network elements which detect or assume a failure that prevents them from reaching down-stream PGM agents through multicast NCFs revert to confirming NAKs through unicast NCFs for a given TSI on a given interface. If the PGM agent is the source itself, than it MUST generate an SPM for the TSI, in addition to sending the unicast NCF.
マルチキャストNCFを介してダウンストリームPGMエージェントに到達できない障害を検出または想定するPGMソースまたはネットワーク要素は、特定のインターフェイス上の特定のTSIのユニキャストNCFSを介してNAKを確認します。PGMエージェントがソース自体である場合、ユニキャストNCFの送信に加えて、TSIのSPMを生成する必要があります。
Network elements MUST keep using unicast NCFs until they receive a regular SPM from the source.
ネットワーク要素は、ソースから通常のSPMを受信するまで、ユニキャストNCFを使用し続ける必要があります。
When a unicast NCF is sent for the reasons described above, it MUST contain the OPT_NBR_UNREACH option and the OPT_PATH_NLA option. OPT_NBR_UNREACH indicates that the sender is unable to use multicast to reach downstream PGM agents. OPT_PATH_NLA carries the network layer address of the NCF sender, namely the NLA of the interface leading to the unreachable subtree.
上記の理由でユニキャストNCFが送信される場合、OPT_NBR_UNREACHオプションとOPT_PATH_NLAオプションを含める必要があります。OPT_NBR_UNREACHは、送信者がマルチキャストを使用して下流のPGMエージェントに到達できないことを示します。opt_path_nlaは、NCF送信者のネットワークレイヤーアドレス、つまり、到達不可能なサブツリーにつながるインターフェイスのNLAを運びます。
When a PGM network element receives an NCF containing the OPT_NBR_UNREACH option, it MUST ignore it if OPT_PATH_NLA specifies an upstream neighbour different from the one currently known to be the upstream neighbor for the TSI. Assuming the network element matches the OPT_PATH_NLA of the upstream neighbour address, it MUST stop forwarding NAKs for the TSI until it receives a regular SPM for the TSI. In addition, it MUST also generate a special SPM to prevent downstream receivers from sending more NAKs. This special SPM MUST contain the OPT_NBR_UNREACH option and SHOULD have a SPM_SQN equal to SPM_SQN of the last regular SPM forwarded. The OPT_NBR_UNREACH option invalidates the windowing information in SPMs (SPM_TRAIL and SPM_LEAD). The PGM network element that adds the OPT_NBR_UNREACH option SHOULD invalidate the windowing information by setting SPM_TRAIL to 0 and SPM_LEAD to 0x80000000.
PGMネットワーク要素がOPT_NBR_UNREACHオプションを含むNCFを受信した場合、OPT_PATH_NLAがTSIの上流の隣人であると現在知られている隣人とは異なるアップストリーム隣人を指定する場合、それを無視する必要があります。ネットワーク要素がアップストリームネイバーアドレスのOPT_PATH_NLAと一致すると仮定すると、TSIの通常のSPMを受信するまでTSIのNAKの転送を停止する必要があります。さらに、下流の受信機がより多くのNAKを送信するのを防ぐために、特別なSPMも生成する必要があります。この特別なSPMには、OPT_NBR_UNREACHオプションが含まれている必要があり、最後の通常のSPM転送のSPM_SQNに等しいSPM_SQNが必要です。OPT_NBR_UNREACHオプションは、SPMS（SPM_TRAILおよびSPM_LEAD）のウィンドウ情報を無効にします。OPT_NBR_UNREACHオプションを追加するPGMネットワーク要素は、SPM_TRAILを0に、SPM_LEADを0x80000000に設定することにより、ウィンドウ情報を無効にする必要があります。
PGM network elements which receive an SPM containing the OPT_NBR_UNREACH option and whose SPM_PATH matches the currently known PGM parent, MUST forward them in the normal way and MUST stop forwarding NAKs for the TSI until they receive a regular SPM for the TSI. If the SPM_PATH does not match the currently known PGM parent, the SPM containing the OPT_NBR_UNREACH option MUST be ignored.
OPT_NBR_UNREACHオプションを含み、SPM_PATHが現在既知のPGM親と一致するSPMを受信するPGMネットワーク要素は、通常の方法で転送する必要があり、TSIの通常のSPMを受け取るまでTSIのNAKの転送を停止する必要があります。SPM_PATHが現在既知のPGM親と一致しない場合、OPT_NBR_UNREACHオプションを含むSPMは無視する必要があります。
Procedures - Receivers
手順 - 受信機
PGM receivers which receive either an NCF or an SPM containing the OPT_NBR_UNREACH option MUST stop sending NAKs until a regular SPM is received for the TSI.
NCFまたはOPT_NBR_UNREACHオプションを含むSPMを受け取るPGMレシーバーは、TSIの通常のSPMを受信するまでNAKの送信を停止する必要があります。
On reception of a unicast NCF containing the OPT_NBR_UNREACH option receivers MUST generate a multicast copy of the packet with TTL set to one on the RPF interface for the data source. This will prevent other receivers in the same subnet from generating NAKs.
opt_nbr_unreachオプションレシーバーを含むユニキャストNCFの受信時に、データソースのRPFインターフェイス上のTTLセットを使用してパケットのマルチキャストコピーを生成する必要があります。これにより、同じサブネット内の他のレシーバーがNAKを生成するのを防ぎます。
Receivers MUST ignore windowing information in SPMs which contain the OPT_NBR_UNREACH option.
受信機は、OPT_NBR_UNREACHオプションを含むSPMSのウィンドウ情報を無視する必要があります。
Receivers MUST ignore NCFs containing the OPT_NBR_UNREACH option if the OPT_PATH_NLA specifies a neighbour different than the one currently know to be the PGM parent neighbour. Similarly receivers MUST ignore SPMs containing the OPT_NBR_UNREACH option if SPM_PATH does not match the current PGM parent.
OPT_PATH_NLAがPGM親の隣人であると知っている隣人とは異なる隣人を指定した場合、受信機はOPT_NBR_UNREACHオプションを含むNCFSを無視する必要があります。同様に、SPM_PATHが現在のPGM親と一致しない場合、受信機はOPT_NBR_UNREACHオプションを含むSPMSを無視する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK Back-Off Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK Back-Off Interval SQN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x04
オプションタイプ= 0x04
NAK Back-Off Interval
NAKバックオフ間隔
The value of NAK-generation Back-Off Interval in microseconds.
マイクロ秒単位でのNAK世代のバックオフ間隔の値。
NAK Back-Off Interval Sequence Number
NAKバックオフ間隔シーケンス番号
The POLL_SQN to which this value of NAK_BO_IVL corresponds. Zero is reserved and means NAK_BO_IVL is NOT being determined through polling (see Appendix D) and may be used immediately. Otherwise, NAK_BO_IVL MUST NOT be used unless the receiver has also seen POLL_ROUND = 0 for POLL_SQN =< NAK_BO_IVL_SQN within half the sequence number space.
NAK_BO_IVLのこの値が対応するPOLL_SQN。ゼロは予約されており、NAK_BO_IVLがポーリングを通じて決定されていないことを意味し（付録Dを参照）、すぐに使用できます。それ以外の場合は、受信者がPoll_sqn = <nak_bo_ivl_sqnのpoll_round = 0をシーケンス番号スペースの半分以内に見た場合を除き、nak_bo_ivlを使用してはなりません。
OPT_NAK_BO_IVL MAY be appended to NCFs, SPMs, or POLLs.
opt_nak_bo_ivlは、NCF、SPM、または世論調査に追加される場合があります。
OPT_NAK_BO_IVL is network-significant.
opt_nak_bo_ivlはネットワーク有意です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum NAK Back-Off Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum NAK Back-Off Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x05
オプションタイプ= 0x05
Maximum NAK Back-Off Interval
最大NAKバックオフ間隔
The maximum value of NAK-generation Back-Off Interval in microseconds.
マイクロ秒単位でのNAK世代のバックオフ間隔の最大値。
Minimum NAK Back-Off Interval
最小NAKバックオフ間隔
The minimum value of NAK-generation Back-Off Interval in microseconds.
マイクロ秒単位でのNAK世代のバックオフ間隔の最小値。
OPT_NAK_BO_RNG MAY be appended to SPMs.
opt_nak_bo_rngはSPMに追加される場合があります。
OPT_NAK_BO_RNG is network-significant.
opt_nak_bo_rngはネットワーク有意です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0B
オプションタイプ= 0x0b
When present in SPMs, it invalidates the windowing information.
SPMSに存在する場合、ウィンドウインプリマーが無効になります。
OPT_NBR_UNREACH MAY be appended to SPMs and NCFs.
opt_nbr_unreachは、SPMSおよびNCFSに追加される場合があります。
OPT_NBR_UNREACH is network-significant.
opt_nbr_unreachはネットワーク有意です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Option Type | Option Length |Reserved |F|OPX|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path NLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0C
オプションタイプ= 0x0c
Path NLA
パスNLA
The NLA of the interface on the originating PGM network element that it uses to send multicast SPMs to the recipient of the packet containing this option.
このオプションを含むパケットの受信者にマルチキャストSPMを送信するために使用する発信元PGMネットワーク要素上のインターフェイスのNLA。
OPT_PATH_NLA MAY be appended to NCFs.
opt_path_nlaはNCFSに追加される場合があります。
OPT_PATH_NLA is network-significant.
opt_path_nlaはネットワーク有意です。
Nota Bene: The concept of and all references to the increment window (TXW_INC) and the window increment (TXW_ADV_SECS) throughout this document are for illustrative purposes only. They provide the shorthand with which to describe the concept of advancing the transmit window without also implying any particular implementation or policy of advancement.
Nota Bene：このドキュメント全体のインクリメントウィンドウ（TXW_INC）およびウィンドウ増分（TXW_ADV_SECS）の概念とすべての参照は、説明のみを目的としています。彼らは、特定の実装または進歩政策を意味することなく、送信ウィンドウを進めるという概念を説明する速記を提供します。
The size of the transmit window in seconds is simply TXW_SECS. The size of the transmit window in bytes (TXW_BYTES) is (TXW_MAX_RTE * TXW_SECS). The size of the transmit window in sequence numbers (TXW_SQNS) is (TXW_BYTES / bytes-per-packet).
数秒で送信ウィンドウのサイズは、単にTXW_SECSです。バイト（txw_bytes）の送信ウィンドウのサイズは（txw_max_rte * txw_secs）です。シーケンス番号（TXW_SQNS）の送信ウィンドウのサイズは（TXW_BYTES / BYTES-PACKET）です。
The fraction of the transmit window size (in seconds of data) by which the transmit window is advanced (TXW_ADV_SECS) is called the window increment. The trailing (oldest) such fraction of the transmit window itself is called the increment window.
送信ウィンドウ（TXW_ADV_SECS）が高度になる送信ウィンドウサイズ（データの秒）の割合は、ウィンドウ増分と呼ばれます。送信ウィンドウ自体のそのような部分の後続（最も古い）は、インクリメントウィンドウと呼ばれます。
In terms of sequence numbers, the increment window is the range of sequence numbers that will be the first to be expired from the transmit window. The trailing (or left) edge of the increment window is just TXW_TRAIL, the trailing (or left) edge of the transmit window. The leading (or right) edge of the increment window (TXW_INC) is defined as one less than the sequence number of the first data packet transmitted by the source TXW_ADV_SECS after transmitting TXW_TRAIL.
シーケンス番号に関しては、インクリメントウィンドウは、送信ウィンドウから最初に有効期限を取るシーケンス番号の範囲です。インクリメントウィンドウの後続（または左）は、送信ウィンドウの末尾（または左のエッジ）であるTXW_TRAILです。インクリメントウィンドウの先行（または右）エッジ（TXW_INC）は、TXW_TRAILを送信した後、ソースTXW_ADV_SECSによって送信された最初のデータパケットのシーケンス番号よりも少ないものとして定義されます。
A data packet is described as being "in" the transmit or increment window, respectively, if its sequence number is in the range defined by the transmit or increment window, respectively.
データパケットは、そのシーケンス番号がそれぞれ送信ウィンドウまたは増分ウィンドウで定義されている範囲にある場合、それぞれ送信または増分ウィンドウの「中」であると説明されます。
The transmit window is advanced across the increment window by the source when it increments TXW_TRAIL to TXW_INC. When the transmit window is advanced across the increment window, the increment window is emptied (i.e., TXW_TRAIL is momentarily equal to TXW_INC), begins to refill immediately as transmission proceeds, is full again TXW_ADV_SECS later (i.e., TXW_TRAIL is separated from TXW_INC by TXW_ADV_SECS of data), at which point the transmit window is advanced again, and so on.
TXW_TRAILをTXW_INCに増分すると、送信ウィンドウはソースによってインクリメントウィンドウを越えて高度になります。送信ウィンドウが増分ウィンドウを越えて前進すると、インクリメントウィンドウが空になり（つまり、TXW_TRAILはTXW_INCに一時的に等しくなります）、トランスミッションが進行するにつれてすぐに補充し始めます。データの）、その時点で送信ウィンドウが再び高度になります。
In anticipation of advancing the transmit window, the source starts a timer TXW_ADV_IVL_TMR which runs for time period TXW_ADV_IVL. TXW_ADV_IVL has a value in the range (0, TXW_ADV_SECS). The value MAY be configurable or MAY be determined statically by the strategy used for advancing the transmit window.
送信ウィンドウを進めることを見越して、ソースは期間TXW_ADV_IVLを実行するタイマーTXW_ADV_IVL_TMRを開始します。TXW_ADV_IVLの範囲（0、TXW_ADV_SECS）の値があります。値は構成可能であるか、送信ウィンドウの前進に使用される戦略によって静的に決定される場合があります。
When TXW_ADV_IVL_TMR is running, a source MAY reset TXW_ADV_IVL_TMR if NAKs are received for packets in the increment window. In addition, a source MAY transmit RDATA in the increment window with priority over other data within the transmit window.
TXW_ADV_IVL_TMRが実行されている場合、ソースは、インクリメントウィンドウのパケットに対してNAKが受信された場合、TXW_ADV_IVL_TMRをリセットできます。さらに、ソースは、送信ウィンドウ内の他のデータよりも優先されて、インクリメントウィンドウでRDATAを送信する場合があります。
When TXW_ADV_IVL_TMR expires, a source SHOULD advance the trailing edge of the transmit window from TXW_TRAIL to TXW_INC.
TXW_ADV_IVL_TMRが期限切れになると、ソースはTXW_TRAILからTXW_INCまで送信ウィンドウの末尾の端を前進させる必要があります。
Once the transmit window is advanced across the increment window, SPM_TRAIL, OD_TRAIL and RD_TRAIL are set to the new value of TXW_TRAIL in all subsequent transmitted packets, until the next window advancement.
送信ウィンドウが増分ウィンドウ全体に進出すると、SPM_TRAIL、OD_TRAIL、RD_TRAILは、次のウィンドウの進歩まで、その後のすべての送信パケットでTXW_TRAILの新しい値に設定されます。
PGM does not constrain the strategies that a source may use for advancing the transmit window. The source MAY implement any scheme or number of schemes. Three suggested strategies are outlined here.
PGMは、ソースが送信ウィンドウを進めるために使用できる戦略を制約しません。ソースは、スキームまたは数のスキームを実装できます。ここでは、3つの提案された戦略が概説されています。
Consider the following example:
次の例を考えてみましょう。
Assuming a constant transmit rate of 128kbps and a constant data packet size of 1500 bytes, if a source maintains the past 30 seconds of data for repair and increments its transmit window in 5 second increments, then
ソースが過去30秒のデータを修復し、送信ウィンドウを5秒の増分で増分するために過去30秒のデータを維持している場合、128kbpsの一定の送信率と1500バイトの一定のデータパケットサイズを仮定すると、その後
TXW_MAX_RTE = 16kBps TXW_ADV_SECS = 5 seconds, TXW_SECS = 35 seconds, TXW_BYTES = 560kB, TXW_SQNS = 383 (rounded up),
txw_max_rte = 16kbps txw_adv_secs = 5秒、txw_secs = 35秒、txw_bytes = 560kb、txw_sqns = 383（丸められた）、
and the size of the increment window in sequence numbers (TXW_MAX_RTE * TXW_ADV_SECS / 1500) = 54 (rounded down).
シーケンス数の増分ウィンドウのサイズ（txw_max_rte * txw_adv_secs / 1500）= 54（丸められて）。
Continuing this example, the following is a diagram of the transmit window and the increment window therein in terms of sequence numbers.
この例を継続すると、以下は送信ウィンドウの図と、シーケンス番号の観点からのインクリメントウィンドウの図です。
TXW_TRAIL TXW_LEAD
| |
| |
|--|--------------- Transmit Window -------------|----|
v | | v
v v
n-1 | n | n+1 | ... | n+53 | n+54 | ... | n+381 | n+382 | n+383
^
^ | ^
|--- Increment Window|---|
|
|
TXW_INC
So the values of the sequence numbers defining these windows are:
したがって、これらのウィンドウを定義するシーケンス番号の値は次のとおりです。
TXW_TRAIL = n
TXW_INC = n+53
TXW_LEAD = n+382
Nota Bene: In this example the window sizes in terms of sequence numbers can be determined only because of the assumption of a constant data packet size of 1500 bytes. When the data packet sizes are variable, more or fewer sequence numbers MAY be consumed transmitting the same amount (TXW_BYTES) of data.
Nota Bene：この例では、シーケンス番号の点でのウィンドウサイズは、1500バイトの一定のデータパケットサイズの仮定のためにのみ決定できます。データパケットサイズが可変の場合、データの同じ量（txw_bytes）を送信するシーケンス番号が消費される場合があります。
So, for a given transport session identified by a TSI, a source maintains: TXW_MAX_RTE a maximum transmit rate in kBytes per second, the cumulative transmit rate of some combination of SPMs, ODATA, and RDATA depending on the transmit window advancement strategy
したがって、TSIによって識別された特定の輸送セッションについて、ソースは次のように維持します：TXW_MAX_RTE 1秒あたりのKBYTESの最大送信速度、SPMS、ODATA、およびRDATAの累積送信率は、送信ウィンドウの前進戦略に依存します
TXW_TRAIL the sequence number defining the trailing edge of the transmit window, the sequence number of the oldest data packet available for repair
TXW_TRAIL送信ウィンドウの末尾エッジ、修理に利用できる最も古いデータパケットのシーケンス番号を定義するシーケンス番号
TXW_LEAD the sequence number defining the leading edge of the transmit window, the sequence number of the most recently transmitted ODATA packet
TXW_LEAD送信ウィンドウの最先端を定義するシーケンス番号、最近送信されたODATAパケットのシーケンス番号
TXW_INC the sequence number defining the leading edge of the increment window, the sequence number of the most recently transmitted data packet amongst those that will expire upon the next increment of the transmit window
TXW_INC増分ウィンドウのリーディングエッジを定義するシーケンス番号、最近送信されたデータパケットのシーケンス番号は、送信ウィンドウの次の増分時に期限切れになります。
PGM does not constrain the strategies that a source may use for advancing the transmit window. A source MAY implement any scheme or number of schemes. This is possible because a PGM receiver must obey the window provided by the source in its packets. Three strategies are suggested within this document.
PGMは、ソースが送信ウィンドウを進めるために使用できる戦略を制約しません。ソースは、スキームまたは数のスキームを実装できます。これは、PGMレシーバーがパケットにソースが提供するウィンドウに従わなければならないため、可能です。このドキュメント内では、3つの戦略が提案されています。
In the first, called "Advance with Time", the transmit window maintains the last TXW_SECS of data in real-time, regardless of whether any data was sent in that real time period or not. The actual number of bytes maintained at any instant in time will vary between 0 and TXW_BYTES, depending on traffic during the last TXW_SECS. In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs and ODATA.
「時刻とともに前進」と呼ばれる最初のものでは、送信ウィンドウは、実際の期間にデータが送信されたかどうかにかかわらず、データの最後のTXW_SECをリアルタイムで維持します。任意の瞬間に維持される実際のバイト数は、最後のTXW_SECのトラフィックに応じて、0からTXW_BYTESの間で変化します。この場合、TXW_MAX_RTEはSPMSおよびODATAの累積送信率です。
In the second, called "Advance with Data", the transmit window maintains the last TXW_BYTES bytes of data for repair. That is, it maintains the theoretical maximum amount of data that could be transmitted in the time period TXW_SECS, regardless of when they were transmitted. In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs, ODATA, and RDATA.
2番目の「Data with Data」と呼ばれる2番目では、送信ウィンドウは、修理のためのデータの最後のTXW_BYTESバイトを維持します。つまり、いつ送信されたかに関係なく、TXW_SECS期間に送信できる理論的な最大量のデータを維持します。この場合、TXW_MAX_RTEは、SPM、ODATA、およびRDATAの累積送信率です。
The third strategy leaves control of the window in the hands of the application. The API provided by a source implementation for this, could allow the application to control the window in terms of APDUs and to manually step the window. This gives a form of Application Level Framing (ALF). In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs, ODATA, and RDATA.
3番目の戦略は、アプリケーションの手に窓の制御を残します。このためのソース実装によって提供されるAPIは、アプリケーションがAPDUの観点からウィンドウを制御し、ウィンドウを手動でステップできるようにすることができます。これにより、アプリケーションレベルのフレーミング（ALF）の形式が得られます。この場合、TXW_MAX_RTEは、SPM、ODATA、およびRDATAの累積送信率です。
In the first strategy, TXW_MAX_RTE is calculated from SPMs and both ODATA and RDATA, and NAKs reset TXW_ADV_IVL_TMR. In this mode of operation the transmit window maintains the last TXW_BYTES bytes of data for repair. That is, it maintains the theoretical maximum amount of data that could be transmitted in the time period TXW_SECS. This means that the following timers are not treated as real-time timers, instead they are "data driven". That is, they expire when the amount of data that could be sent in the time period they define is sent. They are the SPM ambient time interval, TXW_ADV_SECS, TXW_SECS, TXW_ADV_IVL, TXW_ADV_IVL_TMR and the join interval. Note that the SPM heartbeat timers still run in real-time.
最初の戦略では、TXW_MAX_RTEはSPMSおよびOdataとRdataの両方から計算され、NaksはTXW_ADV_IVL_TMRからリセットされます。この操作モードでは、送信ウィンドウは、修理のためのデータの最後のTXW_BYTESバイトを維持します。つまり、TXW_SECSの期間に送信できるデータの最大量を維持します。これは、次のタイマーがリアルタイムタイマーとして扱われず、代わりに「データ駆動型」であることを意味します。つまり、定義された期間に送信されるデータの量が送信されると期限切れになります。それらは、SPMアンビエントタイム間隔、TXW_ADV_SECS、TXW_SECS、TXW_ADV_IVL、TXW_ADV_IVL_TMR、およびJOINインターバルです。SPMハートビートタイマーはまだリアルタイムで実行されることに注意してください。
While TXW_ADV_IVL_TMR is running, a source uses the receipt of a NAK for ODATA within the increment window to reset timer TXW_ADV_IVL_TMR to TXW_ADV_IVL so that transmit window advancement is delayed until no NAKs for data in the increment window are seen for TXW_ADV_IVL seconds. If the transmit window should fill in the meantime, further transmissions would be suspended until the transmit window can be advanced.
TXW_ADV_IVL_TMRが実行されている間、ソースはインクルメントウィンドウ内でODATAのNAKの受領を使用してタイマーTXW_ADV_IVL_TMRをTXW_ADV_IVLにリセットするため、TXW_ADV_IVL秒のデータのNAKが見られるまで送信ウィンドウの進歩が遅れます。その間に送信ウィンドウが埋める必要がある場合、送信ウィンドウを進めることができるまで、さらなる送信が停止されます。
A source MUST advance the transmit window across the increment window only upon expiry of TXW_ADV_IVL_TMR.
ソースは、TXW_ADV_IVL_TMRの有効期限が切れたときにのみ、増分ウィンドウを越えて送信ウィンドウを進める必要があります。
This mode of operation is intended for non-real-time, messaging applications based on the receipt of complete data at the expense of delay.
この操作モードは、遅延を犠牲にして完全なデータの受領に基づいて、非現実的なメッセージのメッセージングアプリケーションを対象としています。
This strategy advances the transmit window in real-time. In this mode of operation, TXW_MAX_RTE is calculated from SPMs and ODATA only to maintain a constant data throughput rate by consuming extra bandwidth for repairs. TXW_ADV_IVL has the value 0 which advances the transmit window without regard for whether NAKs for data in the increment window are still being received.
この戦略は、送信ウィンドウをリアルタイムで進めます。この動作モードでは、TXW_MAX_RTEはSPMSとODATAから計算され、修理のために余分な帯域幅を消費することにより、一定のデータスループットレートを維持します。TXW_ADV_IVLには、増分ウィンドウのデータのNAKSがまだ受信されているかどうかに関係なく、送信ウィンドウを進める値0があります。
In this mode of operation, all timers are treated as real-time timers.
この動作モードでは、すべてのタイマーがリアルタイムタイマーとして扱われます。
This mode of operation is intended for real-time, streaming applications based on the receipt of timely data at the expense of completeness.
この操作モードは、完全性を犠牲にしてタイムリーなデータの受領に基づいて、リアルタイムのストリーミングアプリケーションを対象としています。
Some applications may wish more explicit control of the transmit window than that provided by the advance with data / time strategies above. An implementation MAY provide this mode of operation and allow an application to explicitly control the window in terms of APDUs.
一部のアプリケーションでは、上記のデータ /時間戦略で前払いが提供するものよりも、送信ウィンドウのより明示的な制御を希望する場合があります。実装により、この動作モードが提供され、アプリケーションがAPDUの観点からウィンドウを明示的に制御できるようにする場合があります。
As stated in the introduction, PGM has been designed with a specific class of applications in mind in recognition of the fact that a general solution for reliable multicast has proven elusive. The applicability of PGM is narrowed further, and perhaps more significantly, by the prototypical nature of at least four of the transport elements the protocol incorporates. These are congestion control, router assist, local retransmission, and a programmatic API for reliable multicast protocols of this class. At the same time as standardization efforts address each of these elements individually, this publication is intended to foster experimentation with these elements in general, and to inform that standardization process with results from practise.
導入部で述べたように、PGMは、信頼できるマルチキャストの一般的なソリューションがとらえどころのないことを証明したという事実を認識して、特定のクラスのアプリケーションを念頭に置いて設計されています。PGMの適用性は、プロトコルに組み込まれている輸送要素の少なくとも4つのプロトタイプの性質によって、さらに狭くなり、おそらくより著しく狭くなります。これらは、このクラスの信頼性の高いマルチキャストプロトコルのための輻輳制御、ルーターアシスト、ローカル再送信、およびプログラムAPIです。標準化の取り組みがこれらの各要素に個別に対処すると同時に、この出版物は、これらの要素全般の実験を促進し、実践からの結果を伴う標準化プロセスを通知することを目的としています。
This section briefly describes some of the experimental aspects of PGM and makes non-normative references to some examples of current practise based upon them.
このセクションでは、PGMの実験的側面のいくつかについて簡単に説明し、それらに基づいた現在の実践のいくつかの例に非規範的な言及を行います。
At least 3 different approaches to congestion control can be explored with PGM: a receiver-feedback based approach, a router-assist based approach, and layer-coding based approach. The first is supported by the negative acknowledgement mechanism in PGM augmented by an application-layer acknowledgement mechanism. The second is supported by the router exception processing mechanism in PGM. The third is supported by the FEC mechanisms in PGM. An example of a receiver-feedback based approach is provided in [16], and a proposal for a router-assist based approach was proposed in [17]. Open issues for the researchers include how do each of these approaches behave in the presence of multiple competing sessions of the same discipline or of different disciplines, TCP most notably; how do each of them behave over a particular range of topologies, and over a particular range of loads; and how do each of them scale as a function of the size of the receiver population.
PGMを使用して、輻輳制御に対する少なくとも3つの異なるアプローチを調査できます。レシーバーフィードバックベースのアプローチ、ルーターアシストベースのアプローチ、およびレイヤーコーディングベースのアプローチです。1つ目は、アプリケーション層の確認メカニズムによって増強されたPGMの否定的な承認メカニズムによってサポートされています。2番目は、PGMのルーター例外処理メカニズムによってサポートされています。3番目は、PGMのFECメカニズムによってサポートされています。[16]でレシーバーフィードバックベースのアプローチの例が提供されており、[17]でルーターアシストベースのアプローチの提案が提案されました。研究者のための未解決の問題には、これらのアプローチのそれぞれが、同じ規律または異なる分野の複数の競合セッションの存在下でどのように動作するかを含みます。それらのそれぞれは、特定の範囲のトポロジ、および特定の範囲の負荷でどのように振る舞うのですか。そして、それらのそれぞれは、受信者集団のサイズの関数としてどのように拡大しますか。
Router assist has applications not just to implosion control and retransmit constraint as described in this specification, but also to congestion control as described above, and more generally to any feature which may be enhanced by access to per-network-element state and processing. The full range of these features is as yet unexplored, but a general mechanism for providing router assist in a transport-protocol independent way (GRA) is a topic of active research [18]. That effort has been primarily informed by the router assist component of PGM, and implementation and deployment experience with PGM will continue to be fed back into the specification and eventual standardization of GRA. Open questions facing the researchers ([19], [20], [21]) include how router-based state scales relative to the feature benefit obtained, how system-wide factors (such as throughput and retransmit latency) vary relative to the scale and topology of deployed router assistance, and how incremental deployment considerations affect the tractability of router-assist based features. Router assist may have additional implications in the area of congestion control to the extent that it may be applied in multi-group layered coding schemes to increase the granularity and reduce the latency of receiver based congestion control.
Router Assistには、この仕様で説明されているように、内破制御と再送信の制約だけでなく、上記のように混雑制御、より一般的にはネットワークごとの要素の状態と処理にアクセスすることで強化される可能性のある任意の機能にもアプリケーションがあります。これらの機能の全範囲はまだ未開拓ですが、トランスポートプロトコル独立方法（GRA）でルーターアシストを提供するための一般的なメカニズムは、積極的な研究のトピックです[18]。その努力は主にPGMのルーター支援コンポーネントによって通知されており、PGMの実装と展開の経験は、GRAの仕様と最終的な標準化に引き続き供給されます。研究者が直面している未解決の質問（[19]、[20]、[21]）には、得られた機能の利点に対するルーターベースの状態スケール、システム全体の要因（スループットや再送信など）がスケールに対してどのように変化するかが含まれます。展開されたルーター支援のトポロジー、および漸進的な展開の考慮事項がルーターアシストベースの機能の扱いやすさにどのように影響するか。ルーターアシストは、複数のグループ層コーディングスキームに適用されて、粒度を高め、受信機ベースの混雑制御の潜在性を減らすために、混雑制御の領域に追加の影響を与える可能性があります。
GRA itself explicitly incorporates elements of active networking, and to the extent that the router assist component of PGM is reflected in GRA, experimentation with the narrowly defined network-element functionality of PGM will provide some of the first real world experience with this promising if controversial technology.
GRA自体には、アクティブネットワークの要素が明示的に組み込まれており、PGMのルーター支援コンポーネントがGRAに反映される限り、PGMの狭く定義されたネットワークエレメント機能を実験しますテクノロジー。
Local retransmission is not a new idea in general in reliable multicast, but the specific approach taken in PGM of locating re-transmitters on the distribution tree for the session, diverting repair requests from network elements to the re-transmitters, and then propagating repairs downward from the repair point on the distribution tree raises interesting questions concerning where to locate re-transmitters in a given topology, and how network elements locate those re-transmitters and evaluate their efficiency relative to other available sources of retransmissions, most notably the source itself. This particular aspect of PGM, while fully specified, has only been implemented on the network element side, and awaits a host-side implementation before questions like these can be addressed.
ローカルの再送信は、信頼できるマルチキャストでは一般的に一般的に新しいアイデアではありませんが、セッションの配布ツリーで再送信機を配置し、ネットワーク要素から再送信機に修理要求を迂回させ、その後下向きの繁殖の修理要求を迂回させる特定のアプローチである特定のアプローチ分布ツリーの修理ポイントから、特定のトポロジ内の再送信機を配置する場所と、ネットワーク要素がそれらの再送信機を配置し、他の利用可能な再送信ソース、特にソース自体に比べて効率を評価する方法に関する興味深い質問を提起します。PGMのこの特定の側面は、完全に指定されていますが、ネットワーク要素側にのみ実装されており、このような質問に対処する前にホスト側の実装を待っています。
PGM presents the opportunity to develop a programming API for reliable multicast applications that reflects both those applications' service requirements as well as the services provided by PGM in support of those applications that may usefully be made visible above the transport interface. At least a couple of host-side implementations of PGM and a concomitant API have been developed for research purposes ([22], [23]), and are available as open source explicitly for the kind of experimentation described in this section.
PGMは、これらのアプリケーションのサービス要件の両方を反映する信頼性の高いマルチキャストアプリケーションのプログラミングAPIと、トランスポートインターフェイスの上に有用に見える可能性のあるアプリケーションをサポートするPGMが提供するサービスの両方を反映する機会を提供します。PGMと付随するAPIのホスト側の実装の少なくともいくつかが研究目的で開発されており（[22]、[23]）、このセクションで説明されている種類の実験のために明示的にオープンソースとして利用できます。
Perhaps the broadest experiment that PGM can enable in a community of researchers using a reasonable scale experimental transport protocol is simply in the definition, implementation, and deployment of IP multicast applications for which the reliability provided by PGM is a significant enabler. Experience with such applications will not just illuminate the value of reliable multicast, but will also provoke practical examination of and responses to the attendant policy issues (such as peering, billing, access control, firewalls, NATs, etc.), and, if successful, will ultimately encourage more wide spread deployment of IP multicast itself.
おそらく、PGMが合理的なスケールの実験的輸送プロトコルを使用して研究者のコミュニティで有効にできる最も広い実験は、PGMが提供する信頼性が重要なイネーブラーであるIPマルチキャストアプリケーションの定義、実装、および展開にあります。このようなアプリケーションでの経験は、信頼できるマルチキャストの価値を照らすだけでなく、アテンダントポリシーの問題（ピアリング、請求、アクセス制御、ファイアウォール、NATなど）の実用的な調査と対応も引き起こします。、最終的には、IPマルチキャスト自体のより広範な展開を促進します。
ACK Acknowledgment AFI Address Family Indicator ALF Application Level Framing APDU Application Protocol Data Unit ARQ Automatic Repeat reQuest DLR Designated Local Repairer GSI Globally Unique Source Identifier FEC Forward Error Correction MD5 Message-Digest Algorithm MTU Maximum Transmission Unit NAK Negative Acknowledgment NCF NAK Confirmation NLA Network Layer Address NNAK Null Negative Acknowledgment ODATA Original Data POLL Poll Request POLR Poll Response RDATA Repair Data RSN Receive State Notification SPM Source Path Message SPMR SPM Request TG Transmission Group TGSIZE Transmission Group Size TPDU Transport Protocol Data Unit TSDU Transport Service Data Unit TSI Transport Session Identifier TSN Transmit State Notification
ACK謝辞AFIアドレスファミリインジケーターALFアプリケーションレベルフレーミングAPDUアプリケーションプロトコルデータユニットARQ自動リピートリクエストDLR指定ローカル修理業者GSIグローバルに一意のソース識別子FECフォワードエラー修正MD5メッセージダイジストアルゴリズムアドレスnnak null否定的承認ODATAオリジナルデータ世論調査リクエストPOLR投票応答RDATA修理データRSNは状態通知SPMソースパスメッセージSPMR SPMリクエストTG伝送グループサイズTPDU輸送プロトコルデータユニットTSDUトランスポートサービスデータユニットTSI輸送セッションTSN状態通知を送信します
The design and specification of PGM has been substantially influenced by reviews and revisions provided by several people who took the time to read and critique this document. These include, in alphabetical order:
PGMの設計と仕様は、この文書を読んで批評するために時間をかけた数人の人々によって提供されたレビューと改訂の影響を大きく受けています。これらには、アルファベット順に含まれます。
Bob Albrightson Joel Bion Mark Bowles Steve Deering Tugrul Firatli Dan Harkins Dima Khoury Gerard Newman Dave Oran Denny Page Ken Pillay Chetan Rai Yakov Rekhter Dave Rossetti Paul Stirpe Brian Whetten Kyle York
ボブ・オルブライトソン・ジョエル・バイオン・マーク・ボウルズ・スティーブ・ディアーリング・タグル・フィラトリ・ダン・ハーキンズディマ・クーリー・ジェラルド・ニューマン・デイブ・オラン・デニーページケン・ピレイ・チェタン・ライ・ヤコフ・レクター・デイブ・ロセッティ
[1] B. Whetten, T. Montgomery, S. Kaplan, "A High Performance Totally Ordered Multicast Protocol", in "Theory and Practice in Distributed Systems", Springer Verlag LCNS938, 1994.
[1] B. Whetten、T。Montgomery、S。Kaplan、「分散システムの理論と実践」における「完全に順序付けられたマルチキャストプロトコル」、Springer Verlag LCNS938、1994。
[2] S. Floyd, V. Jacobson, C. Liu, S. McCanne, L. Zhang, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", ACM Transactions on Networking, November 1996.
[2] S. Floyd、V。Jacobson、C。Liu、S。McCanne、L。Zhang、「軽量セッションとアプリケーションレベルのフレーミングのための信頼できるマルチキャストフレームワーク」、1996年11月、ネットワーキングに関するACMトランザクション。
[3] J. C. Lin, S. Paul, "RMTP: A Reliable Multicast Transport Protocol", ACM SIGCOMM August 1996.
[3] J. C. Lin、S。Paul、「RMTP：信頼できるマルチキャスト輸送プロトコル」、ACM Sigcomm 1996年8月。
[4] Miller, K., Robertson, K., Tweedly, A. and M. White, "Multicast File Transfer Protocol (MFTP) Specification", Work In Progress.
[4] Miller、K.、Robertson、K.、Tweedly、A。and M. White、「マルチキャストファイル転送プロトコル（MFTP）仕様」、進行中の作業。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[7] C. Partridge, "Gigabit Networking", Addison Wesley 1994.
[7] C. Partridge、「Gigabit Networking」、Addison Wesley 1994。
[8] H. W. Holbrook, S. K. Singhal, D. R. Cheriton, "Log-Based Receiver-Reliable Multicast for Distributed Interactive Simulation", ACM SIGCOMM 1995.
[8] H. W. Holbrook、S。K。Singhal、D。R。Cheriton、「分散インタラクティブシミュレーション用のログベースの受信機に応えるマルチキャスト」、ACM Sigcomm 1995。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[11] J. Nonnenmacher, E. Biersack, D. Towsley, "Parity-Based Loss Recovery for Reliable Multicast Transmission", ACM SIGCOMM September 1997.
[11] J. Nonnenmacher、E。Biersack、D。Towsley、「信頼できるマルチキャスト伝達のパリティベースの損失回復」、ACM Sigcomm 1997年9月。
[12] L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", Computer Communication Review, April 1997.
[12] L. Rizzo、「信頼できるコンピューター通信プロトコルの効果的な消去コード」、コンピューター通信レビュー、1997年4月。
[13] V. Jacobson, "Congestion Avoidance and Control", ACM SIGCOMM August 1988.
[13] V.ジェイコブソン、「混雑の回避と管理」、ACM Sigcomm 1988年8月。
[14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP, 14, RFC 2119, March 1997.
[14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP、14、RFC 2119、1997年3月。
[15] J. Bolot, T. Turletti, I. Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet", Proc. ACM/Sigcomm 94, pp. 58-67.
[15] J. Bolot、T。Turletti、I。Wakeman、「インターネットでのマルチキャストビデオ配信のためのスケーラブルなフィードバック制御」、Proc。ACM/SIGCOMM 94、pp。58-67。
[16] L. Rizzo, "pgmcc: A TCP-friendly Single-Rate Multicast Congestion Control Scheme", Proc. of ACM SIGCOMM August 2000.
[16] L. Rizzo、「PGMCC：TCPに優しいシングルレートマルチキャスト輻輳制御スキーム」、Proc。ACM Sigcomm 2000年8月。
[17] M. Luby, L. Vicisano, T. Speakman. "Heterogeneous multicast congestion control based on router packet filtering", RMT working group, June 1999, Pisa, Italy.
[17] M. Luby、L。Vicisano、T。Speakman。「ルーターパケットフィルタリングに基づく不均一なマルチキャスト輻輳制御」、RMTワーキンググループ、1999年6月、ピサ、イタリア。
[18] Cain, B., Speakman, T. and D. Towsley, "Generic Router Assist (GRA) Building Block, Motivation and Architecture", Work In Progress.
[18] Cain、B.、Speakman、T。and D. Towsley、「ジェネリックルーターアシスト（GRA）ビルディングブロック、モチベーション、アーキテクチャ」、進行中の作業。
[19] C. Papadopoulos, and E. Laliotis,"Incremental Deployment of a Router-assisted Reliable Multicast Scheme,", Proc. of Networked Group Communications (NGC2000), Stanford University, Palo Alto, CA. November 2000.
[19] C. Papadopoulos、およびE. Laliotis、「ルーター支援の信頼できるマルチキャストスキームの増分展開」、Proc。ネットワークグループコミュニケーション（NGC2000）、スタンフォード大学、パロアルト、カリフォルニア州2000年11月。
[20] C. Papadopoulos, "RAIMS: an Architecture for Router-Assisted Internet Multicast Services." Presented at ETH, Zurich, Switzerland, October 23 2000.
[20] C. Papadopoulos、「Raims：ルーター支援インターネットマルチキャストサービスのアーキテクチャ。」2000年10月23日、スイスのチューリッヒにあるETHで発表されました。
[21] J. Chesterfield, A. Diana, A. Greenhalgh, M. Lad, and M. Lim, "A BSD Router Implementation of PGM", http://www.cs.ucl.ac.uk/external/m.lad/rpgm/
[21] J.チェスターフィールド、A。ダイアナ、A。グリーンハルグ、M。ラッド、およびM.リム、「PGMのBSDルーター実装」、http：//www.cs.ucl.ac.uk/external/m.lad/rpgm/
[22] L. Rizzo, "A PGM Host Implementation for FreeBSD", http://www.iet.unipi.it/~luigi/pgm.html
[22] L. Rizzo、「FreeBSDのPGMホスト実装」、http：//www.iet.unipi.it/~luigi/pgm.html
[23] M. Psaltaki, R. Araujo, G. Aldabbagh, P. Kouniakis, and A. Giannopoulos, "Pragmatic General Multicast (PGM) host implementation for FreeBSD.", http://www.cs.ucl.ac.uk/research/darpa/pgm/PGM_FINAL.html
[23] M. Psaltaki、R。Araujo、G。Aldabbagh、P。Kouniakis、およびA. Giannopoulos、「FreeBSDの実用的な一般的なマルチキャスト（PGM）ホスト実装」、http：//www.cs.ucl.ac.uk/researchearch/darpa/pgm/pgm_final.html
Tony Speakman EMail: speakman@cisco.com
Tony Speakmanメール：speakman@cisco.com
Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 USA EMail: dino@procket.com
Dino Farinacci Procket Networks 3850 North First Street San Jose、CA 95134 USAメール：dino@procket.com
Steven Lin Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94086 USA EMail: steven@juniper.net
スティーブンリンジュニパーネットワーク1194 N.マチルダアベニュー、カリフォルニア州サニーベール94086 USAメール：steven@juniper.net
Alex Tweedly EMail: agt@cisco.com
Alex Tweedlyメール：agt@cisco.com
Nidhi Bhaskar EMail: nbhaskar@cisco.com
nidhi bhaskarメール：nbhaskar@cisco.com
Richard Edmonstone EMail: redmonst@cisco.com
リチャード・エドモンストーンメール：redmonst@cisco.com
Rajitha Sumanasekera EMail: rajitha@cisco.com Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 USA EMail: lorenzo@cisco.com
Rajitha Sumanasekeraメール：rajitha@cisco.com Lorenzo Vicisano Cisco Systems、Inc。170 West Tasman Drive、San Jose、CA 95134 USAメール：lorenzo@cisco.com
Jon Crowcroft Department of Computer Science University College London Gower Street London WC1E 6BT UK EMail: j.crowcroft@cs.ucl.ac.uk
Jon Crowcroft of Computer Science University College London Gower Street London WC1E 6BT UKメール：j.crowcroft@cs.ucl.ac.uk
Jim Gemmell Microsoft Bay Area Research Center 301 Howard Street, #830 San Francisco, CA 94105 USA EMail: jgemmell@microsoft.com
Jim Gemmell Microsoft Bay Area Research Center 301 Howard Street、＃830 San Francisco、CA 94105 USAメール：jgemmell@microsoft.com
Dan Leshchiner Tibco Software 3165 Porter Dr. Palo Alto, CA 94304 USA EMail: dleshc@tibco.com
Dan Leshchiner Tibco Software 3165 Porter Dr. Palo Alto、CA 94304 USAメール：dleshc@tibco.com
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Fremont CA 94538 USA EMail: luby@digitalfountain.com
Michael Luby Digital Fountain、Inc。39141 CIVIC CENTER DRIVE FREMONT CA 94538 USAメール：luby@digitalfountain.com
Todd L. Montgomery Talarian Corporation 124 Sherman Ave. Morgantown, WV 26501 USA EMail: todd@talarian.com Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2 56126 Pisa Italy EMail: luigi@iet.unipi.it
Todd L. Montgomery Talarian Corporation 124 Sherman Ave. Morgantown、WV 26501 USAメール：todd@talarian.com Luigi Rizzo Dip。ディーイング。Dell'informazione Universita` Diotisalvi 2 56126 Pisa Italy Email：luigi@iet.unipi.it
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。