[要約] RFC 3269は、信頼性のあるマルチキャストトランスポート（RMT）のビルディングブロックとプロトコルのインスタンス化に関する著者ガイドラインです。このRFCの目的は、RMTの実装と標準化のための指針を提供することです。
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.
Copyright（c）The Internet Society（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.
このアプローチの重要な利点の1つは、異なるプロトコルインスタンス化で同じビルディングブロックを複数回使用できることです。もう1つの重要な利点は、経験と理解が得られるにつれて、ビルディングブロックがアップグレードされる可能性があることです。この操作を可能にするためには、ビルディングブロックを、それが何をするか、それが他のビルディングブロックとどのように相互作用するか、そしてそれがプロトコルインスタンス化の全体的なアーキテクチャにどのように適合するかという点で明確に定義する必要があります。また、この説明は、特定のビルディングブロックまたはプロトコルのインスタンス化を改善したい人が、以前に行われた設計上の決定とトレードオフを完全に理解することでそれを行うことができるように、十分に詳細にする必要があります。
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.
ビルディングブロック間の誤用と非互換性を回避するには、ビルディングブロックの仕様で外部依存関係を強調表示する必要があります。さらに、仕様には、ビルディングブロックの正確な適用性ステートメントが含まれている必要があります。逆に、プロトコルのインスタンス化仕様は、ITで使用されているビルディングブロックがプロトコルインスタンス化の適用可能性要件をどのように満たしているかを述べる必要があります。これらのガイドラインは、インターネット仕様の記述の一般的な慣行を置き換えることではなく、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.
このドキュメントは、2つの主要なRMTドキュメントの著者のガイドラインを提供します。ビルディングブロックドキュメントとプロトコルインスタンス化ドキュメント。それぞれのガイドラインは次のとおりです。
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:
ビルディングブロックドキュメントの最も重要なセクションの1つは、applicabilityステートメントです。このセクションの目的は、プロトコルのインスタンス化の潜在的な著者が、その適用性の制約に準拠してビルディングブロックを使用できるように、ビルディングブロックの意図された使用に関する十分な詳細を提供することです。また、アプリケーションステートメントセクションでは、将来のビルディングブロックドキュメント著者が、既存のビルディングブロックで特定のニーズを満たすことができるかどうかを迅速に判断できます。これが可能であるためには、適用性ステートメントが説明する必要があります。
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:
具体的には、「他のビルディングブロックセクションからの要件」は、意図した方法で動作するように指定されるために、他のビルディングブロックに行われるすべての要件の完全かつ網羅的な列挙を提供する必要があります。列挙すべき要件には、以下が含まれますが、これらに限定されません。
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.
特定のビルディングブロックは、機能を記述するための一般的なフレームワークを指定し、実装固有のアルゴリズムのために詳細を開いたままにします。このようなビルディングブロックの1つの例は、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.
プロトコルインスタンス化ドキュメントには、複数のビルディングブロックを組み合わせて新しい完全に指定された作業プロトコルを構築する方法を指定することです。そのために、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:
Applicability Statementの目的は、完全に実現されたプロトコルが動作する設計スペースを組み立て、それにより、その後の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) An overview of the major facets of the protocol's operation.
プロトコルのインスタンス化は、1つ以上のビルディングブロックを組み合わせて機能するプロトコルを作成する方法を定義します。アーキテクチャの定義は、これがどのように行われるかについてのフレームワークを紹介します。このフレームワークを完了するには、次の情報を含める必要があります。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では、可能な限りネットワークを保護するためにIETFを使用した標準化のために提案するRMTプロトコルが必要であることを特に思い出させます。これは、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プロトコル数が希少なリソースであるという事実を認識して、プロトコルインスタンス化は最初にUDPで使用するパケット形式を定義する必要があります[RFC768]。特定の信頼性の高いマルチキャスト輸送プロトコルインスタンス化が、独自のプロトコル番号を保証するのに十分に人気があるかどうかは、プロトコルが十分に広く展開および理解されるまで延期される問題です。
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] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Darpa Internet Protocol Specification", STD 5, RFC 791, September 1981.
[RFC791] Postel、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998.
[RFC2460] Deering、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] Handley、M.、Floyd、S.、Whetten、B.、Kermode、R.、Vicisano、L。and M. Luby、「バルクデータ転送用の信頼できるマルチキャスト設計スペース」、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.、Handley、M.、Floyd、S.、M。Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia.
ロジャーカーモードモトローラオーストラリア研究センターロックされたバッグ5028ボタニーNSW 1455、オーストラリア。
EMail: Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems、170 West Tasman Dr. San Jose、CA 95134、米国
EMail: lorenzo@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。