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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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:
ご注意：
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 PGM-ホップバイPGMホップを転送し、NAKを受信したインターフェイスに応じてNAK確認（NCF）をマルチキャストすることにより、各ホップを確認します。修理（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.
NAKの信頼性のための唯一のメカニズムを提供するので、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の最初の発生と任意の受信機から同じNAKのさらなる再送をNCFで応答します。また、そのネットワーク要素から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.
NCFsがグループにマルチキャストですが、彼らはホップバイホップ確認として機能するので、それらは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のただ一つのコピーの伝播です。
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ネットワーク要素におけるソースパス状態を確立するために、基本的なデータ転送動作は、定期的ODATAとインターリーブソースからソースパスメッセージ（のSPM）によって増強されます。 SPMは、ソースからの配信ツリーのすべてのPGMネットワーク要素に与えられたTSIのソースパスの状態を確立するために主に機能します。 PGMネットワーク要素は、ソースに向かって上流のPGMネットワーク要素に直接ユニキャストNAKを返す対処するためにこの情報を使用し、それによっての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ネットワーク要素によって修理の制約のための手順を規定します。 NAKが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はまた、彼らの可用性を発表すると、自分自身にではなく、元のソースへの修理依頼（NAKを）リダイレクトするように指定されたローカル修繕（DLRS）を許可するオプションと手順を指定します。選択的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).
下流に流れる3（SPMは、DATA、NCFs）、及び上流の流れ、一方（のNAK）：PGMは、4つの基本的なパケットタイプを定義します。
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は、比較的単純な信頼性要件を持つマルチキャストアプリケーションの幅広いサービスを提供するために、マルチキャストデータ転送の多くの広告を出したが、多くの場合、未実現ネットワークの効率化を実現した方法でそうするように設計されています。これらの効率を実現する通常の障害は、受信機からソースへの負及び正の肯定応答の爆縮、ソースから修理待ち時間、及び利害受信機の修理の伝播です。
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の目標の一つは、できるだけシンプルなプロトコルから可能な信頼性のような強い定義を取得することです。 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は、受信機は、パケットがソースから、または指定されたローカル修理（DLR）からいずれかの修理のために利用できないように遅く欠落データパケットを検出する確率を最小限に抑えます。 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を除去する第二の結果は、グループメンバーシップの知識を必要としないでもプロトコルによって提供もされていないことです。ソースは、いくつかの受信機からのいくつかの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.
受信機は、マッチングNCFを受信すると、受信機によって（それを送ったかのように、すなわち、それが送信されていないが、受信機作用）NAKが抑制される間隔その間前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つの戦略の組み合わせは、通常、任意の失われたデータパケットに対して1つだけ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.
NAKが最後のホップPGMネットワーク要素へのユニキャストであり、NCFsグループにマルチキャストであるのでまた、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.
フラグメンテーションは、ネットワーク層でサポートされる最大伝送単位（MTU）に適合するように、複数のPGMデータパケットにアプリケーション層のデータパケットを分割するソースにトランスポート・レイヤ・エンティティを可能にするために、データパケットと共に使用することができます。
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がリダイレクトPOLRは、元のソースへの再送信の代替として、自身のアドレスをアドバタイズすると、通常のNCFsや世論調査に応じることができるように投票の回答と併せて使用することができます。
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.
存在する場合グループにマルチキャストソースSPMは、PGMネットワーク要素にソースパスの状態を確立するために、ODATAと交互。
NAK Reliability
NAKの信頼性
Sources multicast NCFs to the group in response to any NAKs they receive.
ソースは、彼らが受け取るどんなのNAKに応じてグループにNCFsをマルチキャストします。
Repairs
修理
Sources multicast RDATA packets to the group in response to NAKs received for data packets within the transmit window.
NAKに応答して、ソースグループへのマルチキャスト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.
源は、多くの戦略のいずれかに記載の窓の後縁を進むことができます。実装は、バイト単位の固定サイズ、パケットの一定数または固定リアルタイム持続時間でウィンドウを維持するよう自動調整をサポートするかもしれません。加えて、それらは必要に応じて一定期間NAK無音に基づいてウィンドウの進行を遅延させることができます。いくつかの可能な戦略は、このドキュメントの後半で概説されています。
Source Path State
ソースパスの状態
Receivers use SPMs to determine the last-hop PGM network element for a given TSI to which to direct their NAKs.
受信機は、それらのNAKを指示するために、指定されたTSIの最後のホップPGMネットワーク要素を決定するためのSPMを使用します。
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.
検出された受信ウィンドウ内のデータ・パケットの最後のホップPGMネットワーク要素の受信ユニキャストNAKを（そして必要に応じてローカルグループに1のTTLと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に応じてグループにNCFsマルチキャストネットワーク要素。各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.
それらが反応してNCFを受信するまで、NAKの繰り返しユニキャスト前方にのみ最初のコピーネットワーク要素はそれらがTSIの配信経路上の上流のPGMネットワーク要素に受け取ります。加えて、それらは、1のTTLと、このNAK上流マルチキャストいてもよいです。
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.
注意ベーネは：NCFによって確認されたら、ネットワーク要素は、NAKパケットを破棄する。 NAKが、この転送動作を超えてネットワーク要素に保持されないが、それらの受信についての状態が保存されています。
NAK Elimination
NAK撤廃
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ネットワーク要素のいずれかによって転送されたもの）の修復状態を有し、マッチングNCFで応答する任意のNAKの正確な複製を破棄します。
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.
TSIは、グローバルに一意である必要があり、かつ一度に一つのソースは、トランスポートセッションのソースとして作用することができます。 （修理業者は、彼らが伝える任意の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からを通して円形のシーケンス番号空間を使用して（** 32（2） - 1）ODATAパケットを識別し、注文します。ソースは、対応するアプリケーションデータが送信のために提出された順序での単位刻みでODATAパケットに番号をしなければなりません。送信中または受信ウィンドウ（以下に定義）、シーケンス番号xが配列番号yよりも「少ない」または「古い」であれば番号ODATAパケットyを先行ODATAパケット、及び配列番号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_SECSを送信することによって、消費シーケンス番号の範囲です。送信ウィンドウ（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プラス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
ソースから受信ウィンドウ、修復のために利用可能な最も古いデータパケットの（データ・パケットとのSPMから知られている）は、シーケンス番号の後縁を規定する配列番号RXW_TRAIL
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データパケットを受信すると、その受信ウィンドウを進めます。
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を拘束するために必要な補修状態を確立するために、それはNAKのソースからディストリビューションツリーの裏面にソースに受信機から戻ることが不可欠です。つまり、彼らは、ODATAが転送さが、逆にして、それを通してPGMネットワーク要素の同じシーケンスを返す必要があります。これには2つの理由がありますが、はるかに重要であることは明白少ない1。
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.
第二の少ない明白な理由は、修理状態が存在しない場合に、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.
SPMの原理機能は、修理状態に方法の各ステップを確立する、TSIのための配信ツリーの裏面に次の1つのPGMネットワーク要素からNAKを転送するためにPGMネットワーク要素に必要なソースパスの状態を提供することです。このソースパスの状態は、単に、TSIの配信ツリーの逆に上流のPGMネットワーク要素のアドレスです。その上流のPGMネットワーク要素は、複数のサブネットが離れるホップであってもよいです。 SPMは、各PGMネットワーク要素の各グループ内の各TSIの配布ツリー上の仮想PGMトポロジのソートを上流のPGMネットワーク要素のアイデンティティを確立します。 NAKをユニキャストに対処しているがだから、彼らは、ユニキャスト、従来の意味でのPGMネットワーク要素によってルーティングされません。代わりPGMネットワーク要素は、ソースに向かってのNAK PGM-ホップバイPGMホップを指示するためのSPMによって確立されたソースパスの状態を使用します。アイデアは、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.
対応RDATAを修復状態の欠如のためのPGMネットワーク要素によって破棄されることはないように、結果は、受信機とソースとの間のすべての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はSPM_TRAILがSPM_LEADプラス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.
このセクションでは、単に手順を分かりやすくするために十分に短い手を提供します。パケットの内容の詳細については、以下のパケット形式を参照してください。
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.
注意ベネ：これは数ODATAとRDATAに使用されるより完全に別個のシーケンスです。
SPM_TRAIL the sequence number defining the trailing edge of the source's transmit window (TXW_TRAIL)
ソースの送信ウィンドウ（TXW_TRAIL）の後縁を規定するシーケンス番号をSPM_TRAIL
SPM_LEAD the sequence number defining the leading edge of the source's transmit window (TXW_LEAD)
ソースの送信ウィンドウ（TXW_LEAD）の前縁を規定するシーケンス番号をSPM_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)
ソースの送信ウィンドウの後縁を規定するシーケンス番号（TXW_TRAIL）OD_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_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をに応答してソースまたはDLRSによって送信されたリペアパケットです。
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.
NAKが、データパケットの欠落のために修理を要求するために受信機によって送信されます。
NAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:
NAKをユニキャスト（PGM-ホップバイPGMホップ）とソースには含まれています。
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.
NNAKsはNAKを元にフロー制御フィードバックを提供するために、受信機またはネットワーク要素のいずれかによってそれにリダイレクト受信DLRによって送信されます。
NNAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:
NNAKsソースへ（PGM-ホップバイPGMホップ）ユニキャストであり、含まれています。
NNAK_TSI NAK_TSI of the corresponding re-directed NAK.
対応するリダイレクトNAKのNNAK_TSI NAK_TSI。
NNAK_SQN NAK_SQN of the corresponding re-directed NAK.
対応するリダイレクトNAKのNNAK_SQN 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.
NCFsはのNAKに応答してネットワーク要素とソースによって送信されます。
NCFs are multicast to the group and contain:
NCFsはグループにマルチキャストであり、含まれています。
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 0×02 - 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の - セッションフィンレシーバー、従来feedbackish
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の - パス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.
SPM、NCFs、およびRDATAはPGMネットワーク要素によって条件付きで処理しなければならないので、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の要件は、[6]のSPM、NCFs、およびRDATAはIPルータ警告オプションで送信しなければならないことです。このオプションでは、ネットワーク要素パケットは、より詳細な処理のために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パケットに番号をしなければなりません。ソースTXW_MAX_RTEを超えない速度でTXW_TRAIL始まるシーケンスでのみ送信ウィンドウ内ODATAパケットを送信しなければなりません。
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.
また、ソースMUSTは、連続したパケットが最大送信レート、または同等の機構で排出リーキーバケット方式を用いて送信され得る最大レートと結合しました。
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の送信ウィンドウのロジックを維持するために、ソースは、厳密に第二のSPMを保留して、最初のNCFsを保留中の送信優先順位を付け、そして何NCFsかのSPMが保留されていない場合にのみODATAまたはRDATAを送らなければなりません。 ODATA対RDATAの優先順位は、アプリケーションに依存します。送信者は、RDATAとODATAの間の重み付け帯域幅共有を実施することができます。常にペンディングRDATA（OPT_JOINと後期ジョイナーの例えば安定した流れ）を有するように生成NAKを保つ受信機が存在する場合ODATA上RDATAの厳格な優先順位付けは、ODATAの進行を停止することができることに留意されたいです。厳密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]、ソース間ハートビートタイマーIHB_TMR最新のパケット（ODATA、RDATA、またはSPM）送信し、次のハートビートの送信の間の時間間隔を維持します。 IHB_TMRは、任意のデータパケットの送信後に最小間隔IHB_MINに初期化されます。 IHB_TMRが満了した場合、ソースは、心拍SPMを送信し、その前の値を倍にIHB_TMRを初期化します。連続した心拍のSPMの透過率は最大間隔IHB_MAXにIHBたびを倍増します。すべてのデータパケットの送信が再びIHB_MINにIHB_TMRを初期化します。効果は、送信するデータが存在しない場合に欠落したパケットの迅速な検出を誘発するために、最小限の帯域幅のオーバーヘッドでそうすることです。
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は、データによってリセットされ続け、カウントダウンタイマーによって駆動されている間、定期的に期限切れになったカウントダウンタイマーによって駆動され、それが期限切れに始まるとの間隔が変化しています。ハートビートタイマーは間のデータ・パケットの間隔を測定している間、周囲SPMタイマーだけで、リアルタイムでダウンカウントされます。
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.
データの存在下で、ハートビートのSPMは、データの送信は、その初期値に戻すIHB_TMRを設定し続けるので、送信されないであろう。しかしながら、同時に、周囲の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をマルチキャストしなければなりません。 RDATAですぐに応答の代替が同じサブネット上の他のPGMネットワーク要素は、NAKの期待感を行うことができないだろう、またそれは、同じサブネット上のDLRSが修理を提供できるようになるので、NCFが必要です。ソースは、NAKストームを検出し、サービス拒否に対してネットワークを保護するための対策を採用することができるべきです。可能な対策は、NAKを抑制する能力に影響を与えることなく、レート制限されている同じNCFsように、NAKに応答して直ちに最初のNCFを送信した後、小さな間隔で（同一のNAKのために）さらにNCFsの発生を遅らせることです。
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.
（TXW_MAX_RTEを尊重しながら）NAKに応答してNCFをマルチキャストした後、ソースはそれが送信ウィンドウ内のデータパケットのために受信した任意のNAKに応答して、RDATAをマルチキャストしなければなりません。
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パケットの効率を高めるの関心では、ソースは、全体損失の近傍からのNAKの到着を収容するRDATA送信を遅延させることができます。この遅延はロス周辺の二倍の最大の伝播遅延を超えないようにしてください。
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に割り当てられ、後続のパケット（のSPMまたは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.
後述JOINオプションは、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パケットを受け入れなければなりません。受信機は、既に送信ウインドウで受信した1つを複製任意のデータパケットを捨てなければなりません。受信機は、受信ウィンドウの外のデータパケットを捨てなければなりません。
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の）を供給しなければなりません。それは違うのTPDUsに断片化されているの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のそれよりも大きく、半分PGM番号空間内であれば、SPMが順番にあります。アウト・オブ・シーケンスSPMは捨てなければなりません。
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のために、受信機は、NAKが対処する上で使用するため、上流のPGMネットワーク要素のNLAを決定するために、最新のSPMを使用しなければなりません。それは、対応するTSIのための少なくとも一つの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は、ホップごとの処理を必要とするので、データよりも遅い速度で転送され、それらがデータ・ストリームと同期して到着することであろうと思われます。この場合は、SPMのが運ぶことをウィンドウ情報が古くなることでしょう。レシーバは、このようなケースであることを期待すべきであり、受信機は、鉛やトレイルのために保存されている値を使用してパケットリード及びトレイル値を比較することにより、それを検出する必要があります。 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です。 SPMにおける前縁フィールドはまた、損失検出アルゴリズムにおいて考慮されるべきです。
Generating NAKs
素敵な生成
NAK generation follows the detection of a missing data packet and is the cycle of:
NAK生成は、欠落したデータパケットの検出を、以下のサイクルです。
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が受信されない場合、マッチングNCFと再開するNAK生成期間（NAK_RPT_IVL）を待っています
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_BO_IVL上でランダムに選ばれたいくつかの間隔NAK_RB_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.
NAK_BO_IVLの値はNAK_BO_IVL_SQNがゼロである、または受信機はPOLL_SQN = <NAK_BO_IVL_SQNためPOLL_RND == 0を見たかしない限り、受信機（すなわち、受信機はNAKないこと）で使用してはいけません（以下16.4.1を参照されたい）OPT_NAK_BO_IVLから学習しました半分のシーケンス番号空間内。
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）が生成されている場合、バックオフ間隔は反比例要求されたパリティパケットの数に対してバイアスされるべきです。この方法のNAKは、パリティパケットの多数を要求するには、最初に送られたため、他の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_RB_IVL中マッチングNCF又はNAKを聞く場合はNAK生成を再開する前に、少なくともNAK_RDATA_IVL待たなければなりません。マッチングNCFはNAK_SQNでNAK_TSIとNCF_TSI、およびNCF_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親が直接接続されていない場合に加えて、それは、グループに1のTTLと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).
これは、マッチングNCFを待っている間にNAK_NCF_RETRIES回までNAK_RPT_IVLに支配率でNAKを繰り返す必要があります。その後、NAK生成を再開する前にNAK_RDATA_IVLを待たなければなりません。それはNAK_RDATA_IVL中マッチングNCF又はNAKを聞く場合、それは（すなわち、一致NCFsとのNAKがNAK_RDATA_IVLを再起動）NAK生成を再開する前に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_DATA_RETRIES / NAK_NCF_RETRIESのマッチングシーケンス番号超えることを除外するようにNAK生成は、受信ウィンドウの前進時に解除されます。 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.
受信機は、送信ウィンドウの外側またはそれが受信したデータパケットのデータパケットに聞く任意NCFs又は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ネットワーク要素は、転送および受信ネットワーク要素との間に介在している場合、このアドレスは、介在するネットワーク要素を挟んで第1の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.
注意ベネ：非PGM対応クラウド横切るPGMネットワーク要素のためのマルチキャストルーティング状態を作成しないようにするために、ネットワーク要素によって送信さNCFsのネットワークヘッダの送信元アドレスがODATAソースのNLAに設定しなければなりませんではなく、ネットワーク要素の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を抑制する能力に影響を与えることなく、レート制限されている同じNCFsように、NAKに応答して直ちに最初のNCFを送信した後、小さな間隔で（同一のNAKのために）さらにNCFsの発生を遅らせることです。
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は、対応するリペア・インターフェース・リストに受信されたインターフェイスを追加しなければなりません。
The NAK forwarding procedures for network elements are quite similar to those for receivers, but three important differences should be noted.
ネットワーク要素のためのNAK転送手順は、受信機のものと非常によく似ていますが、三つの重要な相違点が注目されるべきです。
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の期待と除去と併せて、この要因は、密なネットワーク要素の人口を持つサブネット上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.
注意ベーネは：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転送は、ネットワーク要素が同じトランスポートセッションのためにNCFsに耳を傾けることが必要です。 NAK_RPT_IVLとNAK_RDATA_IVL：NAK転送は、ネットワーク要素（すなわち、NAK_TSI及びNAK_SQNあたり）任意のNAKのための2つのタイムアウト間隔を観察することを必要とします。
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の有効期限は、（NCFの欠落による）NAK転送をキャンセルします。
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はNAK_SQNでNAK_TSIとNCF_TSI、およびNCF_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を受信すると、ネットワーク要素は、対応するRDATAための少なくともNAK_RDATA_IVL待たなければなりません。 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の最初の重複がNAK_ELIM_IVLの満了後に見られるまでNAK_ELIM_IVLの満了時には、ネットワーク要素は、その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が、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を持たないネットワーク要素によって受信されるものです。ネットワーク要素は、それらが受信されているインターフェイスに応じて異なる迷惑NCFsを処理しなければなりません。
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.
予想されるNAKが下流から後続のマッチングのNAKの排除を可能とします。予想修復状態を確立する際に、ネットワーク要素は、NAK_ELIM_IVLの期間以降NAKを排除しなければなりません。そのNAKの最初の重複がNAK_ELIM_IVLの満了後に見られるまでNAK_ELIM_IVLの満了時には、ネットワーク要素は、その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ネットワーク要素は、対応するTSIの状態を見つけるために、トランスポート・ヘッダに含まれる送信元およびグループアドレス（NLAs）を使用して、対応する上流のPGMネットワーク要素のアドレスを検索し、（ユニキャスト）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が少なくとも一度受信している各インタフェースの修復状態を維持しなければなりません。ネットワーク要素は、次いで、リストだけでそれらのインタフェースに対応するRDATAパケットの転送を制限するためにインターフェイスのこのリストを使用しなければなりません。それはNAK_TSIとNAK_SQNと一致した場合にRDATAパケットは、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_RDATA_IVLは、所与のNAKの最新のインスタンスを転送した後に通過します。その後、対応する修理状態を捨てなければなりません。
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.
このセクションで説明するパケットフォーマットのすべてが直ちにパケットにおけるネットワーク層ヘッダに従わなければならないトランスポート層ヘッダーです。唯一のデータパケットヘッダ（ODATAとRDATA）は、アプリケーションデータがパケットに続いてもよいです。各パケットタイプのために、ネットワーク・ヘッダの送信元アドレスと宛先アドレスは、トランスポート層ヘッダのフォーマット及びコンテンツに加えて、指定されています。 IPマルチキャスト経由、PGMのための一般的な手順からリコール、SPMは、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のアプリケーションに割り当てられたグローバルwell-knownポート番号。
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.
Typeフィールドエンコードの上位2ビットのバージョン番号、この例では0x0。タイプフィールドの下位ニブルは、特定のパケットタイプを符号化します。介在する2つのビット（上位ニブルの下位2ビット）が予約され、ゼロでなければなりません。
Within the low-order nibble of the Type field:
Typeフィールドの下位ニブル内：
values in the range 0x0 through 0x3 represent SPM-like packets (i.e., session-specific, sourced by a source, periodic),
0x3のスルー範囲は0x0の値は、SPMのようなパケットを表し（すなわち、セッション固有の、ソースによって供給さ、周期性）、
values in the range 0x4 through 0x7 represent DATA-like packets (i.e., data and repairs),
0x7のスルー範囲を0x4の値は、データのようなパケット（即ち、データ及び修理）を表し、
values in the range 0x8 through 0xB represent NAK-like packets (i.e., hop-by-hop reliable NAK forwarding procedures),
0xBスルー範囲0x8というの値は、NAK状パケット（すなわち、ホップバイホップ信頼NAK転送手順）を表します
and values in the range 0xC through 0xF represent SPMR-like packets (i.e., session-specific, sourced by a receiver, asynchronous).
そして0xFのスルー範囲から0xCの値は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セット=>一の以上のオプション拡張機能が存在しています
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セット=>パケットは、可変サイズのパケット（OPT_VAR_PKTLEN）の送信グループのパリティパケットです。 OPT_PARITYも存在する場合にのみ存在。
bit 7 set => Packet is a parity packet (OPT_PARITY)
ビット7セット=>パケットは、パリティパケット（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].
ファミリーインジケータアドレス（AFIS）[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
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
Spim_pth
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。転送時の各PGMネットワーク要素によって書き換えソースのNLAに源によって初期化。
Data packets carry application data from a source or a repairer to receivers.
データパケットは、ソースまたは受信機に修理からアプリケーションデータを運びます。
ODATA:
ONCE：
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:
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.
ヌル負謝辞はDLRは、対応するRDATAを設けたためODATAのソースにフロー制御フィードバックを提供するDLRSによって送信されます。
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のネットワークヘッダの宛先アドレスはのSPMから公知の上流のPGMネットワーク要素のユニキャストNLAにNAK（受信機）の創始者によって初期化されます。 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のネットワークヘッダの送信元アドレスは、ODATAソースのNLA、予想されるようにしないネットワーク要素の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.
NAKとN-のNAKで、他のパケットとは異なり、フィールドSPORTはデータ宛先ポートが含まれており、フィールドDPORTは、データ・ソース・ポートが含まれていることに注意してください。一般的なルールとして、SPORT / DPORTの含有量は、流れの方向によって決定される：ダウンストリームスポーツを移動するパケットのデータソース（データソースポート）で選択されたポート番号とDPORTはデータ宛先ポートであります数（データ-宛先ポート）。反対は、上流に移動するパケットのために保持しています。これは関係なく、パケットの方向の、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
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を負担してもよい（MAY）
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タイプの7ビットが続く、OPT_ENDビットである最初のバイトに含まれています。 OPT_ENDビットがあるかもしれない方のオプションリストの最後のオプションで設定しなければなりません。 Lengthフィールドは、バイト単位でのオプションの合計の長さであり、直接入力フィールドに続きます。長さフィールドに続く5予約ビット、OP_ENCODEDフラグ、拡張はOPXとOP_ENCODED_NULLフラグビット2オプションです。最後あたりのオプションに基づいて定義することができるオプションの特定の情報のために指定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.
注意ベーネ：唯一のネットワーク要素は、これらのビットに注意を払います。
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）は厳密OPT_FRAGMENTが例である、パケットのコンテンツ（PGMペイロード）に関連付けられています。これらのオプションは、通常、それらを含んでいるでしょう、データパケットを受信していない場合であっても保存されなければならないが、そのペイロードは、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.
フラグメンテーションは、ソースにおけるトランスポート・レイヤ・エンティティはネットワーク層でサポートされているMTUに適合するように、複数のPGMデータパケット（のTPDUs）にアプリケーションプロトコルデータユニット（APDUの）を破壊することを可能にします。断片化オプションは、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.
アーキテクチャ、のAPDUへTSDUsの蓄積は既に受信機によって、受信された重複排除、および連続配列決定されているのTPDUsに適用されます。こうしてのAPDUは、送信ウィンドウの増分を横切って再アセンブルされるかもしれません。
OPT_FRAG_OFF the offset of the fragment from the beginning of the APDU
APDUの先頭からのフラグメントのオフセットOPT_FRAG_OFF
OPT_FRAG_LEN the total length of the original APDU
元のAPDUの全長OPT_FRAG_LEN
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よりも大きくない断片の連続シリーズにのAPDU。ソースは、順次一意それらがAPDUで発生した順序でこれらの断片にOD_SQNsを割り当てます。ソースは、元のAPDUにフラグメントのオフセット値（オフセット0でAPDUの最初のバイトであり、OPT_FRAG_OFF番号フラグメントの最初のバイト）に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に添加OPT_FRAG_LENある断片で終了します。
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 DATA / 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リスト]オプションは、受信機は、単一のNAKパケットで複数のシーケンス番号の送信を要求できるようにするの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.
レシーバは、彼らがRDATAの数の再送信を希望していることを示すために、NAKをNAKリストのオプションを追加するかもしれません。
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ヘッダーのものを含む）NAKで指定されたいずれかのシーケンス番号が現在未処理でない場合、ネットワーク要素はNAKリストオプションを含むNAKを転送しなければなりません。いずれかのシーケンス番号がそれに立候補排除タイマーを持っていない場合、つまり、それは、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を尊重しながら）しなければなりません。
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
オプション長= 4 +（SQNsの4 *数）オクテット
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ネットワーク要素がそれからマルチキャスト配信ツリーの上流または下流のいずれかPGMホップであるDLRを使用することを可能にします。前者は、上流DLRSと呼ばれます。後者はオフツリーDLRSと呼ばれます。彼らは損失の地点の下流であってもオフの木、彼らは損失の影響を受けサブツリー上に存在しない場合がありますので。
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はまた、そのソースからの修復を誘発することなく、元のソースへのフロー制御を提供するために、NULL NAKを送信しなければならない持っているリダイレクトNAKを受信DLRS。
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.
リダイレクトPOLRの受信者は、対応するTSIのために、その後のNAKを指示することができるとOPT_REDIR_NLA 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を送信することにより（あるいはソース自体によって）NCFsまたは親ネットワーク要素によって供給関連するポーリングに応答することができます。
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.
DLRは、その上流のPGM親から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は、元のソースへのフロー制御を提供するために、NULL NAKを送信しなければならない持っているリダイレクトNAKを受信また、上流のDLR。それは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.
注意ベーネ：予想されるとおりに正確にDLRSによって送信ODATA、RDATAとPOLRパケットと同じ配信ツリーは、ネットワーク・ヘッダの送信元アドレスではなく、DLRのNLAとODATAソースの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とPOLLを受信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アドレスを使用します。ユニキャスト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は、元のソースへのフロー制御を提供するために、NULL NAKを発信しなければならない持っているリダイレクトNAKを受信オフツリーDLR。それは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は、それが上流のPGM親のNLAだとNAKのネットワークヘッダの送信元アドレスを比較することにより、下流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つの方法で発生する可能性があります。上流DLRSがある場合は、そのPGM親にこのルータによって送信されるNAKはリダイレクトPOLRを経由して、自分の発見がトリガされます。また、ネットワーク要素は、PGMポーリング機構を使用して、オフツリーDLRS、サブタイプPGM_POLL_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にパリティNAKを指示する必要があり。
When it can, a network element SHOULD use upstream DLRs.
とき、それは、ネットワーク要素は、上流DLRSを使用すべきであることができます。
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のためにリダイレクト情報を記録する必要があり、リダイレクトPOLRに設けられたネットワークアドレスにではなくのSPMを介して既知のPGMネイバーに同じ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).
ネットワーク要素は、対応するTSIのためのリダイレクション情報を記録している場合、後続のNAKのために、それはそれらのNAKの宛先ネットワークアドレスを変更し、DLRに送信しようと試みることができます。 SQNのためのNAKがDLRに関連付けられたインターフェイス上で見られた場合、特定のSQNのためのNAKはオフツリーDLRに送信されるべきではありません。代わりに、NAKは、上流転送されるべきです。異なるSQNsための後続のNAKが前記DLRに転送することができる（再度のためのNAKはDLRとのインタフェースで見れていないと仮定して）。
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のための情報およびPGM上流隣接向かっNAKを転送するために再試行を破棄しなければなりません。
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.
NAKが要求SQNためDLRから受信された場合、ネットワーク要素は、SQNのためのリダイレクト情報を破棄し、PGM上流隣接向かっNAKを転送する試行を再しなければなりません。ネットワーク要素はまだ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.
上流DLRSからRDATAとNCFsは配信ツリーを下に流れます。しかし、オフツリーDLRSから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から要求されたRDATAパケットのためのオフツリーDLRからNULL NAKが常に上流に転送する必要があります。ネットワーク要素は、これらが一致したRDATAの前に到着すると仮定することができます。その他のNULLのNAKは修理状態に一致するすでに作成されていない場合にのみ転送されます。ネットワーク要素は、確認またはNULL NAKを再試行すると、彼らは修理状態に受信インターフェイスを追加してはならないしてはなりません。 NULL NAKが最初に修理状態を作成するために使用されている場合は、この事実は、後続の非NULL 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である場合には、それはとにかくそれらを無視するから、すべてのリダイレクトPOLRsを無視することを選ぶかもしれません。また、受信機がオフツリーDLRSを知ることはありませんのでご注意。
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.
リダイレクトPOLRを受信すると、受信機は、TSIのためにリダイレクト情報を記録する必要があり、受信機が要求されているリダイレクトPOLRではなく、対応するODATA用PGMネイバーに設けられたネットワークアドレスに同じ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
受信機は、対応するTSIのためのリダイレクション情報を記録している場合、後続のNAKのために、それはそれらのNAKの宛先ネットワークアドレスを変更し、それらを送信しようとMAY
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.
DLR。対応するNCFをNAK_RPT_IVL内に受信されない場合、受信機は、TSIのためにリダイレクト情報を破棄し、欠落ODATAのオリジナルソースのPGM隣人に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| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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.
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.
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を使用するかもしれし、セッションが終了され、そのアプリケーションに通知します。
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を含み、
the last ODATA
最後ODATA
any associated RDATAs for the last data
最後のデータのための任意の関連するRDATAs
FEC packets for the last transmission group; in this case it is interpreted as the last packet having the FIN
最後の送信グループのFECパケット。この場合には、フィンを有する最後のパケットとして解釈され
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に等しい期間後までのSPMの送信を停止しないでください。
In an identical manner to sources, DLRs MUST provide OPT_FIN in any retransmitted data that is at the end of a session.
ソースと同じ方法で、DLRSはセッションの終わりにある任意の再送データで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.
RSTオプションは、回復不能なエラーがソースで識別された後に送信されるすべてのSPMに表示されることがあります。これは、セッションが中止されている受信機に通知するように作用します。このオプションは、SPMの中に表示されることがあります。 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を含むべきです。ソースは、それがセッションのためにNAKを処理できないと判断した場合OPT_RSTのNビットは、送信されるべきです。 OPT_RSTの原因は実装固有の値に設定されています。エラーコードが不明の場合は、0×00の値が使用されます。ソースは、それがOPT_RSTを送信する必要があることを検出すると、それはすぐにそれを送るべきです。これはすぐにSPMを送信し、SPMのハートビートタイマーをリセットすることにより行われます（タイマーがSPMを送信する前に期限切れにするために、すなわち、それは待機しません）。 OPT_RSTを送信した後、セッションが終了し、TXW_SECSに等しい期間後までのSPMの送信を停止しないでください。
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ビットは、前のODATAのためのNAKがソースから未回答行くことを示すために1に設定されています。アプリケーションは、オンまたはオフにこのビットをオンにするソースを教えてくれます。
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.
$ 00の値は、未知のリセット理由を示します。他の値は、アプリケーション意図的に中止され、エンド受信機アプリケーションに意味を持つことができる理由（エラーコード値）が得られたことを示します。これらの値は、完全にアプリケーションに依存しています。
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は、それがDLRSを識別するために、NAKを転送するために、修復状態を確立するために、ソースパスの状態を確立するために使用するメカニズムに固有のセキュリティリスクの数に対して脆弱ですそして修理を配布します。これらのメカニズムは、ネットワーク要素ので、セキュリティリスクにPGMネットワーク要素自体を公開するだけでなくスイッチも合法PGMソース、受信機、及びDLRSによって送信することができるすべてがのSPM、NAKを、NCFs、およびRDATAを解釈します。全ての隣接源、レシーバ、DLRS、及びネットワーク要素の完全な認証の短い、プロトコルは、乱用を通しません。
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.
だから、一瞬のために不正なPGMネットワーク要素の問題を脇に置く、単独の源、受信機、及びDLRSに関連するネットワーク要素への十分な潜在的なセキュリティリスクがあります。これらのリスクは、CPUの帯域幅及びメモリの両方の排出を介してサービス拒否、ならびに修復状態のmuddlingスルー（リペア）データ接続の喪失を含みます。
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は要求されたRDATAは今後ないだろうという結果と正当なソースのために意図誤直接のNAKにPGMネットワーク要素を引き起こす可能性があります。
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.
偽NCFsはPGMネットワーク要素は、NAKが早期に転送（またはPOLRsをリダイレクトする場合の誤直接の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.
SPMのネットワークヘッダのソースアドレスまたはパスのSPMで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の延長だけでなく、レート。いずれの場合も、これらの手順は、サービスを維持することを犠牲にしてNAK攻撃を生き残っでネットワーク要素を支援します。より効率的に、ネットワーク要素は、修理状態の増殖を制御するためのSPMから収集のTSIおよびそれらの関連する送信ウィンドウの知識を使用してもよいです。
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が疑惑ネットワークヘッダの送信元アドレスによって識別され、PGMが精通されていることを高い信頼性で確認するために、ネットワーク要素を可能にするネットワーク要素とDLRS間の3ウェイハンドシェイク。
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.
次の手順では、PGMに[11]及び[12]に記載されているように、パケットレベルのリードソロモン消去が技術を補正組み込みます。前方誤り訂正（FEC）に対するこのアプローチは、受信機は、N個のパケットの任意のk個のうちk個のデータ・パケットを再構成することができるように、n個のパケットの合計k個のデータパケットからHパリティパケットの計算に基づいています。元のKデータパケットが伝送グループ、およびFECブロックとして、合計N個のパケットと呼ばれます。
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.
これらの手順は、層状又は集積FECの味を提供するために与えられたTSI内の従来のARQ（選択再送）とプロアクティブFECまたはオンデマンドFECの任意の組み合わせを可能にします。 2つのアプローチは、競合することなく、単一のトランスポートセッションで同じ又は異なる受信機によって使用されることができます。ソースによって提供されると、セッションの損失回復のためのFECまたは選択的再送信の実際の使用は、受信機の裁量に完全です。受信機は、FECが利用可能な場合、それにもかかわらず、ソースがリード部分伝送グループ（まだ満杯ではない、すなわち、最新の伝送グループ、）から選択の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:
これらの手順の目的は、PGMになるようにこれらのFEC技術を組み込むことです。
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).
受信機は、交換可能に（ただし、オンデマンドのパリティが使用可能な受信機が唯一のパリティNAKを使用すべきであるセッションで）同じTSI内の選択やパリティのいずれかの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,
ネットワーク要素は、いずれの場合にのみ検索、RDATA制約、および削除アルゴリズムを変更すること、同一のデータ構造に選択的またはパリティのいずれかのNAKに基づいて、修復状態を維持します
and only OPTION additions to the basic packet formats are REQUIRED.
そして、基本的なパケットフォーマットにのみOPTIONの追加が必要です。
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.
源は、伝送グループ内のパケット数（TGSIZEの== k）としてセッション固有のパラメータを提供するためのSPMにOPT_PARITY_PRMを加えます。このオプションは、受信機が、送信グループにありますどのように多くのパケットを知ることができます、そして、それはネットワーク要素がソート伝送グループ番号で状態を修復することができます。このオプションは、ソースから入手可能ですプロアクティブかどうか、および/またはオンデマンドパリティの表示を含みます。
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.
ソースは（NEが修理状態が存在しない限りRDATAを転送しません）とRDATAなどのオンデマンドパリティパケットODATAとしてプロアクティブパリティパケットを送信します。ソースは、データパケットと区別するためのネットワーク要素およびレシーバを可能にするために、パリティパケットの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_SQN）範囲0でパケット番号（PKT-NUMを指定する伝送グループ（TG）、及び下位部分（PKT_SQN）を指定へのパケットシーケンス番号を仕切りますK-1）は、そのグループ内を通ります。実装の観点から、もしそうであればK、TGのサイズは、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でマークされたパリティパケットはシーケンススペース（PKT_SQN）は完全に限り、hがkよりも大きくないように、Hのパリティパケットに番号を付けるために再利用することを可能にするので、このマッピングは、有効なシーケンス番号空間を減少させません。
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よりも大きい場合には、ソースは、mはちょうど商であるパケットが属するk個のパリティパケットのグループの数mを指定して、K-1よりも大きい任意のパリティパケット番号jにOPT_PARITY_GRPを追加しなければなりませんKによるJの整数除算から。これに対応し、そのようなパリティパケットのPKT-NUMはちょうどJモジュロ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_SQNはPKT_CNT、欠落パケットの数ではなくPKT_NUM、SQNを含まなければなりません特定の欠落パケットの。後でこのすべての詳細。
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.
SPMにOPT_PARITY_PRMオプションでアドバタイズ送信グループのサイズが2のべき乗とセッションの間一定でなければなりません。しかし、使用される実際の送信グループのサイズは、セッションの間、一定でなくてもよい、及びOPT_PARITY_PRMでアドバタイズは異なるTGのサイズが使用される2の累乗ではないかもしれない、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_LEAD、又は次のグループの最初のパケットを持つSPMをグループの終わりを検出しますいずれか早い方。また、このTGから任意のパリティパケットはまた、任意のSPMは、最後のデータパケットのOD_SQNに等しいSPM_LEADで送信されるように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:
欠落パケットMUSTパッド源が行うのと同じ方法で、元のパケットを再構築するために、元のパケットと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の長さをエンコードし、パディングされたFECパケットに2バイト符号化された長さを付加します。
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.
受信パッドそれらが最大元のパケットサイズに受信した後、パディングパケットに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.
固定パケットサイズが伝送グループ内で使用される場合、符号化された長さは、パリティパケットに付加されていません。パリティパケットで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）は厳密OPT_FRAGMENTが例である、パケットのコンテンツ（PGMペイロード）に関連付けられています。これらのオプションは、通常、それらを含んでいるでしょう、データパケットを受信していない場合であっても保存されなければならないが、そのペイロードは、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の元のパケットのうちの少なくとも一方が、所与のタイプのペイロード固有のオプションが含まれているときはいつでも、ソースは、それが送信するすべてのパリティパケットでそのオプションタイプのエンコードされたバージョンを含まなければなりません。符号化されたオプションは、オプション共通ヘッダ（E、オプションタイプ、オプション長、OP_ENCODEDおよびOPXフィールド）の最初の3つのバイトを除いて、全体のオプションにFEC符号化を適用することによって計算されます。符号化されたオプションの種類、長さ、およびOPXは、元のオプションタイプ、長さおよびOPXと同じです。 OP_ENCODEDは、（すべてのオリジナルオプションは= 0をOP_ENCODEDている）1に設定されています。
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の元のパケットがそのオプションタイプが含まれていない場合、すべてのゼロ・オプションは、符号化プロセスのために使用されます。すべてゼロのペイロードを持つ有効なオプションから、この「ダミー」オプションを区別できるようにするには、OP_ENCODED_NULLが使用されています。 OP_ENCODED_NULLは全て元のオプションに0に設定されているが、オプションは、元のパケット内に存在しなかった場合に1の値は、符号化プロセスで使用されます。受信側では、1に等しいOP_ENCODED_NULL持つすべてのオプションは、復号後に廃棄されます。
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リペアパケットを使用して欠落したパケットを回復すると、もしあれば、それはまた、ペイロード固有のオプションを回復しなければなりません。これらの存在は明確にパリティパケットに符号化されたオプション（符号化されたオプションが1に設定さOP_ENCODEDた）の存在を介して検出することができます。彼らは、パケットのペイロードを回復するためにそうであるように受信機は、エンコードオプションと、おそらく元のオプションに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発生を用いて行われなければなりません。一つ以上のオリジナルのパケットがそのオプションの種類が含まれていない場合は、ゼロ値と同じタイプのオプションを使用する必要があります。このオプションは、1に等しいOP_ENCODED_NULLを持たなければなりません。
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
OPT_PARITYは、データパケットと区別するために、（ODATA）プロアクティブおよびオンデマンド（RDATA）パリティパケットで示されました。このオプションは、直接固定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
このような伝送グループのサイズとソースからプロアクティブおよび/またはオンデマンドパリティの可用性などのセッション固有のパラメータを指定するためのSPMのソースによって添付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以上のパリティパケットがソースにより提供される場合、パリティパケットが属するHパリティパケットのグループ（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_SQNの上位部分をNAK_TG_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.
注意ベネ：NAK_PKT_CNT（及びNCF_PKT_CNT）はNAK_PKT_CNT = 0は1 FEC RDATAが要求されていることを意味することを意味し、0ベースのカウンタであり、一般的なNAK_PKT_CNT = Kに - 1がk 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.
注意ベネ：NCF_PKT_CNT（及びNAK_PKT_CNT）はNAK_PKT_CNT = 0は1 FEC RDATAが要求されていることを意味することを意味し、0ベースのカウンタであり、一般NAK_PKT_CNTに= K - 1がk FEC RDATAが要求されていることを意味します。
RDATA_TG_SQN the high-order portion of RDATA_SQN specifying the transmission group to which the parity packet belongs
パリティパケットが属する伝送グループを指定RDATA_SQNの上位部分をRDATA_TG_SQN
RDATA_PKT_SQN the low-order portion of RDATA_SQN specifying the parity packet sequence number within the transmission group
伝送グループ内のパリティパケットのシーケンス番号を指定RDATA_SQNの下位部分をRDATA_PKT_SQN
ODATA_TG_SQN the high-order portion of ODATA_SQN specifying the transmission group to which the parity packet belongs
パリティパケットが属する伝送グループを指定ODATA_SQNの上位部分ODATA_TG_SQN
ODATA_PKT_SQN the low-order portion of ODATA_SQN specifying the parity packet sequence number within the transmission group
伝送グループ内のパリティパケットのシーケンス番号を指定ODATA_SQNの下位部分ODATA_PKT_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.
ソースは所与のトランスポートセッションのためのパリティを提供することを選択した場合、それは最初にそののSPMのOPT_PARITY_PRMオプションで送信グループのサイズPARITY_PRM_TGSを提供しなければなりません。これは、ソースは、より小さいサイズの伝送グループを送信することを選択した場合に最大実効伝送グループサイズとなります。ソースは所与のトランスポートセッションのための積極的なパリティを提供することを選択した場合、それはそののSPMのOPT_PARITY_PRMオプションでPARITY_PRM_PROを設定しなければなりません。ソースは所与のトランスポートセッションのためのオンデマンドのパリティを提供することを選択した場合、それはそののSPMの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に反応しなければなりません。ソースは、オンデマンドのパリティパケットの送信を開始する前に、k個の元データパケットとおそらく予定の積極的なパリティパケットの送信を完了しなければなりません。その後、ソースはそのパリティ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でNAK_PKT_CNT以上である場合。オンデマンドのパリティパケットのために以前の要求から保留（すなわち、未送信）パリティパケットの数は、その後のNAKが確認されなければならないが、ソースのみに保留中のパリティパケットの数を増やす必要があること、その後のNAKでNAK_PKT_CNT未満の場合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を送ってくださいありません。ソースもそれが最後のデータパケットのOD_SQNに等しいSPM_LEADで送信するすべてのSPMにOPT_CURR_TGSIZEを加えなければなりません。
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しなければなりません。ソースは、この点を考慮し、効果的に最大TGのサイズと有効なTGのサイズとの間の差として計算されたオフセットNAK_PKT_CNTとの間の差として必要なパケットの数を計算しなければなりません。
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のためのSPMに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のためのSPMに設定されている場合、受信機は、それが損失回復のために受ける任意のプロアクティブなパリティパケットを使用すべきである、とPARITY_PRM_ONDもTSIのためのSPMに設定されている場合、それはオンデマンドのパリティを求めるかもしれませんロス検出時のパケット。 PARITY_PRM_ONDが設定されている場合は、ソースが可変トランスミッショングループサイズオプションを使用しない場合、受信機は、部分的な伝送グループを除いて、選択的NAKを送ってはいけません。パリティパケットは、受信機がODATA / RDATA_TG_SQNパリティが対応する伝送グループ内の損失の回復のために適用することができるPARITY_PRM_TGSパケットのグループを識別していることを知らせるOPT_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はNAK_TG_SQNによって指定された送信グループから欠落していることが検出パケット数のカウントに設定OPT_PARITYとNAK_PKT_CNTと単にNAKです。これは伝送グループ内のデータパケットが存在するよりもより多くのパリティパケットを要求する受信機を拘束することに注意してください。
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_PKT_CNTに反比例パリティNAKのためのバイアスNAK_BO_IVLの値をより大きな損失のためのNAKが同じ受信機人口の少ない損失を控えたNAK予定される可能性が高いようにする必要があります。
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を選択的に頼るMAY。
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介して可変サイズの伝送グループを使用していた場合、受信機は、任意の再送信を要求された（受信した）を有する前にこれを学ぶかもしれません。それはどんな積極的なパリティパケットまたはSPMで、TGの最後のデータパケットにOPT_CURR_TGSIZEを見ている場合は、上記起こります。次の送信グループの開始を待たずにそれらのための受信機がこれを学習し、それが短く伝送グループ内の1つのまたは複数のパケットを逃したと判断した場合、それはMAYは、NAK。それ以外の場合は、次の送信グループの開始時にNAKingを開始します。
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は、送信グループのサイズが最大実効伝送グループであると仮定欠落なければなりません。言い換えれば、受信機は、それが欠けている、プラスパケットの数が最大に総パケットを起動するために必要とされると考えているすでに伝送グループが小さかったことを知っているかもしれませんが、パケット数のMUST常に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.
第1パリティパケットが受信機に配信された後、実際の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_PKT_CNTの大きい方とするための既知のパケット数に設定通常の方法（すなわち、変更されたパケットの種類とNAKのマルチキャストコピー）が、OPT_PARITYを加えたとNCF_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再送信を保留中キャンセルしなければなりません。ネットワーク要素は、最大の既知パケットとパリティNCFからNCF_PKT_CNT記録を添加して通常の方法でNAKを予測するパリティNCFsを使用しなければならない任意の後続のNAKは、等しい又はNCF_PKT_CNTが除去されるよりも少ないNAK_PKT_CNTで受信するように予想される状態とカウント、およびNCF_PKT_CNTより大きいNAK_PKT_CNTとのいずれかが転送されます。最大の知られているパケット数を増やすこともNAKを予想し、それを使用しなければならない最大の既知のパケット数よりも大きなNCF_PKT_CNTとパリティNCFを受けるネットワーク要素は、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を持っている場合にのみNNAKsが解消されることを除いて、通常の除去手順に従ってください。
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またはのSPMで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ビット（PARITY_PRM_PRO）
Indicates when set that the source is providing pro-active parity packets.
ソースは、プロアクティブなパリティパケットを提供していることを設定した場合を示しています。
O-bit (PARITY_PRM_OND)
Oビット（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の少なくとも一つは設定しなければなりません。
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は唯一のSPMに付加されてもよいです。
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.
最初のk個のパリティパケットは、グループゼロであるパリティパケットが属する伝送グループ内のHパリティパケット間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]).
ソースは、ネットワーク全体の安定性を提供することを目的とし、輻輳回避のための戦略を実装しなければならない、[13] PGM競合間の公平性が流れ、共存するTCPに向けて公平性のある程度が流れます。これを行うためには、ソースは、トラフィック負荷の面でネットワークの状態に関するフィードバックを提供する必要があります。この付録では、スケーラブルな方法でソースに、このようなフィードバックを提供するNE手順を指定します。 （NEのサポートを必要としない輻輳制御のための代替TCPフレンドリーなスキームは、[16]に記載されています）。
The procedures specified in this section enable the collection and selective forwarding of three types of feedback to the source:
このセクションで指定された手順は、収集およびソースへのフィードバックの三種類の選択的転送をイネーブル。
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受信機がNAKを（OPT_CR）に追加してもよいことを、ヘッダ・オプションを定義します。 OPT_CRはソースに向けて上流に伝播のNAKの輻輳レポートを運びます。
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.
ホップバイホップの処理中NAK転送を逆のNE OPT_CRを調べ、おそらくは上流NAKを転送する前にその内容を修正します。 CRを転送することも、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
NE内部測定かかわらず検出されたようにOPT_CR_NE_WLは最悪のリンクに負荷をレポート
OPT_CR_NE_WP Reports the load in the worst end-to-end path as detected though NE internal measurements
NE内部測定かかわらず検出されたように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のインターフェイスで測定した）パケットドロップレートまたはパケット損失率（受信機で測定される）のいずれかです。その値は、直線0xFFFFの100％損失/ドロップ率を表し範囲0-0xFFFFに符号化されます。 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.
負荷報告値の時間基準となるODATA空間内OPT_CR_LEAD A SQN。これを、NAKを送信する時点で既知の送信ウインドウの先端と受信機によって初期化されます。この値は、OPT_CRの内容を変更したNEに前進させることができます。
OPT_CR_RCVR The identity of the receiver that generated the worst OPT_CR_RX_WP.
最悪OPT_CR_RX_WPを生成した受信機のアイデンティティOPT_CR_RCVR。
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.
最悪のリンクを報告するために、ネットワーク要素を可能にするために、受信機はゼロに設定されたビットOPT_CR_NELセットとOPT_CR_NE_WLでNAKにOPT_CRを追加します。後述のようにオプションと更新ごとTSI状態はそれに関連するOPT_CR_NE_WLプロセスを含むNAKを受信するNE。 NEでの行動の最終的な結果は、NAKは、サブツリーを離れたとき、OPT_CR_NE_WLはそのサブツリーの中で最悪のリンクの負荷を反映した輻輳レポートが含まれていることを保証します。これを実現するために、セッションのローカル（送信）リンクと報告書はこれらのリンクから受信した渋滞に測定負荷の中で最悪値を持つOPT_CR_NE_WLを書き換えるNES。
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:
ワーストパスを報告するために、ネットワーク要素を可能にするために、受信機はゼロに設定されたビットOPT_CR_NEPセットとOPT_CR_NE_WPでNAKにOPT_CRを追加します。このフィールドの処理は、NAKの受信時に、OPT_CR_NE_WPの値は、NAKは、以下の式に従って、受信されたインターフェイス上で測定された負荷で調整され、差OPT_CR_NE_WLと同様です。
OPT_CR_NE_WP = if_load + OPT_CR_NE_WP * (100% - if_loss_rate)
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.
マルチキャスト配信ツリーが非PGM対応ルータを含む場合OPT_CR_NE_WLと同様に、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.
パケット損失率を報告するために、受信機は、パケット損失率に設定されたビットOPT_CR_RXPセットとOPT_CR_RX_WPでNAKにOPT_CRを追加します。後述のようにオプションと更新ごとTSI状態はそれに関連するOPT_CR_RX_WPプロセスを含むNAKを受信するNE。 NEでの行動の最終的な結果は、NAKは、サブツリーを離れたとき、OPT_CR_RX_WPはそのサブツリーの中で最悪の受信機の負荷を反映した輻輳レポートが含まれていることを保証します。これを達成するために、報告書は、セッションのためにその発信リンクで受信した渋滞の中で最悪値で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）を提供しなければなりません。報告される特定のフィールドは、セッションのSPMの上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.
レシーバは0にOPT_CR_NE_WLとOPT_CR_NE_WPを初期化する必要がありますし、彼らはNLAにOPT_CR_RCVRを初期化する必要があります。 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
OPT_CRで運ばO負荷の値が最新であると考えられ、受信機へのネットワーク要素からラウンドトリップ時間のばらつきとは無関係になるように熟成されていません
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.
NEに記録O古い負荷値は、選択された基準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:
記録された値が期待間NAK時間が経過因子EXP（-1/2）ずつ縮小されますように、指数関数的エージングが計算されます。以下のようしたがってエージング式は、現在の損失率を含める必要があります。
aged_loss_rate = loss_rate * exp( - SQN_difference * loss_rate / 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)
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.
ネットワーク要素は、独立して、輻輳レポートの三つの可能なタイプを処理することにより、OPT_CRを処理します。
For each congestion report in an incoming NAK, a new value is computed to be used in the outgoing NAK:
受信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.
OPT_CR_RX_WPが入ってくるNAKから選択された場合は、O、OPT_CR_RCVRの新しい値は、受信NAKの1です。それ以外の場合は、以前に上流送信された値です。
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が上流に転送するかどうかを決定するために保持します。発信輻輳レポートのいずれかが先に送信されたアップストリーム1に対して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ビット：セットは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).
最悪のReceiverの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は唯一のNAKに付加されてもよいです。
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ビット：セットはOPT_CR_NE_WPが要求されていることを示します
R OPT_CRQST_RXP bit : set indicates OPT_CR_RX_WP is being requested
R OPT_CRQST_RXPビット：セットはOPT_CR_RX_WPが要求されていることを示し
OPT_CRQST MAY be appended only to SPMs.
OPT_CRQSTは唯一のSPMに付加されてもよいです。
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要求（SPMRs）は、非implosive方法でソースから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をユニキャストするかもしれません。受信機は、ローカルコンフィギュレーションまたはディレクトリサービスからなど、又は任意の他の手段によって、TSI、それはグループで受信他のPGMパケットからSPMRを指示するためにソースを学習することができます。受信機は、それが募集SPMからそのNAKを指示する必要がありしたユニキャストアドレスを収集するために通常のSPMの手順を使用しなければなりません。
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.
SPMRsソースからのSPMを求めるために受信機によって送信されます。
SPMs are unicast to a source and contain:
SPMは、ソースへのユニキャストであり、含まれています。
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.
ソースは、一度にTSIあたりIHB_MINあたりの制限に対応するSPM率でSPMRに即座に反応しなければなりません。対応するSPMはSPMR_DPORTにSPMR_TSIとSPM_DPORTにSPM_TSIと一致します。
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.
密集サブネットに少なくともSPMRsの潜在implosive挙動を緩和するために、受信機は、先行のソースにSPMRをユニキャストに加えて、1のTTLとSPMRをマルチキャストに基づいて、以下のバックオフおよび抑制手順を使用しなければなりません。マルチキャストSPMRの役割は、サブネットから同じSPMRsの送信を抑制するためです。
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のマルチキャストをリッスンその間SPMR_BO_IVL（〜250ミリ秒）にランダム遅延を選択する必要があります。受信機は、その選択されたランダムな間隔以内に一致マルチキャストSPMRを参照していない場合、それはまずソースに独自SPMRをユニキャストする前に、1のTTLを持つグループに独自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_DPORTにSPMR_TSIとSPMR_DPORTにSPMR_TSIと一致します。対応するSPMはSPMR_DPORTにSPMR_TSIとSPM_DPORTにSPM_TSIと一致します。
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
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.
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:
ポーリングは、二つの追加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.
POLL PGM親が投票を行うためにグループにマルチキャストノードポーリング要求。それらはPGMネットワーク要素によって転送されないように同様NCFsに、POLLパケットは、それらが到達する最初の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の子ノード（ネットワーク要素または受信機のいずれか）がトリガPOLLを送信したインターフェイスの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.
ポーリングメカニズムは、POLLパケットを受信PGMの子ノードは、一定の条件が満たされた場合にのみ、それに返信し、そうでない場合はPOLLを無視することを指示します。条件の2種類が選択できます：ポーリングの子供のための返信の確率、および決定論的条件を定義して、ランダムな状態。ランダム状態と決定論的条件の両方が返信それぞれ決定論的条件（複数可）を定義する確率を指定することにより、ポーリングPGM親ノードによって制御されます。ランダムのみ投票、決定論のみの投票または両者の組み合わせが可能です。
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 *であるN Nは、ポーリングPGM親に対するPGMの子供の数です。ポーリングノードがPOLLパケットに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 POLLが送信されているネットワーク層アドレス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
POLR_ROUND POLL_ROUND of the poll request for which this is a reply
これは、返信されたポーリング要求のPOLR_ROUNDのPOLL_ROUND
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の子供をカウントするために使用することができます。彼らはPGM_POLL_GENERALに等しいPOLL_S_TYPEを持っています。一般的な世論調査を受けるPGM子供はPOLLのランダムな条件の存在に基づいてそれに返信するかどうかを決定します。
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は、子供の数であるN * P、です。この数を計算できるようにするには、PGMの両親は、すでに子供の数の概算を持つべきである（SHOULD）。彼らはこの数の最近の見積もりを持っていない場合、彼らは返信するのが非常に低い確率で最初のポーリングを送信し、返信の必要な数を得るために、その後の世論調査で、それを増やす必要があります。
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.
返答する確率の増加に伴って二つの連続ポーリングの間で生じる子どもの人口の急激な増加によるポーリング応答爆縮を防止するためには、PGMの両親は、ポーリングラウンドを使用すべきです。ポーリングラウンドはPGMの両親は、彼らが投票を開始したときの子どもの人口の大きさを「凍結」するために、複数のポーリング間で（同じPOLL_SQNが異なるPOLL_ROUND付き）、それを一定に維持することができます。これは、PGM子供たちがそのPOLL_ROUNDがゼロか、彼らが以前に同じPOLL_SQNとゼロに等しいPOLL_ROUNDでポーリングを受けた場合である場合にのみポーリングに対応できるようにすることで動作します。
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で別の世論調査を開始しなければなりません。 POLLを受け取るPGMの子供たちが受け取った最後のPOLLのものとは異なるPOLL_SQNとの世論調査のために保留中の返事をキャンセルしなければなりません。
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は、受信した応答の数は、M / Pとして、子供の数を推定します。 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の子供たちのために検索する方法を提供します。一例として、特定の世論調査では、ダウンストリームDLRSを検索するために使用することができます。特定の投票をPGM_POLL_GENERAL異なるPOLL_S_TYPEことを特徴とします。 PGMの子供たちは、ランダムな状態にし、POLL中に存在する可能性のオプションで、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.
彼らはPOLL_S_TYPEを理解していない場合はPGMの子供たちがPOLLパケットを無視しなければなりません。いくつかの具体的なPOLL_S_TYPEはまた、彼らは完全にパケット内に存在するすべてのPGMオプションを理解していない場合は子供がPOLLを無視することを要求することができます。
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ホップ子供がとそのインターフェイス上のPOLLパケットを送信しなければならないポーリングたい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のPOLL_SQNに等しい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。世論調査は、1回のラウンドを持っている場合、これはゼロでなければなりません。世論調査は、複数のラウンドを持っている場合、これはこのPOLL_SQN内の最初のラウンドであれば、これは1プラス同じPOLL_SQNの最後のPOLL_ROUND、またはゼロでなければなりません。
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
発信インターフェイスのNLAに設定POLL_PATH
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募集返信バックオフ間隔に設定してください。予想される応答の数が応答（P）の保存的に低い確率良い自信を持って、または場合を決定することができる場合に限り、この選択に関しては、NAK_BO_IVLが通常保守的なオプションで使用して、しかし、小さい値を使用することができます（次のPOLL_MASKを参照）が使用されています。予想される応答の数が不明の場合受信された応答の数が多すぎると、ポーリングを効果的に中止することができるように、大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 BはPOLL_MASK [15]に設定されたビット数の関係P = 1 /（^ B 2）によれば、Pを返信する確率を決定します。これは決定論的投票である場合、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
注意ベネ：ODATAソースのネットワークヘッダの送信元アドレスではなく、ネットワーク要素のNLAを負担しなければならないネットワーク要素によって送信されるポーリングします。世論調査ではまた、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.
POLLパケットを送信することで世論調査を開始した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親は、応答の内破を防止するために、一般的な手順の説明で述べたルールを遵守すべきです。これらのルールは、一般的に、一般的な世論調査や具体的な世論調査の両方を観察する必要があります。後者は、しかし、回答数の期待値が小さいことが知られている場合（NO爆縮防止有する）確定的ポーリングを用いて行うことができます。子供の集団の大きさを推定することを意図して、一般的な世論調査を発行する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を参照されたい）、のSPMに付加されなければならないNCFsとポーリングに付加されてもよく、全ての場合においてNAK_BO_IVL_SQNはPOLL_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子（受信機又はネットワーク要素）POLLを受信した場合には、入ってくるポーリングのPOLL_RANDに一致するように、そのRAND_NODE_IDを使用しなければなりません。一致がPOLL_MASKによって指定されたビットに制限されています。入ってくるPOLLがすべてゼロで作られたPOLL_MASKが含まれている場合、マッチはPOLL_RAND（決定論的応答）の内容にもかかわらず、成功しています。マッチが失敗した場合、受信機またはネットワーク要素が、それ以外の場合は、それがポーリングに応答すべきかどうかを判断するためにPOLL_ROUND、POLL_S_TYPEおよび任意のPGMオプションがPOLLに含まれてフィールドをチェックしなければなりません、それ以上のアクションなしでPOLLを捨てなければなりません。
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オプションの存在にもかかわらず、POLLに返信をスケジュールする必要があります。
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と異なる場合は、返信が必要な時期であるかどうかの決定は、実際の種類に及びPOLL中に存在する可能性のオプションによって異なります。
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の受信者に知られていない場合は、返信および投票を無視してはいけません。現在定義されている唯一の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に含まれる1つです。このタイマーの期限が切れると、それは宛先アドレスとして受信POLLのPOLL_PATHを使用してPOLRを送らなければなりません。 POLR_SQNはPOLL_SQNと同じである必要があり、POLR_ROUNDはPOLL_ROUNDに等しくなければなりません。 POLRはPOLL_S_TYPEの意味やPOLL中に存在する可能性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.
新しいPOLLをPOLRsスケジュールポーリングのPOLR_SQN異なるPOLL_SQNで受信された場合PGM受信機又はネットワーク要素がPOLRsの保留中の送信を中止しなければなりません。
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.
POLLは、彼らの最初のPGMホップの子供たちの間で投票を開始するために、PGM親（ソースまたはネットワーク要素）によって送信されます。
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マルチキャストグループに送信されます。 POLLのネットワークヘッダの送信元アドレスは、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
一緒にPOLL_GSIフォームとデータ・ソースポート、POLL_TSI
Destination Port:
宛先ポート：
POLL_DPORT
POLL_DPORT
Data-Destination Port
データ、宛先ポート
Type:
タイプ：
POLL_TYPE = 0x01
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に割り当てられたシーケンス番号。
POLL's Round
POLLのラウンド
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のバックオフの間隔
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はPOLLに返信する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をトリガPOLLから公知の上流のPGM要素（ソースまたはネットワーク要素）のユニキャストNLAにPOLLの創始者によって初期化されます。
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
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パケットのシーケンス番号（POLL_SQN）。
POLR's Round
POLRのラウンド
POLR_ROUND
POLR_ROUND
The round number (POLL_ROUND) of the POLL packet for which this is a reply.
この返信されたPOLLパケットのラウンド数（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仮想トポロジが確立され、走査型プローブ顕微鏡によってリフレッシュされます。 1つの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ホップ受信機NAKバックオフ間隔（NAK_BO_IVL）を受信し、調整するためにこの観察を使用して監視します。レシーバはNCFsかのSPMに追加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ホップ受信機が使用すべきこと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.
最初の重複NAKを特定のインターフェイス上の所与SQNのために受信されたときの電流値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は、各測定値は、新しい修理状態の作成に対応する最後NAK_PROBE_NUM測定のための特定のインターフェイスで受信されない場合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の現在の値を宣伝します。彼らはまた、発信のSPMにOPT_NAK_BO_IVLを追加するかもしれません。
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を含むのSPMを受けるネットワーク要素はのSPMを転送する前に、発信インターフェース（複数可）のためNAK_BO_IVLの現在の値とオプションまたは過剰書き込み、その内容（NAK_BO_IVL）を除去する必要があります。
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を追加してセッションに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やSPMの中に存在する場合受信機は、NAK_BO_IVLの値は、オプションOPT_NAK_BO_IVLを通じて使用することを学びます。いずれかNAK_BO_IVL_SQNがゼロである、または受信機が半シーケンス番号空間内POLL_SQN = <NAK_BO_IVL_SQNためPOLL_RND == 0を見ていない限りNAK_BO_IVLの値は、受信機によって使用してはいけませんOPT_NAK_BO_IVLから学びました。 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ホップ受信機集団の大きさの変化を追跡し、それに応じてNAK_BO_IVLを調整するための手段を提供します。所与SQNの重複のNAKの数がスケジュール（または転送）最初のPGMホップ子供の数NAKまでとしない最初のPGMホップ子供の絶対数に関連していることに留意されたいです。このメカニズムは、しかし、多くの新しい受信機がその間にセッションに参加している場合は、重複のNAKので、多数が、NAKをせずに期間後ことが可能となり、パケットロスのない状態では動作しません。世論調査の結果は、人口規模が期間中に大幅に増加していることを示していた場合は、この問題に対処するには、PGMソースとネットワーク要素は、定期的に、付録D.に記載されている「一般世論調査」手順を使用して最初のPGM-ホップ子供の数をポーリングする必要がありますNAKをせずに、彼らは安全対策として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.
彼らはNAKを受信したときに、いくつかのケースではPGM（親）ネットワーク要素は、速やかに、そのマルチキャストの接続性をチェックすることにより、（によるネットワーク障害やルート変更に）抑えマルチキャスト配信ツリーの全部または一部の損失を検出することができます。接続の問題が下流いくつかの他の非PGMノードで発生する可能性があり、またはマルチキャストルーティングテーブルに反映するために時間がかかる可能性があるなど、いくつかの他の場合では、これは不可能です。これら後者のケースに対処するために、PGMは、単純なヒューリスティックを使用する：重複のNAKの数が修復状態のために受信されたときに障害がTSIのために想定されるインタフェースのいずれかの値DUP_NAK_MAXに達します。
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に応答してそれらにユニキャストNCFsを送信します。ユニキャストNCFsを受信し、マルチキャストセッションのマルチキャスト接続性を有する下流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.
検出またはマルチキャストNCFsを介してダウンストリーム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を受け取るまで、ネットワーク要素は、ユニキャストNCFsを使用して維持する必要があります。
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を持つべきである（SHOULD）。 OPT_NBR_UNREACHオプションは、SPMは（SPM_TRAILとSPM_LEAD）でウィンドウ情報を無効にします。 OPT_NBR_UNREACHオプションを追加するPGMネットワーク要素は0x80000000の0とSPM_LEADにSPM_TRAILを設定することにより、ウィンドウ情報を無効にすべきです。
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.
そしてSPM_PATH現在知られているPGM親に一致するOPT_NBR_UNREACHオプションを含む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受信機は、通常のSPMは、TSIのために受信されるまで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オプションが含まれているのSPMに情報をウインドウ無視しなければなりません。
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が1よりも異なる隣人を指定した場合の受信機がOPT_NBR_UNREACHオプションを含むNCFsを無視しなければなりません現在、PGM親隣人であることを知っています。 SPM_PATHは、現在のPGM親と一致しない場合も同様の受信機はOPT_NBR_UNREACHオプションを含むのSPMを無視しなければなりません。
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はNCFs、走査型プローブ顕微鏡、または投票に付加することができます。
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は、走査型プローブ顕微鏡に付加されてもよいです。
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.
存在する場合のSPMで、それは、ウィンドウ情報を無効にします。
OPT_NBR_UNREACH MAY be appended to SPMs and NCFs.
OPT_NBR_UNREACHは、走査型プローブ顕微鏡と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.
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 /バイトあたりのパケット）です。
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_INCにTXW_TRAILをインクリメント源によって増分ウィンドウを横切って進められます。送信ウィンドウが増分ウィンドウを横切って前進するときに、増分ウィンドウ（すなわち、TXW_TRAILはTXW_INCに瞬間的に等しい）空にされ、送信が進行するにつれて、すぐに補充し始め、再び後（すなわち、TXW_TRAILがTXW_ADV_SECSによりTXW_INCから分離さTXW_ADV_SECS満杯であります送信ウィンドウがそのように再び前進され、その時点でデータ）の。
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_INCへTXW_TRAILから送信ウィンドウの後縁を進めるべきです。
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は、ソースが送信ウィンドウを進めるために使用することの戦略を制約しません。ソースは、スキームのいずれかの方式や数を実施することができます。三つの提案戦略がここに概説されています。
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秒刻みでその送信ウィンドウをインクリメントする場合、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
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.
注意ベネ：この例では、シーケンス番号の点でウィンドウサイズのみなぜなら1500バイトの一定のデータ・パケット・サイズの想定を決定することができます。データ・パケットのサイズが可変である場合、より多くのまたはより少ないシーケンス番号は、同じ量のデータ（TXW_BYTES）を送信消費され得ます。
So, for a given transport session identified by a TSI, a source maintains:
だから、TSIによって識別される所与のトランスポートセッションのために、ソースを維持します。
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
TXW_MAX_RTE毎秒キロバイトの最大送信速度、送信ウィンドウ前進戦略に応じのSPM、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_SECSを維持します。時間の任意の瞬間に維持バイトの実際の数は、最後のTXW_SECS中のトラフィックに応じて、0とTXW_BYTESの間で変化するであろう。この場合、TXW_MAX_RTEはのSPMと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.
「データとアドバンス」と呼ばれる第二では、送信ウィンドウは、修理のために、データの最後の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.
第三の戦略は、アプリケーションの手の中にウィンドウのコントロールを離れます。このためソース実装によって提供される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は、SPMの両方ODATAとRDATAから計算され、そしてNAKがTXW_ADV_IVL_TMRをリセットします。この動作モードでは、送信ウィンドウは、修理のために、データの最後のTXW_BYTESバイトを維持しています。すなわち、期間TXW_SECSで送信することができるデータの理論上の最大量を維持、です。これは、次のタイマーではなく、彼らが「データ駆動型」され、リアルタイムタイマーとして扱われていないことを意味します。それは、彼らが定義した期間中に送ることができるデータの量が送信されたときに期限切れ、です。彼らは、SPM周囲の時間間隔、TXW_ADV_SECS、TXW_SECS、TXW_ADV_IVL、TXW_ADV_IVL_TMRと加入期間です。 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が実行されている間、ソースは、インクリメント・ウィンドウ内のデータにはNAKをがTXW_ADV_IVL秒間見られなくなるまで、その送信ウィンドウの進歩が遅れているようTXW_ADV_IVLにタイマーTXW_ADV_IVL_TMRをリセットするために増分ウィンドウ内ODATAのための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のみを修理のための余分な帯域幅を消費することにより、一定のデータスループット・レートを維持するためのSPMとODATAから計算されます。 TXW_ADV_IVLはインクリメントウィンドウ内のデータのためのNAKがまだ受信されているかどうかにかかわらず、送信ウィンドウを進める値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.
輻輳制御するために、少なくとも3つの異なるアプローチがPGMで探求することができる：受信機フィードバックベースのアプローチ、ルータアシストベースのアプローチ、および層符号化ベースのアプローチを。最初は、アプリケーション層の肯定応答メカニズムによって増大PGMにおける否定応答機構によって支持されています。第二は、PGMのルータ例外処理機構によって支持されています。第三は、PGMにおけるFECメカニズムによってサポートされています。受信機フィードバックベースのアプローチの例は、[16]内に設けられ、ルータアシストベースのアプローチのための提案は[17]で提案されました。研究者のためのオープンな問題は、これらのアプローチのそれぞれが最も顕著なのは、同じ規律のか、さまざまな分野の競合する複数のセッションの存在下で、TCPを振る舞うどうやっ類;どのようにそれらのそれぞれは、トポロジの特定の範囲にわたり、および負荷の特定の範囲に渡って振る舞うん。そしてどのようにそれらのそれぞれは、受信機の人口の大きさの関数として拡張します。
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.
ルータは、アシスト制御を爆縮、本明細書ではなく、輻輳制御に記載されているように上記のように制約を再送し、より一般的に毎ネットワーク要素状態と処理にアクセスすることによって向上させることができる任意の特徴にするだけではなく、用途を有します。これらの機能の完全な範囲はまだ未開拓の通りであるが、ルータはトランスポートプロトコルに依存しない方法（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のこの特定の局面では、完全に指定されている間、唯一のネットワーク素子側に実装されており、これらのような質問に対処することができます前に、ホスト側の実装を待ちます。
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は、これらのアプリケーションのサービス要件だけでなく、有効トランスポート・インタフェース上に可視にすることができる、それらのアプリケーションのサポートにPGMが提供するサービスの両方を反映した信頼性の高いマルチキャストアプリケーションのためのプログラミングAPIを開発する機会を提供します。少なくとも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メッセージダイジェストアルゴリズムMTU最大伝送単位NAK否定応答NCF NAKの確認NLAネットワーク層アドレスNNAKヌル否定応答ODATAオリジナルデータPOLLポーリング要求のPOLRポーリングレスポンスRDATAは、データRSNが状態通知SPMのソースパスメッセージSPMR SPM要求TGトランスミッショングループTGSIZEトランスミッショングループサイズ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
ボブAlbrightsonジョエル・ビオンマーク・ボウルズスティーブデアリングTugrul FiratliダンハーキンズディマKhouryさんジェラール・ニューマンデイブ・オランデニーページケンPillayチェタン・ラーイヤコフ・レックターデイブ・ロセッティポールStirpeブライアンWhettenカイルニューヨーク
[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.モンゴメリー、S.カプラン、「分散システムにおける理論と実践」の「高完全マルチキャストプロトコル順序パフォーマンス」、シュプリンガーフェアラーク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.フロイド、V. Jacobsonの、C.劉、S. McCanne、L.チャン、「高信頼マルチキャストフレームワーク軽量セッションおよびアプリケーションレベルフレーミング」、ネットワーク11月1996年ACMトランザクション。
[3] J. C. Lin, S. Paul, "RMTP: A Reliable Multicast Transport Protocol", ACM SIGCOMM August 1996.
[3] J. C.林、S.ポール、 "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]ミラー、K.、ロバートソン、K.、Tweedly、A.およびM.ホワイト、 "マルチキャストファイル転送プロトコル（MFTP）仕様"、進行中の作業。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[7] C. Partridge, "Gigabit Networking", Addison Wesley 1994.
[7] C.ヤマウズラ、 "ギガビット・ネットワーク"、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.ホルブルック、S. K.シングハル、D. R. Cheriton、 "ログベースの分散対話型シミュレーションのための受信機、高信頼マルチキャスト"、ACM SIGCOMM 1995。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、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.リゾー、「信頼性の高いコンピュータ通信プロトコルのための効果的な消去符号」、コンピュータコミュニケーションレビュー、1997年4月。
[13] V. Jacobson, "Congestion Avoidance and Control", ACM SIGCOMM August 1988.
[13] V. Jacobson氏、 "輻輳回避とコントロール"、ACM SIGCOMM 1988年8月。
[14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP, 14, RFC 2119, March 1997.
[14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ウェイクマン、 "インターネットにおけるマルチキャスト映像配信のためのスケーラブルなフィードバック制御"、PROC。 ACM / SIGCOMM 94頁58から67。
[16] L. Rizzo, "pgmcc: A TCP-friendly Single-Rate Multicast Congestion Control Scheme", Proc. of ACM SIGCOMM August 2000.
[16] L.リゾー、「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.ルビー、L. Vicisano、T.スピークマン。 「異機種マルチキャスト輻輳制御ルータのパケットフィルタリングに基づいて」、RMTワーキンググループ、1999年6月、ピサ、イタリア。
[18] Cain, B., Speakman, T. and D. Towsley, "Generic Router Assist (GRA) Building Block, Motivation and Architecture", Work In Progress.
[18]カイン、B.、スピークマン、T.および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.パパドプロス、及び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.パパドプロス、「RAIMS：ルータ支援インターネットマルチキャストサービスのためのアーキテクチャ。」 ETHチューリッヒ、スイス、2000年10月23日に発表。
[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.リゾー、 "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.アラウージョ、G. Aldabbagh、P. Kouniakis、及びA. Giannopoulos、 "FreeBSDのための実用的な一般的なマルチキャスト（PGM）ホスト実装。"、Http://www.cs.ucl.ac。英国/研究/ DARPA / PGM / PGM_FINAL.html
Tony Speakman EMail: speakman@cisco.com
トニー・スピークマンEメール：speakman@cisco.com
Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 USA EMail: dino@procket.com
ディノファリナッチProcket Networksの3850北まずストリートサンノゼ、CA 95134 USA電子メール：dino@procket.com
Steven Lin Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94086 USA EMail: steven@juniper.net
スティーブン林ジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94086 USA Eメール：steven@juniper.net
Alex Tweedly EMail: agt@cisco.com
アレックスTweedly Eメール：agt@cisco.com
Nidhi Bhaskar EMail: nbhaskar@cisco.com
Nidhi Bhaskar Eメール：nbhaskar@cisco.com
Richard Edmonstone EMail: redmonst@cisco.com
リチャードEdmonstone Eメール：redmonst@cisco.com
Rajitha Sumanasekera EMail: rajitha@cisco.com
Rajitha Sumanasekera Eメール：rajitha@cisco.com
Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 USA EMail: lorenzo@cisco.com
ロレンツォVicisanoシスコシステムズ、株式会社170西タスマン・ドライブ、サンノゼ、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
コンピュータサイエンス大学ロンドンガウアーストリートロンドンWC1E 6BTイギリスの電子メールのジョン・クロークロフト部門：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
ジム・Gemmellマイクロソフトベイエリアリサーチセンター301ハワード・ストリート、＃830サンフランシスコ、CA 94105 USA Eメール：jgemmell@microsoft.com
Dan Leshchiner Tibco Software 3165 Porter Dr. Palo Alto, CA 94304 USA EMail: dleshc@tibco.com
ダンLeschiner Tibko Softvare 3165博士ポーター。パロアルト、CA 94304 EメールUCA：дълешк@тибко.ком
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Fremont CA 94538 USA EMail: luby@digitalfountain.com
マイケル・ルビーデジタル泉社39141シビックセンタードライブフレモントCA 94538 USA Eメール：luby@digitalfountain.com
Todd L. Montgomery Talarian Corporation 124 Sherman Ave. Morgantown, WV 26501 USA EMail: todd@talarian.com
トッド・L.モンゴメリーTalarian株式会社124シャーマンアベニュー。モーガンタウン、WV 26501 USA Eメール：todd@talarian.com
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2 56126 Pisa Italy EMail: luigi@iet.unipi.it
ルイジ・リゾディップのIngディオーティソルビ2 56126ピサイタリアの電子メールを介してピサの情報大学：。。luigi@iet.unipi.it
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。