Network Working Group R. Kermode
Request for Comments: 3269 Motorola
Category: Informational L. Vicisano
Cisco
April 2002
Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents
リライアブルマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス文書の作者のガイドライン
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.
この文書では、信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス定義の作成者を支援するための一般的なガイドラインを提供します。これらのガイドラインの目的は、生成される任意のビルディングブロックとプロトコルのインスタンス化の定義は完全に彼らの操作と使用を説明するために十分な情報が含まれていることを確認することです。また、これらのガイドラインは、洗練かつ安全に任意の既存のプロトコルが設計されなかったため、新たなシナリオで使用するための新しいプロトコルを作成するように拡張することができるモジュラーと明確に定義されRMTビルディングブロックとプロトコルのインスタンスを指定するための方向性を提供します。
Table of Contents
目次
1 Introduction ................................................... 2
1.1 Terminology .................................................. 3
2 The Guidelines ................................................. 3
2.1 Building Block Document Guidelines ........................... 3
2.1.1 Rationale .................................................. 3
2.1.2 Functionality .............................................. 4
2.1.3 Applicability Statement .................................... 4
2.1.4 Packet-Header Fields ....................................... 4
2.1.5 Requirements from other Building Blocks .................... 5
2.1.6 Security Considerations .................................... 5
2.1.7 Codepoint Considerations ................................... 6
2.1.8 Summary Checklist .......................................... 6
2.2 Protocol Instantiation Document Guidelines ................... 7
2.2.1 Applicability Statement .................................... 7
2.2.2 Architecture Definition .................................... 7
2.2.3 Conformance Statement ...................................... 8
2.2.4 Functionality Definition ................................... 8
2.2.5 Packet Formats ............................................. 9
2.2.6 Summary Checklist .......................................... 9
3 IANA Considerations ............................................ 9
4 Acknowledgements ............................................... 10
5 References ..................................................... 10
6 Authors' Addresses ............................................. 11
7 Full Copyright Statement ....................................... 12
Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations than others. It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RFC2887]. However, it is also believed that there is sufficient commonality between the various approaches that it should be possible to define a number of building blocks [RFC3048] from which the various RMT protocols can be constructed.
信頼性の高いマルチキャストトランスポート（RMT）プロトコルは、他よりも、特定の状況のために良い仕事しますそのうちのいくつかは、さまざまな方法で構築することができます。信頼性の高いマルチキャストトランスポートの要件スペースは誰のプロトコルがすべての要件[RFC2887]を満たすことができないことを十分に多様であると考えられています。しかし、また、様々なRMTプロトコルを構築することが可能なビルディングブロック[RFC3048]の数を定義することが可能でなければならない様々なアプローチの間に十分な共通性があると考えられています。
One key benefit of this approach is that the same building block can be used multiple times in different protocol instantiations. Another key benefit is that building blocks may be upgraded as experience and understanding is gained. For this operation to be possible the building block needs to be clearly defined in terms of what it does, how it interacts with other building blocks, and how it fits into the overall architecture of a protocol instantiation. This description should also be sufficiently detailed so that those wishing to improve upon a particular building block or protocol instantiation can do so with a full understanding of the design decisions and tradeoffs that were made earlier.
このアプローチの一つの重要な利点は、同じビルディングブロックは、異なるプロトコルのインスタンスで複数回使用することができることです。もう一つの重要な利点は、経験や理解が得られるようなビルディングブロックをアップグレードすることができるということです。この操作を可能にするにはビルディングブロックは、それが他のビルディング・ブロックとどのように相互作用するか、そしてそれは、プロトコルのインスタンスの全体的なアーキテクチャにどのように適合するか、明確にそれが何をするかという観点で定義する必要があります。特定のビルディングブロックまたはプロトコルのインスタンス化を改善したい方は、先に行われた設計上の決定とトレードオフを完全に理解した上でそうすることができるように、この説明も十分に詳細でなければなりません。
The building block approach also presents some dangers that must be well understood in order to avoid potential specification flaws.
ビルディング・ブロック・アプローチは、ウエル電位の仕様上の欠陥を避けるために理解しなければならないいくつかの危険性を提示します。
The most important danger is related to inappropriate usage of building blocks. Although efforts should be made in order to produce a modular and reusable specification of building blocks, for practical reasons this goal is not always fully achievable. This results in the specification of building blocks whose applicability is context dependent, which in turn creates the potential for the risk of co-dependence incompatibilities between building blocks. An example of such an incompatibility would be situation where the combinations of building blocks A and B works, the combination of building blocks B and C works, however the combination of building blocks A, B, and C does not work.
最も重要な危険は、ビルディングブロックの不適切な使用法に関連しています。努力はビルディングブロックのモジュラー及び再利用可能な仕様を生産するためになされるべきであるが、実用的な理由から、この目標は、常に完全に達成可能ではありません。これは、順番にビルディングブロック間の共同依存性の非互換性のリスクの可能性を作成し、適用文脈依存しているビルディングブロックの仕様になります。そのような非互換性の例は、ビルディングブロックAとBの組み合わせは動作状況、B及びCが機能ビルディングブロックの組み合わせ、Aは、B、およびCが機能しないビルディングブロックの組み合わせがあることになります。
In order to avoid misusage of and incompatibilities between building blocks, any external dependency must be highlighted in the building block specification. Furthermore, the specification must contain a precise applicability statement for the building block. Conversely, any protocol instantiation specification must state how any building block being used in it meets the protocol instantiation's applicability requirements. These guidelines are not intended to replace the common practice of Internet specification writing, but to augment them in a manner that better fits the RMT framework.
誤用やビルディングブロック間の非互換性を避けるために、任意の外部依存関係は、ビルディングブロックの仕様で強調表示されなければなりません。さらに、仕様は、ビルディングブロックの正確な適用性声明が含まれている必要があります。逆に、任意のプロトコルのインスタンス仕様は、それに使用されているすべてのビルディングブロックは、プロトコルのインスタンス化の適用要件を満たす方法を述べなければなりません。これらのガイドラインは、インターネット仕様の書き込みの一般的な方法を置き換えるために、より良いRMTフレームワークに合った方法でそれらを強化することを意図していません。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document provides guidelines for authors of the two main kinds of RMT documents; building block documents and protocol instantiation documents. The guidelines for each are as follows.
この文書では、RMTの文書には主に2つの種類の作者のためのガイドラインを提供します。ビルディングブロックの文書やプロトコルのインスタンス文書。次のようにそれぞれのガイドラインです。
All RMT Building block documents MUST contain sections that cover the following.
すべてのRMTビルディングブロックの文書は、次をカバーするセクションが含まれていなければなりません。
Individual building blocks SHOULD be reusable within multiple protocols and MUST provide functionality not present within other building blocks. If a building block is currently used in a single protocol instantiation, then it MUST specify some functionality that is likely to be reused in another (future) protocol instantiation.
個々のビルディングブロックは、複数のプロトコル内で再利用可能であるべきで、他のビルディングブロック内に存在しない機能を提供しなければなりません。ビルディングブロックは現在、単一のプロトコルのインスタンスで使用されている場合、それは別の（将来の）プロトコルのインスタンスで再利用される可能性があるいくつかの機能を指定しなければなりません。
The rationale section of a building block document must clearly define why the particular level of granularity for the functional decomposition resulted in that building block being chosen. If the granularity is too small it is highly likely that the building blocks will be trivial, and therefore require excessive additional effort to realize a working protocol. Conversely, if the level of granularity is too large, building blocks will only be usable within a single protocol instantiation. The rationale section MUST show that the level of granularity is appropriate so that neither problem occurs.
機能分解のための粒度の特定のレベルが選択されていることビルディングブロックになった理由のビルディングブロックの文書の根拠セクションは、明確に定義する必要があります。粒度が小さすぎる場合には、ビルディング・ブロックは、些細なこと、そのための作業プロトコルを実現するために、過剰な付加的な努力が必要になる可能性が高いです。粒度のレベルが大きすぎると逆に、ビルディング・ブロックは、単一のプロトコルのインスタンス内で使用可能であろう。根拠のセクションでは、どちらの問題が発生したように、粒度のレベルが適切であることを示さなければなりません。
The functionality section within a building block document MUST describe all algorithms and functions contained within the building block. In addition, the external interfaces for accessing these algorithms and functions MUST be fully specified so that the building block can be combined with other building blocks and any additional functionality specified within a protocol instantiation document to realize a working protocol.
ビルディング・ブロック・ドキュメント内の機能部は、ビルディングブロック内に含まれるすべてのアルゴリズム及び機能を説明しなければなりません。ビルディングブロックは、他のビルディングブロックと作業プロトコルを実現するプロトコルインスタンス文書内の指定された任意の追加の機能と組み合わせることができるように加えて、これらのアルゴリズム及び機能にアクセスするための外部インターフェースは、完全に指定されなければなりません。
One of the most important sections of a building block document will be the Applicability Statement. The purpose of this section is to provide sufficient details about the intended use of the building block so that potential authors of protocol instantiations will be able to use the building block in conformance to its applicability constraints. Also the Applicability Statement section will enable future building block document authors to quickly determine whether or not their particular need can be met with an existing building block. For this to be possible the Applicability Statement MUST describe:
ビルディングブロックの文書の中で最も重要なセクションの一つは、適用性に関する声明となります。このセクションの目的は、プロトコルのインスタンス化の潜在的な著者はその適用性の制約に準拠したビルディングブロックを使用することができるようになりますように、ビルディングブロックの使用目的についての十分な詳細を提供することです。また、適用性に関する声明のセクションでは、すぐに彼らの特定の必要性は、既存のビルディングブロックを満たすことができるかどうかを判断するために、将来のビルディングブロックの文書の作成者が有効になります。これを可能にするために適用性に関する声明は、説明しなければなりません：
o Intended scenarios for the building block's use.
Oビルディングブロックの使用のためのシナリオを対象としています。
o The building block's known failure modes, why they occur, and how they can be detected.
それらが発生する理由ビルディングブロックの既知の故障モード、Oおよびそれらがどのように検出することができます。
o A list of environmental considerations that includes but is not limited to whether the building block requires multi-source multicast or can be used in single-source only multicast networks, satellite networks, asymmetric networks, and wireless networks.
O含むが、ビルディングブロックは、マルチソースマルチキャストを必要とするか、単一のソースのみマルチキャストネットワーク、衛星ネットワーク、非対称ネットワーク、および無線ネットワークで使用することができるかどうかに限定されるものではない環境への配慮のリスト。
o A list of potential areas of conflict or incompatibilities with other building blocks.
他のビルディング・ブロックとの競合または非互換性の可能性のある領域のリストO。
If a building block implements a functionality whose realization requires an exchange of protocol messages between multiple agents, then the building block specification MUST state what kind of information is required and how the exchanged occurs. This includes detailed description of the data format and various communication requirements, such as timing constraints, and network requirements (e.g., multicast vs. unicast delivery).
ビルディングブロックは、その実現に複数のエージェントとの間のプロトコルメッセージの交換を必要とする機能を実装した場合、ビルディングブロックの仕様が必要とどのようにやり取りが発生される情報の種類を述べなければなりません。これは、データフォーマットの詳細な説明およびそのようなタイミング制約などの様々な通信要件、およびネットワークの要件（例えば、マルチキャスト対ユニキャスト配信）を含みます。
Typically the data format specification is at the level of "generic header fields" without a full bit-level header specification. Generic header fields MAY specify additional requirements, such as representation precision or preferred position within the packet header (this last constraint might be dictated by efficiency concerns).
典型的には、データフォーマット仕様では、完全なビット・レベル・ヘッダー仕様なし「ジェネリックヘッダフィールド」のレベルです。ジェネリックヘッダフィールドは、そのような表現の精度またはパケットヘッダ内の好ましい位置（この最後の制約は、効率の問題によって決定されるかもしれない）のような追加要件を指定することができます。
A building block specification MAY specify "abstract messages" that carry particular information for exclusive use within the building block, however, more frequently, it will rely on the protocol messages specified in the protocol instantiation to carry the information it needs.
ビルディングブロック仕様はビルディングブロック内で排他的に使用するための特定情報を運ぶ「抽象メッセージ」を指定できるが、より頻繁に、それは必要な情報を伝えるために、プロトコルのインスタンスで指定されたプロトコルメッセージに依存しています。
The building block that provides Generic Router Assist functionality is an exception to the rule stated above. For efficiency reasons, this building block may fully specify header fields and positions of these fields within the packet-header.
一般的なルータ機能を支援提供するビルディングブロックは、上述したルールの例外です。効率上の理由から、このビルディングブロックは、完全ヘッダフィールドと、パケットヘッダ内のこれらのフィールドの位置を指定することができます。
Each building block will specify a well defined piece of functionality that is common to multiple protocol instantiations. However, this does not mean that building block definitions will be generated in isolation from other building blocks. For example, a congestion control building block will have specific requirements regarding loss notification from either a NACK or ACK building block. The "Requirements from other Building Blocks" section is included to capture these requirements so that the authors of related building blocks can determine what functionality they need to provide in order to use a particular building block.
各ビルディングブロックは、複数のプロトコルのインスタンスに共通する機能のよく定義された部分を指定します。しかし、これは、ビルディングブロックの定義は、他のビルディングブロックから分離して生成されることを意味するものではありません。例えば、輻輳制御ビルディングブロックは、NACKまたはACKのビルディングブロックのいずれかから喪失通知に関する特定の要件があります。 「要件他のビルディング・ブロックからの」セクションは、関連するビルディングブロックの作者は、彼らが特定のビルディングブロックを使用するために提供するために必要なものな機能を判断できるように、これらの要件をキャプチャするために含まれています。
Specifically, the "Requirements from other Building Blocks section" MUST provide a complete and exhaustive enumeration of all the requirements that will be made upon other building blocks in order for the building block being specified to operate in its intended manner. Requirements that SHOULD be enumerated include but are not limited to:
具体的には、「他のビルディング・ブロック部からの要求」は、その意図された様式で動作するように指定されたビルディングブロックのために、他のビルディングブロックの際に行われるすべての要件の完全かつ網羅的列挙を提供しなければなりません。列挙含むがこれらに限定されないべきである（SHOULD）要件：
o Event generation for and responses to other building blocks.
Oイベントの生成や他のビルディングブロックへの応答。
o Message ordering relative to messages from other building blocks.
Oメッセージは、他のビルディングブロックからのメッセージに対する注文。
Protocol instantiations have the ultimate responsibility of addressing security requirements, in conformance to RFC 2357. Security considerations may not be applicable to generic building blocks other than a specific "security" building block. Some building blocks, however, may raise special security issues, either due to the nature of communication required by the building block or due to the intended usage of the building block in a protocol instantiation. When special security issues are present in a building block, its specification MUST address them explicitly.
プロトコルインスタンスは、RFCに準拠した2357.セキュリティの考慮事項は、特定の「セキュリティ」ビルディングブロック以外の一般的なビルディング・ブロックには適用できない場合があり、セキュリティ要件に対処する最終的な責任を持っています。いくつかのビルディングブロックは、しかし、ビルディングブロックで必要な通信の性質に起因するか、プロトコルのインスタンスにおけるビルディングブロックの使用目的のいずれかに、特別なセキュリティ上の問題を引き起こす可能性があります。特別なセキュリティ上の問題はビルディングブロックに存在している場合は、その仕様が明示的に対処しなければなりません。
An example of this might be a building block that involves exchange of data that is particularly sensitive to security attacks.
この例では、セキュリティ攻撃に特に敏感であるデータの交換を伴うビルディングブロックであるかもしれません。
Certain Building Blocks will specify general frameworks for describing functionality while leaving the detail open for implementation specific algorithms. One example of such a building block is the Forward Error Correction (FEC) building block which describes the framing aspects for FEC message fragments but not the algorithms used to generate the redundant data.
特定のビルディング・ブロックは、実装固有のアルゴリズムのためのオープンなディテールを残しながら機能性を記述するための一般的なフレームワークを指定します。そのようなビルディングブロックの一例は、フレーミングFECメッセージフラグメントについての局面ではなく、冗長データを生成するために使用されるアルゴリズムを記述する前方誤り訂正（FEC）ビルディングブロックです。
Rationale _ Provide justification for the building block's existence _ Provide rationale for the building block's granularity
理論的根拠_ビルディングブロックの細かさのための理論的根拠を提供_ビルディングブロックの存在を正当化を提供します
Functionality _ Functionality contained within the building block _ External interfaces
ビルディングブロック内に含まれる機能_ _機能外部インタフェース
Applicability Statement _ Intended usage _ Failure modes (including means of detection if known) _ Environmental considerations _ Incompatibilities / Conflicts with other building blocks
使用_故障モード（既知の場合、検出の手段を含む。）_環境への配慮_他のビルディングブロックとの非互換性/競合意図適用ステートメント_
Packet Header Fields _ Specification of logical packet-header fields (*) _ Abstract messages specifications (*)
パケットヘッダフィールド_論理パケットヘッダフィールドの仕様（*）_抽象メッセージ仕様（*）
Requirements from other building blocks; _ Mandatory needs from other building blocks
他のビルディングブロックからの要件。他のビルディングブロックから_必須ニーズ
Security Considerations _ Specify as much as possible (with respect to procedures, algorithms and data encoding), without affecting the general applicability of the building block.
セキュリティの考慮事項は、_ビルディングブロックの一般的な適用に影響を与えずに、（手続き、アルゴリズムとデータのエンコードに関して）できるだけ多くを指定します。
(*) May not be applicable to some building blocks.
（*）一部のビルディングブロックに適用できない場合があります。
Protocol Instantiation documents have one purpose: to specify how one can combine multiple building blocks to construct a new fully specified working protocol. To that end RMT Protocol Instantiation documents MUST contain the following four sections.
1は、新しい完全に指定された作業プロトコルを構築するために、複数のビルディングブロックを組み合わせることができます方法を指定するには：プロトコルインスタンス文書は、1つの目的を持っています。そのためにRMTプロトコルインスタンス文書は、次の4つのセクションが含まれていなければなりません。
The applicability statement's purpose is to frame the design space in which the fully realized protocol will operate and to thereby enable subsequent would-be RMT protocol designers to determine whether or not an existing protocol already meets their needs. For this to be possible the applicability statement MUST adhere to the following guidelines:
適用性ステートメントの目的は、完全に実現プロトコルが動作することにより、既存のプロトコルは、すでに彼らのニーズを満たしているかどうかを判断するために、後続の-だろうRMTプロトコル設計を可能にするためにした設計空間をフレームにあります。これを可能にするために適用文は次のガイドラインに従う必要があります。
1) The target application space for which the protocol is intended MUST be clearly identified. For example; is the protocol to be used for real-time delivery, or non-real time file transfer?
1）プロトコルが意図されているターゲットアプリケーション空間が明確に識別されなければなりません。例えば;プロトコルは、リアルタイム配信、または非リアルタイムのファイル転送に使用するのですか？
2) The target scale, in terms of maximum number of receivers per session, for which the protocol is intended MUST be clearly specified. If the protocol has an architectural limitation resulting from the optimization of another feature, such as per packet acknowledgment, this SHOULD be included.
2）プロトコルが意図されるセッションごとの受信機の最大数の点で目標スケールは、明確に規定されなければなりません。プロトコルは、パケットの確認応答あたりのような別の機能の最適化に起因するアーキテクチャ上の制限がある場合、これは含まれるべきです。
3) The applicability statement MUST identify the intended environments for the protocol's use AND list any environments in which the protocol should not be used. Example environments that should be considered include asymmetric networks, wireless networks, and satellite networks.
3）適用ステートメントは、プロトコルの使用のために意図された環境を識別し、プロトコルを使用すべきでない任意の環境をリストする必要があります。考慮されるべき例示的環境は、非対称ネットワーク、無線ネットワーク、衛星ネットワークを含みます。
4) Finally, all protocols have inherent weaknesses that stem from the optimization for a specific feature. These weaknesses can manifest in spectacular failure modes when certain conditions occur. When known, these conditions and the nature of how the subsequent failure can be detected MUST be included in the applicability statement.
4）最後に、すべてのプロトコルは、特定の機能の最適化から生じる固有の弱点を持っています。特定の条件が発生した場合、これらの弱点は、壮大な故障モードで現れ得ます。知られている場合は、これらの条件とその後の故障を検出することができる方法の性質は適用書に含まれなければなりません。
Protocol Instantiations define how to combine one or more building blocks to create a working protocol. The Architecture Definition lays out the framework for how this take place. For this framework to be complete, it MUST contain the following information:
プロトコルのインスタンス化は、作業手順を作成するために、1つ以上のビルディング・ブロックを結合する方法を定義します。アーキテクチャの定義は、これは場所を取る方法のためのフレームワークをレイアウトします。このフレームワークは完全であるためには、以下の情報を含まなければなりません：
1) An overview of the major facets of the protocol's operation.
1）プロトコルの操作の主要なファセットの概要。
2) Full enumeration and overview of which Building Blocks are used with explicit references to their documents that define them.
2）ビルディング・ブロックは、それらを定義、そのドキュメントへの明示的な参照で使用されているの完全な列挙と概要を。
3) An overview of how the aforementioned building blocks are to be joined.
3）上記のビルディングブロックを接合される方法の概要を。
4) A discussion of the design tradeoffs made in the selection of the chosen architecture.
4）選択されたアーキテクチャの選択で作ら設計トレードオフの議論。
The conformance statement below MUST be included and adhered to:
以下の適合性宣言が含まれてに付着しなければなりません：
"This Protocol Instantiation document, in conjunction with the following Building Block documents identified in [list of relevant building block references] completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357."
「[関連するビルディングブロック参照のリスト]で特定され、以下のビルディングブロックの書類と一緒にこのプロトコルインスタンス文書は、完全にRFC 2357.に記載されている要件に適合して取り組んで信頼性の高いマルチキャストトランスポートプロトコルを指定します」
Protocol instantiation document authors are specifically reminded that RFC 2357 requires that any RMT protocol put forward for standardization with the IETF is required to protect the network in as much as is possible. This does not mean that RMT protocols will be held to a higher standard than unicast transport protocols, merely that they should be designed to perform at least as well as unicast transport protocols when it comes to the possibility of protocol failure.
プロトコルインスタンス化文書の作成者は、具体的RFC 2357は、任意のRMTプロトコルはIETFで標準化のために前方に置くことが必要であることを思い出しているできるだけ多くあるようにネットワークを保護するために必要とされます。これは、RMTプロトコルは、それがプロトコルの失敗の可能性に来るとき、彼らは、少なくともだけでなく、ユニキャストトランスポートプロトコルを実行するように設計されなければならないだけであること、ユニキャストトランスポートプロトコルよりも高い水準に開催されることを意味するものではありません。
Building Block documents will be incomplete in that they will specify an abstract framework of a building block's functionality. Complete algorithmic specifications for each building block along with any additional functionality MUST be provided within the Protocol Instantiation document's functionality definition. Furthermore, this description must show that each building block is used in accordance with its respective applicability statement. Finally the functionality description must provide a description of the abstract programming interface for interfacing the protocol instantiation with the applications that will use it.
彼らはビルディングブロックの機能の抽象的枠組みを指定することでビルディングブロックの文書が不完全になります。任意の付加的な機能に加えて、各ビルディングブロックのための完全なアルゴリズムの仕様はプロトコルインスタンスドキュメントの機能の定義内で提供されなければなりません。なお、この説明では、各ビルディングブロックがそれぞれの適用に関する声明に従って使用されていることを示さなければなりません。最後に、機能の説明は、それを使用するアプリケーションとプロトコルのインスタンスをインタフェースするための抽象プログラミング・インタフェースの記述を提供しなければなりません。
Once all the functionality has been fully defined, the Protocol Instantiation document must define the packet formats that will be used by the protocol. Each message part and the rules for their concatenation MUST be specified for both IPv4 [RFC791] and IPv6 [RFC2460]. Support for IPSEC [RFC2401] MUST be explicitly shown.
すべての機能が完全に定義された後、プロトコルインスタンス文書はプロトコルによって使用されるパケットフォーマットを定義する必要があります。各メッセージ部分とその連結のためのルールは、IPv4 [RFC791]とIPv6 [RFC2460]の両方のために指定されなければなりません。 IPSEC [RFC2401]のサポートが明示的に示さなければなりません。
In recognition of the fact that protocols will evolve and that IP protocol numbers are a scarce resource, protocol instantiations MUST initially define packet formats for use over UDP [RFC768]. Whether or not a particular Reliable Multicast Transport protocol instantiation becomes sufficiently popular to warrant its own protocol number is an issue which will be deferred until such time that the protocol has been sufficiently widely deployed and understood.
プロトコルが進化すると、そのIPプロトコル番号が希少資源であるという事実の認識では、プロトコルのインスタンス化は、最初に[RFC768] UDP上の使用のためにパケット・フォーマットを定義しなければなりません。特に信頼性の高いマルチキャストトランスポートプロトコルのインスタンスは、独自のプロトコル番号を保証するために十分に普及するかどうかは、プロトコルが十分に広く展開して理解されているような時間まで延期される問題です。
Applicability Statement _ Target application space _ Target scale _ Intended environment _ Weaknesses and known failure modes
適用性に関する声明_ターゲットアプリケーションスペース_ターゲットスケール_意図された環境_弱点と既知の故障モード
Architecture Definition _ Operational overview _ Building blocks used _ Details on how building blocks are joined
_ビルディングブロックが結合される方法についての詳細を使用するアーキテクチャの定義は_動作の概要_ビルディングブロック
Conformance Statement _ Inclusion of mandatory paragraph
適合性宣言_必須段落のインクルージョン
Functionality Definition _ Building block algorithmic specification _ Addition functionality specification _ Compliance with building block applicability statements _ Abstract program interface
機能の定義_ビルディングブロックアルゴリズムの仕様_追加機能仕様_ビルディングブロックの適用文の遵守_抽象プログラム・インタフェース
Packet Formats _ IPv4 message parts _ IPv6 message parts _ IPSEC support _ Message ordering
パケット形式_ IPv4のメッセージ部分_ IPv6のメッセージ部分_ IPSECサポート_メッセージの順序
There are no explicit IANA considerations for this document.
この文書には明示的なIANAの考慮事項はありません。
This document represents an overview of the mandatory elements required for the specification of building blocks and protocol instantiations within the RMT working group. The requirements presented are a summarization of discussions held between the RMT Working Group chairs and the participants in the IRTF Reliable Multicast Research Group. Although the name of these participants are too numerous to list here, the Working Group chairs would like to thank everyone who has participated in these discussions for their contributions.
この文書では、RMTワーキンググループ内のビルディングブロックおよびプロトコルのインスタンスの指定のために必要な必須要素の概要を表します。提示の要件はRMTワーキンググループの議長とIRTF信頼性の高いマルチキャスト・リサーチ・グループの参加者の間で行われた議論の要約です。これらの参加者の名前がここに一覧表示するにはあまりにもたくさんありますが、ワーキンググループチェアは、彼らの貢献のためにこれらの議論に参加しているすべての人に感謝したいと思います。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Darpa Internet Protocol Specification", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "DARPAインターネットプロトコル仕様"、STD 5、RFC 791、1981年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC2460、1998年12月。
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L. and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887]ハンドリー、M.、フロイド、S.、Whetten、B.、Kermode、R.、Vicisano、L.およびM.ルビー、 "大量データ転送のための信頼できるマルチキャストデザインスペース"、RFC 2887、2000年8月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia.
ロジャーKermodeモトローラオーストラリアの研究センターは、バッグ5028ボタニーNSW 1455、オーストラリアのロックされました。
EMail: Roger.Kermode@motorola.com
メールアドレス：Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
ロレンツォVicisanoシスコシステムズ、170西タスマン博士サンノゼ、CA 95134、USA
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。