summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3269.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3269.txt')
-rw-r--r--doc/rfc/rfc3269.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3269.txt b/doc/rfc/rfc3269.txt
new file mode 100644
index 0000000..455ae3f
--- /dev/null
+++ b/doc/rfc/rfc3269.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+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
+
+
+
+Kermode & Vicisano Informational [Page 1]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+ 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
+
+ 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
+
+
+
+
+Kermode & Vicisano Informational [Page 2]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+ 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
+
+ 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].
+
+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
+
+ All RMT Building block documents MUST contain sections that cover the
+ following.
+
+2.1.1. Rationale
+
+ 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.
+
+
+
+Kermode & Vicisano Informational [Page 3]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+2.1.2. Functionality
+
+ 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
+
+ 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
+
+ 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).
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 4]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+ 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
+
+ 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.
+
+ 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
+
+ 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
+
+
+
+Kermode & Vicisano Informational [Page 5]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+ 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
+
+ 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
+
+ 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.
+
+
+
+
+Kermode & Vicisano Informational [Page 6]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+2.2. Protocol Instantiation Document Guidelines
+
+ 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
+
+ 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
+
+ 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:
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 7]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+ 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
+
+ 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."
+
+ 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.
+
+2.2.4. Functionality Definition
+
+ 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.
+
+
+
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 8]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+2.2.5. Packet Formats
+
+ 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.
+
+ 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.
+
+2.2.6. Summary Checklist
+
+ 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
+
+3. IANA Considerations
+
+ There are no explicit IANA considerations for this document.
+
+
+
+Kermode & Vicisano Informational [Page 9]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+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.
+
+ [RFC791] Postel, J., "Darpa Internet Protocol Specification", STD 5,
+ RFC 791, September 1981.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC2460, December 1998.
+
+ [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.
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 10]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+6. Authors' Addresses
+
+ Roger Kermode
+ Motorola Australian Research Centre
+ Locked Bag 5028
+ Botany NSW 1455,
+ Australia.
+
+ EMail: Roger.Kermode@motorola.com
+
+
+ Lorenzo Vicisano
+ Cisco Systems,
+ 170 West Tasman Dr.
+ San Jose, CA 95134, USA
+
+ EMail: lorenzo@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 11]
+
+RFC 3269 RMT Author Guidelines April 2002
+
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kermode & Vicisano Informational [Page 12]
+