Network Working Group                                         R. Kermode
Request for Comments: 3269                                      Motorola
Category: Informational                                      L. Vicisano
                                                              April 2002

Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents


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.




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.


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
1. Introduction
1. はじめに

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.


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.


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.


1.1. Terminology
1.1. 用語

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]に記載されているように解釈されます。

2. The Guidelines

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.1. Building Block Document Guidelines
2.1. ビルディングブロックドキュメントのガイドライン

All RMT Building block documents MUST contain sections that cover the following.


2.1.1. Rationale
2.1.1. 理由

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.


2.1.2. Functionality
2.1.2. 機能

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.


2.1.3. Applicability Statement
2.1.3. 適用性に関する声明

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 The building block's known failure modes, why they occur, and how they can be detected.


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 A list of potential areas of conflict or incompatibilities with other building blocks.


2.1.4. Packet-Header Fields
2.1.4. パケットヘッダフィールド

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.


2.1.5. Requirements from other Building Blocks
2.1.5. 他のビルディングブロックからの要件

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 Message ordering relative to messages from other building blocks.


2.1.6. Security Considerations
2.1.6. セキュリティの考慮事項

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.


An example of this might be a building block that involves exchange of data that is particularly sensitive to security attacks.


2.1.7. Codepoint Considerations
2.1.7. コードポイントの考慮事項

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.


2.1.8. Summary Checklist
2.1.8. 概要チェックリスト

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.


2.2. Protocol Instantiation Document Guidelines
2.2. プロトコルインスタンスドキュメントのガイドライン

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.


2.2.1. Applicability Statement
2.2.1. 適用性に関する声明

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:


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?


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.


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.


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.


2.2.2. Architecture Definition
2.2.2. アーキテクチャの定義

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.


2) Full enumeration and overview of which Building Blocks are used with explicit references to their documents that define them.


3) An overview of how the aforementioned building blocks are to be joined.


4) A discussion of the design tradeoffs made in the selection of the chosen architecture.


2.2.3. Conformance Statement
2.2.3. 適合性宣言

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プロトコルは、それがプロトコルの失敗の可能性に来るとき、彼らは、少なくともだけでなく、ユニキャストトランスポートプロトコルを実行するように設計されなければならないだけであること、ユニキャストトランスポートプロトコルよりも高い水準に開催されることを意味するものではありません。

2.2.4. Functionality Definition
2.2.4. 機能の定義

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.


2.2.5. Packet Formats
2.2.5. パケットフォーマット

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上の使用のためにパケット・フォーマットを定義しなければなりません。特に信頼性の高いマルチキャストトランスポートプロトコルのインスタンスは、独自のプロトコル番号を保証するために十分に普及するかどうかは、プロトコルが十分に広く展開して理解されているような時間まで延期される問題です。

2.2.6. Summary Checklist
2.2.6. 概要チェックリスト

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サポート_メッセージの順序

3. IANA Considerations
3. IANAの考慮事項

There are no explicit IANA considerations for this document.


4. Acknowledgements

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.


5. References

[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月。

6. Authors' Addresses

Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia.

ロジャーKermodeモトローラオーストラリアの研究センターは、バッグ5028ボタニーNSW 1455、オーストラリアのロックされました。



Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA

ロレンツォVicisanoシスコシステムズ、170西タスマン博士サンノゼ、CA 95134、USA



7. Full Copyright Statement

Copyright (C) The Internet Society (2002). 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.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。