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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

onBeforeCopy

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る