RFC3208 日本語訳
3208 PGM Reliable Transport Protocol Specification. T. Speakman, J.Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby,T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R.Sumanasekera, L. Vicisano. December 2001. (Format: TXT=244637 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Speakmanがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3208年のシスコシステムズカテゴリ: 実験的なJ.のJ.GemmellマイクロソフトD.ファリナッチクロウクロフトUCL Procketは2001年12月にデジタルS.リン杜松ネットワークのT.モンゴメリTalarian社のL.D.Leshchiner TIBCO Software M.Luby FountainリゾーのためにPisa A.Tweedly N.Bhaskar R.Edmonstone R.Sumanasekera L.Vicisanoシスコシステムズ大学をネットワークでつなぎます。
PGM Reliable Transport Protocol Specification
PGMの信頼できる輸送プロトコル仕様
Status of this Memo
この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.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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
実践的な司令官のMulticast(PGM)は複数のソースから複数の受信機までの命令されるか順不同の、無写しのマルチキャストデータ配送を必要とするアプリケーションのための信頼できるマルチキャストトランスポート・プロトコルです。 PGMは、グループにおける受信機がトランスミッションと修理からすべてのデータ・パケットを受けるか、または復しないデータパケット損失を検出できるのを保証します。 PGMはそうです。
Speakman, et. al. Experimental [Page 1] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[1ページ]RFC3208PGM
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.
基本の信頼度要求事項があるマルチキャストアプリケーションのための実行し得る解決法として明確に意図しています。 主要なデザイン目標は当然払うべき敬意を払ってスケーラビリティとネットワーク効率のための操作の簡単さです。
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
1. 序論と概要… 3 2. 建築記述… 9 3. 用語と概念… 12 4. 手順--、一般… 18 5. 手順--出典を明示します。 19 6. 手順--、受信機… 22 7. 手順--Elementsをネットワークでつないでください… 27 8. パケット形式… 31 9. オプション… 40 10. セキュリティ問題… 56 11. 付録A--エラー修正を進めてください… 58 12. 付録B--混雑には、コントロールをサポートしてください… 72 13. 付録C--SPM要求… 79 14. 付録D--メカニズムに投票してください… 82 15. 付録E--内部破裂防止… 92 16. 付録F--窓の例を伝えてください… 98 17付録G--適用性声明… 103 18. 略語… 105 19. 承認… 106 20. 参照… 106 21. 作者のアドレス… 108 22. 完全な著作権宣言文… 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のReliable Multicast Transport作業部会における進行中の、より長い期間標準化過程にその経験をフィードバックできるようにこのクラスの信頼できるマルチキャストプロトコルの実装と展開を経験に提供することです。 付録Gはこの実験のいくつかの範囲と状態に関する、より特定の詳細を明らかにします。 実験のレポートは[16-23]を含んでいます。 追加結果と新しい実験は奨励されます。
Speakman, et. al. Experimental [Page 2] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[2ページ]RFC3208PGM
1. Introduction and Overview
1. 序論と概要
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])。 この伝統では、Pragmatic Multicast司令官(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には、グループ会員資格の考えが全くありません。 純粋にローカルの戦略に応じて、それはソースで、単に、窓の高度な状態でaの中のデータ配送が伝える信頼できるマルチキャストを提供します。 信頼できる配信は受信機が出発するまでグループに加わる時からの中に、情報筋のものが窓を伝えるかどうかということです。 PGMは、グループにおける受信機がトランスミッションと修理からすべてのデータ・パケットを受けるか、または復しないデータパケット損失を検出できるのを保証します。 PGMはマルチキャストグループの中のいろいろなソースをサポートします、とグローバルにユニークなTransport Session Identifier(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データ・パケットのトランスポート層消費者は受信機と呼ばれます、そして、介入しているネットワークにおけるネットワーク層実体はネットワーク要素と呼ばれます。
Speakman, et. al. Experimental [Page 3] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[3ページ]RFC3208PGM
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[14]について説明して、対応するPGM実装のために要件レベルを示すとき本書では解釈されることであるべきですか?
1.1. Summary of Operation
1.1. 操作の概要
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)、およびデータ・パケットのためのユニキャストの選択している否定応答(NAKs)が予想された系列からなくなるように検出した受信機を配列しました。 ネットワーク要素は、近くNAKs PGM-跳びPGM-ホップをソースに送って、応答におけるマルチキャスティングa NAK確認(NCF)でNAKが受け取られたインタフェースで各ホップを確認します。 修理(RDATA)はソース自体かNAKに対応したDesignated Local Repairer(DLR)によって提供されるかもしれません。
Since NAKs provide the sole mechanism for reliability, PGM is particularly sensitive to their loss. To minimize NAK loss, PGM defines a network-layer hop-by-hop procedure for reliable NAK forwarding.
NAKsが唯一のメカニズムを信頼性に提供するので、PGMは特に彼らの損失に敏感です。 NAKの損失を最小にするために、PGMはホップごとの信頼できるNAK推進のためのネットワーク層手順を定義します。
Upon detection of a missing data packet, a receiver repeatedly unicasts a NAK to the last-hop PGM network element on the distribution tree from the source. A receiver repeats this NAK until it receives a NAK confirmation (NCF) multicast to the group from that PGM network element. That network element responds with an NCF to the first occurrence of the NAK and any further retransmissions of that same NAK from any receiver. In turn, the network element repeatedly forwards the NAK to the upstream PGM network element on the reverse of the distribution path from the source of the original data packet until it also receives an NCF from that network element. Finally, the source itself receives and confirms the NAK by multicasting an NCF to the group.
欠測値パケット、受信機の検出、繰り返して、最後のホップPGMへのユニキャストa NAKは要素をソースから分配木にネットワークでつなぎます。 そのPGMネットワーク要素からNAK確認(NCF)マルチキャストをグループに受けるまで、受信機はこのNAKを繰り返します。 そのネットワーク要素はNCFと共にどんな受信機からもその同じNAKのNAKとどんな一層の「再-トランスミッション」の最初の発生にも応じます。順番に、また、そのネットワーク要素からNCFを受けるまで、ネットワーク要素はNAKをオリジナルのデータ・パケットの源から裏面に分配経路の上流のPGMネットワーク要素に繰り返して送ります。 情報筋自身は、マルチキャスティングで最終的に、NAKを受け取って、確認します。グループへのNCF。
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ネットワーク要素によって伝播されません。
Speakman, et. al. Experimental [Page 4] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[4ページ]RFC3208PGM
To avoid NAK implosion, PGM specifies procedures for subnet-based NAK suppression amongst receivers and NAK elimination within network elements. The usual result is the propagation of just one copy of a given NAK along the reverse of the distribution path from any network with directly connected receivers to a source.
NAK内部破裂を避けるために、PGMはネットワーク要素の中で受信機の中のサブネットベースのNAK抑圧とNAK除去のための手順を指定します。 普通の結果は分配経路の直接接続された受信機があるどんなネットワークからソースまでの逆に沿った与えられたNAKのコピーちょうど1部の伝播です。
The net effect is that unicast NAKs return from a receiver to a source on the reverse of the path on which ODATA was forwarded, that is, on the reverse of the distribution tree from the source. More specifically, they return through exactly the same sequence of PGM network elements through which ODATA was forwarded, but in reverse. The reasons for handling NAKs this way will become clear in the discussion of constraining repairs, but first it's necessary to describe the mechanisms for establishing the requisite source path state in PGM network elements.
ネットの効果はNAKsが受信機からソースまで裏面に返すODATAが進められた経路と、すなわち、ソースからの裏面に分配木のそのユニキャストです。 より明確に、彼らはどのODATAを進めたか、しかし、逆における、PGMネットワーク要素のまさに同じ系列を通して戻ります。 この道がそうする取り扱いNAKsの理由は修理を抑制する議論で明確になりますが、最初に、それが、必要なソース経路州を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ネットワーク要素に証明するために、Source Path Messages(SPMs)はODATAと共に定期的にはさみ込まれたソースから基礎データ転送操作を増大させます。 SPMsは、主として分配木のすべてのPGMネットワーク要素の与えられたTSIのためにソースからソース経路州を証明するために機能します。 PGMネットワーク要素は、戻っているユニキャストがNAKsであると直接上流のPGMネットワーク要素にソースに向かって扱うのにこの情報を使用して、その結果、NAKsが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.
SPMsは上から日付へのPGMが情報を近所付き合いさせると主張するのに役立つレートでソースによって送られます。 さらに、受信機から一層のNAKsを引き起こして、受信機でウィンドウ状態を受けるように主張する際にSPMsはDATAパケットの役割の補足となります。
As a further efficiency, PGM specifies procedures for the constraint of repairs by network elements so that they reach only those network segments containing group members that did not receive the original transmission. As NAKs traverse the reverse of the ODATA path (upward), they establish repair state in the network elements which is used in turn to constrain the (downward) forwarding of the corresponding RDATA.
さらなる効率として、PGMがネットワーク要素に従った修理の規制のための手順を指定するので、それらはオリジナルのトランスミッションを受けなかったグループのメンバーを含むそれらのネットワークセグメントだけに達します。 NAKsが(上向きに)ODATA経路の逆を横断するとき、彼らはネットワーク要素の対応するRDATAの(下向き)の推進を抑制するのに順番に使用される修理状態を設置します。
Besides procedures for the source to provide repairs, PGM also specifies options and procedures that permit designated local repairers (DLRs) to announce their availability and to redirect repair requests (NAKs) to themselves rather than to the original source. In addition to these conventional procedures for loss recovery through selective ARQ, Appendix A specifies Forward Error Correction (FEC) procedures for sources to provide and receivers to request general error correcting parity packets rather than selective retransmissions.
また、手順以外に、ソースが修理を提供するように、PGMはオプションを指定します、そして、可能にする手順は彼らの有用性を発表して、修理要求(NAKs)を一次資料にというよりむしろ自分たちに向け直すために(DLRs)に地元の修理工を任命しました。 選択しているARQを通した損失回復のためのこれらの従来の手順に加えて、提供する情報筋と受信機が選択している「再-トランスミッション」よりむしろ一般的なエラー修正パリティパケットを要求するように、Appendix AはForward Error Correction(FEC)手順を指定します。
Speakman, et. al. Experimental [Page 5] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[5ページ]RFC3208PGM
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は、TCPの好意的で、NEベースのソリューションをPGM輻輳制御に指定して、PGM輻輳制御のために終わりから終わりへのTCPに優しいソリューションに参照を引用します。
In its basic operation, PGM relies on a purely rate-limited transmission strategy in the source to bound the bandwidth consumed by PGM transport sessions and to define the transmit window maintained by the source.
基本的な操作では、PGMがソースの純粋にレートで有限なトランスミッション戦略を帯域幅がPGM輸送セッションで消費したバウンドを当てにする、定義する、ソースによって維持された窓を伝えてください。
PGM defines four basic packet types: three that flow downstream (SPMs, DATA, NCFs), and one that flows upstream (NAKs).
PGMは4つの基本的なパケットタイプを定義します: 川下を流れる3(SPMs、DATA、NCFs)、および逆流するもの(NAKs)。
1.2. Design Goals and Constraints
1.2. デザイン目標と規制
PGM has been designed to serve that broad range of multicast applications that have relatively simple reliability requirements, and to do so in a way that realizes the much advertised but often unrealized network efficiencies of multicast data transfer. The usual impediments to realizing these efficiencies are the implosion of negative and positive acknowledgments from receivers to sources, repair latency from the source, and the propagation of repairs to disinterested receivers.
PGMは、比較的簡単な信頼度要求事項を持っているマルチキャストアプリケーションのその広い声域に役立って、そうマルチキャストデータ転送の多くの広告を出していますが、しばしば実現されるというわけではないネットワーク効率を達成する方法でするように設計されています。 受信機からソース(ソース、および修理の伝播から公平無私の受信機までの修理潜在)までこれらの効率を達成する普通の障害は否定的で積極的な承認の内部破裂です。
1.2.1. Reliability.
1.2.1. 信頼性。
Reliable data delivery across an unreliable network is conventionally achieved through an end-to-end protocol in which a source (implicitly or explicitly) solicits receipt confirmation from a receiver, and the receiver responds positively or negatively. While the frequency of negative acknowledgments is a function of the reliability of the network and the receiver's resources (and so, potentially quite low), the frequency of positive acknowledgments is fixed at at least the rate at which the transmit window is advanced, and usually more often.
頼り無いネットワークの向こう側の確実な資料配送は終わりから終わりへのソース(それとなくか明らかである)が受信機から領収書確認に請求するプロトコルを通して慣習上達成されます、そして、受信機は明確か否定的に応じます。 肯定応答の頻度が否定応答の頻度がネットワークと受信機のリソースの信頼性の関数(そのように、潜在的に全く安値)である間、少なくともレートで固定されている、どれ、 よりしばしば通常、進められた窓を伝えてくださいか。
Negative acknowledgments primarily determine repairs and reliability. Positive acknowledgments primarily determine transmit buffer management.
否定応答は主として修理と信頼性を決定します。 肯定応答は、バッファ管理を伝えるように主として決定します。
When these principles are extended without modification to multicast protocols, the result, at least for positive acknowledgments, is a burden of positive acknowledgments transmitted to the source that quickly threatens to overwhelm it as the number of receivers grows. More succinctly, ACK implosion keeps ACK-based reliable multicast protocols from scaling well.
これらの原則がマルチキャストプロトコルへの変更なしで敷衍されるとき、少なくとも肯定応答のために、結果は受信機の数が成長するときそれを圧倒するとすぐに脅かすソースに伝えられた肯定応答の負担です。 より簡潔に、ACK内部破裂は、ACKベースの信頼できるマルチキャストプロトコルがよく比例するのを妨げます。
Speakman, et. al. Experimental [Page 6] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[6ページ]RFC3208PGM
One of the goals of PGM is to get as strong a definition of reliability as possible from as simple a protocol as possible. ACK implosion can be addressed in a variety of effective but complicated ways, most of which require re-transmit capability from other than the original source.
PGMの目標の1つは信頼性のできるだけ簡単なプロトコルからできるだけ強い定義を得ることです。 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は受信機からNAKsを繰り返して引き起こして、NAKs自身に信頼性を加えるための戦略を含んでいます。 NAKメカニズムを補強することによって、PGMは受信機がソース、または、指定された地元の修理工からパケットが修理を入手できないほど遅れる欠測値パケットを検出するという確率(DLR)を最小にします。 しかしながら、グループ会員資格に関するACKsと知識がなければ、PGMはこの可能性を排除できません。
1.2.2. Group Membership
1.2.2. グループ会員資格
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.
ACKsを排除する2番目の結果はグループ会員資格に関する知識がプロトコルによって必要でなく、また提供されないということです。 情報筋はいくつかの受信機からいくつかのPGMパケット(例えば、NAKs)を受けるかもしれませんが、受信機のアイデンティティはそれらのパケットの処理を含みません。 PGM輸送セッションのコースの間会員資格が知識なしで変化するかもしれないグループ、ソースへの結果または残っている受信機。
1.2.3. Efficiency
1.2.3. 効率
While PGM avoids the implosion of positive acknowledgments simply by dispensing with ACKs, the implosion of negative acknowledgments is addressed directly.
PGMが単にACKsを省くことによって肯定応答の内部破裂を避けている間、否定応答の内部破裂は直接記述されます。
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ネットワーク要素は同じネットワーク要素の上に異なったインタフェースに受け取られた写しNAKsを排除します。
Speakman, et. al. Experimental [Page 7] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[7ページ]RFC3208PGM
The combination of these two strategies usually results in the source receiving just a single NAK for any given lost data packet.
通常、これらの2つの戦略の組み合わせはどんな当然のことのロストデータパケットのためのまさしくソース受信のa独身の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か一次資料から修理を提供するか否かに関係なく、グループ中でそれを伝播するより否定的にむしろオリジナルのトランスミッションを承諾したメンバーを含むそれらのネットワークセグメントだけにその修理を抑制するのは重要です。 ネットワーク要素が対応する修理を進めるグループの中で下位木を定義するのにNAKsのパターンを使用するようにPGMが手順を指定するので、それは第一にそれを逃したそれらの受信機だけに達します。
1.2.4. Simplicity
1.2.4. 簡単さ
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は会議コントロール、グループの複数のソースの中のグローバルな注文、およびネットワークパーティションからの回復を記述しません。
1.2.5. Operability
1.2.5. 運転可能性
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/NCF操作も、NAKsが最後のホップPGMネットワーク要素へのユニキャストであり、NCFsがグループへのマルチキャストであるので、非PGMネットワーク要素の向こう側に一貫しています。 NAK抑圧が最も効果的であるように、受信機が自分たちとあらゆる経路の間の最初のホップネットワーク要素としていつもすべてのPGMソースにPGMネットワーク要素を持っているはずであることに注意してください。 受信機が最初のPGMネットワーク要素から取り除かれたいくつかのホップであるなら、NAK抑圧の効力は下がるかもしれません。
1.3. Options
1.3. オプション
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は、断片化、遅い接合、リダイレクション、Forward Error Correction(FEC)、可到達性、およびセッション同期/終了/リセットを支持するためにオプションを指定します。 彼らのオリジナルの送信機だけはPGMデータパケットのヘッダーにオプションを追加するかもしれません。 それらはネットワーク要素によって解釈されるかもしれませんが、オプションは、ネットワーク要素によって加えられないで、また取り除かれません。
Speakman, et. al. Experimental [Page 8] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[8ページ]RFC3208PGM
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.
リダイレクションは、向け直すPOLRが代替の再送信機としてそれ自身のアドレスの一次資料に広告を出していてDLRが正常なNCFsかPOLLsに応じるのを許容するのにPoll Responsesに関連して使用されるかもしれません。
FEC techniques MAY be applied by receivers to use source-provided parity packets rather than selective retransmissions to effect loss recovery.
FECのテクニックは受信機によって適用されて、選択している「再-トランスミッション」よりむしろソースによって提供されたパリティパケットを効果損失回復に使用するかもしれません。
2. Architectural Description
2. 建築記述
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は、ネットワーク要素がNAKsの信頼性を改良して、修理の伝播を抑制するためにパケット・フォーマットと手順を指定します。 これらの機能の分割は、このセクションで説明されて、次のセクションで詳細に広げられます。
2.1. Source Functions
2.1. ソース機能
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.
存在しているならソース経路州をPGMネットワーク要素に証明するためにODATAと共にはさみ込まれたグループへのソースマルチキャストSPMs。
Speakman, et. al. Experimental [Page 9] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[9ページ]RFC3208PGM
NAK Reliability
NAKの信頼性
Sources multicast NCFs to the group in response to any NAKs they receive.
彼らが受けるどんなNAKsに対応したグループへのソースマルチキャストNCFs。
Repairs
修理
Sources multicast RDATA packets to the group in response to NAKs received for data packets within the transmit window.
NAKsに対応したグループへのソースマルチキャストRDATAパケットがデータ・パケットのために中で受けた、窓を伝えてください。
Transmit Window Advance
窓の進歩を伝えてください。
Sources MAY advance the trailing edge of the window according to one of a number of strategies. Implementations MAY support automatic adjustments such as keeping the window at a fixed size in bytes, a fixed number of packets or a fixed real time duration. In addition, they MAY optionally delay window advancement based on NAK-silence for a certain period. Some possible strategies are outlined later in this document.
多くの戦略の1つに応じて、ソースは窓のトレーリングエッジを進めるかもしれません。 実現はバイト(パケットか固定リアルタイムの持続時間の定数)で表現される固定サイズで窓を保つことなどの自動調整を支持するかもしれません。 さらに、彼らは任意にある期間、NAK-沈黙に基づく窓の前進を遅らせるかもしれません。 いくつかの可能な戦略が後で本書では概説されます。
2.2. Receiver Functions
2.2. レシーバ関数
Source Path State
ソース経路州
Receivers use SPMs to determine the last-hop PGM network element for a given TSI to which to direct their NAKs.
受信機は、彼らのNAKsを向ける与えられたTSIのために最後のホップPGMネットワーク要素を測定するのにSPMsを使用します。
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ネットワーク要素への受信機ユニキャストNAKs、(任意にそうするかもしれない、地域団体への1のTTLとマルチキャストa NAK)、データ・パケット、中、予想された系列からなくなるように検出された窓を受けてください。 合っているNCFを受けるまで、受信機は繰り返して与えられたNAKを伝えなければなりません。
NAK Suppression
NAK抑圧
Receivers suppress NAKs for which a matching NCF or NAK is received during the NAK transmit back-off interval.
受信機は受け取られた合っているNCFかNAKがNAKの間に下に後部間隔を伝えるNAKsを抑圧します。
Speakman, et. al. Experimental [Page 10] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[10ページ]RFC3208PGM
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を受け取り次第中で窓を受けてください、進む窓を伝えてください、窓を受けてください。
2.3. Network Element Functions
2.3. ネットワーク要素機能
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.
ネットワーク要素は、マルチキャストの前に対応するTSIのためにソース経路州を証明するのに不断のとおり彼らを進めながら、SPMsを妨害して、彼らを使用します。
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を受けるまで、ユニキャストは彼らがTSIのために分配経路の上流のPGMネットワーク要素に受けるどんなNAKの第一刷だけも進めます。 さらに、任意にそうするかもしれない、マルチキャスト、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パケットを捨てます。 NAKsはネットワーク要素でこの推進操作を超えて保有されませんが、それらのレセプションに関する状態は格納されます。
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の正確な写しも捨てます。
Speakman, et. al. Experimental [Page 11] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[11ページ]RFC3208PGM
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が受け取られたインタフェースのリストから成る修理状態を維持するのにNAKsを使用します、そして、それらはこれらのインタフェースだけの対応する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について応じて、写しを排除することを予測してそれは外向的なインタフェースなしで修理状態を設置します。
3. Terms and Concepts
3. 用語と概念
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.
その後のProceduresで前の概観から詳細になりまで続く前に、このセクションはその詳細をより明瞭にするいくつかの概念と定義を提示します。
3.1. Transport Session Identifiers
3.1. 輸送セッション識別子
Every PGM packet is identified by a:
あらゆるPGMパケットがaによって特定されます:
TSI transport session identifier
TSI輸送セッション識別子
TSIs MUST be globally unique, and only one source at a time may act as the source for a transport session. (Note that repairers do not change the TSI in any RDATA they transmit). TSIs are composed of the concatenation of a globally unique source identifier (GSI) and a source-assigned data-source port.
TSIsはグローバルにユニークでなければなりません、そして、一度に1つのソースだけが輸送セッションのためにソースとして務めるかもしれません。 (修理工が彼らが伝えるどんなRDATAでもTSIを変えないことに注意します。) TSIsはグローバルにユニークなソース識別子(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を反響します。
3.2. Sequence Numbers
3.2. 一連番号
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
PGMは0つの特定するために突き抜けること((2**32)--1)と注文ODATAパケットから円形の一連番号スペースを使用します。 ソースは対応するアプリケーションデータがトランスミッションのために提出されるオーダーにおけるユニット増分における数のODATAパケットがそうしなければなりません。 またはaの中では、伝えてください。
Speakman, et. al. Experimental [Page 12] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[12ページ]RFC3208PGM
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.
ODATAパケットxへのその後のODATAパケットに付番するなら、一連番号yは、窓(以下では、定義される)を受けてください、ODATAパケット先行ODATAパケットyに付番するなら、一連番号xは、「より少ない」か「一連番号yより古く」、「よりすばらしい」かまたは「一連番号xより最近です」。
3.3. Transmit Window
3.3. 窓を伝えてください。
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.
サイズ、半分以下が、より少ない1のPGM一連番号スペースであったに違いないなら一連番号(TXW_SQNS)(すなわち、先導と、トレーリングエッジと1の違い)で窓を伝えてください。
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つと等しいときに、空である、ウィンドウサイズは空です。
3.4. Receive Window
3.4. 窓を受けてください。
The receive window at the receivers is determined entirely by PGM packets from the source. That is, a receiver simply obeys what the source tells it in terms of window state and advancement.
受信してください。受信機の窓はソースからのPGMパケットで完全に断固としています。 すなわち、受信機は単に、情報筋がウィンドウ状態と前進でそれを言うことに従います。
For a given transport session identified by a TSI, a receiver maintains:
TSIによって特定された与えられた輸送セッションのために、受信機は以下を維持します。
RXW_TRAIL the sequence number defining the trailing edge of the receive window, the sequence number (known from data packets and SPMs) of the oldest data packet available for repair from the source
RXW_TRAIL、トレーリングエッジを定義する一連番号、窓、ソースからの修理に利用可能な最も古いデータ・パケットの一連番号(データ・パケットとSPMsから、知られている)を受けてください。
Speakman, et. al. Experimental [Page 13] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[13ページ]RFC3208PGM
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.
データ・パケットが“in"であるとして記述されている、中に一連番号があるなら窓を受けてください、窓を受けてください。
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.
それが中でSPMかODATAパケットを受けたら受信機で進められた窓を受けてください、RXW_TRAILを増加する窓を伝えてください。 また、受信機が進む、それら、どんなPGMデータ・パケットを受け取り次第中で窓を受けてください、進む窓を受けてください、窓を受けてください。
3.5. Source Path State
3.5. ソース経路州
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.
NAKsがソースから受信機から裏面に分配木の源まで戻るのは、修理を証明するのに、状態がRDATAを抑制するのが必要であることが不可欠です。 すなわち、それらは、ODATAが進められたPGMネットワーク要素の同じ系列を通して戻りますが、逆であり戻らなければなりません。 それほど明白でないものが断然重要であることで、この2つの理由があります。
The first and obvious reason is that RDATA is forwarded on the same path as ODATA and so repair state must be established on this path if it is to constrain the propagation of RDATA.
1番目と明白な理由はRDATAの伝播を抑制するつもりであるならODATAと同じ経路でRDATAを進めるのでこの経路で修理状態を設置しなければならないということです。
The second and less obvious reason is that in the absence of repair state, PGM network elements do NOT forward RDATA, so the default behavior is to discard repairs. If repair state is not properly established for interfaces on which ODATA went missing, then receivers on those interfaces will continue to NAK for lost data and ultimately experience unrecoverable data loss.
2番目と、より少ない明白な理由はデフォルトの振舞いが修理状態がないときPGMネットワーク要素がRDATAを進めないので修理を捨てることであるということです。 修理状態が適切にODATAが雲隠れしたインタフェースに設置されないと、それらのインタフェースの受信機は、ロストデータのためのNAKに続いて、結局、復しないデータの損失を経験するでしょう。
The principle function of SPMs is to provide the source path state required for PGM network elements to forward NAKs from one PGM network element to the next on the reverse of the distribution tree for the TSI, establishing repair state each step of the way. This source path state is simply the address of the upstream PGM network element on the reverse of the distribution tree for the TSI. That upstream PGM network element may be more than one subnet hop away. SPMs establish the identity of the upstream PGM network element on the distribution tree for each TSI in each group in each PGM network element, a sort of virtual PGM topology. So although NAKs are unicast addressed, they are NOT unicast routed by PGM network elements in the conventional sense. Instead PGM network elements use
PGMネットワーク要素がTSIのために1つのPGMネットワーク要素から裏面に分配木の次までNAKsを進めるのにSPMsの機能がソース経路州を提供することであるという原則が必要であることで、修理を確立して、方法の各ステップを述べてください。 このソース経路州は単にTSIのための裏面に分配木の上流のPGMネットワーク要素のアドレスです。 その上流のPGMネットワーク要素は遠くの1つ以上のサブネットホップであるかもしれません。 SPMsはそれぞれのPGMネットワーク要素(一種の仮想のPGMトポロジー)の各グループにおける各TSIのために分配木の上で上流のPGMネットワーク要素のアイデンティティを確立します。 NAKsは記述されたユニキャストですが、それで、彼らはPGMネットワーク要素によってこれまで一般に使われてきた意味で発送されたユニキャストではありません。 代わりにPGMネットワーク要素使用
Speakman, et. al. Experimental [Page 14] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[14ページ]RFC3208PGM
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.
近くNAKs PGM-跳びPGM-ホップをソースに向けるためにSPMsによって設置されたソース経路州。 考えはPGMと非PGMネットワーク要素の両方の、より異種の基本的なトポロジーにかかる純粋なPGMトポロジーにNAKsを抑制することです。
The result is repair state in every PGM network element between the receiver and the source so that the corresponding RDATA is never discarded by a PGM network element for lack of repair state.
結果が受信機とソースの間のあらゆるPGMネットワーク要素の修理状態であるので、対応するRDATAは修理状態の不足のためのPGMネットワーク要素によって決して捨てられません。
SPMs also maintain transmit window state in receivers by advertising the trailing and leading edges of the transmit window (SPM_TRAIL and SPM_LEAD). In the absence of data, SPMs MAY be used to close the transmit window in time by advancing the transmit window until SPM_TRAIL is equal to SPM_LEAD plus one.
また、SPMsが、引きずるのと先導の広告を出すのによる受信機の州が斜めに進む窓を伝えるように主張する、窓(SPM_TRAILとSPM_LEAD)を伝えてください。 データがないときSPMsが閉じるのに使用されるかもしれない、時間内に進むことによって窓を伝えてください、SPM_TRAILがSPM_LEADプラス1と等しくなるまで、窓を伝えてください。
3.6. Packet Contents
3.6. パケットコンテンツ
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.
このセクションはただProceduresを明瞭にすることができるくらいの速記を提供します。 パケットコンテンツの一部始終について、以下のPacket Formatsを参照してください。
3.6.1. Source Path Messages
3.6.1. ソース経路メッセージ
3.6.1.1. SPMs
3.6.1.1. SPMs
SPMs are transmitted by sources to establish source-path state in PGM network elements, and to provide transmit-window state in receivers.
SPMsは、ソース道の州をPGMネットワーク要素に証明して、窓を伝えている状態を受信機に供給するために情報筋によって伝えられます。
SPMs are multicast to the group and contain:
SPMsはグループへのマルチキャストであり、以下を含んでいます。
SPM_TSI the source-assigned TSI for the session to which the SPM corresponds
SPMが相当するセッションのためのSPM_TSIのソースによって割り当てられた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)
SPM_TRAIL、ソースのもののトレーリングエッジを定義する一連番号は窓を伝えます。(TXW_道)
SPM_LEAD the sequence number defining the leading edge of the source's transmit window (TXW_LEAD)
SPM_LEAD、ソースのもののリーディングエッジを定義する一連番号は窓を伝えます。(TXW_リード)
SPM_PATH the network-layer address (NLA) of the interface on the PGM network element on which the SPM is forwarded
SPMが進められるPGMネットワーク要素の上のインタフェースのSPM_PATHネットワーク層アドレス(NLA)
Speakman, et. al. Experimental [Page 15] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[15ページ]RFC3208PGM
3.6.2. Data Packets
3.6.2. データ・パケット
3.6.2.1. ODATA - Original Data
3.6.2.1. ODATA--オリジナルのデータ
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
過量_TSIのグローバルにユニークなソースによって割り当てられたTSI
OD_TRAIL the sequence number defining the trailing edge of the source's transmit window (TXW_TRAIL)
_TRAILを過量に与えてください、ソースのもののトレーリングエッジを定義する一連番号は窓を伝えます。(TXW_道)
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.
窓を伝えてください。過量_TRAILがプロトコルを無くなっているSPMsトレーリングエッジを含んでいることに直面してより強健にする、あらゆるデータ・パケットの上で窓を伝えてください、進んだどんなSPMsも逃した受信機、まだケースを検出できて、アプリケーションを回復してください、そして、輸送セッションまで潜在的に再連動してください。
OD_SQN a sequence number assigned sequentially by the source in unit increments and scoped by OD_TSI
一連番号がユニットのソースで連続して割り当てた過量_SQNは過量_TSIで増加して、見ました。
3.6.2.2. RDATA - Repair Data
3.6.2.2. RDATA--修理データ
RDATA packets are repair packets transmitted by sources or DLRs in response to NAKs.
RDATAパケットはNAKsに対応してソースか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
RD、_これが修理であるODATAパケットの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パケットの過量_TRAILと同じであるというわけではありません。
RD_SQN OD_SQN of the ODATA packet for which this is a repair
RD、_これが修理であるODATAパケットのSQN OD_SQN
3.6.3. Negative Acknowledgments
3.6.3. 否定応答
3.6.3.1. NAKs - Negative Acknowledgments
3.6.3.1. NAKs--否定応答
NAKs are transmitted by receivers to request repairs for missing data packets.
NAKsは受信機によって伝えられて、欠測値パケットのための修理を要求します。
Speakman, et. al. Experimental [Page 16] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[16ページ]RFC3208PGM
NAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:
NAKsはソースへのユニキャスト(PGMはPGMホップで跳ぶ)であり、以下を含んでいます。
NAK_TSI OD_TSI of the ODATA packet for which a repair is requested
NAK、_修理が要求されているODATAパケットのTSI OD_TSI
NAK_SQN OD_SQN of the ODATA packet for which a repair is requested
NAK、_修理が要求されているODATAパケットのSQN OD_SQN
NAK_SRC the unicast NLA of the original source of the missing ODATA.
なくなったODATAの一次資料のNAK_SRCユニキャストNLA。
NAK_GRP the multicast group NLA
NAK_GRPマルチキャストグループNLA
3.6.3.2. NNAKs - Null Negative Acknowledgments
3.6.3.2. NNAKs--ヌル否定応答
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は受信機かネットワーク要素のどちらかによってそれに向け直された、フロー制御給送をソースに提供して戻したNAKsを受ける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.
NNAK、_対応のTSI NAK_TSIはNAKを向け直しました。
NNAK_SQN NAK_SQN of the corresponding re-directed NAK.
NNAK、_対応のSQN NAK_SQNはNAKを向け直しました。
NNAK_SRC NAK_SRC of the corresponding re-directed NAK.
NNAK、_対応のSRC NAK_SRCはNAKを向け直しました。
NNAK_GRP NAK_GRP of the corresponding re-directed NAK.
NNAK、_対応のGRP NAK_GRPはNAKを向け直しました。
3.6.4. Negative Acknowledgment Confirmations
3.6.4. 否定応答確認
3.6.4.1. NCFs - NAK confirmations
3.6.4.1. NCFs--NAK確認
NCFs are transmitted by network elements and sources in response to NAKs.
NCFsはNAKsに対応してネットワーク要素と情報筋によって伝えられます。
NCFs are multicast to the group and contain:
NCFsはグループへのマルチキャストであり、以下を含んでいます。
NCF_TSI NAK_TSI of the NAK being confirmed
NCF、_確認されるNAKのTSI NAK_TSI
NCF_SQN NAK_SQN of the NAK being confirmed
NCF、_確認されるNAKのSQN NAK_SQN
NCF_SRC NAK_SRC of the NAK being confirmed
NCF、_確認されるNAKのSRC NAK_SRC
NCF_GRP NAK_GRP of the NAK being confirmed
NCF、_確認されるNAKのGRP NAK_GRP
Speakman, et. al. Experimental [Page 17] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[17ページ]RFC3208PGM
3.6.5. Option Encodings
3.6.5. オプションEncodings
OPT_LENGTH 0x00 - Option's Length
_長さ0x00を選んでください--、オプションの長さ
OPT_FRAGMENT 0x01 - Fragmentation
選ぶ、_0×01--断片化を断片化してください。
OPT_NAK_LIST 0x02 - List of NAK entries
OPT_NAK_LIST0x02--NAKエントリーのリスト
OPT_JOIN 0x03 - Late Joining
選ぶ、_0×03--遅い接合を接合してください。
OPT_REDIRECT 0x07 - Redirect
_再直接の0×07を選んでください--、再直接
OPT_SYN 0x0D - Synchronization
_SYN 0x0Dを選んでください--、同期
OPT_FIN 0x0E - Session Fin receivers, conventional feedbackish
OPT_FIN 0x0E--セッションFin受信機、従来のfeedbackish
OPT_RST 0x0F - Session Reset
_RST 0x0Fを選んでください--、セッションリセット
OPT_PARITY_PRM 0x08 - Forward Error Correction Parameters
_同等_PRM0x08を選んでください--エラー修正パラメタを転送してください。
OPT_PARITY_GRP 0x09 - Forward Error Correction Group Number
_同等_GRP0x09を選んでください--エラー修正グループ番号を進めてください。
OPT_CURR_TGSIZE 0x0A - Forward Error Correction Group Size
_CURR_TGSIZE 0x0Aを選んでください--エラー修正グループサイズを進めてください。
OPT_CR 0x10 - Congestion Report
_CR0x10を選んでください--混雑は報告します。
OPT_CRQST 0x11 - Congestion Report Request
_CRQST0x11を選んでください--混雑は要求を報告します。
OPT_NAK_BO_IVL 0x04 - NAK Back-Off Interval
_NAK_棒_IVL0x04を選んでください--NAKは間隔を戻します。
OPT_NAK_BO_RNG 0x05 - NAK Back-Off Range
_NAK_棒_RNG0x05を選んでください--NAKは範囲を戻します。
OPT_NBR_UNREACH 0x0B - Neighbor Unreachable
_NBR_UNREACH 0x0Bを選んでください--隣人、手の届かなさ
OPT_PATH_NLA 0x0C - Path NLA
_経路_NLA 0x0Cを選んでください--、経路NLA
OPT_INVALID 0x7F - Option invalidated
OPT_INVALID 0x7F--無効にされたオプション
4. Procedures - General
4. 手順--一般
Since SPMs, NCFs, and RDATA must be treated conditionally by PGM network elements, they must be distinguished from other packets in the chosen multicast network protocol if PGM network elements are to extract them from the usual switching path.
PGMネットワーク要素で条件付きにSPMs、NCFs、およびRDATAを扱わなければならないので、PGMネットワーク要素が普通の切り換え経路からそれらを抽出することであるなら他のパケットと選ばれたマルチキャストネットワーク・プロトコルでそれらを区別しなければなりません。
Speakman, et. al. Experimental [Page 18] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[18ページ]RFC3208PGM
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のための要件はSPMs、NCFs、およびRDATA MUSTがIP Router Alert Option[6]と共に伝えられるということです。 このオプションはパケットが、より詳細な処理のために切り替わるIPから抽出されるべきであるというネットワーク層指示をネットワーク要素に与えます。
5. Procedures - Sources
5. 手順--ソース
5.1. Data Transmission
5.1. データ伝送
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ソースの最小のREQUIREDです。
5.1.1. Maximum Cumulative Transmit Rate
5.1.1. 最大累積する、レートを伝えてください。
A source MUST number ODATA packets in the order in which they are submitted for transmission by the application. A source MUST transmit ODATA packets in sequence and only within the transmit window beginning with TXW_TRAIL at no greater a rate than TXW_MAX_RTE.
ソースはそれらがトランスミッションのためにアプリケーションで提出されるオーダーにおける数のODATAパケットがそうしなければなりません。 情報筋がODATAパケットを連続してと中だけに伝えなければならない、TXW_TRAILと共にTXW_MAX_RTEほど大きくない速度で始まる窓を伝えてください。
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を定義するかもしれません。
5.1.2. Transmit Rate Regulation
5.1.2. レート規則を伝えてください。
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.
さらに、ソースはバウンドしなければなりません。連続したパケットが最大における汁気を切ったの水漏れするバケツ計画を使用することで伝えられるかもしれない最高率はレート、または同等なメカニズムを伝えます。
Speakman, et. al. Experimental [Page 19] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[19ページ]RFC3208PGM
5.1.3. Outgoing Packet Ordering
5.1.3. 外向的なパケット注文
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.
NCFsかどんなSPMsも未定でないときに、PGMの論理を保存するために、窓を伝えてください、そして、ソースは最初に、SPMs2番目まで未定のNCFsの発信を厳密に最優先させなければならなくて、単にODATAかRDATAを送ってください。 RDATA対ODATAの優先権はアプリケーションに依存しています。 送付者はRDATAとODATAを平等に割り当てる荷重している帯域幅を実行するかもしれません。 (例えば、OPT_JOINとの故joinersの一定の流れ)までいつもRDATAを持つためにNAKsを発生させ続ける受信機があればODATAの上のRDATAの厳しい優先順位づけがODATAの進歩を失速させるかもしれないことに注意してください。 RDATAの上でODATAを厳密に最優先させるのは復しない損失を得る受信機の、より大きい部分に通じるかもしれません。
5.1.4. Ambient SPMs
5.1.4. 周囲のSPMs
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ネットワーク要素で現在のソース経路州を少なくとも維持できるくらいのレートでSPMsを伝えなければなりません。 SPMが変えられた分配木を横断するまでネットワーク要素のソース経路州がソースから分配木における基本的な変化を追わないことに注意してください。 結果は基本的な分配木における変化が起こっている間NAKsが受信機においてネットワーク要素の中で未確認になるかもしれないということです。
5.1.5. Heartbeat SPMs
5.1.5. 鼓動SPMs
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.
送るデータ、SHOULDが伝えるソースがないとき、ロストデータの早期発見を促進して、PGMネットワーク要素で現在のソース経路州を維持して、電流を維持する腐食レートにおけるSPMsは受信機でウィンドウ状態を受けます。
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を初期化します。 連続した鼓動SPMsのトランスミッションはその都度、IHBを最大の間隔IHB_MAXまで倍にします。 どんなデータ・パケットのトランスミッションももう一度IHB_TMRをIHB_MINに初期化します。 効果はデータがないときなくなったパケットの迅速な検出が伝わるので最小量の帯域幅オーバーヘッドを処理することを引き起こすことです。
Speakman, et. al. Experimental [Page 20] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[20ページ]RFC3208PGM
5.1.6. Ambient and Heartbeat SPMs
5.1.6. 周囲と鼓動SPMs
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.
周囲と鼓動SPMsは、それらの対照機能を目立たせるようにこの仕様で別々のタイマによる駆動であると記述されています。 鼓動SPMsがデータでリセットしてください続ける下に数えタイマ、および一度それがどの変化を吐き出し始めるかに関する間隔のそばで運転されている間、周囲のSPMsは定期的に期限が切れる下に数えタイマによって運転されます。 鼓動タイマが相互データ・パケット間隔を測定している間、周囲の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.
データがあるとき、データの伝達がIHB_TMRを初期の値に遅らせ続けるので、鼓動がないSPMsは伝えられるでしょう。 しかしながら、同時に、当然のこととして周囲のSPMsをデータにはさみ込まなければなりません、必ずどんな鼓動メカニズムとしても、そうしません。 SPMsのこの周囲のトランスミッションはネットワークにおける分配木の情報を現在に保って、新しい受信機がセッションに連動するのを許容するREQUIREDです。
An implementation SHOULD de-couple ambient and heartbeat SPM timers sufficiently to permit them to be configured independently of each other.
互いの如何にかかわらず構成されて、SHOULDがそれらを可能にすることができるくらい周囲と鼓動SPMタイマの衝撃を吸収する実現。
5.2. Negative Acknowledgment Confirmation
5.2. 否定応答確認
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.
ソースがすぐにそうしなければならない、マルチキャスト、NCF、どんなNAKに対応して、それは受信されます。 同じサブネットの他のPGMネットワーク要素はRDATAがあるすぐに応じる代替手段でNAKに予期できないでしょう、したがって、NCFがREQUIREDです、そして、それは同じサブネットのDLRsが修理を提供するのを許容しないでしょう。 SHOULDがNAK嵐を検出できて、対策を採用するソースはサービスの否定に対してネットワークを保護します。 可能な対策は小さい間隔までに一層のNCFs(同じNAKsのための)の世代をすぐNAKと次に、遅れに対応した最初のNCFに送ることです、同じNCFsがレートによって限られるように、NAKsを抑圧する能力に影響しないで。
5.3. Repairs
5.3. 修理
After multicasting an NCF in response to a NAK, a source MUST then multicast RDATA (while respecting TXW_MAX_RTE) in response to any NAK it receives for data packets within the transmit window.
NAK、ソースに対応したNCFがそうしなければならないマルチキャスティングの後、どんなNAKに対応した次に、マルチキャストRDATA(TXW_MAX_RTEを尊敬している間)、データ・パケットのために中で受ける、窓を伝えてください。
In the interest of increasing the efficiency of a particular RDATA packet, a source MAY delay RDATA transmission to accommodate the arrival of NAKs from the whole loss neighborhood. This delay SHOULD not exceed twice the greatest propagation delay in the loss neighborhood.
特定のRDATAパケットの効率を増加させる利益のためでは、ソースは、全体の損失地域からのNAKsの到着を収容するためにRDATAトランスミッションを遅らせるかもしれません。 この遅れSHOULDは損失近所の最もすばらしい伝播遅延の2倍を超えていません。
Speakman, et. al. Experimental [Page 21] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[21ページ]RFC3208PGM
6. Procedures - Receivers
6. 手順--受信機
6.1. Data Reception
6.1. データ受信
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.
それが広告を出すことの中で受ける最初のデータ・パケットと共に始まる受信機SHOULD開始データレセプションは窓を伝えます。 このパケットの一連番号(ODATA_SQN)が一時トレーリングエッジを定義する、受信機の見解から窓を伝えてください。 すなわち、それは受信機の中にRXW_TRAIL_INITに割り当てられます、そして、その後のパケット(SPMs、ODATAまたはRDATA)の広告に掲載されたトレーリングエッジ一連番号が過去のRXW_TRAIL_INITを増加するまで、受信機はRXW_TRAIL_INITへのその後の一連番号のための修理を要求するだけでよいです。 その後中でどこでも修理を要求するかもしれない、窓を伝えてください。 修理要求のこの一時的な制限は、最初に与えられたPGM輸送セッションを受け始めると受信機が潜在的に多量の歴史を要求するのを防ぎます。
Note that the JOIN option, discussed later, MAY be used to provide a different value for RXW_TRAIL_INIT.
後で議論した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.
デフォルト運転モードとして、受信機は隣接のデータ・パケットだけをアプリケーションに果たさなければなりません、そして、それはそれらのデータ・パケットの一連番号によって定義されたオーダーでそうしなければなりません。 これは信頼できる規則正しいデータフローをアプリケーションに提供します。
Speakman, et. al. Experimental [Page 22] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[22ページ]RFC3208PGM
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受信機実現は任意に、データがアプリケーションに送られる運転モードを受注に提供するかもしれません。 しかしながら、実現はアプリケーションへのデータ単位(APDUs)を完全なアプリケーション・プロトコルに届けるだけでよいです。 配送の前にすなわち、異なったTPDUsに断片化されたAPDUsをアプリケーションに組み立て直さなければなりません。
6.2. Source Path Messages
6.2. ソース経路メッセージ
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のためにもSPMsを受けて、配列しなければなりません。彼らは受信しています。 一連番号が系列の最新のSPMのものと半分の中でPGM数のスペースより大きいなら、系列にはSPMがあります。 順序が狂ってSPMsを捨てなければなりません。
For each TSI, receivers MUST use the most recent SPM to determine the NLA of the upstream PGM network element for use in NAK addressing. A receiver MUST NOT initiate repair requests until it has received at least one SPM for the corresponding TSI.
各TSIに関しては、受信機は、NAKアドレシングにおける使用のために上流のPGMネットワーク要素のNLAを決定するのに最新のSPMを使用しなければなりません。 対応するTSIのために少なくとも1SPMを受けるまで、受信機は修理要求を開始してはいけません。
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.
データより遅いレートで彼らを進めるでしょう、そして、SPMsが1ホップあたりの処理を必要とするので、それらはデータ・ストリームと同期していなく到着しそうでしょう。 この場合、SPMsが運ぶという窓の情報は時代遅れになるでしょう。 受信機SHOULDが、これがそうであると予想して、SHOULDは受信機がリードのために格納した値とパケットリードと道の値を比べることによってそれを検出して、引きずります。 値がSPMパケットであるなら、より少なく、それらがSHOULDである、無視されてください、しかし、残り、パケットSHOULDでは、標準として処理されてください。
6.3. Data Recovery by Negative Acknowledgment
6.3. 否定応答によるデータ回復
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世代を開始するかもしれません。
Speakman, et. al. Experimental [Page 23] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[23ページ]RFC3208PGM
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.
すべての場合では、受信機SHOULDはネットワークによって導入された簡単な誤注文のために説明するNAK世代の創設を焼き戻します。 これを達成する可能なメカニズムは一連番号が(想定されます)無くなっているパケットのものより高い状態でNパケットのレセプションの後にだけ損失を仮定することです。 Nのための可能な値は2です。 この方法SHOULD、データ・ストリームのトランスミッションにおけるくぎりの前に最後のパケットの損失を扱うタイムアウトに基づいているメカニズムを補ってください。 リーディングエッジはSPMs SHOULDでも損失検出におけるアカウントに連れていかれたアルゴリズムをさばきます。
Generating NAKs
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
無作為の期間(NAK_RB_IVL)の間、合っているNCFsかNAKsの聞こうとしている間、待つこと。
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世代を再開するための期間(NAK_RDATA_IVL)は受け取られていません。
The entire generation process can be summarized by the following state machine:
以下の州のマシンは全体の発生経過をまとめることができます:
Speakman, et. al. Experimental [Page 24] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[24ページ]RFC3208PGM
| | 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
| | なくなったtpduを検出してください。| - 明確なデータ再試行カウント| - 明確なNCFは、NCFを合わせながら、カウントVを再試行します。|--------------------------| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| _状態を戻してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| タイマ(NAK_RB_IVL)を始動してください。| ^ ^ | | | | | | |--------------------------| | | | マッチング| | タイマは期限が切れます。| | | NAK| | - NAKを送ってください。| | | | | | | | V V| | | |--------------------------| | | | | _NCF_状態を待ってください。| | | | 合っているNCF| タイマ(NAK_RPT_IVL)を始動してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| |、-、-、-、-、-、-、-、-、-、-、--、>|、| |--------------------------| タイマは期限が切れます。| | | | ^ ―NCFを増加してください。| | NAK_NCF_再試行| | | 再試行カウント| | 超えられています。| | | | | V----------- | | Cancelationの合っているNAK| | - 再開タイマ(NAK_RPT_IVL)| | | | | V|--------------------------| | --------------->| _データ_状態を待ってください。|----------------------->| タイマ(NAK_RDATA_IVL)を始動してください。| タイマは期限が切れます。| | - 増分のデータ|--------------------------| 再試行カウント| | ^NAK_データ_は再試行されます。| | | 超えられています。| | | | ----------- | 合っているNCFかNAK V--再開タイマ(NAK_RDATA_IVL)キャンセル
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.
どんな状態でも、窓のトレーリングエッジが一連番号を超えたところまで動くなら、その一連番号のためのデータ回復は終わります。
Speakman, et. al. Experimental [Page 25] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[25ページ]RFC3208PGM
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のための値がOPT_NAK_BO_IVLから学んだ、(見る、16.4、.1、下) NAK_BO_IVL_SQNがゼロであるか受信機が一連番号スペースの半分の中でPOLL_SQNのための目にふれているPOLL_RND=0が<NAK_BO_IVL_SQNとの等しさにしない場合、受信機(すなわち、受信機MUST NOT NAK)によって使用されてはいけません。
When a parity NAK (Appendix A, FEC) is being generated, the back-off interval SHOULD be inversely biased with respect to the number of parity packets requested. This way NAKs requesting larger numbers of parity packets are likely to be sent first and thus suppress other NAKs. A NAK for a given transmission group suppresses another NAK for the same transmission group only if it is requesting an equal or larger number of parity packets.
同等であるときに、NAK(付録A、FEC)は発生しています、下に後部間隔SHOULD。パケットが要求した同等の数に関して逆に偏られてください。 このように、より多くのパリティパケットを要求するNAKsは最初に、送られて、その結果、他のNAKsを抑圧しそうです。 等しいか、より多くのパリティパケットを要求している場合にだけ、与えられたトランスミッショングループのためのNAKは同じトランスミッショングループのために別のNAKを抑圧します。
When a receiver has to transmit a sequence of NAKs, it SHOULD transmit the NAKs in order from oldest to most recent.
受信機がそうしなければならないとき、NAKsの系列を伝えてください、それ。SHOULDは最も古いのから最新になるまで整然とした状態でNAKsを伝えます。
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はNCF_TSIをNAK_TSIに合わせて、NAK_SQNと共に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
NAK_RB_IVLの満期に、受信機は輸送セッション識別子となくなった一連番号を指定するTSIのための上流のPGMネットワーク要素へのユニキャストa NAKがそうしなければなりません。 さらに、それはそうするかもしれません。
Speakman, et. al. Experimental [Page 26] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[26ページ]RFC3208PGM
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.
グループへの1のTTLとマルチキャストa NAK PGM親が直接接されないなら。 また、それは対応する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_RPT_IVLによってNAK_NCF_RETRIES回数まで決定されたレートでNAKを繰り返さなければなりません。 そして、NAK世代を再開する前に、それはNAK_RDATA_IVLを待たなければなりません。 NAK_RDATA_IVLの間、合っているNCFかNAKを聞くなら、NAK世代を再開する前に、それは新たにNAK_RDATA_IVLを待たなければなりません(すなわち、合っているNCFsとNAKsは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とマルチキャストNAKsを受けます。
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やNAKsも捨てなければならない、窓かそれが受けたデータ・パケットには、伝わってください。 さもなければ、それらは適宜現在の修理状態に扱われます。
7. Procedures - Network Elements
7. 手順--ネットワークElements
7.1. Source Path State
7.1. ソース経路州
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のためのマルチキャストルーティング情報でSource Path Address SPM_PATHを記録します。 受信ネットワーク要素が推進ネットワーク要素と同じサブネットにあると、このアドレスは分配木でTSIにすぐに上流のネットワーク要素のアドレスと同じになるでしょう。 しかしながら、非PGMネットワーク要素が推進と受信ネットワーク要素を仲裁すると、このアドレスは介入しているネットワーク要素の向こう側の最初のPGMネットワーク要素のアドレスになるでしょう。
Speakman, et. al. Experimental [Page 27] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[27ページ]RFC3208PGM
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で外向的なインタフェースのネットワーク・アドレスをコード化します。
7.2. NAK Confirmation
7.2. NAK確認
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 MUST、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のネットワークヘッダーソースアドレスをネットワーク要素のNLAではなく、ODATAソースの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嵐を検出して、対応策を採用できるはずです。 可能な対策は小さい間隔までに一層のNCFs(同じNAKsのための)の世代をすぐNAKと次に、遅れに対応した最初のNCFに送ることです、同じNCFsがレートによって限られるように、NAKsを抑圧する能力に影響しないで。
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が対応する修理インタフェースリストに受け取られたインタフェースを加えなければなりません。
7.3. Constrained NAK Forwarding
7.3. 強制的なNAK推進
The NAK forwarding procedures for network elements are quite similar to those for receivers, but three important differences should be noted.
受信機に、ネットワーク要素のために手順を進めるNAKはそれらと全く同様ですが、3つの重要な違いが注意されるべきです。
First, network elements do NOT back off before forwarding a NAK (i.e., there is no NAK_BO_IVL) since the resulting delay of the NAK would compound with each hop. Note that NAK arrivals will be randomized by the receivers from which they originate, and this factor in conjunction with NAK anticipation and elimination will combine to forestall NAK storms on subnets with a dense network element population.
まず最初に、ネットワーク要素は以前、NAKの結果として起こる遅れ以来のNAK(すなわち、NAK_BO_IVLが全くない)が各ホップで合成する推進を戻しません。 NAK到着がそれらが由来する受信機によってランダマイズされることに注意してください。そうすれば、NAK予期と除去に関連したこの要素は結合して、周密なネットワーク要素人口があるサブネットでNAK嵐を出し抜くでしょう。
Second, network elements do NOT retry confirmed NAKs if RDATA is not seen; they simply discard the repair state and rely on receivers to re-request the repair. This approach keeps the repair state in the network elements relatively ephemeral and responsive to underlying routing changes.
2番目に、RDATAが見られないなら、ネットワーク要素は確認されたNAKsを再試行しません。 彼らは、単に修理状態を捨てて、修理を再要求するために受信機を当てにします。 このアプローチは、基本的なルーティング変化に比較的はかなくて敏感なネットワーク要素に修理が状態であることを保ちます。
Speakman, et. al. Experimental [Page 28] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[28ページ]RFC3208PGM
Third, note that ODATA does NOT cancel NAK forwarding in network elements since it is switched by network elements without transport- layer intervention.
3番目に、それがネットワーク要素によって輸送層の介入なしで切り換えられるので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推進は、NAK(すなわち、NAK_TSIとNAK_SQNあたりの)を考えて、ネットワーク要素がいずれのためにも2回のタイムアウト間隔を観測するのを必要とします: NAK_RPT_IVLとNAK_RDATA_IVL。
The NAK repeat interval NAK_RPT_IVL, limits the length of time for which a network element will repeat a NAK while waiting for a corresponding NCF. NAK_RPT_IVL is counted down from the transmission of a NAK. Expiry of NAK_RPT_IVL cancels NAK forwarding (due to missing NCF).
NAKは間隔NAK_RPT_IVLを繰り返して、限界はネットワーク要素が対応するNCFを待っている間にNAKを繰り返す時間の長さです。 NAK_RPT_IVLはNAKのトランスミッションから数えられます。 NAK_RPT_IVLの満期はNAK推進(なくなったNCFによる)を中止します。
The NAK RDATA interval NAK_RDATA_IVL, limits the length of time for which a network element will wait for the corresponding RDATA. NAK_RDATA_IVL is counted down from the time a matching NCF is received. Expiry of NAK_RDATA_IVL causes the network element to discard the corresponding repair state (due to missing RDATA).
NAK RDATA間隔NAK_RDATA_IVL、aが要素をネットワークでつなぐ時間の長さがそうする限界、対応する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.
Network要素はTSIのために上流のPGMネットワーク要素だけにNAKsを送らなければなりません。
A network element MUST repeat a NAK at a rate of NAK_RPT_RTE for an interval of NAK_RPT_IVL until it receives a matching NCF. A matching NCF must match NCF_TSI with NAK_TSI, and NCF_SQN with NAK_SQN.
合っているNCFを受けるまで、ネットワーク要素はNAK_RPT_IVLの間隔の間、NAK_RPT_RTEのレートでNAKを繰り返さなければなりません。 合っているNCFはNCF_TSIをNAK_TSIに合わせて、NAK_SQNと共に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推進を中止して、対応する修理状態を取りこわします。
7.4. NAK elimination
7.4. 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を持っているなら、2NAKsが互いをコピーします。 ネットワーク要素は未定のNAKのすべての写しを捨てなければなりません。
Speakman, et. al. Experimental [Page 29] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[29ページ]RFC3208PGM
Once a NAK is outstanding, network elements MUST discard all duplicates of that NAK for NAK_ELIM_IVL. Upon expiry of NAK_ELIM_IVL, network elements MUST suspend NAK elimination for that TSI/SQN until the first duplicate of that NAK is seen after the expiry of NAK_ELIM_IVL. This duplicate MUST be forwarded in the usual manner. Once this duplicate NAK is outstanding, network elements MUST once again discard all duplicates of that NAK for NAK_ELIM_IVL, and so on. NAK_RDATA_IVL MUST be reset each time a NAK for the corresponding TSI/SQN is confirmed (i.e., each time NAK_ELIM_IVL is reset). NAK_ELIM_IVL MUST be some small fraction of NAK_RDATA_IVL.
NAKがいったん傑出するようになると、ネットワーク要素はNAK_ELIM_IVLのためにそのNAKのすべての写しを捨てなければなりません。 NAK_ELIM_IVLの満期に、そのNAKの最初の写しが満期の後にNAK_ELIM_IVLについて見られるまで、ネットワーク要素はそのTSI/SQNのためにNAK除去を中断させなければなりません。 常法でこの写しを転送しなければなりません。 この写しNAKがいったん傑出するようになると、ネットワーク要素はもう一度NAK_ELIM_IVLのためのそのNAKなどのすべての写しを捨てなければなりません。 NAK_RDATA_IVL MUST、対応するTSI/SQNのためのNAKが確認されるたびに(_IVLがリセットされるすなわち各回のNAK_ELIMのときに)リセットされてください。 NAK_ELIM_IVL MUSTはいくつかそうです。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は、修理州の活性に対して内部破裂防止のバランスをとるために行動します。 すべての除去をもたらしますが、最も1つでは、その結果繰り返されたNAKsにPGMで修理状態を生かさせるNAK_ELIM_IVLあたりのNAKは要素をネットワークでつなぎます。
7.5. NAK Anticipation
7.5. NAK予期
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
予期されたNAKsは川下からどんなその後の合っているNAKsの除去も可能にします。 予期された修理状態を設置すると、ネットワーク要素はしばらくだけ、NAK_ELIM_IVLについてその後のNAKsを排除しなければなりません。 NAK_ELIM_IVLの満期に、そのNAKの最初の写しが満期の後にNAK_ELIM_IVLについて見られるまで、ネットワーク要素はそのTSI/SQNのためにNAK除去を中断させなければなりません。 常法でこの写しを転送しなければなりません。 この写しNAKがいったん傑出するようになると、ネットワーク要素はもう一度NAK_ELIM_IVLのためのそのNAKなどのすべての写しを捨てなければなりません。 NAK_RDATA_IVL MUST、リセットされてください。
Speakman, et. al. Experimental [Page 30] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[30ページ]RFC3208PGM
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.
その都度、対応するTSI/SQNのためのNAKは確認されます(_IVLがリセットされるすなわち各回のNAK_ELIMのときに)。 NAK_ELIM_IVLはNAK_RDATA_IVLのあるわずかな部分であるに違いありません。
7.6. NAK Shedding
7.6. NAKの落ちること
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確認のためのローカルの手順を実行するかもしれません。 結局、これらの手順の結果は受信機の復しないデータの損失でしょう。
7.7. Addressing NAKs
7.7. NAKsを記述します。
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のための分配木に上流のインタフェースで対応TSI、面相が対応する上流のPGMネットワーク要素のアドレスを上げて、用途が(ユニキャスト)NAKを再記述するそれであり、ユニキャストがそれであるので状態を見つけるために輸送ヘッダーに含まれたソースとグループアドレス(NLAs)を使用します。
7.8. Constrained RDATA Forwarding
7.8. 強制的なRDATA推進
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の最新の例を進めるか、またはNAK_RDATA_IVLが次々と通るまでしか、ネットワーク要素はこの修理状態を維持してはいけません。 その後、対応する修理状態を捨てなければなりません。
Network elements SHOULD discard and not forward RDATA packets for which they have no repair state. Note that the consequence of this procedure is that, while it constrains repairs to the interested subset of the network, loss of repair state precipitates further NAKs from neglected receivers.
ネットワーク要素SHOULDは捨てて、それらには修理状態が全くないパケットをRDATAに送りません。 この手順の結果がネットワークの関心がある部分集合に修理を抑制しますが、修理状態の損失が無視された受信機から一層のNAKsを沈殿させるということであることに注意してください。
8. Packet Formats
8. パケット・フォーマット
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
このセクションで説明されたパケット・フォーマットのすべてがすぐにパケットでネットワーク層ヘッダーについて来なければならない輸送層のヘッダーです。 アプリケーションデータはパケットでデータパケットのヘッダーだけ(ODATAとRDATA)のあとに続くかもしれません。 アドレスが指定されるそれぞれのパケットタイプ、ネットワークヘッダーソース、および目的地に
Speakman, et. al. Experimental [Page 31] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[31ページ]RFC3208PGM
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.
トランスポート層ヘッダーの形式とコンテンツへの添加。 Procedures司令官から、また、SPMs、NCFs、およびRDATA MUSTがIPマルチキャストの上のPGMに関してIP Router Alert Optionを持っていると思い出してください。
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:
すべてのパケットでは、Data-ソースPort、Data-目的地Port、Type、Options、Checksum、Global Source ID(GSI)、およびTransport Service Data Unit(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.
ソースによって発生した無作為のポートナンバー。 このポートナンバーはソースの中でユニークであるに違いありません。 Global Source IDに伴うソースPortはTSIを形成します。
Data-Destination Port:
データ仕向港:
A globally well-known port number assigned to the given PGM application.
グローバルに、ウェルノウン・ポート番号はPGMアプリケーションを当然のことに割り当てました。
Type:
以下をタイプしてください。
The high-order two bits of the Type field encode a version number, 0x0 in this instance. The low-order nibble of the type field encodes the specific packet type. The intervening two bits (the low-order two bits of the high-order nibble) are reserved and MUST be zero.
Type分野の高位2ビットはこの場合バージョン番号、0×0をコード化します。 タイプ分野の下位の少量が特定のパケットタイプをコード化します。 介入している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),
範囲0×0から0x3の値はSPMのようなパケット(すなわち、ソースによって出典を明示されて、周期的なセッション詳細)を表します。
values in the range 0x4 through 0x7 represent DATA-like packets (i.e., data and repairs),
範囲0×4から0x7の値はDATAのようなパケット(すなわち、データと修理)を表します。
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).
そして、範囲の0xCから0xFの値はSPMRのようなパケット(すなわち、受信機で出典を明示されて、非同期なセッション詳細)を表します。
Speakman, et. al. Experimental [Page 32] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[32ページ]RFC3208PGM
Options:
オプション:
This field encodes binary indications of the presence and significance of any options. It also directly encodes some options.
この分野は存在の2進のしるしとどんなオプションの意味もコード化します。 また、それは直接いくつかのオプションをコード化します。
bit 0 set => One or more Option Extensions are present
ビット0が=>Oneを設定するか、または、より多くのOption Extensionsが存在しています。
bit 1 set => One or more Options are network-significant
ビット1が=>Oneを設定するか、または、より多くのOptionsがネットワーク重要です。
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セット=Packetは可変大きさで分けられたパケット(_OPT_バールPKTLEN)のトランスミッショングループのためのパリティパケットです。 また、OPT_PARITYも存在しているときだけ、提示します。
bit 7 set => Packet is a parity packet (OPT_PARITY)
>ビット7セット=Packetはパリティパケットです。(_同等を選びます)
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は輸送セッションの持続時間中で変化してはいけません。 RECOMMENDED識別子はソースのDNS名のMD5[9]署名の下位の48ビットです。 Data-ソースPortに伴うグローバルなSource IDはTSIを形成します。
Speakman, et. al. Experimental [Page 33] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[33ページ]RFC3208PGM
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パケットのヘッダー(_特定の_サイズをタイプする)のサイズとどんな存在するかもしれないオプションの長さです。
Address Family Indicators (AFIs) are as specified in [10].
アドレスFamily Indicators(AFIs)が[10]で指定されるようにあります。
8.1. Source Path Messages
8.1. ソース経路メッセージ
SPMs are sent by a source to establish source path state in network elements and to provide transmit window state to receivers.
SPMsはソース経路州をネットワーク要素に証明するためにソースによって送られます、そして、提供するのはウィンドウ状態を受信機に伝えます。
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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPMの一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トレーリングエッジ一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リーディングエッジ一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路NLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ | 存在しているときのオプションExtensions… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Speakman, et. al. Experimental [Page 34] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[34ページ]RFC3208PGM
Source Port:
ソースポート:
SPM_SPORT
SPM_スポーツ
Data-Source Port, together with SPM_GSI forms SPM_TSI
SPM_GSIフォームに伴うデータソースPort SPM_TSI
Destination Port:
仕向港:
SPM_DPORT
SPM_DPORT
Data-Destination Port
データ仕向港
Type:
以下をタイプしてください。
SPM_TYPE = 0x00
SPM_タイプ=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_道
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_リード
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であるなら、これは、どんな窓の情報もパケットに存在していないのを示します。
Speakman, et. al. Experimental [Page 35] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[35ページ]RFC3208PGM
Path NLA:
経路NLA:
SPM_PATH
SPM_経路
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に初期化されます。
8.2. Data Packets
8.2. データ・パケット
Data packets carry application data from a source or a repairer to receivers.
データ・パケットはソースか修理工から受信機までアプリケーションデータを運びます。
ODATA:
ODATA:
Original data packets transmitted by a source.
オリジナルのデータ・パケットはソースで伝わりました。
RDATA:
RDATA:
Repairs transmitted by a source or by a designated local repairer (DLR) in response to a NAK.
ソースか指定された地元の修理工(DLR)で修理はNAKに対応して伝わりました。
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 ... +-+-+- ...
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ・パケット一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トレーリングエッジ一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 存在しているときのオプションExtensions… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+- ...
Speakman, et. al. Experimental [Page 36] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[36ページ]RFC3208PGM
Source Port:
ソースポート:
OD_SPORT, RD_SPORT
過量_スポーツ、_第スポーツ
Data-Source Port, together with Global Source ID forms:
Global Source IDフォームに伴うデータソースPort:
OD_TSI, RD_TSI
_TSI、_第TSIを過量に与えてください。
Destination Port:
仕向港:
OD_DPORT, RD_DPORT
_DPORT、_第DPORTを過量に与えてください。
Data-Destination Port
データ仕向港
Type:
以下をタイプしてください。
OD_TYPE = 0x04 RD_TYPE = 0x05
過量_タイプは0×04番目の_タイプ=0x05と等しいです。
Global Source ID:
グローバルなソースID:
OD_GSI, RD_GSI
_GSI、_第GSIを過量に与えてください。
Together with Source Port forms:
Source Portフォームと共に:
OD_TSI, RD_TSI
_TSI、_第TSIを過量に与えてください。
Data Packet Sequence Number:
データ・パケット一連番号:
OD_SQN, RD_SQN
_SQN、_第SQNを過量に与えてください。
The sequence number originally assigned to the ODATA packet by the source.
元々ソースによってODATAパケットに割り当てられた一連番号。
Trailing Edge Sequence Number:
トレーリングエッジ一連番号:
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パケットの過量_TRAILと同じでないかもしれません。
Data:
データ:
Application data.
アプリケーションデータ。
Speakman, et. al. Experimental [Page 37] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[37ページ]RFC3208PGM
8.3. Negative Acknowledgments and Confirmations
8.3. 否定応答と確認
NAK:
NAK:
Negative Acknowledgments are sent by receivers to request the repair of an ODATA packet detected to be missing from the expected sequence.
受信機で否定的Acknowledgmentsを送って、予想された系列からなくなるように検出された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.
ヌルNegative Acknowledgmentsは、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のネットワークヘッダー送付先アドレスはNAK(受信機)の創始者によってSPMsから知られている上流のPGMネットワーク要素のユニキャストNLAに初期化されます。NAKのネットワークヘッダー送付先アドレスはこのNAKが送られる上流のPGMネットワーク要素のユニキャストNLAと共にそれぞれのPGMネットワーク要素によって書き直されます。 最終的なホップの上では、NAKのネットワークヘッダー送付先アドレスは一次資料のユニキャストNLAかDLRのユニキャストNLAと共にPGMネットワーク要素によって書き直されます。
NCF:
NCF:
NAK Confirmations are sent by network elements and sources to confirm the receipt of a NAK.
NAK Confirmationsは、NAKの領収書を確認するためにネットワーク要素とソースによって送られます。
The network-header source address of an NCF is the ODATA source's NLA, not the network element's NLA as might be expected.
NCFのネットワークヘッダーソースアドレスはネットワーク要素のNLAではなく、当然のことだがODATAソースのNLAです。
The network-header destination address of an NCF is a multicast group NLA.
NCFのネットワークヘッダー送付先アドレスはマルチキャストグループNLAです。
Note that in NAKs and N-NAKs, unlike the other packets, the field SPORT contains the Data-Destination port and the field DPORT contains the Data-Source port. As a general rule, the content of SPORT/DPORT is determined by the direction of the flow: in packets which travel down-stream SPORT is the port number chosen in the data source (Data-Source Port) and DPORT is the data destination port number (Data-Destination Port). The opposite holds for packets which travel upstream. This makes DPORT the protocol endpoint in the recipient host, regardless of the direction of the packet.
NAKsとN-NAKsでは、他のパケットと異なって、分野SPORTがData-仕向港を含んでいて、分野DPORTがData-ソースポートを含むことに注意してください。 概して、SPORT/DPORTの内容は流れの方向で決定します: 川下に移動するパケットでは、SPORTはデータ送信端末(データソースPort)で選ばれたポートナンバーです、そして、DPORTはデータ目的地ポートナンバー(データ目的地Port)です。 正反対はパケットのためにどの旅行上流を保持するか。 これはパケットの方向にかかわらず受取人ホストでDPORTをプロトコル終点にします。
Speakman, et. al. Experimental [Page 38] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[38ページ]RFC3208PGM
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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 要求された一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースNLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストグループNLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ | 存在しているときのオプションExtensions… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
Source Port:
ソースポート:
NAK_SPORT, NNAK_SPORT
NAK_スポーツ、NNAK_スポーツ
Data-Destination Port
データ仕向港
NCF_SPORT
NCF_スポーツ
Data-Source Port, together with Global Source ID forms NCF_TSI
Global Source IDフォームに伴うデータソースPort NCF_TSI
Destination Port:
仕向港:
NAK_DPORT, NNAK_DPORT
NAK_DPORT、NNAK_DPORT
Data-Source Port, together with Global Source ID forms:
Global Source IDフォームに伴うデータソースPort:
NAK_TSI, NNAK_TSI
NAK_TSI、NNAK_TSI
NCF_DPORT
NCF_DPORT
Data-Destination Port
データ仕向港
Speakman, et. al. Experimental [Page 39] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[39ページ]RFC3208PGM
Type:
以下をタイプしてください。
NAK_TYPE = 0x08 NNAK_TYPE = 0x09
0×08NNAK_タイプ=NAK_タイプ=0×09
NCF_TYPE = 0x0A
NCF_タイプは0x0Aと等しいです。
Global Source ID:
グローバルなソースID:
NAK_GSI, NNAK_GSI, NCF_GSI
NAK_GSI、NNAK_GSI、NCF_GSI
Together with Data-Source Port forms
Data-ソースPortフォームと共に
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を持っているかもしれません。
9. Options
9. オプション
PGM specifies several end-to-end options to address specific application requirements. PGM specifies options to support fragmentation, late joining, and redirection.
PGMは、特定のアプリケーションが要件であると扱うために終わりから終わりへのいくつかのオプションを指定します。 PGMは、断片化、遅い接合、およびリダイレクションをサポートするためにオプションを指定します。
Speakman, et. al. Experimental [Page 40] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[40ページ]RFC3208PGM
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スタイル、またはType、Length、Valueにあります。 Type分野はタイプの7ビットがビット0がOPT_ENDビットであるところに支えた最初のバイトに含まれています。 それがどれでもであるかもしれなくてもオプションリストにおける最後のオプションでOPT_ENDビットを設定しなければなりません。 Length分野は、バイトで表現されるオプションの全長であり、直接Type野原に続きます。 Length野原に続くのは、予約された5ビットと、OP_ENCODED旗と、2Option ExtensibilityビットOPXとOP_ENCODED_NULL旗です。 最後に、1オプションあたり1個のベースで定義されるかもしれないオプション特殊情報のために指定された7ビットがあります。 特定のオプションのために定義されないなら、0にそれらを設定しなければなりません。
The Option Extensibility bits dictate the desired treatment of an option if it is unknown to the network element processing it.
それを処理するネットワーク要素において、それが未知であるなら、Option Extensibilityビットはオプションの必要な処理を決めます。
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)の現在のいくつかのオプションが厳密にパケット含有量(PGMペイロード)(例であるOPT_FRAGMENT)に関連しています。 これらのオプションは保存されて、通常、それらを含むデータ・パケットがいつであるかさえ受信されなかったのにもかかわらずの、それがペイロードであるということであるに違いありません。FECの使用ですが、回復されます。 PGMは、オプションの一般的なヘッダーでF(OP_ENCODED)とU(OP_ENCODED_NULL)ビットを使用するこれを達成するためにメカニズムを指定します。 ゼロに設定されて、オプションがオリジナルのオプションを保存するのにFECパケットで使用されるとき、通常、OP_ENCODEDとOP_ENCODED_NULL MUSTはそうです。 詳細に関してAppendix Aを見てください。
There is a limit of 16 options per packet.
1パケットあたり16のオプションの限界があります。
Speakman, et. al. Experimental [Page 41] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[41ページ]RFC3208PGM
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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U|選んでください。 特定| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
9.1. Option extension length - OPT_LENGTH
9.1. オプション拡大の長さ--OPT_LENGTH
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.
さらに、Checksumが計算される前に標準のPGMヘッダーのOptions分野でオプションの存在をコード化しなければなりません。
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(0×80)は引きずっているオプション拡大のOption Type分野で用意ができなければなりません。
9.1.1. OPT_LENGTH - Packet Extension Format
9.1.1. _拡大がフォーマットする長さ--パケットを選んでください。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x00
オプションタイプ=0x00
Option Length = 4 octets
オプションLengthは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はネットワーク重要ではありません。
Speakman, et. al. Experimental [Page 42] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[42ページ]RFC3208PGM
9.2. Fragmentation Option - OPT_FRAGMENT
9.2. 断片化オプション--_断片を選んでください。
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)へのアプリケーション・プロトコルデータ単位(APDUs)にソースのトランスポート層実体が壊れます。 断片化オプションはODATAとRDATAパケットだけに適用されるかもしれません。
Architecturally, the accumulation of TSDUs into APDUs is applied to TPDUs that have already been received, duplicate eliminated, and contiguously sequenced by the receiver. Thus APDUs MAY be reassembled across increments of the transmit window.
建築上、APDUsへのTSDUsの蓄積は既に受け取られたTPDUsに適用されます、排除されて、近接して受信機によって配列された写し。その結果、APDUsが増分の向こう側に組み立て直されるかもしれない、窓を伝えてください。
9.2.1. OPT_FRAGMENT - Packet Extension Contents
9.2.1. _拡大が満足させる断片--パケットを選んでください。
OPT_FRAG_OFF the offset of the fragment from the beginning of the APDU
OPT_FRAG_OFFはAPDUの始まりからの断片のオフセットです。
OPT_FRAG_LEN the total length of the original APDU
OPT_FRAG_LENはオリジナルのAPDUの全長です。
9.2.2. OPT_FRAGMENT - Procedures - Sources
9.2.2. _断片--手順を選んでください--ソース
A source fragments APDUs into a contiguous series of fragments no larger than the MTU supported by the network layer. A source sequentially and uniquely assigns OD_SQNs to these fragments in the order in which they occur in the APDU. A source then sets OPT_FRAG_OFF to the value of the offset of the fragment in the original APDU (where the first byte of the APDU is at offset 0, and OPT_FRAG_OFF numbers the first byte in the fragment), and set OPT_FRAG_LEN to the value of the total length of the original APDU.
ソースはネットワーク層によって支持されたMTUほど大きくない断片の隣接のシリーズにAPDUsを断片化します。 ソースは連続して唯一それらがAPDUに起こるオーダーにおけるこれらの断片に過量_SQNsを割り当てます。 次に、ソースはオリジナルのAPDU(APDUの最初のバイトがオフセット0、およびOPT_FRAG_OFF番号において断片における最初のバイトであるところ)での断片のオフセットの値にOPT_FRAG_を始めます、そして、OPT_FRAG_LENをオリジナルのAPDUの全長の値に設定してください。
9.2.3. OPT_FRAGMENT - Procedures - Receivers
9.2.3. _断片--手順--受信機を選んでください。
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_を運んでいて始まって、長さが_FRAG_OFFがOPT_FRAG_LENであるとOPTに言い足した断片で終わります。
Speakman, et. al. Experimental [Page 43] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[43ページ]RFC3208PGM
9.2.4. OPT_FRAGMENT - Packet Extension Format
9.2.4. _拡大がフォーマットする断片--パケットを選んでください。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初の一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x01
オプションタイプ=0x01
Option Length = 12 octets
オプションLengthは12の八重奏と等しいです。
First Sequence Number
最初の一連番号
Sequence Number of the PGM DATA/RDATA packet containing the first fragment of the APDU.
APDUの最初の断片を含むPGM DATA/RDATAパケットの系列Number。
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はネットワーク重要ではありません。
9.3. NAK List Option - OPT_NAK_LIST
9.3. NAKリストオプション--_NAK_リストを選んでください。
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 Listオプションは、受信機が単一のNAKパケットで1つ以上の一連番号のためのトランスミッションを要求するのを許容するのにNAKsに関連して使用されるかもしれません。 オプションは62の記載されたNAKエントリーに制限されます。 NAKリストには、ユニーク、そして、写しがあってはいけません。 それは、注文しなければならなくて、選択することのリストかパリティNAKsのリストのどちらかから成らなければなりません。 一般に、まるで彼らがリストの各一連番号のために個々のNAKsを受けたかのようにネットワーク要素、ソース、および受信機はNAKリストを処理しなければなりません。 それぞれのための手順は先程詳細に本書では概説されます。 明確化と違いはここで詳細です。
Speakman, et. al. Experimental [Page 44] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[44ページ]RFC3208PGM
9.3.1. OPT_NAK_LIST - Packet Extensions Contents
9.3.1. _拡大が満足させるNAK_リスト--パケットを選んでください。
A list of sequence numbers for which retransmission is requested.
「再-トランスミッション」が要求されている一連番号のリスト。
9.3.2. OPT_NAK_LIST - Procedures - Receivers
9.3.2. _NAK_リスト--手順--受信機を選んでください。
Receivers MAY append the NAK List option to a NAK to indicate that they wish retransmission of a number of RDATA.
受信機は、彼らが多くのRDATAの「再-トランスミッション」を願っているのを示すためにNAK Listオプションを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.
受信機SHOULDはただ一つの一連番号NAKsのために概説されている手順と一致した方法で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 Listオプションを含むNCFかマルチキャストNAKのレセプションはNAKリストの中のすべての一連番号のためにNAKsの世代を中断させます、NAKヘッダーの中の一連番号と同様に。
9.3.3. OPT_NAK_LIST - Procedures - Network Elements
9.3.3. _NAK_リスト--手順を選んでください--ネットワークElements
Network elements MUST immediately respond to a NAK with an identical NCF containing the same NAK list as the NAK itself.
同じNCFがNAK自身と同じNAKリストを含んでいて、ネットワーク要素はすぐに、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 Listオプションを含む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によって指定されたあらゆる一連番号のためのデータを予期しなければなりません。
9.3.4. OPT_NAK_LIST - Procedures - Sources
9.3.4. _NAK_リスト--手順を選んでください--ソース
A source MUST immediately respond to a NAK with an identical NCF containing the same NAK list as the NAK itself.
同じNCFがNAK自身と同じNAKリストを含んでいて、情報筋はすぐに、NAKに応じなければなりません。
It MUST then multicast RDATA (while respecting TXW_MAX_RTE) for every requested sequence number.
それはあらゆる要求された一連番号のための次に、マルチキャストRDATA(TXW_MAX_RTEを尊敬している間)がそうしなければなりません。
Speakman, et. al. Experimental [Page 45] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[45ページ]RFC3208PGM
9.3.5. OPT_NAK_LIST - Packet Extension Format
9.3.5. _拡大がフォーマットする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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Sequence Number 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Sequence Number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 要求された一連番号1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 要求された一連番号N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x02
オプションタイプ=0x02
Option Length = 4 + (4 * number of SQNs) octets
オプションLengthは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はネットワーク重要です。
9.4. Late Joining Option - OPT_JOIN
9.4. 遅い接合オプション--_を選ぶのは接合します。
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.
このオプションは、進行中の輸送セッションに参加する受信機がそれらが輸送セッションに参加する時から与えられた最小の一連番号としての遠いとしてのすべてのデータの修理を要求するかもしれないのを示します。 デフォルトは受信機が単に彼らが受ける最初のパケットからデータを前方へ受け取ることです。
9.4.1. OPT_JOIN - Packet Extensions Contents
9.4.1. 選んでください。_接合してください--、パケット拡大コンテンツ
OPT_JOIN_MIN the minimum sequence number for repair
修理のための最小の一連番号のOPT_JOIN_MIN
9.4.2. OPT_JOIN - Procedures - Receivers
9.4.2. 選ぶ、_受信機を接合してください(手順)。
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.
受信機がトレーリングエッジを初期化するかもしれないa PGMパケット(ODATA、RDATA、またはSPM)クマOPT_JOIN、aである、正常なデータ受信で窓(RXW_TRAIL_INIT)を与えられたMinimum Sequence Numberと売り上げに受けてください。
Speakman, et. al. Experimental [Page 46] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[46ページ]RFC3208PGM
9.4.3. OPT_JOIN - Packet Extension Format
9.4.3. 選んでください。_接合してください--、パケット拡大形式
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Option Type | Option Length |Reserved |F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小の一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x03
オプションタイプ=0x03
Option Length = 8 octets
オプションLengthは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はネットワーク重要ではありません。
9.5. Redirect Option - OPT_REDIRECT
9.5. オプションを向け直してください--再直接で_を選んでください。
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 Network Elementはマルチキャスト分配木で上流か川下でそれから1つのPGMホップであるDLRを使用できます。 前者は上流のDLRsと呼ばれます。 後者はオフ木のDLRsと呼ばれます。 川下の損失のポイントのものですが、損失で影響を受ける下位木にないかもしれないので、Treeです。
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 MUSTはそれが「再-トランスミッション」を提供したがっているどんなPGMセッションも受けます。 DLR SHOULDは向け直しているPOLR応答パケットがそれ自身のネットワーク層アドレスを提供するOPT_REDIRECTを含んでいてPGM親によって出典を明示されたNCFsかPOLLsに応じます。 そして、POLRsを向け直す受取人はその後のODATA一連番号のために一次資料にというよりむしろDLRにNAKsを向けるかもしれません。 さらに、受信するDLRsが彼らがRDATA MUSTにまた、そのソースから修理を引き起こさないでフロー制御を一次資料に提供するためにNULL NAKを送らせるNAKsを向け直しました。
Speakman, et. al. Experimental [Page 47] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[47ページ]RFC3208PGM
9.5.1. OPT_REDIRECT - Packet Extensions Contents
9.5.1. 再直接で_を選んでください--、パケット拡大コンテンツ
OPT_REDIR_NLA the DLR's own unicast network-layer address to which recipients of the redirecting POLR MAY direct subsequent NAKs for the corresponding TSI.
OPT_REDIR_NLA DLRのものはPOLR MAYが対応するTSIのためのその後のNAKsを向け直すことのそれの受取人にあてるユニキャストネットワーク層アドレスを所有しています。
9.5.2. OPT_REDIRECT - Procedures - DLRs
9.5.2. _再直接(手順)のDLRsを選んでください。
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 MUSTはそれが修理の源を提供したがっているどんなPGMセッションも受けます。 次に、普通のPGM受信機、DLR MAYが親によって出典を明示されたNCFsか関連POLLsに応じるように行動することに加えて、OPT_REDIRECTを含むPOLRにそれ自身のネットワーク層アドレスを提供させることによって、要素(またはソース自体でさえ)をネットワークでつないでください。
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をはめ込むことによって、これを指示しなければなりません。
9.5.2.1. Upstream DLRs
9.5.2.1. 上流のDLRs
If the NCF completes NAK transmission initiated by the DLR itself, the DLR MUST NOT send a redirecting POLR.
NCFがDLR自身によって開始されたNAKトランスミッションを終了するなら、DLR MUST NOTは向け直す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.
aであるときに、DLRは上流のPGM親からNCFを受けます、それ。SHOULDは向け直すPOLR(グループへのマルチキャスト)を送ります。 前述のセッションのために上流のDLRとして機能しているというDLR SHOULD記録。 このPOLR MUSTがデータ送信端末のソースアドレスとルータの両方にネットワークヘッダーでオプションを警告させることに注意してください。
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.
どんなNAKにもそれを反応させることにおける普通のPGMソースとしての上流のDLR MUST条例は受信されます(すなわち、それに向けられます)。 それはそうであり、それはSHOULDです。最初に、正常なNCFと次に、通常通りのRDATAと共に応じてください。 さらに、受信する上流のDLRはRDATA MUSTがフロー制御を一次資料に提供するためにそれでNULL NAKを送るNAKsを向け直しました。 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.
背板嘆願: まさにODATAと同じ分配木の上で伝播するために、DLRsによって伝えられたRDATAとPOLRパケットはDLRのNLAではなく、ネットワークヘッダーソースアドレスとして当然のことだがODATAソースのNLAを持たなければなりません。
Speakman, et. al. Experimental [Page 48] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[48ページ]RFC3208PGM
9.5.2.2. Off-Tree DLRs
9.5.2.2. オフ木のDLRs
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.
適切なサービスを提供するならユニキャストがPOLRを向け直していてPOLL_DLR MUSTが反応させるサブタイプPGM_でPOLLを受けるDLR。 DLR SHOULDは、本稿のAppendix Dで世論調査のために概説された規則を使用することで応じます。 DLRは応じて、それは前述のセッションのためにオフ木のDLRとして機能しているというSHOULD記録です。
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を親にunicastingすることによって向けられたNAKに応じなければなりません。 そして、親は分配木の下側にRDATAを送るでしょう。 DLRはソースと目的地にネットワークヘッダーでそれぞれそれ自身と親のNLAアドレスを使用します。 ユニキャストNCFとRDATAパケットSHOULDはルータにオプションを警告させません。 RDATAヘッダーが“as if"であるべき他のすべての方法で、パケットはソースから来ました。
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.
一方、受信するオフ木のDLRはRDATA MUSTがフロー制御を一次資料に提供するためにそれでNULL NAKを溯源するNAKsを向け直しました。 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 SHOULDは正常で、当時としてのNCFがすぐに前述のデータ・パケットのためにNAKを送るユニキャストがあるNAKを親に確認して戻します。
9.5.2.3. Simultaneous Upstream and Off-Tree DLR operation
9.5.2.3. 同時のUpstreamとOff-木のDLR操作
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がNEと川下かその親とNAKのネットワークヘッダーソースアドレスをそれと比較することによってNAKsを区別するというメモは上流のPGM親のNLAです。 DLRはセッションのSPMメッセージから親のNLAを知っています。
Speakman, et. al. Experimental [Page 49] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[49ページ]RFC3208PGM
9.5.3. OPT_REDIRECT - Procedures - Network Elements
9.5.3. 再直接で_を選んでください--手順--Elementsをネットワークでつないでください。
9.5.3.1. Discovering DLRs
9.5.3.1. DLRsを発見します。
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を使用するSHOULD最初のトライであるか。 そのようなDLRが知られていない、それ、SHOULDはDLR発見を開始します。 DLR発見は2つの方法で起こるかもしれません。 DLRsが上流へあると、PGM親へのこのルータによって伝えられたNAKは彼らの発見の引き金となるでしょう、向け直すPOLRを通して。 ネットワーク要素SHOULD開始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をはめ込むことによって、これを指示するでしょう。 ネットワーク要素SHOULDは修理をFECに供給できるDLRにパリティNAKsを向けるだけです。
9.5.3.2. Redirected Repair
9.5.3.2. 向け直された修理
When it can, a network element SHOULD use upstream DLRs.
使用できるとき、ネットワーク要素SHOULDは上流の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を受けると、ネットワーク要素SHOULDはTSIのための向け直す情報を記録します、そして、SHOULDは同じTSIのためにSPMsを通して知られているPGM隣人にというよりむしろ向け直しているPOLRに提供されたネットワーク・アドレスにその後のNAKsを向け直します。しかしながら、そのNAKのトランスミッションを終了しないように向け直すPOLRがそれを引き起こした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).
その後のNAKsに関しては、ネットワーク要素が対応するTSIのためのリダイレクション情報を記録したなら、それは、それらのNAKsの目的地ネットワーク・アドレスを変えて、彼らをDLRに伝えるのを試みるかもしれません。 いいえ、NAK。特定のSQN SHOULDに関しては、DLRに関連しているインタフェースでSQNのためのNAKを見たなら、オフ木のDLRに送ってください。 代わりにNAK SHOULD、上流へ進めてください。 異なったSQNsのためのその後のNAKsを前述のDLRに送るかもしれません(インタフェースでDLRにおいて彼らのために再びNAKを全く仮定しないのを見てあります)。
If a corresponding NCF is not received from the DLR within NAK_RPT_IVL, the network element MUST discard the redirecting information for the TSI and re-attempt to forward the NAK towards the PGM upstream neighbor.
対応するNCFがNAK_RPT_IVLの中のDLRから受け取られないなら、ネットワーク要素は、PGMの上流の隣人に向かってNAKを送るためにTSIと再試みのための向け直す情報を捨てなければなりません。
Speakman, et. al. Experimental [Page 50] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[50ページ]RFC3208PGM
If a NAK is received from the DLR for a requested SQN, the network element MUST discard the redirecting information for the SQN and re- attempt to forward the NAK towards the PGM upstream neighbor. The network element MAY still direct NAKs for different SQNs to the DLR.
要求されたSQNのためにDLRからNAKを受け取るなら、ネットワーク要素は、PGMの上流の隣人に向かってNAKを送るためにSQNと再試みのための向け直す情報を捨てなければなりません。 ネットワーク要素は異なったSQNsのためにまだDLRにNAKsを向けているかもしれません。
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.
RDATAパケットのためのオフ木のDLRからのNULL NAKsは、そのオフ木のDLR MUSTからいつも上流へ進められるよう要求しました。 ネットワーク要素は、これらが合っているRDATAの前で到着すると仮定できます。 既に合っている修理状態を創設していない場合にだけ、他のNULL NAKsを進めます。 ネットワーク要素は、NULL NAKsを確認してはいけませんし、また再試行してはいけません、そして、彼らは受信インタフェースを修理状態に追加してはいけません。 初めは修理状態を創設するのにNULL NAKを使用すると、この事実を少しのその後の非NULL NAKも排除されないように記録しなければなりませんが、実際の修理を引き起こすためにむしろ転送するでしょう。 NULL NAKによって創設された状態はNAK_ELIM_IVLのためだけに存在しています。
9.5.4. OPT_REDIRECT - Procedures - Receivers
9.5.4. _再直接(手順)の受信機を選んでください。
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 Network Elementでない例でこれらの手順が適用されることを意図します。 それで、受信機は受信機が住んでいるのと同じIPサブネットでDLRから向け直すPOLRを無視しなければなりません、これが受信機への同じ損失を受けて、役に立たない傾向があるので。 したがって、これらの手順は完全にOPTIONALです。 逆の経路の最初のホップルータができる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を受けると、受信機SHOULDはTSIのための向け直す情報を記録します、そして、ネットワーク・アドレスへの同じTSIのための5月の再直接のその後のNAKsは受信機が修理を要求している対応するODATAのためにPGM隣人にというよりむしろ向け直しているPOLRに供給しました。 しかしながら、そのNAKのトランスミッションを終了しないように向け直すPOLRがそれを引き起こした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
その後のNAKsに関しては、受信機が対応するTSIのためのリダイレクション情報を記録したなら、それは彼らを伝えるそれらのNAKsと試みの目的地ネットワーク・アドレスを変えるかもしれません。
Speakman, et. al. Experimental [Page 51] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[51ページ]RFC3208PGM
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の中に受け取られないなら、受信機は、なくなったODATAの一次資料のためにPGM隣人にNAKを送るためにTSIと再試みのための向け直す情報を捨てなければなりません。
9.5.5. OPT_REDIRECT - Packet Extension Format
9.5.5. 再直接で_を選んでください--、パケット拡大形式
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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLRのNLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
Option Type = 0x07
オプションタイプ=0x07
Option Length = 4 + NLA length
オプション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.
DLRのものはPOLRがそうする向け直すことの受取人がその後のNAKsを向けるユニキャストネットワーク・アドレスを所有しています。
OPT_REDIRECT is network-significant.
OPT_REDIRECTはネットワーク重要です。
9.6. OPT_SYN - Synchronization Option
9.6. _SYNを選んでください--、同期オプション
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オプションは、流れのスタート通知を提供することによってアプリケーション設計を簡素化できるアプリケーションに役に立つ抽象化を提供するのに使用されるかもしれません。 また、故セッションまでのjoinerに本当に、遅いのを知らせるのにそれは使用されるかもしれません(すなわち、それはSYNオプションを見ないでしょう)。
9.6.1. OPT_SYN - Procedures - Receivers
9.6.1. _SYN--手順--受信機を選んでください。
Procedures for receivers are implementation dependent. A receiver MAY use the SYN to provide its applications with abstractions of the data stream.
受信機のための手順は実現に依存しています。 受信機は、データ・ストリームの抽象化をアプリケーションに提供するのにSYNを使用するかもしれません。
Speakman, et. al. Experimental [Page 52] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[52ページ]RFC3208PGM
9.6.2. OPT_SYN - Procedures - Sources
9.6.2. _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を持っている最初のパケットとして解釈されます。
9.6.3. OPT_SYN - Procedures - DLRs
9.6.3. _SYN--手順--DLRsを選んでください。
In an identical manner to sources, DLRs MUST provide OPT_SYN in any retransmitted data that is at the start of a session.
ソースへの同じ方法で、DLRsはセッションの始めにあるどんな再送されたデータにもOPT_SYNを提供しなければなりません。
9.6.4. OPT_SYN - Packet Extension Format
9.6.4. _SYNを選んでください--、パケット拡大形式
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Option Type | Option Length |Reserved |F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0D
オプションタイプは0x0Dと等しいです。
Option Length = 4
オプションの長さ=4
OPT_SYN is NOT network-significant.
OPT_SYNはネットワーク重要ではありません。
9.7. OPT_FIN - Session Finish Option
9.7. _フィンを選んでください--セッションはオプションを終えます。
This FIN option indicates the last data packet for a session and an orderly close down.
このFINオプションはセッションと規則的な近い下であるのに最後のデータ・パケットを示します。
The FIN option MAY be used to provide an abstraction to applications that can simplify application design by providing stream end notification.
FINオプションは、流れの終わりの通知を提供することによってアプリケーション設計を簡素化できるアプリケーションに抽象化を提供するのに使用されるかもしれません。
This option MAY be present in the last data packet or transmission group for a session. The FIN PGM option MUST appear in every SPM sent after the last ODATA for a session. The SPM_LEAD sequence number in an SPM with the FIN option indicates the last known data successfully transmitted for the session.
セッションの間、このオプションは最後のデータ・パケットかトランスミッショングループで存在しているかもしれません。 FIN PGMオプションは最後のODATAの後に送られたあらゆるSPMにセッションに関して現れなければなりません。 FINオプションがあるSPMのSPM_LEAD一連番号は、最後に知られているデータがセッションのために首尾よく送られたのを示します。
Speakman, et. al. Experimental [Page 53] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[53ページ]RFC3208PGM
9.7.1. OPT_FIN - Procedures - Receivers
9.7.1. _フィン--手順--受信機を選んでください。
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.
SHOULD使用が領収書を出させる適当な期間がいったん期限が切れると前述のセッションのためにデータ構造を取りこわすことができるのを知らせるFIN(TXW_SECS)の受信機。 それは伝えるかもしれません、それでも、存在の中で「再-トランスミッション」に請求するトライが窓を伝えます。
Other than this, procedures for receivers are implementation dependent. A receiver MAY use the FIN to provide its applications with abstractions of the data stream and to inform its applications that the session is ending.
これを除いて、受信機のための手順は実現に依存しています。 受信機は、データ・ストリームの抽象化をアプリケーションに提供して、セッションが終わっていることをアプリケーションに知らせるのにFINを使用するかもしれません。
9.7.2. OPT_FIN - Procedures - Sources
9.7.2. _フィン--手順を選んでください--ソース
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パケットは分類されます。 この場合、それはFINを持っている最後のパケットとして解釈されます。
When a source detects that it needs to send an OPT_FIN it SHOULD immediately send it. This is done either by appending it to the last data packet or transmission group or by immediately sending an SPM and resetting the SPM heartbeat timer (i.e. it does not wait for a timer to expire before sending the SPM). After sending an OPT_FIN, the session SHOULD not close and stop sending SPMs until after a time period equal to TXW_SECS.
ソースがそれを検出するとき、OPT_FINを送るのが必要である、それ、SHOULDはすぐに、それを送ります。 最後のデータ・パケットかトランスミッショングループにそれを追加するか、すぐにまでにSPMを送って、SPM鼓動タイマをリセットしながら、これをします(すなわち、それは、SPMを送る前にタイマが期限が切れるのを待っていません)。 セッションSHOULDは、TXW_SECSと等しい期間の後までOPT_FINをSPMsを送るのを、閉じて、次々と止めません。
9.7.3. OPT_FIN - Procedures - DLRs
9.7.3. _フィン--手順--DLRsを選んでください。
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を提供しなければなりません。
Speakman, et. al. Experimental [Page 54] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[54ページ]RFC3208PGM
9.7.4. OPT_FIN - Packet Extension Format
9.7.4. _拡大がフォーマットするフィン--パケットを選んでください。
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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0E
オプションタイプは0x0Eと等しいです。
Option Length = 4
オプションの長さ=4
OPT_FIN is NOT network-significant.
OPT_FINはネットワーク重要ではありません。
9.8. OPT_RST - Session Reset Option
9.8. _RSTを選んでください--セッションはオプションをリセットしました。
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で送られるように見えるかもしれません。 これは、セッションが中止されているように受信機に通知するために行動します。 このオプションはSPMsだけで見えるかもしれません。RSTオプションがあるSPMのSPM_LEAD一連番号は、最後に知られているデータがセッションのために首尾よく送られたのを示します。
9.8.1. OPT_RST - Procedures - Receivers
9.8.1. _RST--手順--受信機を選んでください。
Receivers SHOULD treat the reception of OPT_RST in an SPM as an abort of the session.
受信機SHOULDはセッションのアボートとして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.
OPT_RSTと共にSHOULDがソースに向かった前述のセッションのためにそれ以上のNAKsを送らないNビットのセットでSPMを受ける受信機。 どんなセット、5月が請求しトライに続けている受信機は電流の中でデータを再送しません。Nに噛み付いた、(見る、9.8、.5、)、窓を伝えてください。
9.8.2. OPT_RST - Procedures - Sources
9.8.2. _RST--手順--ソースを選んでください。
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.
ソースSHOULDは回復不能エラー状態が現れたことを決定した後に送られたあらゆるSPMにOPT_RSTを含んでいます。 Nに噛み付きました。OPT_RST SHOULDでは、ソースが、セッションのためにNAKsを処理できないと決心していたなら、単に送ってください。 OPT_RSTの原因は実現の特定の値に設定されます。 エラーコードが未知であるなら、0×00の値は使用されています。 ソースがそれを検出するとき、OPT_RSTを送るのが必要である、それ、SHOULDはすぐに、それを送ります。 すぐにまでにSPMを送って、SPM鼓動タイマをリセットしながら、これをします(すなわち、それは、SPMを送る前にタイマが期限が切れるのを待っていません)。 セッションSHOULDは、TXW_SECSと等しい期間の後までOPT_RSTをSPMsを送るのを、閉じて、次々と止めません。
Speakman, et. al. Experimental [Page 55] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[55ページ]RFC3208PGM
9.8.3. OPT_RST - Procedures - DLRs
9.8.3. _RST--手順--DLRsを選んでください。
None.
なし。
9.8.4. OPT_RST - Packet Extension Format
9.8.4. _RSTを選んでください--、パケット拡大形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U|N|エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
1にNビットが、前のODATAのためのNAKsがソースから答えがなくなるのを示すように設定されます。 アプリケーションは、このビットをつけたり消したりするようにソースに言うでしょう。
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.
0×00の値は未知のリセット理由を示します。 いかなる他の値も、アプリケーションがわざわざエンド受信側アプリケーションに意味を持っているかもしれない理由(誤りコード値)を中止して、あげたのを示します。 これらの値はアプリケーションに完全に依存しています。
OPT_RST is NOT network-significant.
OPT_RSTはネットワーク重要ではありません。
10. Security Considerations
10. セキュリティ問題
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は多くのそれがソース経路州を証明して、修理状態を証明して、NAKsを進めて、DLRsを特定して、修理を広げるのに使用するメカニズムに特定のセキュリティリスクに傷つきやすいです。 ネットワーク要素が切り替わるだけではなく、SPMs、NAKs、NCFs、およびRDATA(それのすべてがPGMソース、受信機、およびDLRsによって合法的に伝えられるかもしれない)を解釈もするので、これらのメカニズムはPGMネットワーク要素自体をセキュリティリスクに露出します。 すべての隣接しているソース、受信機、DLRs、およびネットワーク要素の完全な認証に不足していて、プロトコルは、乱用するために不浸透性ではありません。
Speakman, et. al. Experimental [Page 56] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[56ページ]RFC3208PGM
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帯域幅とメモリの両方の消耗によるサービスの否定を含んでいます、修理状態の混乱状態による(修理)データの接続性の損失と同様に。
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.
偽のSPMsは正統のソースに意図する誤ダイレクトなNAKsへのネットワーク要素をPGMに引き起こすかもしれません、その結果、要求されたRDATAが用意されていないでしょう。
False NAKs may cause PGM network elements to establish spurious repair state that will expire only upon time-out and could lead to memory exhaustion in the meantime.
偽のNAKsは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ネットワーク要素に、早まって(またはPOLRsを向け直す場合における誤ダイレクトなNAKsに)、結局RDATAの損失をもたらしながら、NAK推進を中断させるかもしれません。
False RDATA may cause PGM network elements to tear down legitimate repair state resulting eventually in loss of legitimate RDATA.
偽のRDATAは結局正統のRDATAの損失をもたらす正統の修理状態の下側までPGMネットワーク要素を引き裂かせるかもしれません。
The development of precautions for network elements to protect themselves against incidental or unsophisticated versions of these attacks is work outside of this spec and includes:
この仕様の外で働くことであり、ネットワーク要素がこれらの攻撃の付帯的であるか単純なバージョンに対して我が身をかばう注意の開発ことです。
Damping of jitter in the value of either the network-header source address of SPMs or the path NLA in SPMs. While the network-header source address is expected to change seldom, the path NLA is expected to change occasionally as a consequence of changes in underlying multicast routing information.
ネットワークヘッダーの値におけるジターがしっとりとして、SPMsにSPMsか経路NLAのアドレスの出典を明示してください。ネットワークヘッダーソースアドレスがめったに変化しないと予想されますが、経路NLAが基本的なマルチキャストルーティング情報における変化の結果として時折変化すると予想されます。
The extension of NAK shedding procedures to control the volume, not just the rate, of confirmed NAKs. In either case, these procedures assist network elements in surviving NAK attacks at the expense of maintaining service. More efficiently, network elements may use the knowledge of TSIs and their associated transmit windows gleaned from SPMs to control the proliferation of repair state.
レートだけではなく、ボリュームを制御するNAK落ちる手順の拡大はNAKsを確認しました。 どちらの場合ではも、サービスを維持することを犠牲にしてこれらの手順は生き残っているNAK攻撃にネットワーク要素を助けます。 そして、 より効率的に、ネットワーク要素がTSIsに関する知識を使用するかもしれない、彼ら、関連づけられて、修理状態の増殖を制御するためにSPMsから収集された窓を伝えてください。
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方向ハンドシェイク。
Speakman, et. al. Experimental [Page 57] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[57ページ]RFC3208PGM
11. Appendix A - Forward Error Correction
11. 付録A--前進型誤信号訂正
11.1. Introduction
11.1. 序論
The following procedures incorporate packet-level Reed Solomon Erasure correcting techniques as described in [11] and [12] into PGM. This approach to Forward Error Correction (FEC) is based upon the computation of h parity packets from k data packets for a total of n packets such that a receiver can reconstruct the k data packets out of any k of the n packets. The original k data packets are referred to as the Transmission Group, and the total n packets as the FEC Block.
以下の手順は[11]と[12]でPGMに説明されるようにテクニックを修正するパケット・レベルリードソロモンErasureを組み込みます。 Forward Error Correction(FEC)へのこのアプローチは、受信機がnパケットのどんなkでもkデータ・パケットを再建できるように、合計nパケットのためのkデータ・パケットからhパリティパケットの計算に基づいています。 オリジナルのkデータ・パケットはFEC BlockとしてTransmission Group、および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.
これらの手順は従来のARQ(選択している「再-トランスミッション」)と共に層にされたか統合しているFECのどんな風味も提供する与えられたTSIの中で先を見越すFECかオンのどんな組み合わせようにも要求FECを可能にします。 同じであるか異なった受信機はただ一つの輸送セッションのときに闘争なしで2つのアプローチを使用できます。 ソースによっていったん提供されると、完全に受信機の裁量にはFECか選択している「再-トランスミッション」のセッションにおける損失回復の実際の使用があります。 しかしながら、受信機SHOULD NOTが、選択している「再-トランスミッション」のためにFECがいつ利用可能であるかを尋ねて、それにもかかわらず、ソースが主な部分的なトランスミッショングループ(すなわち、まだ完全でない最新のトランスミッショングループ)からの選択しているNAKsに対応して選択している「再-トランスミッション」を前提としなければならないことに注意してください。 どんな完全なグループのためにも、ソースSHOULDは選択している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は損失回復をシンプレクスの上に供給するためのRECOMMENDEDか修理要求を返すのが不可能であるか、または高価である非対称のマルチキャストチャンネルです。 それは帯域幅を犠牲にして増加する信頼性を提供します。
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は、失われているどんな単一のパケットの確率もかなりなものである非常に大きい受信機人口における非相関の損失の損失回復を供給するためのRECOMMENDEDです。 それは帯域幅のもうと通常少ない費用で選択しているNAKs(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
選択しているNAKsは予想された系列(従来のARQ)からなくなるように検出されたどんなデータ・パケットの一連番号にも対応する一連番号に従って特定のパケットの「再-トランスミッション」を要求するNAKsです。 損失を取り戻すのに選択しているNAKsを使用できます。
Speakman, et. al. Experimental [Page 58] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[58ページ]RFC3208PGM
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).
すなわち、主な部分的なトランスミッショングループ、最新のトランスミッショングループでは、起こります。(それは、まだ完全ではありません)。 しかしながら、部分的なトランスミッショングループを扱うRECOMMENDED方法はデータ送信端末が可変サイズトランスミッショングループを使用する(以下を見てください)ことです。
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).
パリティNAKsはkデータ・パケット(要求次第のFEC)のグループからなくなるように検出されたデータ・パケットの数のカウントに対応するカウントによる特定の数のパリティパケットのトランスミッションを要求するNAKsです。
The objective of these procedures is to incorporate these FEC techniques into PGM so that:
これらの手順の目的がしたがって、これらのFECのテクニックをPGMに組み入れることである、それ:
sources MAY provide parity packets either pro-actively or on- demand, interchangeably within the same TSI,
ソースが親活発にパリティパケットを提供するかもしれない、オンである、同じTSIの中で互換性を持って要求します。
receivers MAY use either selective or parity NAKs interchangeably within the same TSI (however, in a session where on-demand parity is available receivers SHOULD only use parity NAKs).
受信機は同じTSIの中で選択するかパリティNAKsを互換性を持って使用するかもしれません(しかしながら、要求次第の同等が利用可能であるセッションのときに、受信機SHOULDはパリティNAKsを使用するだけです)。
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,
ネットワーク要素は選択に基づいた修理状態か同じデータ構造におけるパリティNAKsを維持します、どちらかのアルゴリズムがケースに入れる検索、RDATA規制、および削除だけを変更して
and only OPTION additions to the basic packet formats are REQUIRED.
そして、基本的なパケット・フォーマットへの唯一のOPTION追加はREQUIREDです。
11.2. Overview
11.2. 概観
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)の数などのセッション特有のパラメタを提供するためにOPT_PARITY_PRMをSPMsに加えます。 このオプションは、トランスミッショングループにはいくつのパケットがあるかを受信機に知らせます、そして、それで、ネットワーク要素はトランスミッショングループ番号で修理状態を分類します。 このオプションは先を見越すそして/または、要求次第の同等がソースから利用可能であるかどうかしるしを含んでいます。
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.
ソースはRDATAとしてODATA(修理状態が存在していない場合、NEsはRDATAを進めない)としての先を見越すパリティパケットと要求次第のパリティパケットを送ります。 情報筋は、ネットワーク要素と受信機がデータ・パケットとそれらを区別することを許可するためにパリティパケットのODATA/RDATAパケットのヘッダーにOPT_PARITYを加えなければなりません。
Speakman, et. al. Experimental [Page 59] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[59ページ]RFC3208PGM
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.
Transmission Groupとして知られているデータ・パケットの定数kに関してパリティパケットについて計算しなければなりません。 事実上、トランスミッショングループへのパケットの組分けは、トランスミッショングループ(TG)、およびそのグループの中でパケット番号(k-1を通した範囲0のPKT-NUM)を指定する下位の部分(PKT_SQN)を指定しながら、高位部分(TG_SQN)にパケット一連番号を仕切ります。 実現観点から、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と共にマークされたパリティパケットが、hパリティパケットに付番するために系列スペース(PKT_SQN)が完全に再利用されるのを許容するので、このマッピングは有効な一連番号スペースを減少させません、hがkほどすばらしくない限り。
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、情報筋がOPT_を加えなければならないよりすばらしい場合では、どんなパリティパケットへのPARITY_GRPもk-1よりすばらしいjに付番しました、mがただkによるjの整数分割からの商であるパケットが属するkパリティパケットのグループの数のmを指定して。 そのようなパリティパケットのためのPKT-NUMは対応する、ただj法kです。 言い換えれば、ソースが、オリジナルのデータ・パケットがあったより(恐らくaのために、特に損失性が立ち並んでいるので、受信機はオリジナルのデータだけではなく、また、いくらかのパリティ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.
また、パリティNAKs(そして、その結果彼らの対応するパリティNCFs)が固定ヘッダーのオプション分野にOPT_PARITY旗を保管しなければならなくて、これらのパケットでは、PKT_SQN MUSTが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.
SPMsにOPT_PARITY_PRMオプションの広告に掲載されたトランスミッショングループサイズはセッションの持続時間のための2と定数のパワーであるに違いありません。 しかしながら、サイズが使用した実際のトランスミッショングループは、セッションの持続時間には一定でないかもしれなく、また2のパワーでないかもしれません。 _ものと異なったTGサイズがOPTに広告を出したとき、PARITY_PRMは使用されています、OPT_PARITY_PRM MUSTの広告に掲載されたTGサイズ。TGの最大の有効なサイズを指定しながら、解釈されてください。
Speakman, et. al. Experimental [Page 60] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[60ページ]RFC3208PGM
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を追加します。 これで、受信機はこのトランスミッショングループでそれ以上のパケットを予想するべきでなくて、どんななくなったパケットのための修理も要求するのを出発するかもしれないのを知っています。 最後のデータ・パケット自体が雲隠れしたなら、受信機はそれがグループのためにパリティパケットを受けるグループの終わりを検出するでしょう、_最後のデータ・パケットのSQN、または次のグループの最初のパケットを過量に与えるために等しいSPM_LEADとSPM、どれが一番になっても。 また、さらに、このTGからのどんなパリティパケットも_最後のデータ・パケットのSQNを過量に与えるために等しいSPM_LEADと共に送られたどんなSPMのようにもOPT_CURR_TGSIZEオプションを運ぶでしょう。
Variable TSDU length
可変TSDUの長さ
If a non constant TSDU length is used within a given transmission group, the size of parity packets in the corresponding FEC block MUST be equal to the size of the largest original data packet in the block. Parity packets MUST be computed by padding the original packets with zeros up to the size of the largest data packet. Note that original data packets are transmitted without padding.
非一定のTSDUの長さが与えられたトランスミッショングループの中で使用されるなら、対応するFECブロックのパリティパケットのサイズはブロックの最も大きいオリジナルのデータ・パケットのサイズと等しいに違いありません。 最も大きいデータ・パケットのサイズまでのゼロでオリジナルのパケットを水増しすることによって、パリティパケットを計算しなければなりません。 オリジナルのデータ・パケットが詰め物なしで伝えられることに注意してください。
Receivers using a combination of original packets and FEC packets to rebuild missing packets MUST pad the original packets in the same way as the source does. The receiver MUST then feed the padded original packets plus the parity packets to the FEC decoder. The decoder produces the original packets padded with zeros up to the size of the largest original packet in the group. In order for the receiver to eliminate the padding on the reconstructed data packets, the original size of the packet MUST be known, and this is accomplished as follows:
同様に、なくなったパケットを再建するのにオリジナルのパケットとFECパケットの組み合わせを使用する受信機はソースがそっと歩くようにオリジナルのパケットを水増ししなければなりません。 そして、受信機はそっと歩いているオリジナルのパケットとパリティパケットをFECデコーダへ供給しなければなりません。 デコーダはグループにおける、最も大きいオリジナルのパケットのサイズまでのゼロで水増しされたオリジナルのパケットを作り出します。 受信機が再建されたデータ・パケットの上で詰め物を排除するように、パケットの原寸を知っていなければなりません、そして、これは以下の通り達成されます:
The source, along with the packet payloads, encodes the TSDU length and appends the 2-byte encoded length to the padded FEC packets.
ソースは、パケットペイロードと共にTSDUの長さをコード化して、2バイトのコード化された長さをそっと歩いているFECパケットに追加します。
Receivers pad the original packets that they received to the largest original packet size and then append the TSDU length to the padded packets. They then pass them and the FEC packets to the FEC decoder.
受信機は、彼らが最も大きい元のパケットサイズに受けたオリジナルのパケットを水増しして、次に、TSDUの長さをそっと歩いているパケットに追加します。 そして、彼らはそれらとFECパケットをFECデコーダに通過します。
Speakman, et. al. Experimental [Page 61] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[61ページ]RFC3208PGM
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)の現在のいくつかのオプションが厳密にパケット含有量(PGMペイロード)(例であるOPT_FRAGMENT)に関連しています。 これらのオプションは保存されて、通常、それらを含むデータ・パケットがいつであるかさえ受信されなかったのにもかかわらずの、それがペイロードであるということであるに違いありません。FECの使用ですが、回復されます。
To achieve this, PGM encodes the content of these options in special options that are inserted in parity packets. Two flags present in the the option common-header are used for this process: bit F (OP_ENCODED) and bit U (OP_ENCODED_NULL).
これを達成するために、PGMはパリティパケットに挿入される特別なオプションにおけるこれらのオプションの内容をコード化します。 オプションの一般的なヘッダーの現在の2個の旗がこの過程に使用されます: ビットF(OP_ENCODED)とビットU(OP_ENCODED_NULL)。
Whenever at least one of the original packets of a TG contains a payload-specific option of a given type, the source MUST include an encoded version of that option type in all the parity packets it transmits. The encoded option is computed by applying FEC encoding to the whole option with the exception of the first three bytes of the option common-header (E, Option Type, Option Length, OP_ENCODED and OPX fields). The type, length and OPX of the encoded option are the same as the type, length and OPX in the original options. OP_ENCODED is set to 1 (all original option have OP_ENCODED = 0).
少なくともTGのオリジナルのパケットの1つが与えられたタイプのペイロード特有のオプションを含んでいるときはいつも、ソースはそれが伝えるすべてのパリティパケットでそのオプションタイプのコード化されたバージョンを入れなければなりません。 コード化されたオプションは、オプションの一般的なヘッダー(E、Option Type、Option Length、OP_ENCODED、およびOPX分野)の最初の3バイトを除いて、全体のオプションへのFECコード化を適用することによって、計算されます。 コード化されたオプションのタイプ、長さ、およびOPXはオリジナルのオプションでタイプ、長さ、およびOPXと同じです。 OP_ENCODEDは1に用意ができています(すべてのオリジナルのオプションには、OP_ENCODED=0があります)。
The encoding is performed using the same process that is used to compute the payload of the parity packet. i.e. the FEC encoder is fed with one copy of that option type for each original packet in the TG. If one (or more) original packet of the TG does not contain that option type, an all zeroes option is used for the encoding process. To be able to distinguish this "dummy" option from valid options with all-zeroes payload, OP_ENCODED_NULL is used. OP_ENCODED_NULL is set to 0 in all the original options, but the value of 1 is used in the encoding process if the option did not exist in the original packet. On the receiver side, all option with OP_ENCODED_NULL equal to 1 are discarded after decoding.
パリティパケットのペイロードを計算するのに使用されるのと同じ過程を使用することでコード化を実行します。TGのそれぞれのオリジナルのパケットのためにそのオプションタイプのコピー1部ですなわち、FECエンコーダを与えます。 TGの1つ(さらに)のオリジナルのパケットがそのオプションを含まないならタイプしてください、すべてのゼロがゆだねる、コード化の過程には、使用されます。 _オールゼロペイロード、OP_ENCODEDとの妥当な選択肢とこの「ダミー」のオプションを区別できるように、NULLは使用されています。 OP_ENCODED_NULLはすべてのオリジナルのオプションで0に用意ができていますが、オプションがオリジナルのパケットに存在しなかったなら、1の値はコード化の過程で使用されます。 受信機側では、解読していた後にNULLが1と等しいOP_ENCODED_とのすべてのオプションが捨てられます。
Speakman, et. al. Experimental [Page 62] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[62ページ]RFC3208PGM
When a receiver recovers a missing packet using FEC repair packets, it MUST also recover payload-specific options, if any. The presence of these can be unequivocally detected through the presence of encoded options in parity packets (encoded options have OP_ENCODED set to 1). Receivers apply FEC-recovery to encoded options and possibly original options, as they do to recover packet payloads. The FEC decoding is applied to the whole option with the exception of the first three bytes of the option common-header (E, Option Type, Option Length, OP_ENCODED and OPX fields). Each decoded option is associated with the relative payload, unless OP_ENCODED_NULL turns out to be 1, in which case the decoded option is discarded.
また、受信機がFEC修理パケットを使用することでなくなったパケットを回復すると、それはもしあればペイロード特有のオプションを回復しなければなりません。 明確にパリティパケットでのコード化されたオプションの存在を通してこれらの存在を検出できます(コード化されたオプションで、OP_ENCODEDを1に用意ができさせます)。 受信機はパケットペイロードを回収するためにするようにコード化されたオプションとことによるとオリジナルのオプションにFEC-回復を適用します。 オプションの一般的なヘッダー(E、Option Type、Option Length、OP_ENCODED、およびOPX分野)の最初の3バイトを除いて、FEC解読は全体のオプションに適用されます。 それぞれの解読されたオプションが相対的なペイロードに関連している、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つ以上のオリジナルのパケットがそのオプションタイプを含んでいないなら、同じくらいのオプションを使用しなければなりませんゼロがあるタイプが、評価する。 このオプションはNULLが1と等しいOP_ENCODED_を持たなければなりません。
11.3. Packet Contents
11.3. パケットコンテンツ
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.
このセクションはただProceduresを明瞭にすることができるくらいの速記を提供します。 パケットコンテンツの一部始終について、以下のPacket Formatsを参照してください。
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_バールPKTLEN MAY、対応するトランスミッショングループが可変サイズデータ・パケットで構成されるのを示す先を見越す(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
PRMが先を見越す、そして/または、オンのトランスミッショングループサイズや有用性などのセッションの特定のパラメタを指定するためにソースでSPMsに追加したOPT_PARITY_はソースから同等を要求します。
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以上)の数です。
Speakman, et. al. Experimental [Page 63] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[63ページ]RFC3208PGM
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
TGSIZEがソースで変数で最後のデータ・パケットとどんなパリティパケットにも追加したOPT_CURR_は、トランスミッショングループの実サイズを受信機に示すためにトランスミッショングループを大きさで分けました。 また、あるSPMsに追加するかもしれません。
11.3.1. Parity NAKs
11.3.1. パリティNAKs
NAK_TG_SQN the high-order portion of NAK_SQN specifying the transmission group for which parity packets are requested
NAK_TG_SQNはパリティパケットが要求されているトランスミッショングループを指定するNAK_SQNの高位一部です。
NAK_PKT_CNT the low-order portion of NAK_SQN specifying the number of missing data packets for which parity packets are requested
NAK_PKT_CNTはパリティパケットが要求されている欠測値パケットの数を指定するNAK_SQNの下位の一部です。
Nota Bene: NAK_PKT_CNT (and NCF_PKT_CNT) are 0-based counters, meaning that NAK_PKT_CNT = 0 means that 1 FEC RDATA is being requested, and in general NAK_PKT_CNT = k - 1 means that k FEC RDATA are being requested.
背板嘆願: NAK_PKT_CNT(そして、NCF_PKT_CNT)は0ベースのカウンタです、NAK_PKT_CNT=0が、1FEC RDATAが要求されていて、一般に、NAK_PKT_CNTがkと等しいことを意味することを意味して--1は、k FEC RDATAが要求されていることを意味します。
11.3.2. Parity NCFs
11.3.2. パリティNCFs
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)は0ベースのカウンタです、NAK_PKT_CNT=0が、1FEC RDATAが要求されていて、一般に、NAK_PKT_CNTがkと等しいことを意味することを意味して--1は、k FEC RDATAが要求されていることを意味します。
11.3.3. On-demand Parity
11.3.3. 要求次第の同等
RDATA_TG_SQN the high-order portion of RDATA_SQN specifying the transmission group to which the parity packet belongs
RDATA_TG_SQNはパリティパケットが属するトランスミッショングループを指定するRDATA_SQNの高位一部です。
RDATA_PKT_SQN the low-order portion of RDATA_SQN specifying the parity packet sequence number within the transmission group
RDATA_PKT_SQNはトランスミッショングループの中でパリティパケット一連番号を指定するRDATA_SQNの下位の一部です。
Speakman, et. al. Experimental [Page 64] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[64ページ]RFC3208PGM
11.3.4. Pro-active Parity
11.3.4. 先を見越す同等
ODATA_TG_SQN the high-order portion of ODATA_SQN specifying the transmission group to which the parity packet belongs
ODATA_TG_SQNはパリティパケットが属するトランスミッショングループを指定するODATA_SQNの高位一部です。
ODATA_PKT_SQN the low-order portion of ODATA_SQN specifying the parity packet sequence number within the transmission group
ODATA_PKT_SQNはトランスミッショングループの中でパリティパケット一連番号を指定するODATA_SQNの下位の一部です。
11.4. Procedures - Sources
11.4. 手順--ソース
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.
ソースが、与えられた輸送セッションのために同等を提供するのを選ぶなら、それは最初に、トランスミッショングループサイズPARITY_PRM_TGSをSPMsのOPT_PARITY_PRMオプションに提供しなければなりません。ソースが、より小さいサイズトランスミッショングループを送るのを選ぶ場合、これは最大の有効なトランスミッショングループサイズになります。 ソースが、与えられた輸送セッションのために先を見越す同等を提供するのを選ぶなら、それはSPMsのOPT_PARITY_PRMオプションにPARITY_PRM_PROをはめ込まなければなりません。ソースが、与えられた輸送セッションのために要求次第の同等を提供するのを選ぶなら、SPMsのOPT_PARITY_PRMオプションにPARITY_PRM_ONDをはめ込まなければなりません。
A source MUST send any pro-active parity packets for a given transmission group only after it has first sent all of the corresponding k data packets in that group. Pro-active parity packets MUST be sent as ODATA with OPT_PARITY in the fixed header.
最初にそのグループで対応するkデータ・パケットのすべてを送った後にだけソースは与えられたトランスミッショングループのためにどんな先を見越すパリティパケットも送らなければなりません。 固定ヘッダーのOPT_PARITYと共にODATAとして先を見越すパリティパケットを送らなければなりません。
If a source elects to provide on-demand parity, it MUST respond to a parity NAK for a transmission group with a parity NCF. The source MUST complete the transmission of the k original data packets and the proactive parity packets, possibly scheduled, before starting the transmission of on-demand parity packets. Subsequently, the source MUST send the number of parity packets requested by that parity NAK. On-demand parity packets MUST be sent as RDATA with OPT_PARITY in the fixed header. Previously transmitted pro-active parity packets cannot be reused as on-demand parity packets, these MUST be computed with new, previously unused, indexes.
ソースが、要求次第の同等を提供するのを選ぶなら、それはトランスミッショングループのためにパリティNCFと共にパリティNAKに応じなければなりません。 要求次第のパリティパケットのトランスミッションを始める前に、ソースはことによると予定されていた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.
どちらの場合ではも、単に主な部分的なトランスミッショングループからの選択しているNAKsに対応してソースは選択している「再-トランスミッション」を提供しなければなりません。 どんな完全なグループのためにも、ソースSHOULDは選択している「再-トランスミッション」要求に対応してオンデマンドの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を含めて、SHOULDが早まって変流器グループを終えるソースは提供しました。
Speakman, et. al. Experimental [Page 65] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[65ページ]RFC3208PGM
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 SHOULDを送る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.
以下の手順によると、ソースは要求次第の同等を求める要求を同じトランスミッショングループに統合します。 要求次第のパリティパケットを求める前の要求からの未定(すなわち、unsent)のパリティパケットの数がその後のNAKのNAK_より等しいかすばらしいPKT_CNTであるなら、そのその後のNAK MUSTは確認されますが、別の方法で無視されるかもしれません。 その後のNAKでは、要求次第のパリティパケットを求める前の要求からの未定(すなわち、unsent)のパリティパケットの数がNAK_PKT_CNTより少ないなら、その後のNAK MUSTが確認されていてソースであることは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オプションを短くされたグループにおける最後のデータ・パケットに追加して、それはSHOULDです。それがそのグループの中で送るどんなパリティパケットにもOPT_CURR_TGSIZEオプションを追加しなければなりません。 グループを短くするのを決断をする前に最後のデータ・パケットを送って、送付への支給が全くないといけないので、同等がパケット(OPT_CURR_TGSIZE SHOULDを送るSPM)であると予測してください。 また、情報筋はそれが_最後のデータ・パケットの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サイズに基づいて消えるパケットの全体の数のための受信機MUST NAK。 NAK_PKT_CNTとオフセットの違いが最大TGサイズと有効なTGサイズの違いとして計算されたように、ソースは、これを考慮に入れて、事実上、必要であるパケットの数を計算しなければなりません。
11.5. Procedures - Receivers
11.5. 手順--受信機
If a receiver elects to make use of parity packets for loss recovery, it MUST first learn the transmission group size PARITY_PRM_TGS from OPT_PARITY_PRM in the SPMs for the TSI. The transmission group size is used by a receiver to determine the sequence number boundaries between transmission groups.
受信機が、損失回復にパリティパケットを利用するのを選ぶなら、それは最初に、TSIのためにSPMsでOPT_PARITY_PRMからトランスミッショングループサイズPARITY_PRM_TGSを学ばなければなりません。 トランスミッショングループサイズは受信機によって使用されて、トランスミッショングループの間の一連番号境界を決定します。
Speakman, et. al. Experimental [Page 66] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[66ページ]RFC3208PGM
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がSPMsで用意ができているなら、TSI、SHOULDが使用する受信機に関して、それが損失回復とPARITY_PRM_ONDがあるかどうかのために受けるどんな先を見越すパリティパケットもTSIのためにSPMsにセットして、それは損失検出のときに要求次第のパリティパケットに請求するかもしれません。 PARITY_PRM_ONDが用意ができて、ソースが可変トランスミッショングループサイズオプションを使用しないなら、受信機は部分的なトランスミッショングループ以外の選択しているNAKsを送ってはいけません。 パリティパケットはODATA(予測する)であるかTG_SQNが特定するそのODATA/RDATA_を受信機に知らせるOPT_PARITYで顕著なRDATA(要求次第)のパケットは同等が対応するトランスミッショングループにおける損失回復のために適用されるかもしれないPARITY_PRM_TGSパケットのグループです、そして、その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.
要求次第のパリティパケットに請求するために、受信機はパリティNAKsを損失検出に送らなければなりません。 要求次第の同等に請求する目的のために、損失検出はトランスミッショングループ限界に起こります、すなわち、トランスミッショングループにおける最後のデータ・パケットを受け取り次第、どんなその後のトランスミッショングループ、または現在のグループかその後のトランスミッショングループにおけるどんなパリティパケットを受け取り次第どんなデータ・パケットを受け取り次第。
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は単にPKT_CNTがNAK_TG_SQNによって指定されたトランスミッショングループからなくなるように検出されたパケットの数のカウントに設定するOPT_PARITYとNAK_と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.
受信機SHOULDが逆にNAK_PKT_CNTに変化するパリティNAKsのためにNAK_BO_IVLの値に偏るので、より大きい損失のためのNAKsはNAKsの前で同じ受信機人口における、よりわずかな損失で予定されていそうです。
A confirming NCF for a parity NAK is a parity NCF with NCF_PKT_CNT equal to or greater than that specified by the parity NAK.
パリティNAKのための確認NCFはNCF_PKT_CNTがそれより等しいか、またはすばらしいNCFがパリティNAKで指定した同等です。
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と等しいSPMsベアリングSPM_LEADから、検出される)がないとき、受信機はその部分的なトランスミッショングループにおけるどんななくなったパケットのためにも選択しているNAKsに頼るかもしれません。
Speakman, et. al. Experimental [Page 67] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[67ページ]RFC3208PGM
When a receiver handles parity packets belonging to a transmission group with variable sized packets, (detected from the presence of the OPT_VAR_PKTLEN option in the parity packets), it MUST decode them as specified in the overview description and use the decoded TSDU length to get rid of the padding in the decoded packet.
受信機が可変大きさで分けられた(パリティパケットでのOPT_VAR_PKTLENオプションの存在から検出される)のパケットでトランスミッショングループのものパリティパケットを扱うとき、それは、概観記述で指定されるようにそれらを解読して、解読されたパケットで詰め物を取り除くのに解読されたTSDUの長さを使用しなければなりません。
If the source was using a variable sized transmission group via the OPT_CURR_TGSIZE, the receiver might learn this before having requested (and received) any retransmission. The above happens if it sees OPT_CURR_TGSIZE in the last data packet of the TG, in any proactive parity packet or in a SPM. If the receivers learns this and determines that it has missed one or more packets in the shortened transmission group, it MAY then NAK for them without waiting for the start of the next transmission group. Otherwise it will start NAKing at the start of the next transmission group.
ソースがOPT_CURR_TGSIZEを通して可変大きさで分けられたトランスミッショングループを使用しているなら、どんな「再-トランスミッション」も要求する(そして、受信します)前に、受信機はこれを学ぶでしょうに。 TGの最後のデータ・パケット、どんな先を見越すパリティパケットまたはSPMのOPT_CURR_TGSIZEも見るなら、上記は起こります。 受信機が、これを学んで、短くされたトランスミッショングループにおける1つ以上のパケットを逃したことを決定するなら、それはそれらのための次に次のトランスミッショングループの始まりを待つことのないNAKを決定します。 さもなければ、それは次のトランスミッショングループの始めで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.
どちらの場合も、トランスミッショングループのサイズが最大の有効なトランスミッションであると仮定するのを逃すパケットの数のための受信機MUST NAKは分類します。 言い換えれば、受信機は、トランスミッショングループが、より小さかったのを既に知るかもしれないという事実を利用できませんが、それがなくなると信じているパケットの数、および総パケットを最大の有効なトランスミッショングループサイズまで持って来なければならなかったパケットの数のためのいつもNAKを利用しなければなりません。
After the first parity packet has been delivered to the receiver, the actual TG size is known to him, either because already known or because discovered via OPT_CURR_TGSIZE contained in the parity packet. Hence the receiver can decode the whole group as soon as the minimum number of parity packets needed is received.
最初のパリティパケットによる受信機に渡します、実際のTGサイズは彼にとって知られています、既に知られるのでことであった後かTGSIZEがパリティパケットに含んだOPT_CURR_を通して発見されるので。 したがって、パケットが必要とした同等の最小の数が受け取られているとすぐに、受信機は全体のグループを解読できます。
11.6. Procedures - Network Elements
11.6. 手順--ネットワークElements
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とNAKsを受け取って、レコードが対応するNAKsのNAK_PKT_CNTのインタフェースを記録することに加えたどの対応に見られる中において最も大きい値であるかをそれぞれ連結します。 この値は知られているパケットカウントと呼ばれます。 最も大きい知られているパケットカウントが修理状態にどんなインタフェースにも記録した、グループを伝えるか、または最も大きい知られているパケットと呼ばれた状態でNCFによって運ばれて、数えてください。
Speakman, et. al. Experimental [Page 68] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[68ページ]RFC3208PGM
Upon receipt of a parity NAK, a network element responds with the corresponding parity NCF. The corresponding parity NCF is just an NCF formed in the usual way (i.e., a multicast copy of the NAK with the packet type changed), but with the addition of OPT_PARITY and with NCF_PKT_CNT set to the larger of NAK_PKT_CNT and the known packet count for the receiving interface. The network element then creates repair state in the usual way with the following modifications.
同等を受け取り次第、NAK、ネットワーク要素は対応するパリティNCFと共に応じます。 対応するパリティNCFはただ不断のとおり形成されたNCF(すなわち、パケットタイプを変えているNAKのマルチキャストコピー)ですが、OPT_PARITYの添加とCNTが、より大きく設定するNAK_のNCF_PKT_で、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を排除しなければなりません、そして、NAK_PKT_CNTは最も大きい知られているパケットより等しいか少ないカウントです。 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が期限が切れたなら、ネットワーク要素は不断のとおりCNTが最も大きい知られているパケットカウントと等しいNAK_PKT_の値があるパリティ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
NCF、ネットワーク要素がそうしなければならない同等のレセプションでは、NCF_PKT_CNTが最も大きい知られているパケットカウントと、より優れているか、または等しい場合にだけ、未定のNAK retransmissionを取り消してください。 そしてネットワーク要素が不断のとおりどんなその後のNAKsもNAKと共に_PKT_CNTのNCF_より等しいか少ないPKT_CNTを受けたように予期がある最も大きい知られているパケットカウントとしてのパリティNCFからのCNTが述べるNCF_PKT_を記録する添加があるNAKsが排除されると予期するのにパリティNCFsを使用しなければならない。
Speakman, et. al. Experimental [Page 69] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[69ページ]RFC3208PGM
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).
NAK_PKT_CNTがNCF_よりすばらしい場合、いくらか、PKT_CNTを進めるでしょう。 NCF_PKT_CNTが最も大きい知られているパケットカウントより大きいNCFが受けなければならない同等を受ける要素をネットワークでつないでください、また、それを使用して、NAKsを予期してください、NCF_PKT_CNT(部分的な予期)を反映するために最も大きい知られているパケットカウントを増加させて。
Parity NNAKs follow the usual elimination procedures with the exception that NNAKs are eliminated only if existing NAK state has a NAK_PKT_CNT greater than NNAK_PKT_CNT.
NNAKsが例外がある普通の除去手順ですが、存在している場合にだけ排除されて、NNAKsが続く同等で、NAK_PKT_CNTはNNAK_PKT_CNTよりすばらしくなりますNAKが、述べる。
Network elements must take extra precaution when the source is using a variable sized transmission group. Network elements learn that the source is using a TG size smaller than the maximum from OPT_CURR_TGSIZE in parity RDATAs or in SPMs. When this happens, they compute a TG size offset as the difference between the maximum TG size and the actual TG size advertised by OPT_CURR_TGSIZE. Upon reception of parity RDATA, the TG size offset is used to update the repair state as follows:
ソースが可変大きさで分けられたトランスミッショングループを使用しているとき、ネットワーク要素は大事を取らなければなりません。 ネットワーク要素は、ソースがパリティRDATAsかSPMsでOPTから_CURR_TGSIZEを最大より小さいTGサイズに使用していることを学びます。これが起こると、彼らはOPT_CURR_TGSIZEによって広告に掲載された最大のTGサイズと実際の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サイズと等しいときに適用される正常な規則を置き換えます。
11.7. Procedures - DLRs
11.7. 手順--DLRs
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は、OPT_PARITYビットを向け直しているPOLRにはめ込むことによって、これを示さなければなりません。 そして、それは不断のとおりどんな向け直されたFEC NAKsも処理しなければなりません。
11.8. Packet Formats
11.8. パケット・フォーマット
11.8.1. OPT_PARITY_PRM - Packet Extension Format
11.8.1. _同等_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| |P O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmission Group Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| |P O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トランスミッショングループサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x08
オプションタイプ=0x08
Option Length = 8 octets
オプションLengthは8つの八重奏と等しいです。
P-bit (PARITY_PRM_PRO)
P-ビット(パリティ_PRM_プロ)
Speakman, et. al. Experimental [Page 70] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[70ページ]RFC3208PGM
Indicates when set that the source is providing pro-active parity packets.
ソースが提供しているセットが、同等がパケットであると予測すると、示します。
O-bit (PARITY_PRM_OND)
O-ビット(_パリティ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.
少なくとも1、PARITY_PRM_PROとPARITY_PRM_OND MUSTでは、設定してください。
Transmission Group Size (PARITY_PRM_TGS)
トランスミッショングループサイズ(_パリティ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 MAY、SPMsだけに追加してください。
OPT_PARITY_PRM is network-significant.
OPT_PARITY_PRMはネットワーク重要です。
11.8.2. OPT_PARITY_GRP - Packet Extension Format
11.8.2. _同等_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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parity Group Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パリティグループ番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x09
オプションタイプ=0x09
Option Length = 8 octets
オプションLengthは8つの八重奏と等しいです。
Parity Group Number (PRM_GROUP)
パリティグループ番号(PRM_グループ)
The number of the group of k parity packets amongst the h parity packets within the transmission group to which the parity packet belongs, where the first k parity packets are in group zero. PRM_GROUP MUST NOT be zero.
パリティパケットが属するトランスミッションの中のhパリティパケットの中のkパリティパケットのグループの数は分類されます、グループゼロには最初kのパリティパケットがあるところで。 PRM_GROUP MUST NOT、ゼロになってください。
OPT_PARITY_GRP MAY be appended only to parity packets.
OPT_PARITY_GRP MAY、パリティパケットだけに追加してください。
OPT_PARITY_GRP is NOT network-significant.
OPT_PARITY_GRPはネットワーク重要ではありません。
Speakman, et. al. Experimental [Page 71] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[71ページ]RFC3208PGM
11.8.3. OPT_CURR_TGSIZE - Packet Extension Format
11.8.3. _CURR_TGSIZEを選んでください--、パケット拡大形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 実際のトランスミッショングループサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x0A
オプションタイプは0x0Aと等しいです。
Option Length = 8 octets
オプションLengthは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.
このトランスミッションにおける、データ・パケットの実数は分類されます。 これは_最大のトランスミッショングループサイズよりPARITY_PRMがOPT_PARITY_PRMのTGSであったならそうしなければなりません。
OPT_CURR_TGSIZE MAY be appended to data and parity packets (ODATA or RDATA) and to SPMs.
OPT_CURR_TGSIZE MAY、データとパリティパケット(ODATAかRDATA)と、そして、SPMsに追加してください。
OPT_CURR_TGSIZE is network-significant except when appended to ODATA.
ODATAに追加する時を除いて、OPT_CURR_TGSIZEはネットワーク重要です。
12. Appendix B - Support for Congestion Control
12. 付録B--輻輳制御のサポート
12.1. Introduction
12.1. 序論
A source MUST implement strategies for congestion avoidance, aimed at providing overall network stability, fairness among competing PGM flows, and some degree of fairness towards coexisting TCP flows [13]. In order to do this, the source must be provided with feedback on the status of the network in terms of traffic load. This appendix specifies NE procedures that provide such feedback to the source in a scalable way. (An alternative TCP-friendly scheme for congestion control that does not require NE support can be found in [16]).
ソースは競争しているPGM流れの中の公正、および共存しているTCP流れ[13]に向かった公正の何らかの度合いで総合的なネットワークの安定性を提供するのが目的とされた輻輳回避のための戦略を実行しなければなりません。 これをするために、トラヒック負荷でネットワークの状態のフィードバックをソースに提供しなければなりません。 この付録はスケーラブルな方法でそのようなフィードバックをソースに提供するNE手順を指定します。 ([16])でNEサポートを必要としない輻輳制御の代替のTCPに優しい計画を見つけることができます。
The procedures specified in this section enable the collection and selective forwarding of three types of feedback to the source:
このセクションで指定された手順は3つのタイプのフィードバックの収集と選択している推進をソースに可能にします:
o Worst link load as measured in network elements.
o ネットワーク要素で測定されるように最もひどく負荷をリンクしてください。
o Worst end-to-end path load as measured in network elements.
o 終わりから終わりへの経路ネットワーク要素で測定される中で最も悪い負荷。
o Worst end-to-end path load as reported by receivers.
o 終わりから終わりへの経路受信機によって報告される中で最も悪い負荷。
Speakman, et. al. Experimental [Page 72] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[72ページ]RFC3208PGM
This specification defines in detail NE procedures, receivers procedures and packet formats. It also defines basic procedures in receivers for generating congestion reports. This specification does not define the procedures used by PGM sources to adapt their transmission rates in response of congestion reports. Those procedures depend upon the specific congestion control scheme.
この仕様は詳細にNE手順、受信機手順、およびパケット・フォーマットを定義します。 また、それは、混雑レポートを作るために受信機で基本的な手順を定義します。 この仕様は混雑レポートの応答で彼らの通信速度を適合させるのにPGMソースによって用いられた手順を定義しません。 それらの手順は特定の輻輳制御計画に依存します。
PGM defines a header option that PGM receivers may append to NAKs (OPT_CR). OPT_CR carries congestion reports in NAKs that propagate upstream towards the source.
PGMはPGM受信機がNAKs(OPT_CR)に追加するかもしれないヘッダーオプションを定義します。 OPT_CRは上流へソースに向かって伝播するNAKsでの混雑レポートを運びます。
During the process of hop-by-hop reverse NAK forwarding, NEs examine OPT_CR and possibly modify its contents prior to forwarding the NAK upstream. Forwarding CRs also has the side effect of creating congestion report state in the NE. The presence of OPT_CR and its contents also influences the normal NAK suppression rules. Both the modification performed on the congestion report and the additional suppression rules depend on the content of the congestion report and on the congestion report state recorded in the NE as detailed below.
ホップごとの逆のNAK推進の過程の間、NEsはOPT_CRを調べて、NAK上流を進める前に、ことによるとコンテンツを変更します。 また、推進CRsは作成混雑の副作用にNEで状態を報告させます。 また、OPT_CRとそのコンテンツの存在は正常なNAK抑圧規則に影響を及ぼします。 混雑レポートに実行された変更と追加抑圧規則の両方が混雑レポートの中身と、そして、以下で詳しく述べられるようにNEに記録された混雑レポート状態に依存します。
OPT_CR contains the following fields:
OPT_CRは以下の分野を含んでいます:
OPT_CR_NE_WL Reports the load in the worst link as detected though NE internal measurements
OPT_CR_NE_WL ReportsはNEの内部の測定値ですが、検出される中で最も悪いリンクの負荷です。
OPT_CR_NE_WP Reports the load in the worst end-to-end path as detected though NE internal measurements
OPT_CR_NE_WP Reportsは終わりから端へのNEの内部の測定値ですが、検出される中で最も悪い経路の負荷です。
OPT_CR_RX_WP Reports the load in the worst end-to-end path as detected by receivers
OPT_CR_RX_WP Reportsは終わりから端への受信機によって検出される中で最も悪い経路の負荷です。
A load report is either a packet drop rate (as measured at an NE's interfaces) or a packet loss rate (as measured in receivers). Its value is linearly encoded in the range 0-0xFFFF, where 0xFFFF represents a 100% loss/drop rate. Receivers that send a NAK bearing OPT_CR determine which of the three report fields are being reported.
負荷レポートは、パケット低下率(NEのインタフェースで測定されるように)かパケット損失率(受信機で測定されるように)のどちらかです。 値は範囲0-0xFFFFで直線的にコード化されます。そこでは、0xFFFFが100%の損失/低下率を表します。 NAKがOPT_CRを持っている受信機は、3つのレポート分野のどれが報告されているかを決定します。
OPT_CR also contains the following fields:
また、OPT_CRは以下の分野を含んでいます:
OPT_CR_NEL A bit indicating that OPT_CR_NE_WL is being reported.
OPT_CR_NE_WLが報告されているのを示しながら、OPT_CR_NEL Aに噛み付きました。
OPT_CR_NEP A bit indicating that OPT_CR_NE_WP is being reported.
OPT_CR_NE_WPが報告されているのを示しながら、OPT_CR_NEP Aに噛み付きました。
OPT_CR_RXP A bit indicating that OPT_CR_RX_WP is being reported.
OPT_CR_RX_WPが報告されているのを示しながら、OPT_CR_RXP Aに噛み付きました。
Speakman, et. al. Experimental [Page 73] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[73ページ]RFC3208PGM
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の内容を変更するNEsで進められるかもしれません。
OPT_CR_RCVR The identity of the receiver that generated the worst OPT_CR_RX_WP.
OPT_CR_RCVR、最も悪い_OPT_CR RX_WPを発生させた受信機のアイデンティティ。
The complete format of the option is specified later.
オプションの完全な形式は後で指定されます。
12.2. NE-Based Worst Link Report
12.2. Neベースの最も悪いリンクレポート
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.
ネットワーク要素が、リンクするように最もひどく報告することを許可するには、受信機はNELが設定するビットOPT_CR_とNE_WLがゼロに設定するOPT_CR_とNAKにOPT_CRを追加します。 オプションとアップデートTSIが述べるOPT_CR_NE_WLの過程を含むNAKsを受けるNEsが以下で説明されるようにそれに関連しました。 NEsの動作の究極の結果は、NAKが下位木を残すとき、OPT_CR_NE_WLがその下位木で最も悪いリンクの荷重を反映する混雑レポートを含むのを確実にします。 これを達成するために、NEsは最悪がいるNE_WLがセッションのために地方(外向的な)のリンクの上に測定された負荷の中で評価して、混雑レポートがそれらのリンクから受けたOPT_CR_を書き直します。
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マルチキャストルータで(送信する)のリンクの上の負荷のモニターを可能にしないことに注意してください。 これが推論して、中古のコネ純粋なPGM topologiesが唯一であったならWorst Link Reports SHOULDをNE基礎づけたので。 さもなければ、このメカニズムは混雑を検出する際に失敗するかもしれません。 この限界を克服するために、PGMソースはベースのNE Worst Link ReportsとベースのReceiver Reportsを結合するヒューリスティックを使用するかもしれません。
12.3. NE-Based Worst Path Report
12.3. 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:
ネットワーク要素が最も悪い経路を報告することを許可するために、受信機はNEPが設定するビットOPT_CR_とNE_WPがゼロに設定するOPT_CR_とNAKにOPT_CRを追加します。 NAKのレセプションのOPT_CR_NE_WPの値は違いがあるOPT_CR_NE_WLのものですが、負荷が以下の公式に応じてNAKが受け取られたインタフェースで測定されている状態で調整されて、この分野の処理は同様です:
OPT_CR_NE_WP = if_load + OPT_CR_NE_WP * (100% - if_loss_rate)
OPT_CR_NE_WPは= _であるなら+ OPT_CR_NE_WP*をロードします。(100%--__損失であるなら、評価してください)
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に書かれています。 これはホップごとの経路損失率へのリンク損失率の蓄積をもたらします。
Speakman, et. al. Experimental [Page 74] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[74ページ]RFC3208PGM
As with OPT_CR_NE_WL, the congestion report in OPT_CR_NE_WP may be invalid if the multicast distribution tree includes non-PGM-capable routers.
OPT_CR_NE_WLなら、マルチキャスト分配木ができる非PGMルータを含んでいるなら、OPT_CR_NE_WPでの混雑レポートは無効であるかもしれません。
12.4. Receiver-Based Worst Report
12.4. 受信機ベースの最も悪いレポート
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.
パケット損失率を報告するために、受信機はRXPが設定するビットOPT_CR_とRX_WPがパケット損失率に設定するOPT_CR_とNAKにOPT_CRを追加します。 オプションとアップデートTSIが述べるOPT_CR_RX_WPの過程を含むNAKsを受けるNEsが以下で説明されるようにそれに関連しました。 NEsの動作の究極の結果は、NAKが下位木を残すとき、OPT_CR_RX_WPがその下位木で最も悪い受信機の荷重を反映する混雑レポートを含むのを確実にします。 これを達成するために、NEsは混雑レポートの中に最も悪い値があるRE_WPがセッションのために出発しているリンクの上に受けたOTP_CR_を書き直します。 これに加えて、OPT_CR_RCVR MUSTは元々進められるOTP_CR_RE_WPの値を測定した受信機のNLAを含んでいます。
12.5. Procedures - Receivers
12.5. 手順--受信機
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.
どんなタイプの混雑レポートの世代も可能にするために、受信機はそれらが対応する野原(OPT_CR_NE_WL、OPT_CR_NE_WP、OPT_CR_RX_WP)を発生して、供給する各NAKにOPT_CRを挿入しなければなりません。 セッションのSPMsの上のOPT_CRQSTの受信機に報告されるべき特定の分野の広告を出すでしょう。受信機はOPT_CRQSTで要求されたそれらのオプションだけを供給しなければなりません。
Receivers MUST initialize OPT_CR_NE_WL and OPT_CR_NE_WP to 0 and they MUST initialize OPT_CR_RCVR to their NLA. At the moment of sending the NAK, they MUST also initialize OPT_CR_LEAD to the leading edge of the transmission window.
受信機はOPT_CR_NE_WLとOPT_CR_NE_WPを0に初期化しなければなりません、そして、それらはOPT_CR_RCVRを自己のNLAに初期化しなければなりません。 現在、また、NAKを送るのにおいて、彼らはOPT_CR_LEADをトランスミッションウィンドウのリーディングエッジに初期化しなければなりません。
Additionally, if a receiver generates a NAK with OPT_CR with OPT_CR_RX_WP, it MUST initialize OPT_CR_RX_WP to the proper value, internally computed.
さらに、受信機がOPT_CRと共にOPT_CR_RX_WPでNAKを発生させるなら、それはOPT_CR_RX_WPを内部的に計算された固有値に初期化しなければなりません。
12.6. Procedures - Network Elements
12.6. 手順--ネットワークElements
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です。 通常、これはCR_LEADが受け取られたNAKに含んだOPT_です。
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 局所的に測定された負荷値(例えば、インタフェース負荷)は最新であると考えられます。
Speakman, et. al. Experimental [Page 75] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[75ページ]RFC3208PGM
o load values carried in OPT_CR are considered up-to-date and are not aged so as to be independent of variance in round-trip times from the network element to the receivers
o 最新であると考えられて、往復の回による変化からネットワーク要素から受信機まで独立しているためにOPT_CRで運ばれた負荷値老いない
o old load values recorded in the NE are exponentially aged according to the difference between the selected reference SQN and the reference SQN associated with the old load value.
o 古い負荷値に関連している選択された参照SQNと参照SQNの違いに従って、NEに記録された古い負荷値は指数関数的に熟成します。
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)
_高年層_損失_レート=損失レート*exp(--SQN_違い*損失_が、/が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/損失_率が2NAKsの間の予想されたSQN_立ち遅れであるというメモ、したがって、また、上の公式を以下と読むことができます。
aged_loss_rate = loss_rate * exp( - 1/2 * SQN_difference / SQN_lag)
_高年層_損失_レート=損失レート*exp(--1/2*SQN_差/SQN_が遅れる)
which equates to (loss_rate * exp(-1/2)) when the SQN_difference is equal to expected SQN_lag between two NAKs.
どれ、同一視、(SQN_違いであるときに、損失_レート*exp(-1/2))は2NAKsの間の予想されたSQN_立ち遅れと等しいか。
All the subsequent computations refer to the aged load values.
すべてのその後の計算が老いている負荷値について言及します。
Network elements process OPT_CR by handling the three possible types of congestion reports independently.
ネットワーク要素は、独自に3つの可能なタイプの混雑レポートを扱うことによって、OPT_CRを処理します。
For each congestion report in an incoming NAK, a new value is computed to be used in the outgoing NAK:
入って来るNAKでのそれぞれの混雑レポートに関しては、新しい値は出発している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が負荷の最大であるので、セッションのための外向的なインタフェース、OPT_CRの値で_入って来るNAKの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のNE_WPが負荷で調整したOPT_CR_の値(上で説明されるように)です。
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の値です。
Speakman, et. al. Experimental [Page 76] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[76ページ]RFC3208PGM
o If OPT_CR_RX_WP was selected from the incoming NAK, the new value for OPT_CR_RCVR is the one in the incoming NAK. Otherwise it is the value previously sent upstream.
o OPT_CR_RX_WPが入って来るNAKから選択されたなら、OPT_CR_RCVRのための新しい値は入って来るNAKのものです。 さもなければ、それは以前に上流へ送られた値です。
o The new value for OPT_CR_LEAD is the reference SQN selected for the aging procedure.
o OPT_CR_LEADのための新しい値は古い手順のために選択された参照SQNです。
12.6.1. Overriding Normal Suppression Rules
12.6.1. 正常な抑圧規則をくつがえします。
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は抑圧されません。
12.6.2. Link Load Measurement
12.6.2. リンク・ロード測定
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ルータは、それらのすべての出発しているリンクの上に負荷をモニターして、1インタフェースあたりの損失レート統計の形にそれを記録します。 落とされたインタフェースで進められることが意味される場合、パケットの割合として「負荷」を解釈しなければなりません。 負荷統計は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.
このドキュメントは、そのような統計を集めるのに使用されるためにアルゴリズムを指定しませんが、そのようなアルゴリズムが精度と反応性の両方を測定の過程に提供するのを必要とします。 精度は関係があって、予想された測定誤差がSHOULDである限り、上側に制限されてください(例えば、10より少ない%)。 反応性に関する限り、測定負荷SHOULDは限られた時代(例えば、200ミリセカンド未満で実価の90%まで一点に集まる)で実価に一点に集まります。(その時、瞬時に起こっている提供された負荷は変化します)。 同時間、精度SHOULDで両方の必要条件を満たすことができないときはいつも、反応性のために取り引きしてください。
Speakman, et. al. Experimental [Page 77] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[77ページ]RFC3208PGM
12.7. Packet Formats
12.7. パケット・フォーマット
12.7.1. OPT_CR - Packet Extension Format
12.7.1. _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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Report Reference SQN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NE Worst Link | NE Worst Path | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rcvr Worst Path | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Worst Receiver's 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| L P R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 混雑レポート参照SQN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neの最も悪いリンク| Neの最も悪い経路| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rcvrの最も悪い経路| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最も悪い受信機のNLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
Option Type = 0x10
オプションタイプ=0x10
Option Length = 20 octets + NLA length
オプション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(_CR_リードを選びます)。
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の最も悪いリンク(__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の最も悪い経路(__CR_Ne WPを選びます)。
Reports the load in the worst end-to-end path as detected though NE internal measurements
NEの内部の測定値ですが、検出されるように終わりから端への最も悪い経路で負荷を報告します。
Speakman, et. al. Experimental [Page 78] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[78ページ]RFC3208PGM
Rcvr Worst Path (OPT_CR_RX_WP).
Rcvrの最も悪い経路(_CR_RX_WPを選びます)。
Reports the load in the worst end-to-end path as detected by receivers
受信機によって検出されるように終わりから端への最も悪い経路で負荷を報告します。
Worst Receiver's NLA (OPT_CR_RCVR).
最も悪い受信機のNLA(_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 MAY、NAKsだけに追加してください。
OPT-CR is network-significant.
OPT-CRはネットワーク重要です。
12.7.2. OPT_CRQST - Packet Extension Format
12.7.2. _CRQSTを選んでください--、パケット拡大形式
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| L P R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x11
オプションタイプ=0x11
Option Length = 4 octets
オプションLengthは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 MAY、SPMsだけに追加してください。
OPT-CRQST is network-significant.
OPT-CRQSTはネットワーク重要です。
13. Appendix C - SPM Requests
13. 付録C--SPM要求
13.1. Introduction
13.1. 序論
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 Requests(SPMRs)は、ソースからSPMに非内破音方法で請求するのに使用されるかもしれません。 主用途はそのソースから定期的に予定されているSPMを待つ必要はなくてなくなったパケットにおいてNAKにできるために直接ソースからSPMsに請求する遅く接合している受信機のためのものです。
Speakman, et. al. Experimental [Page 79] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[79ページ]RFC3208PGM
13.2. Overview
13.2. 概観
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内部破裂保護手順、受信機5月のユニキャストのためにソースへのSPMRが受信機の後にそのソースから最も現在のセッション、窓、および経路州にいつでも請求するのを許容するのがグループに加わりました。 受信機はそれがグループで受けるいかなる他のPGMパケット、または地方の構成や電話番号案内などのいかなる他の手段でもSPMRをあてるTSIとソースを学ぶかもしれません。 受信機は、それが請求されたSPMからNAKsを向けるべきであるユニキャストアドレスを収集するのに普通のSPM手順を用いなければなりません。
13.3. Packet Contents
13.3. パケットコンテンツ
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.
このセクションはただProceduresを明瞭にすることができるくらいの速記を提供します。 パケットコンテンツの一部始終について、以下のPacket Formatsを参照してください。
13.3.1. SPM Requests
13.3.1. SPM要求
SPMRs are transmitted by receivers to solicit SPMs from a source.
SPMRsは受信機によって伝えられて、ソースからSPMsに請求します。
SPMs are unicast to a source and contain:
SPMsはソースへのユニキャストであり、以下を含んでいます。
SPMR_TSI the source-assigned TSI for the session to which the SPMR corresponds
SPMRが相当するセッションのためのSPMR_TSIのソースによって割り当てられたTSI
13.4. Procedures - Sources
13.4. 手順--ソース
A source MUST respond immediately to an SPMR with the corresponding SPM rate limited to once per IHB_MIN per TSI. The corresponding SPM matches SPM_TSI to SPMR_TSI and SPM_DPORT to SPMR_DPORT.
対応するSPMレートがTSI単位でIHB_MINあたりの一度に制限されている状態で、情報筋はすぐSPMRに応じなければなりません。 対応するSPMはSPMR_TSIへのSPM_TSIとSPMR_DPORTへのSPM_DPORTに合っています。
13.5. Procedures - Receivers
13.5. 手順--受信機
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.
加減する、潜在的に内破音の振舞い、unicastingする前とソースにSPMRをunicastingすることに加えて、少なくとも人口密度が高いサブネットのSPMRsでは、受信機は下に以下の後部を使用しなければならなくて、抑圧手順は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
より明確に、与えられたSPMRをunicastingする前に、受信機はSPMR_BO_IVL(~250msec)の上のそれらが同じSPMRのマルチキャストの聞こうとする無作為の遅れを選ばなければなりません。1のTTLがあるグループへのそれ自身の最初のマルチキャストSPMRがそれ以前それ自身のSPMRをソースにunicastingして、受信機が選ばれた無作為の間隔中に合っているマルチキャストSPMRを見ないなら、それは見なければなりません。 受信機がそうするなら、aを見てください。
Speakman, et. al. Experimental [Page 80] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[80ページ]RFC3208PGM
matching multicast SPMR within its chosen random interval, it MUST refrain from unicasting its SPMR and wait instead for the corresponding SPM.
選ばれた無作為の間隔中にマルチキャストSPMRを合わせて、それは、SPMRをunicastingするのを控えて、代わりに対応するSPMを待たなければなりません。
In addition, receipt of the corresponding SPM within this random interval SHOULD cancel transmission of an SPMR.
添加、SPMRのこの無作為の間隔SHOULDキャンセル送信の中の対応するSPMの領収書で。
In either case, the receiver MUST wait at least SPMR_SPM_IVL before attempting to repeat the SPMR by choosing another delay on SPMR_BO_IVL and repeating the procedure above.
どちらの場合ではも、受信機はSPMR_BO_IVLの上の別の遅れを選んで、上の手順を繰り返すことによってSPMRを繰り返すのを試みる前に、少なくともSPMR_SPM_IVLを待たなければなりません。
The corresponding SPMR matches SPMR_TSI to SPMR_TSI and SPMR_DPORT to SPMR_DPORT. The corresponding SPM matches SPM_TSI to SPMR_TSI and SPM_DPORT to SPMR_DPORT.
対応するSPMRはSPMR_TSIへのSPMR_TSIとSPMR_DPORTへのSPMR_DPORTに合っています。 対応するSPMはSPMR_TSIへのSPM_TSIとSPMR_DPORTへのSPM_DPORTに合っています。
13.6. SPM Requests
13.6. SPM要求
SPMR:
SPMR:
SPM Requests are sent by receivers to request the immediate transmission of an SPM for the given TSI from a source.
受信機でSPM Requestsを送って、与えられた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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース港| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 存在しているときのオプションExtensions… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...
Source Port:
ソース港:
SPMR_SPORT
SPMR_スポーツ
Data-Destination Port
データ仕向港
Speakman, et. al. Experimental [Page 81] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[81ページ]RFC3208PGM
Destination Port:
仕向港:
SPMR_DPORT
SPMR_DPORT
Data-Source Port, together with Global Source ID forms SPMR_TSI
Global Source IDフォームに伴うデータソースPort SPMR_TSI
Type:
以下をタイプしてください。
SPMR_TYPE = 0x0C
SPMR_タイプは0x0Cと等しいです。
Global Source ID:
グローバルなソースID:
SPMR_GSI
SPMR_GSI
Together with Source Port forms
Source Portフォームと共に
SPMR_TSI
SPMR_TSI
14. Appendix D - Poll Mechanism
14. 付録D--投票メカニズム
14.1. Introduction
14.1. 序論
These procedures provide PGM network elements and sources with the ability to poll their downstream PGM neighbors to solicit replies in an implosion-controlled way.
これらの手順は内部破裂で制御された方法で回答に請求するために彼らの川下のPGM隣人に投票する能力をPGMネットワーク要素とソースに提供します。
Both general polls and specific polls are possible. The former provide a PGM (parent) node with a way to check if there are any PGM (children) nodes connected to it, both network elements and receivers, and to estimate their number. The latter may be used by PGM parent nodes to search for nodes with specific properties among its PGM children. An example of application for this is DLR discovery.
一般的な投票と特定の投票の両方が可能です。 前者は何かそれに接続されたPGM(子供)ノード、ネットワーク要素と受信機の両方があるかどうかチェックして、それらの番号を見積もる方法をPGM(親)ノードに提供します。 後者はPGM親ノードによって使用されて、PGM子供を特定の性質でノードを検索するかもしれません。 これのアプリケーションに関する例はDLR発見です。
Polling is implemented using two additional PGM packets:
世論調査は2つの追加PGMパケットを使用することで実行されます:
POLL a Poll Request that PGM parent nodes multicast to the group to perform the poll. Similarly to NCFs, POLL packets stop at the first PGM node they reach, as they are not forwarded by PGM network elements.
PGMがグループへのノードマルチキャストの親代わりとなるPOLL a Poll Requestは投票を実行します。 同様に、NCFsに、POLLパケットはそれらが達する最初のPGMノードに止まります、それらがPGMネットワーク要素によって進められないとき。
POLR a Poll Response that PGM children nodes (either network elements or receivers) use to reply to a Poll Request by addressing it to the NLA of the interface from which the triggering POLL was sent.
PGM子供ノード(ネットワーク要素か受信機のどちらか)が引き金となっているPOLLが送られたインタフェースのNLAにそれを記述することによってPoll Requestに答えるのに使用するPOLR a Poll Response。
Speakman, et. al. Experimental [Page 82] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[82ページ]RFC3208PGM
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を無視する場合にだけ、世論調査メカニズムは、POLLパケットを受けるPGM子供ノードがそれに答えると決めます。 状態の2つのタイプが可能です: 投票された子供を代わって答えるという確率を定義する無作為の状態、および決定論的な状態。 無作為の状態と決定論的な状態の両方が、世論調査PGM親ノードによってそれぞれ返答して、決定論的な状態を定義するという確率を指定することによって、規制されます。 無作為に唯一の投票、決定論的に唯一の投票またはa組み合わせ、2は可能です。
The random condition in polls allows the prevention of implosion of replies by controlling their number. Given a probability of replying P and assuming that each receiver makes an independent decision, the number of expected replies to a poll is P*N where N is the number of PGM children relative to the polling PGM parent. The polling node can control the number of expected replies by specifying P in the POLL packet.
投票における無作為の状態は、それらの番号を制御することによって、回答の内部破裂の防止を許します。 各受信機で返答Pとそれを独立決議を仮定するという確率を考えて、投票に関する予想された回答の数は世論調査PGM親に比例したNがPGM子供の数であるところのP*Nです。 世論調査ノードは、POLLパケットでPを指定することによって、予想された回答の数を制御できます。
14.2. Packet Contents
14.2. パケットコンテンツ
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.
このセクションはただProceduresを明瞭にすることができるくらいの速記を提供します。 パケットコンテンツの一部始終について、以下のPacket Formatsを参照してください。
14.2.1. POLL (Poll Request)
14.2.1. 投票(投票要求)
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 a投票。 複数の投票ラウンドが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が伝えられるPGMネットワーク要素かソースの上のインタフェースのPOLL_PATHネットワーク層アドレス(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は返答する際に偶発性を実行するのに使用される無作為のストリングです。
Speakman, et. al. Experimental [Page 83] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[83ページ]RFC3208PGM
POLL_MASK a bit-mask used to determine the probability of random replies
MASKが少しマスクをかけるPOLL_は以前はよく無作為の回答の確率を測定していました。
Poll request MAY also contain options which specify deterministic conditions for the reply. No options are currently defined.
また、投票要求は回答のための決定論的な状態を指定するオプションを含むかもしれません。 オプションは全く現在、定義されません。
14.2.2. POLR (Poll Response)
14.2.2. POLR(投票応答)
POLR_SQN POLL_SQN of the poll request for which this is a reply
これが回答である投票のSQNが要求するPOLR_SQN POLL_
POLR_ROUND POLL_ROUND of the poll request for which this is a reply
これが回答である投票のROUNDが要求するPOLR_ROUND POLL_
Poll response MAY also contain options. No options are currently defined.
また、投票応答はオプションを含むかもしれません。 オプションは全く現在、定義されません。
14.3. Procedures - General
14.3. 手順--一般
14.3.1. General Polls
14.3.1. 一般投票
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.
司令官のPollsは、与えられたノードのインタフェースについてチェックして、PGMが川下を飛び越す1歳であるPGM子供を数えるのに使用されるかもしれません。 彼らは_PGM_POLL_一般と等しい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.
応答内部破裂を防ぐために、一般的な投票SHOULDを開始するPGM両親は投票に答えるという確率を確立します、P、回答の予想された数が含まれているように。 回答の予想された数はN*Pです。(そこでは、Nが子供の数です)。 この数を計算できるように、PGM両親のSHOULDには、子供の数の概算が既にあります。 彼らには、この数の最近の推定がなくて、それらは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.
子供の母集団の急増で引き起こされた投票応答内部破裂が2つの連続した投票の間に返答するという増加する確率で起こるのを防ぐために、PGM両親のSHOULDは投票ラウンドを使用します。 投票ラウンドで、PGM両親は、彼らが投票を始める子供の母集団のサイズを「凍らせ」て、複数の投票(同じPOLL_SQNにもかかわらず、異なったPOLL_ROUNDと)の向こう側に一定にそれを維持します。 POLL_ROUNDがゼロにすぎないか彼らが以前に投票を受けたならPGM子供が投票に応じるのを許容することによって、これは同じPOLL_SQNとゼロに合わせるために等しいPOLL_ROUNDと共に働いています。
Speakman, et. al. Experimental [Page 84] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[84ページ]RFC3208PGM
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の1つと異なったPOLL_SQNとPOLLsのためのどんな未定の回答も受けたPOLL MUSTキャンセルを受けるPGM子供。
For a given poll with probability of replying P, a PGM parent estimates the number of children as M / P, where M is the number of responses received. PGM parents SHOULD keep polling periodically and use some average of the result of recent polls as their estimate for the number of children.
返答Pの確率がある与えられた投票のために、PGM親はM/Pとして子供の数を見積もっています。そこでは、Mが受けられた応答の数です。 PGM両親のSHOULDは定期的に投票し続けて、子供の数に彼らの見積りとして最近の投票の結果の何らかの平均を使用します。
14.3.2. Specific Polls
14.3.2. 特定の投票
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を捜し求めるのに特定の投票を使用できました。 特定の投票はPOLL_S_TYPEでPGM_POLL_一般と異なった状態で特徴付けられます。 PGM子供は、無作為の条件と_POLL_S TYPEに基づいたことによるとPOLLの現在のオプションのときに特定の投票に答えるかどうか決めます。 オプションが解釈されるべき方法は_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を無視するのを必要とするかもしれません。
14.4. Procedures - PGM Parents (Sources or Network Elements)
14.4. 手順--PGM両親(ソースかネットワーク要素)
A PGM parent (source or network element), that wants to poll the first PGM-hop children connected to one of its outgoing interfaces MUST send a POLL packet on that interface with:
PGM親(ソースかネットワーク要素)でありそれはそのインタフェースで以下で外向的なインタフェースの1つに接続された子供が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のSQNが送ったPOLL_と等しいSQNが1つ増加したPOLL_。 投票ラウンドが使用されているなら、これは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のための最後のPOLL_ROUNDでなければなりませんかゼロはこれが1番目であるならこのPOLLの中で_SQNを一周させます。
Speakman, et. al. Experimental [Page 85] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[85ページ]RFC3208PGM
POLL_S_TYPE the type of the poll. For general poll use PGM_POLL_GENERAL
投票のタイプのPOLL_S_TYPE。 一般的な投票には、PGM_POLL_一般を使用してください。
POLL_PATH set to the NLA of the outgoing interface
POLL_PATHは外向的なインタフェースのNLAにセットしました。
POLL_BO_IVL set to the wanted reply back-off interval. As far as the choice of this is concerned, using NAK_BO_IVL is usually a conservative option, however a smaller value MAY be used, if the number of expected replies can be determined with a good confidence or if a conservatively low probability of reply (P) is being used (see POLL_MASK next). When the number of expected replies is unknown, a large POLL_BO_IVL SHOULD be used, so that the poll can be effectively aborted if the number of replies being received is too large.
POLL_BO_IVLは欲しい回答下に後部間隔までセットしました。 NAK_を使用して、これの選択に関する限り、通常、BO_IVLが保守的なオプションである、しかしながら、より小さい値は使用されるかもしれません、良い自信をもって予想された回答の数を測定できるか、または回答(P)の保守的に低確率が使用されているなら(次に、POLL_MASKを見てください)。 予想された回答の数が未知であるときに、大きい_POLL_ボーIVL SHOULDが使用されて、受け取るのは、事実上、回答の数であるなら投票を中止できるくらい大き過ぎます。
POLL_RAND MUST be a random string re-computed each time a new poll is sent on a given interface
POLL_RAND MUST、与えられたインタフェースで新しい投票を送るたびに再計算された無作為のストリングになってください。
POLL_MASK determines the probability of replying, P, according to the relationship P = 1 / ( 2 ^ B ), where B is the number of bits set in POLL_MASK [15]. If this is a deterministic poll, B MUST be 0, i.e. POLL_MASK MUST be a all-zeroes bit-mask.
POLL_MASKは返答するという確率を測定します、P、関係P=1/(2^B)に従って。そこでは、BがPOLL_MASK[15]に設定されたビットの数です。 これが決定論的な投票であるなら、Bは0、すなわち、POLL_MASK MUSTであるに違いありません。オールゼロビットマスクになってください。
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
背板嘆願: ネットワーク要素によって伝えられたPOLLsはネットワーク要素のNLAではなく、ODATAソースのネットワークヘッダーソースアドレスを示さなければなりません。 また、IPと共にPOLLsを伝えなければなりません。
Router Alert Option [6], to be allow PGM network element to intercept them.
ルータAlert Option[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パケットSHOULD待ちPOLL_BO_IVLを送ることによって投票を始めたPGM親。 この間隔、それ、SHOULDはすべての有効回答(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
PGM親SHOULDは応答の内部破裂を防ぐために基本手順の記述で言及した規則を守ります。 一般に、これらの規則は一般的な投票と特定の投票に関して守られるべきです。 しかしながら、回答の予想された数が小さいのが知られているなら決定論的な投票(内部破裂防止のない)を使用することで後者を実行できます。 子供人口サイズSHOULD使用に投票すると見積もる意図をもって一般的な投票を発行するPGM親は測定の過程にかかわる子供を「凍結」に一周させます。 これは、送付者が横切って「ドアを大きく開くこと」を許容します。
Speakman, et. al. Experimental [Page 86] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[86ページ]RFC3208PGM
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.
故joinersによる水につかることへの恐怖のないその後のラウンド(応答の確率を増加させるのによる)。 ラウンドの使用には人口サイズの見積りの追加遅れを導入する欠点があることに注意してください、丸いグループの終わりで得られた見積りが最初のラウンド時点の現在の状態について言及するとき。
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.
SHOULDが数をモニターする投票を始めたPGM親は収集段階の間、返答します。 これであるなら、大きくなり過ぎてください、SHOULDがすぐに新しい投票(異なったPOLL_SQN)を始めて、返答するという非常に低い確率を指定しながら投票を中止するPGM親。
When polling is being used to estimate the receiver population for the purpose of calculating NAK_BO_IVL, OPT_NAK_BO_IVL (see 16.4.1 below) MUST be appended to SPMs, MAY be appended to NCFs and POLLs, and in all cases MUST have NAK_BO_IVL_SQN set to POLL_SQN of the most recent complete round of polls, and MUST bear that round's corresponding derived value of NAK_BAK_IVL. In this way, OPT_NAK_BO_IVL provides a current value for NAK_BO_IVL at the same time as information is being gathered for the calculation of a future value of NAK_BO_IVL.
_投票するとき、NAK_BO_IVLについて計算する目的、OPT_NAKのために受信機人口を見積もるのに使用されるのが、BO_IVLである、(見る、16.4、.1、下) SPMsに追加しなければならなくて、NCFsとPOLLsに追加されるかもしれなくて、すべての場合でIVL_SQNが投票の最新の完成弾薬のPOLL_SQNに設定するNAK_BO_を持たなければならなくて、そのラウンドのNAK_BAK_IVLの対応する引き出している値に堪えなければなりません。 このように、BO_IVLが情報と同時にNAK_BO_IVLのための現行価値を供給するOPT_NAK_はNAK_BO_IVLの将来価値の計算のために集められています。
14.5. Procedures - PGM Children (Receivers or Network Elements)
14.5. 手順--PGM子供(受信機かネットワーク要素)
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を受け取るとき、それは、入って来るPOLLsのPOLL_RANDを合わせるのにRAND_NODE_IDを使用しなければなりません。 マッチはPOLL_MASKによって指定されたビットに制限されます。 入って来るPOLLがすべてのゼロで作られたPOLL_MASKを含んでいるなら、POLL_RAND(決定論的な回答)の内容にもかかわらず、マッチはうまくいっています。 マッチが失敗するなら受信機かネットワーク要素が少しもさらなる動作なしでPOLLを捨てなければならなくて、さもなければ、TYPEとどんなPGMオプションも決定するために中にPOLLを含んだ分野POLL_ROUND、POLL_S_をチェックしなければならない、それ、SHOULDは投票に答えます。
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_一般と等しいなら、PGMオプションの存在にもかかわらず、PGM子供はPOLLパケットの上でPOLLに回答の計画をしなければなりません。
Speakman, et. al. Experimental [Page 87] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[87ページ]RFC3208PGM
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_一般と異なるなら、回答が予定されるべきであるかどうかに関する決定は実際のタイプと、そして、ことによると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の受取人にとって、POLL_S_TYPEが未知であるなら、それは、返答して、投票を無視してはいけません。 _現在の、TYPEが定義した唯一のPOLL_S_はPGM_POLL_一般であり、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受信機かネットワーク要素が、POLLに答えると決めたなら、それは将来、無作為の時に独身のPOLRのトランスミッションの計画をしなければなりません。 無作為の遅れは間隔[0、POLL_BO_IVL]で選ばれています。 POLL_BO_IVLは受け取られたPOLLに含まれたものです。 このタイマが期限が切れると、送付先アドレスとして容認されたPOLLのPOLL_PATHを使用して、それはPOLRを送らなければなりません。 POLR_SQN MUST、_POLLの同輩がROUNDであったに違いないならPOLL_SQNとPOLR_ROUNDと等しくいてください。 _POLL_S TYPEの意味かことによるとPOLLの現在のPGMオプションの意味によると、POLR MAYはPGMオプションを含んでいます。 POLL_S_TYPEがPGM_POLL_一般であるなら、どんなオプションもREQUIREDではありません。
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.
POLRsの計画をした投票のPOLR_SQNと異なったPOLL_SQNと共に新しいPOLLを受け取るなら、PGM受信機かネットワーク要素がPOLRsのどんな未定のトランスミッションも中止しなければなりません。
14.6. Constant Definition
14.6. 一定の定義
The POLL_S_TYPE values currently defined are:
現在定義されているPOLL_S_TYPE値は以下の通りです。
PGM_POLL_GENERAL 0
PGM_投票_一般的な0
PGM_POLL_DLR 1
PGM_投票_DLR1
14.7. Packet Formats
14.7. パケット・フォーマット
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.
Data-ソースPort、Data-目的地Port、Options、Checksum、Global Source ID(GSI)、およびTSDU Lengthの記述はセクション8に提供されたものです。
14.7.1. Poll Request
14.7.1. 投票要求
POLL are sent by PGM parents (sources or network elements) to initiate a poll among their first PGM-hop children.
POLLは、彼らの最初のPGM-ホップ子供で投票を開始するためにPGM両親(ソースかネットワーク要素)によって送られます。
Speakman, et. al. Experimental [Page 88] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[88ページ]RFC3208PGM
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マルチキャストグループにPOLLsを送ります。 POLLのネットワークヘッダーソースアドレスはODATAソースのNLAです。 POLL MUST、IP Router Alert Optionと共に伝えられてください。
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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース港| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 投票の一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 投票のラウンド| 投票のサブタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLA AFI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路NLA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ | 投票の下に後部間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 無作為のストリング| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合っているビットマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 存在しているときのオプションExtensions… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:
ソース港:
POLL_SPORT
投票_スポーツ
Data-Source Port, together with POLL_GSI forms POLL_TSI
POLL_GSIフォームに伴うデータソースPort POLL_TSI
Destination Port:
仕向港:
POLL_DPORT
投票_DPORT
Data-Destination Port
データ仕向港
Type:
以下をタイプしてください。
POLL_TYPE = 0x01
投票_タイプ=0x01
Speakman, et. al. Experimental [Page 89] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[89ページ]RFC3208PGM
Global Source ID:
グローバルなソースID:
POLL_GSI
投票_GSI
Together with POLL_SPORT forms POLL_TSI
POLL_と共に、SPORTはPOLL_TSIを形成します。
POLL's Sequence Number
投票の一連番号
POLL_SQN
投票_SQN
The sequence number assigned to the POLL by the originator.
創始者によってPOLLに割り当てられた一連番号。
POLL's Round
投票のラウンド
POLL_ROUND
投票_ラウンド
The round number within the poll sequence number.
投票一連番号の中の概数。
POLL's Sub-type
投票のサブタイプ
POLL_S_TYPE
投票_S_はタイプします。
The sub-type of the poll request.
投票要求のサブタイプ。
Path NLA:
経路NLA:
POLL_PATH
投票_経路
The NLA of the interface on the source or network element on which this POLL was forwarded.
このPOLLが進められたソースかネットワーク要素の上のインタフェースのNLA。
POLL's Back-off Interval
投票の下に後部間隔
POLL_BO_IVL
_投票_棒IVL
The back-off interval used to compute a random back-off for the reply, expressed in microseconds.
下に後部間隔はマイクロセカンドのときに言い表された回答のために以前はよく下に無作為の後部を計算していました。
Random String
無作為のストリング
POLL_RAND
投票_底ならし革
A random string used to implement the random condition in replying.
無作為のストリングは以前は返答する際に無作為の条件をよく満たしていました。
Speakman, et. al. Experimental [Page 90] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[90ページ]RFC3208PGM
Matching Bit-Mask
合っているビットマスク
POLL_MASK
投票_マスク
A bit-mask used to determine the probability of random replies.
無作為の回答の確率を測定するのに使用されて、少しマスクをかけます。
14.7.2. Poll Response
14.7.2. 投票応答
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のネットワークヘッダー送付先アドレスはPOLLの創始者によってPOLRの引き金となったPOLLから知られている上流のPGM要素(ソースかネットワーク要素)のユニキャストNLAに初期化されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Options | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Source ID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Global Source ID | TSDU Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POLR's Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POLR's Round | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Extensions when present ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース港| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプション| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなソースID… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... グローバルなソースID| TSDUの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POLRの一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POLRのラウンド| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 存在しているときのオプションExtensions… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:
ソース港:
POLR_SPORT
POLR_スポーツ
Data-Destination Port
データ仕向港
Destination Port:
仕向港:
POLR_DPORT
POLR_DPORT
Data-Source Port, together with Global Source ID forms POLR_TSI
Global Source IDフォームに伴うデータソースPort POLR_TSI
Speakman, et. al. Experimental [Page 91] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[91ページ]RFC3208PGM
Type:
以下をタイプしてください。
POLR_TYPE = 0x02
POLR_タイプ=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_ラウンド
The round number (POLL_ROUND) of the POLL packet for which this is a reply.
これが回答であるPOLLパケットの概数(POLL_ROUND)。
15. Appendix E - Implosion Prevention
15. 付録E--内部破裂防止
15.1. Introduction
15.1. 序論
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_BO_IVL、また、彼らは適応型にNAK下に後部間隔を調整する手段を提供します。
The PGM virtual topology is established and refreshed by SPMs. Between one SPM and the next, PGM nodes may have an out-of-date view of the PGM topology due to multicast routing changes, flapping, or a link/router failure. If any of the above happens relative to a PGM parent node, a potential NAK implosion problem arises because the parent node is unable to suppress the generation of duplicate NAKs as it cannot reach its children using NCFs. The procedures described below introduce an alternative way of performing suppression in this case. They also attempt to prevent implosion by adaptively tuning NAK_BO_IVL.
PGMの仮想のトポロジーは、SPMsによって設置されて、リフレッシュされます。1SPMで次の間では、PGMノードはマルチキャストルーティング変化、ばたつくこと、またはリンク/ルータ失敗のためPGMトポロジーの時代遅れな視点を持っているかもしれません。 上記のどれかがPGM親ノードに比例して起こるなら、NCFsを使用することで子供に届くことができないで親ノードが写しNAKsの世代を抑圧できないので、潜在的NAK内部破裂問題は起こります。 以下で説明された手順はこの場合抑圧を実行する代替の方法を導入します。 また、彼らは、適応型調律NAK_BO_IVLによる内部破裂を防ぐのを試みます。
Speakman, et. al. Experimental [Page 92] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[92ページ]RFC3208PGM
15.2. Tuning NAK_BO_IVL
15.2. _調律NAK_棒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.
ソースとネットワーク要素は、絶え間なく受け取られたコピーされたNAKsの数をモニターして、それらに接続された最初のPGM-ホップ受信機のために、NAK下に後部間隔(NAK_BO_IVL)を調整するのにこの観測を使用します。 受信機はBO_IVLがNCFsかSPMsに追加したOPT_NAK_を通してNAK_BO_IVLの現行価値を学びます。
15.2.1. Procedures - Sources and Network Elements
15.2.1. 手順--ソースとネットワーク要素
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に関しては、ソースとネットワーク要素はインタフェースが最初に修理州のリストに追加された時から修理状態が捨てられる時まで特定の修理状態(すなわち、1TSIあたりの一連番号あたりの)に受け取られたNAKsの数を数えます。 次に、彼らはNAK_BO_IVLの現行価値を以下の通りに調整するのにこの数を使用します:
Increase the current value NAK_BO_IVL when the first duplicate NAK is received for a given SQN on a particular interface.
与えられたSQNのために特定のインタフェースに最初の写しNAKを受け取るときには現行価値NAK_BO_IVLを増加させてください。
Decrease the value of NAK_BO_IVL if no duplicate NAKs are received on a particular interface for the last NAK_PROBE_NUM measurements where each measurement corresponds to the creation of a new repair state.
各測定が新しい修理状態の創設に対応する最後のNAK_PROBE_NUM測定値のために特定のインタフェースに写しNAKsを全く受け取らないなら、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_ボー_IVL_DEFAULTです。 増加して減少している_NAK_BO IVLのためのRECOMMENDEDがそれぞれ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.
ソースとネットワーク要素はOPT_NAK_BO_IVLを通したそれらがNCFsに追加するNAK_BO_IVLの現行価値の広告を出します。 また、彼らはOPT_NAK_BO_IVLを出発しているSPMsに追加するかもしれません。
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.
IVLが親で広告を出したNAK_BO_を進めるのを避けるために、ネットワーク要素はOPT_NAK_BO_IVLを認識できなければなりません。 OPT_NAK_ボー_IVL MUSTを含むSPMsを受けるネットワーク要素が、オプションを移すか、またはNAK_の現行価値に満足している(NAK_BO_IVL)BO_IVLを外向的なインタフェースに上書きします、SPMsを進める前に。
Speakman, et. al. Experimental [Page 93] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[93ページ]RFC3208PGM
Sources MAY advertise the value of NAK_BO_IVL_MAX and NAK_BO_IVL_MIN to the session by appending a OPT_NAK_BO_RNG to SPMs.
ソースは、OPT_NAK_BO_RNGをSPMsに追加することによって、セッションまでNAK_BO_IVL_MAXとNAK_BO_IVL_MINの値の広告を出すかもしれません。
15.2.2. Procedures - Receivers
15.2.2. 手順--受信機
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.
受信機はオプションOPT_NAKで_BO_IVLを使用するためにNAK_BO_IVLの値を学びます、これがNCFsかSPMsに存在しているとき。NAK_BO_IVL_SQNがゼロであるか受信機が、POLL_SQNのためのPOLL_RND=0が一連番号スペースの半分の中で<NAK_BO_IVL_SQNと等しいのを見ていない場合、NAK_BO_IVLのための値は、OPT_NAK_ボー_IVL MUST NOTから受信機によって使用されるように学びました。 NAK_BO_IVLの初期の値はNAK_ボー_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_ボー_RNG MUSTを含むSPMを受ける受信機は、NAK_BO_IVL_MAXとNAK_BO_IVL_MINの地方の値を設定するのに内容を使用します。
15.2.3. Adjusting NAK_BO_IVL in the absence of NAKs
15.2.3. NAKsが不在のときNAK_BO_IVLを調整します。
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.
写しNAKsの数をモニターすると、間接的に最初に、PGM-ホップ受信機人口のサイズにおける変化を追って、それに従って、NAK_BO_IVLを調整する手段は提供されます。 与えられたSQNのための写しNAKsの数が最初に、PGM-ホップ子供の無名数ではなく、最初に、NAKの計画をした(または、進めます)PGM-ホップ子供の数に関連することに注意してください。 しかしながら、このメカニズムはパケット損失が不在のとき動作しません、したがって、多くの写しNAKsが期間の後にNAKsなしで可能です、多くの新しい受信機がその間セッションに参加しているなら。 SHOULDが定期的に投票するこの問題、PGM Sources、およびネットワーク要素を記述するために、最初に、「一般的な投票」手順を用いているPGM-ホップ子供の数はAppendix D.Ifで投票ショーの結果について説明しました。人口サイズが期間、NAKsなしでかなり増加していて、彼らがSHOULDであることは安全対策としてNAK_BO_IVLを増加させます。
15.3. Containing Implosion in the Presence of Network Failures
15.3. ネットワーク失敗があるとき内部破裂を含んでいます。
15.3.1. Detecting Network Failures
15.3.1. ネットワーク失敗を検出します。
In some cases PGM (parent) network elements can promptly detect the loss of all or part of the suppressing multicast distribution tree (due to network failures or route changes) by checking their multicast connectivity, when they receive NAKs. In some other cases this is not possible as the connectivity problem might occur at some other non-PGM node downstream or might take time to reflect in the multicast routing table. To address these latter cases, PGM uses a simple heuristic: a failure is assumed for a TSI when the count of duplicated NAKs received for a repair state reaches the value DUP_NAK_MAX in one of the interfaces.
いくつかの場合、PGM(親)ネットワーク要素はそれらのマルチキャストの接続性をチェックすることによって、即座に、すべての損失か抑圧しているマルチキャスト分配木の一部(ネットワーク失敗かルート変化による)を検出できます、彼らがNAKsを受けるとき。 ある他の場合では、接続性問題がある他の非PGMノード川下に起こるか、またはマルチキャスト経路指定テーブルで反射するには時間がかかるかもしれないので、これは可能ではありません。 これらの後者のケースを記述するために、PGMは簡単なヒューリスティックを使用します: 修理状態に受け取られたコピーされたNAKsのカウントがインタフェースの1つで値のDUP_NAK_MAXに達するとき、失敗はTSIのために想定されます。
Speakman, et. al. Experimental [Page 94] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[94ページ]RFC3208PGM
15.3.2. Containing Implosion
15.3.2. 内部破裂を含んでいます。
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エージェント(受信機かネットワーク要素のどちらか他の)へマルチキャストの接続性を発射する失敗を検出するか、または仮定すると、それはNAKsに対応してユニキャストNCFsを彼らに送ります。 マルチキャストセッションまでユニキャストNCFsを受けて、マルチキャストの接続性を持っている川下のPGMネットワーク要素は、ソースによって送られた通常のSPMがPGM木をリフレッシュするまで一層のNAKsを防ぐために特別なSPMsを送ります。
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を通してNAKsを確認するのに戻ります。 PGMエージェントがSPMを発生させなければならないよりTSI(発信に加えたユニキャストNCF)ためのソース自体であるなら
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のためにNAKsを進めるのをTSIのために通常のSPMを受けるまで止めなければなりません。 また、さらに、それは、川下で受信機が、より多くのNAKsを送るのを防ぐために特別なSPMを発生させなければなりません。 この特別なSPM MUSTはOPT_NBR_UNREACHオプションを含んでいます、そして、SHOULDには、最後の通常のSPMのSQNが進めたSPM_と等しいSPM_SQNがあります。 OPT_NBR_UNREACHオプションはSPMs(SPM_TRAILとSPM_LEAD)のウインドー情報を無効にします。 PGMはOPT_NBR_UNREACHオプションSHOULDがSPM_TRAILを0に設定することによってウインドー情報を無効にすると言い足す要素とSPM_LEADを0×80000000までネットワークでつなぎます。
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
SPM_PATHがOPT_NBR_UNREACHオプションを含むSPMを受けて、現在知られているPGM親を合わせて、正常な方法でそれらを進めなければならなくて、止まらなければならないPGMネットワーク要素
Speakman, et. al. Experimental [Page 95] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[95ページ]RFC3208PGM
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.
彼らがTSIのために通常のSPMを受けるまで、TSIのためにNAKsを進めます。 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.
OPT_NBR_UNREACHオプションを含むNCFかSPMのどちらかを受けるPGM受信機は、TSIのために通常のSPMを受け取るまでNAKsを送るのを止めなければなりません。
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インタフェースの1つに用意ができているTTLと共にパケットのマルチキャストコピーを発生させなければなりません。 これは、同じサブネットにおける他の受信機がNAKsを発生させるのを防ぐでしょう。
Receivers MUST ignore windowing information in SPMs which contain the OPT_NBR_UNREACH option.
受信機はOPT_NBR_UNREACHオプションを含むSPMsのウインドー情報を無視しなければなりません。
Receivers MUST ignore NCFs containing the OPT_NBR_UNREACH option if the OPT_PATH_NLA specifies a neighbour different than the one currently know to be the PGM parent neighbour. Similarly receivers MUST ignore SPMs containing the OPT_NBR_UNREACH option if SPM_PATH does not match the current PGM parent.
受信機はOPT_PATH_NLAが人が、現在PGM親隣人であることを知っているより異なった隣人を指定するならOPT_NBR_UNREACHオプションを含むNCFsを無視しなければなりません。 同様に、受信機はSPM_PATHが現在のPGM親に合っていないならOPT_NBR_UNREACHオプションを含むSPMsを無視しなければなりません。
15.4. Packet Formats
15.4. パケット・フォーマット
15.4.1. OPT_NAK_BO_IVL - Packet Extension Format
15.4.1. __NAK_棒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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK Back-Off Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK Back-Off Interval SQN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK下に後部間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK下に後部間隔SQN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x04
オプションタイプ=0x04
NAK Back-Off Interval
NAK下に後部間隔
The value of NAK-generation Back-Off Interval in microseconds.
マイクロセカンドのNAK-世代下にBack Intervalの値。
Speakman, et. al. Experimental [Page 96] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[96ページ]RFC3208PGM
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が世論調査(Appendix Dを見る)で決定していなくて、すぐに使用されるかもしれないことを意味します。 そうでなければ、NAK_ボー_IVL MUST NOT、受信機にまた、見られたPOLL_ROUND=0がない場合、POLL_SQN=<NAK_BO_IVL_SQNには、一連番号スペースの半分の中で使用されてください。
OPT_NAK_BO_IVL MAY be appended to NCFs, SPMs, or POLLs.
OPT_NAK_BO_IVL MAY、NCFs、SPMs、またはPOLLsに追加してください。
OPT_NAK_BO_IVL is network-significant.
OPT_NAK_BO_IVLはネットワーク重要です。
15.4.2. OPT_NAK_BO_RNG - Packet Extension Format
15.4.2. __NAK_棒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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum NAK Back-Off Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum NAK Back-Off Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のNAK下に後部間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のNAK下に後部間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type = 0x05
オプションタイプ=0x05
Maximum NAK Back-Off Interval
最大のNAK下に後部間隔
The maximum value of NAK-generation Back-Off Interval in microseconds.
マイクロセカンドのNAK-世代下にBack Intervalの最大値。
Minimum NAK Back-Off Interval
最小のNAK下に後部間隔
The minimum value of NAK-generation Back-Off Interval in microseconds.
マイクロセカンドのNAK-世代下にBack Intervalの最小値。
OPT_NAK_BO_RNG MAY be appended to SPMs.
OPT_NAK_BO_RNG MAY、SPMsに追加してください。
OPT_NAK_BO_RNG is network-significant.
OPT_NAK_BO_RNGはネットワーク重要です。
15.4.3. OPT_NBR_UNREACH - Packet Extension Format
15.4.3. _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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Speakman, et. al. Experimental [Page 97] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[97ページ]RFC3208PGM
Option Type = 0x0B
オプションタイプは0x0Bと等しいです。
When present in SPMs, it invalidates the windowing information.
SPMsに存在しているとき、それはウインドー情報を無効にします。
OPT_NBR_UNREACH MAY be appended to SPMs and NCFs.
OPT_NBR_UNREACH MAY、SPMsとNCFsに追加してください。
OPT_NBR_UNREACH is network-significant.
OPT_NBR_UNREACHはネットワーク重要です。
15.4.4. OPT_PATH_NLA - Packet Extension Format
15.4.4. _経路_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Option Type | Option Length |Reserved |F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| オプションタイプ| オプションの長さ|予約されます。|F|OPX|U| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路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.
それがこのオプションを含むパケットの受取人にマルチキャストSPMsを送るのに使用する由来しているPGMネットワーク要素の上のインタフェースのNLA。
OPT_PATH_NLA MAY be appended to NCFs.
OPT_PATH_NLA MAY、NCFsに追加してください。
OPT_PATH_NLA is network-significant.
OPT_PATH_NLAはネットワーク重要です。
16. Appendix F - Transmit Window Example
16. 付録F--窓の例を伝えてください。
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.
背板嘆願: そして、概念、増分のウィンドウ(TXW_INC)とこのドキュメント中の窓の増分(TXW_ADV_SECS)のすべての参照が説明に役立った目的だけのためのものです。 彼らが前進の概念について説明する速記を提供する、どんな特定の実現も含意するか、前進の方針なしでも窓を伝えてください。
The size of the transmit window in seconds is simply TXW_SECS. The size of the transmit window in bytes (TXW_BYTES) is (TXW_MAX_RTE * TXW_SECS). The size of the transmit window in sequence numbers (TXW_SQNS) is (TXW_BYTES / bytes-per-packet).
窓を伝えてください。サイズ、秒に、単にTXW_SECSがあります。 バイトで窓を伝えてください。サイズ、(TXW_BYTES)は(TXW_マックス_RTE*TXW_SECS)です。 一連番号で窓を伝えてください。サイズ、(TXW_SQNS)は(1パケットあたりの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)を伝えてください。断片、ウィンドウサイズ(秒のデータの)を伝える、どれ、窓の増分と呼ばれるか。 窓自体を伝えてください。そのような(最も古い)の断片を引きずる、増分のウィンドウと呼ばれます。
Speakman, et. al. Experimental [Page 98] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[98ページ]RFC3208PGM
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.
一連番号に関して、増分のウィンドウが1番目である吐き出される一連番号の範囲である、窓を伝えてください。 増分のウィンドウの引きずっている(または、残される)縁はただTXW_TRAILです、引きずっている(または、残される)縁、窓を伝えてください。 増分のウィンドウ(TXW_INC)の主、そして、(正しい)の縁はTXW_TRAILを伝えた後に最初のデータ・パケットの一連番号がソースTXW_ADV_SECSで伝わったより少ない1つと定義されます。
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.
データ・パケットが“in"であるとして記述されている、それぞれ伝わるか、または窓を増加してください、一連番号が定義された範囲にあるならそれぞれ伝わるか、または窓を増加してください。
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_ADV_SECSが、より遅れているか、(すなわち、TXW_TRAILはデータについてTXW_ADV_SECSによってTXW_INCと切り離されます)再び、などに進められた窓を伝えてください。
16.1. Advancing across the Increment Window
16.1. 増分のウィンドウの向こう側に進みます。
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_TMRを始動します(期間のTXW_ADV_IVLに立候補します)。 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が走っているとき、増分のウィンドウのパケットのためにNAKsを受け取るなら、ソースは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が期限が切れて、ソースSHOULD進歩がトレーリングエッジであるか、TXW_TRAILからTXW_INCまで窓を伝えてください。
Once the transmit window is advanced across the increment window, SPM_TRAIL, OD_TRAIL and RD_TRAIL are set to the new value of TXW_TRAIL in all subsequent transmitted packets, until the next window advancement.
一度、増分のウィンドウの向こう側に進められた窓を送ってください、そして、SPM_TRAIL、過量_TRAIL、およびRD_TRAILはすべてのその後の伝えられたパケットのTXW_TRAILの新しい値へのセットです、次の窓の前進まで。
PGM does not constrain the strategies that a source may use for advancing the transmit window. The source MAY implement any scheme or number of schemes. Three suggested strategies are outlined here.
PGMがソースが進むのに使用するかもしれない戦略を抑制しない、窓を伝えてください。 ソースはどんな計画や数の計画も実行するかもしれません。 3は、戦略がここに概説されているのを示しました。
Speakman, et. al. Experimental [Page 99] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[99ページ]RFC3208PGM
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
aが一定であると仮定して、128kbpsのレートと1500バイトの一定のデータ・パケットサイズを伝えてください、ソースが修理と増分のための過去の30秒のデータを保守するならそれ、中の5秒が増加する窓を伝えてください、そして
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秒、35秒のTXW_SECS=、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_マックス_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
TXW_道のTXW_リード| | | | |--|--------------- 窓を伝えてください。-------------|----| v| | v対n-1に| n| n+1| ... | n+53| n+54| ... | n+381| n+382| n+383 ^ ^ | ^ |--- 増分のウィンドウ|---| | | 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は+53 n TXW_INC=n 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バイトの一定のデータ・パケットサイズの仮定のために決定できます。 データ・パケットサイズが可変であるか、より多くより少ない一連番号5月であるときには、同じ量(TXW_BYTES)のデータを送りながら、消費されてください。
So, for a given transport session identified by a TSI, a source maintains:
それで、TSIによって特定された与えられた輸送セッションのためにソースは以下を維持します。
Speakman, et. al. Experimental [Page 100] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[100ページ]RFC3208PGM
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 a最大が1秒あたりのkBytesでレートを伝えるとSPMs、ODATA、およびRDATA依存の何らかの組み合わせの速度を伝える、窓の前進戦略を伝えてください。
TXW_TRAIL the sequence number defining the trailing edge of the transmit window, the sequence number of the oldest data packet available for repair
TXW_TRAIL、トレーリングエッジを定義する一連番号、窓を伝えてください、修理に利用可能な最も古いデータ・パケットの一連番号
TXW_LEAD the sequence number defining the leading edge of the transmit window, the sequence number of the most recently transmitted ODATA packet
TXW_LEAD、リーディングエッジを定義する一連番号、窓を伝えてください、最も最近伝えられたODATAパケットの一連番号
TXW_INC the sequence number defining the leading edge of the increment window, the sequence number of the most recently transmitted data packet amongst those that will expire upon the next increment of the transmit window
TXW_INC、一連番号が増分のウィンドウのリーディングエッジを定義して、大部分の一連番号が最近それが次の増分で期限が切れるそれらにデータ・パケットを伝えた、窓を伝えてください。
PGM does not constrain the strategies that a source may use for advancing the transmit window. A source MAY implement any scheme or number of schemes. This is possible because a PGM receiver must obey the window provided by the source in its packets. Three strategies are suggested within this document.
PGMがソースが進むのに使用するかもしれない戦略を抑制しない、窓を伝えてください。 ソースはどんな計画や数の計画も実行するかもしれません。 PGM受信機がパケットのソースによって提供された窓に従わなければならないので、これは可能です。 3つの戦略がこのドキュメントの中に示されます。
In the first, called "Advance with Time", the transmit window maintains the last TXW_SECS of data in real-time, regardless of whether any data was sent in that real time period or not. The actual number of bytes maintained at any instant in time will vary between 0 and TXW_BYTES, depending on traffic during the last TXW_SECS. In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs and ODATA.
「時間との進歩」と呼ばれる1番目、データの最後のTXW_SECSをコネリアルタイムで維持して、そのリアルタイムの期間にどんなデータもそうであったかどうかにかかわらず送られて、窓を伝えてください。 時間内にどんな瞬間にも維持されたバイトの実数は0とTXW_BYTESの間で異なるでしょう、最後のTXW_SECSの間、交通によって。 この場合、累積がSPMsとODATAのレートを伝えるというTXW_MAX_RTEによることです。
In the second, called "Advance with Data", the transmit window maintains the last TXW_BYTES bytes of data for repair. That is, it maintains the theoretical maximum amount of data that could be transmitted in the time period TXW_SECS, regardless of when they were transmitted. In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs, ODATA, and RDATA.
窓を伝えてください。「データとの進歩」と呼ばれる2番目、最後のTXW_BYTESが修理のためのバイトのデータであることを支持します。 期間のTXW_SECSで伝えることができた理論上の最大のデータ量を維持します、彼らが伝えられた時にかかわらず。 この場合、累積がSPMs、ODATA、およびRDATAのレートを伝えるというTXW_MAX_RTEによることです。
The third strategy leaves control of the window in the hands of the application. The API provided by a source implementation for this, could allow the application to control the window in terms of APDUs and to manually step the window. This gives a form of Application Level Framing (ALF). In this case, TXW_MAX_RTE is the cumulative transmit rate of SPMs, ODATA, and RDATA.
3番目の戦略はアプリケーションの手での窓のコントロールを残します。 これのためのソース実現で提供されたAPI、アプリケーションがAPDUsに関して窓を制御して、手動で窓を踏むのを許容できました。 これはApplication Level Framing(ALF)の書式を与えます。 この場合、累積がSPMs、ODATA、およびRDATAのレートを伝えるというTXW_MAX_RTEによることです。
Speakman, et. al. Experimental [Page 101] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[101ページ]RFC3208PGM
16.2. Advancing with Data
16.2. データと共に進みます。
In the first strategy, TXW_MAX_RTE is calculated from SPMs and both ODATA and RDATA, and NAKs reset TXW_ADV_IVL_TMR. In this mode of operation the transmit window maintains the last TXW_BYTES bytes of data for repair. That is, it maintains the theoretical maximum amount of data that could be transmitted in the time period TXW_SECS. This means that the following timers are not treated as real-time timers, instead they are "data driven". That is, they expire when the amount of data that could be sent in the time period they define is sent. They are the SPM ambient time interval, TXW_ADV_SECS, TXW_SECS, TXW_ADV_IVL, TXW_ADV_IVL_TMR and the join interval. Note that the SPM heartbeat timers still run in real-time.
窓を伝えてください。最初の戦略で、TXW_MAX_RTEがSPMsから計算されて、この運転モードがNAKsリセットTXW_ADV_IVL_TMR ODATAとRDATAとコネの両方が計算される、最後の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が走っている間、それが窓の前進を伝えて、増分のウィンドウのデータのためのNAKsが全くTXW_ADV_IVL秒の間、見られないまでタイマTXW_ADV_IVL_TMRをTXW_ADV_IVLにリセットする増分のウィンドウの中の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.
この運転モードは遅れを犠牲にして完全なデータの領収書に基づく非リアルタイムのメッセージングアプリケーションのために意図します。
16.3. Advancing with Time
16.3. 時間と共に進みます。
This strategy advances the transmit window in real-time. In this mode of operation, TXW_MAX_RTE is calculated from SPMs and ODATA only to maintain a constant data throughput rate by consuming extra bandwidth for repairs. TXW_ADV_IVL has the value 0 which advances the transmit window without regard for whether NAKs for data in the increment window are still being received.
この戦略が進む、リアルタイムでで窓を伝えてください。 この運転モードで、TXW_MAX_RTEはSPMsとODATAから計算されますが、修理のために余分な帯域幅を消費することによって、一定のデータ押出量を維持します。 TXW_ADV_IVLには進む値0がある、まだ増分のウィンドウのデータのためのNAKsを受け取っているかどうかへの尊敬なしで窓を伝えてください。
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.
この運転モードはリアルタイム(完全性を犠牲にしてタイムリーなデータの領収書に基づくストリーミング・アプリケーション)に意図します。
Speakman, et. al. Experimental [Page 102] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[102ページ]RFC3208PGM
16.4. Advancing under explicit application control
16.4. 明白なアプリケーション制御装置の下で進みます。
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.
いくつかのアプリケーションが、より明白なコントロールを願うかもしれない、上で進歩でデータ/時間戦略に提供されたそれより窓を伝えてください。 実現は、この運転モードを前提として、アプリケーションがAPDUsに関して明らかに窓を制御するのを許容するかもしれません。
17. Appendix G - Applicability Statement
17. 付録G--適用性証明
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つの輸送要素のprototypical本質で。 これらは、このクラスの信頼できるマルチキャストプロトコルのための輻輳制御と、ルータアシストと、地方の「再-トランスミッション」と、プログラムに従ったAPIです。 標準化が結果で処理するこの公表は、一般に、これらの要素で実験を伸ばして、それぞれこれらの要素の標準化努力アドレスと同時に個別に、知らせるつもりです。練習してください。
This section briefly describes some of the experimental aspects of PGM and makes non-normative references to some examples of current practise based upon them.
このセクションは、簡潔にPGMの実験局面のいくつかについて説明して、それらに基づいた状態で電流に関するいくつかの例の非引用規格を練習させます。
At least 3 different approaches to congestion control can be explored with PGM: a receiver-feedback based approach, a router-assist based approach, and layer-coding based approach. The first is supported by the negative acknowledgement mechanism in PGM augmented by an application-layer acknowledgement mechanism. The second is supported by the router exception processing mechanism in PGM. The third is supported by the FEC mechanisms in PGM. An example of a receiver- feedback based approach is provided in [16], and a proposal for a router-assist based approach was proposed in [17]. Open issues for the researchers include how do each of these approaches behave in the presence of multiple competing sessions of the same discipline or of different disciplines, TCP most notably; how do each of them behave over a particular range of topologies, and over a particular range of loads; and how do each of them scale as a function of the size of the receiver population.
PGMと共に輻輳制御への少なくとも3つの異なるアプローチについて調査できます: 受信機フィードバックはアプローチを基礎づけました、そして、ルータアシストはアプローチを基礎づけました、そして、層コード化はアプローチを基礎づけました。 1番目は応用層承認メカニズムによって増大させられるPGMの否定的承認メカニズムによって支持されます。 2番目はPGMのルータ例外処理メカニズムによって支持されます。 3番目はPGMのFECメカニズムによって支持されます。 フィードバックが基礎づけた受信機アプローチに関する例を[16]に提供しました、そして、ルータアシストがアプローチを基礎づけたので、[17]で提案を提案しました。 研究者がどのようにを入れるかので、未解決の問題はします。それぞれのこれらのアプローチは同じ規律か異なった規律の倍数競争セッション、TCPの面前で最も著しく振る舞います。 それぞれの彼らはtopologiesの特定の範囲の上と、そして、特定の範囲の負荷の上でどのように振る舞うか。 そして、それぞれのそれらは受信機人口のサイズの関数としてどのように比例しますか?
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
ルータアシストは、この仕様で説明されるようにアプリケーションがまさしく内部破裂に制御して、規制を再送しないのをさせますが、混雑に、状態と処理は一般にアクセスで高められるどんな特徴への説明されて、よりその他としてもネットワーク要素単位でまた制御されています。 まだこれらの特徴の最大限の範囲はそうです。
Speakman, et. al. Experimental [Page 103] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[103ページ]RFC3208PGM
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の仕様と最後の規格化にフィードバックされ続けるでしょう。 再送してください。そして、[20] [21]) 未決問題が研究者([19]に面していて、ルータを拠点とする州がどう利益が得た特徴、どのようにに比例してシステム全体の要素をスケーリングするかを含めてください、(スループットなど、潜在) 配備されたルータ支援と、増加の展開問題がどう基づくルータアシスト機能の御しやすさに影響するかに関するスケールとトポロジーに比例して、異なってください。 ルータアシストは輻輳制御の領域に追加意味をそれが粒状を増加させて、受信機に基づいている輻輳制御のレイテンシを減少させるためにマルチグループの層にされたコード構成で適用されるかもしれないという範囲まで持っているかもしれません。
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の2、3のホストサイド実現と並立している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
恐らくPGMが妥当なスケール実験トランスポート・プロトコルを使用している研究者の共同体で可能にすることができる中で最も広い実験は単にIPの定義、実現、および展開中です。
Speakman, et. al. Experimental [Page 104] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[104ページ]RFC3208PGM
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によって提供された信頼性が重要なイネーブラであるマルチキャストアプリケーション。 そのようなアプリケーションの経験はただ信頼できるマルチキャストの値を照らさないでしょう、また、付き添いの政策問題(じっと見る支払い、アクセス管理、ファイアウォール、NATsなどの)への実技試験と応答を引き起こして、うまくいくと結局IPマルチキャスト自体の、より広い普及の展開を奨励するのを除いて。
18. Abbreviations
18. 略語
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アプリケーションレベルのデータ単位のARQの自動反復要求縁どりAPDUアプリケーション・プロトコルDLRはグローバルにユニークなソースのNAK否定応答NCF NAK確認NLA識別子FEC前進型誤信号訂正MD5メッセージダイジェストアルゴリズムMTUマキシマム・トランスミッション・ユニットネットワーク層に地元の修理工GSIを指定しました; ヌルオリジナルのアドレスの投票応答RDATA修理データNNAK否定応答ODATAデータ投票投票要求POLR RSNはソース経路メッセージSPMR SPMが、TGトランスミッショングループTGSIZEトランスミッショングループサイズTPDUトランスポート・プロトコルデータ単位TSDU輸送サービスデータ単位TSI輸送セッション識別子TSNが州の通知を伝えるよう要求するという州の通知SPMを受けます。
Speakman, et. al. Experimental [Page 105] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[105ページ]RFC3208PGM
19. Acknowledgements
19. 承認
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ジョエル・Bionマークボウルズ・スティーブ・デアリングTugrul Firatliダン・ハーキン・ディマ・Khouryジェラード・ニューマン・デーヴ・オランデニー・Pageケン・Pillay Chetanライ・ヤコフ・Rekhterデーヴ・ロゼッティ・ポール・Stirpeブライアン・Whettenカイルヨーク
20. References
20. 参照
[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.キャプラン、「分散システムにおける理論と習慣」における「マルチキャストプロトコルが完全に注文された高性能」よりバネのVerlag LCNS938、1994。
[2] S. Floyd, V. Jacobson, C. Liu, S. McCanne, L. Zhang, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", ACM Transactions on Networking, November 1996.
[2] S.フロイド対ジェーコブソン、C.リュウ、S.McCanne、L.チャン、「軽量のセッションとアプリケーションレベル縁どりのための信頼できるマルチキャスト枠組み」、ネットワーク(1996年11月)のACM取引
[3] J. C. Lin, S. Paul, "RMTP: A Reliable Multicast Transport Protocol", ACM SIGCOMM August 1996.
[3] J.C.リン、S.ポール、「RMTP:」 ACM SIGCOMM1996年8月の「信頼できるマルチキャストトランスポート・プロトコル。」
[4] Miller, K., Robertson, K., Tweedly, A. and M. White, "Multicast File Transfer Protocol (MFTP) Specification", Work In Progress.
[4] 「マルチキャストファイル転送プロトコル(MFTP)仕様」というミラー、K.、ロバートソン、K.、Tweedly、A.、およびM.ホワイトは進行中で働いています。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[7] C. Partridge, "Gigabit Networking", Addison Wesley 1994.
[7] C.ヤマウズラ、「ギガビットネットワーク」、アディソン・ウエスリー1994。
Speakman, et. al. Experimental [Page 106] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[106ページ]RFC3208PGM
[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.Singhal、D.R.Cheriton、「分配された対話的なシミュレーションのためのログベースの受信機信頼できるマルチキャスト」、ACM SIGCOMM1995。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、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 SIGCOMM1997年9月。
[12] L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", Computer Communication Review, April 1997.
[12] L.リゾー、「有効な消去がコード化する、信頼できる、コンピュータ通信プロトコル、」、コンピュータコミュニケーションレビュー、4月1997
[13] V. Jacobson, "Congestion Avoidance and Control", ACM SIGCOMM August 1988.
ジェーコブソンと、「輻輳回避とコントロール」に対するACM SIGCOMM1988年8月の[13]。
[14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP, 14, RFC 2119, March 1997.
[14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP、14、RFC2119、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/Sigcomm94、ページ 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 SIGCOMM8月2000番目
[17] M. Luby, L. Vicisano, T. Speakman. "Heterogeneous multicast congestion control based on router packet filtering", RMT working group, June 1999, Pisa, Italy.
[17] M.Luby、L.Vicisano、T.Speakman。 「ルータパケットフィルタリングに基づく異種のマルチキャスト輻輳制御」、RMTワーキンググループ、1999年6月、ピサ、イタリア。
[18] Cain, B., Speakman, T. and D. Towsley, "Generic Router Assist (GRA) Building Block, Motivation and Architecture", Work In Progress.
[18] 「一般的なルータアシスト(GRA)ブロック、動機、および構造」というカイン、B.、Speakman、T.、およびD.Towsleyは進行中で働いています。
[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月。
Speakman, et. al. Experimental [Page 107] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[107ページ]RFC3208PGM
[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.Greenhalgh、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.リゾー、「無料OSの一つのための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、「実践的な司令官のMulticast(PGM)は無料OSの一つのための実現を主催する」、 http://www.cs.ucl.ac.uk/research/darpa/pgm/PGM_FINAL.html
21. Authors' Addresses
21. 作者のアドレス
Tony Speakman EMail: speakman@cisco.com
トニーSpeakmanはメールします: speakman@cisco.com
Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 USA EMail: dino@procket.com
ディーノファリナッチProcketは3850北で最初に、通りサンノゼ(カリフォルニア)95134米国メールをネットワークでつなぎます: dino@procket.com
Steven Lin Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94086 USA EMail: steven@juniper.net
スティーブンリンJuniperは1194N.マチルダAveをネットワークでつなぎます。 カリフォルニア94086サニーベル(米国)はメールされます: steven@juniper.net
Alex Tweedly EMail: agt@cisco.com
アレックスTweedlyはメールします: agt@cisco.com
Nidhi Bhaskar EMail: nbhaskar@cisco.com
Nidhi Bhaskarはメールします: nbhaskar@cisco.com
Richard Edmonstone EMail: redmonst@cisco.com
リチャードEdmonstoneはメールします: redmonst@cisco.com
Rajitha Sumanasekera EMail: rajitha@cisco.com
Rajitha Sumanasekeraはメールします: rajitha@cisco.com
Speakman, et. al. Experimental [Page 108] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[108ページ]RFC3208PGM
Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 USA EMail: lorenzo@cisco.com
ロレンツォVicisanoシスコシステムズInc.170の西タスマンDrive、サンノゼ、カリフォルニア95134米国はメールされます: 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イギリスのEMail: 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マイクロソフト湾岸地区Research Center301#830カリフォルニア94105サンフランシスコ(米国)はメールされます: jgemmell@microsoft.com
Dan Leshchiner Tibco Software 3165 Porter Dr. Palo Alto, CA 94304 USA EMail: dleshc@tibco.com
ダンLeshchiner Tibco Software3165ポーターパロアルトカリフォルニア94304博士(米国)はメールされます: dleshc@tibco.com
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Fremont CA 94538 USA EMail: luby@digitalfountain.com
マイケルLubyのデジタル噴水Inc.39141シビック・センタードライブフレモントカリフォルニア94538米国メール: luby@digitalfountain.com
Todd L. Montgomery Talarian Corporation 124 Sherman Ave. Morgantown, WV 26501 USA EMail: todd@talarian.com
トッドL.モンゴメリTalarian社124のシャーマンAve。 ウェストヴァージニア26501モーガンタウン(米国)はメールされます: todd@talarian.com
Speakman, et. al. Experimental [Page 109] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[109ページ]RFC3208PGM
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2 56126 Pisa Italy EMail: luigi@iet.unipi.it
ルーイジリゾーDipディIng Diotisalvi2 56126ピサイタリアEMailを通したdell'Informazione Universita'ディピサ: luigi@iet.unipi.it
Speakman, et. al. Experimental [Page 110] RFC 3208 PGM Reliable Transport Protocol December 2001
et Speakman、アル。 トランスポート・プロトコル2001年12月に信頼できる実験的な[110ページ]RFC3208PGM
22. Full Copyright Statement
22. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Speakman, et. al. Experimental [Page 111]
et Speakman、アル。 実験的[111ページ]
一覧
スポンサーリンク