📄 rfc3269.txt
字号:
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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -