As per Relevance of the word building, we have this rfc below:
Network Working Group R.
Request for Comments: 3269
Category: Informational L.
April 2002
Author Guidelines for Reliable Multicast Transport (RMT) Building
and Protocol Instantiation
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document provides general guidelines to assist the authors
Reliable Multicast Transport (RMT) building block and
instantiation definitions. The purpose of these guidelines is
ensure that any building block and protocol instantiation
produced contain sufficient information to fully explain
operation and use. In addition these guidelines provide
to specify modular and clearly defined RMT building blocks
protocol instantiations that can be refined and augmented to
create new protocols for use in new scenarios for which any
protocols were not designed
Table of
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.
Reliable Multicast Transport (RMT) protocols can be constructed in
variety of ways, some of which will work better for
situations than others. It is believed that the requirements
for reliable multicast transport is sufficiently diverse that no
protocol can meet all the requirements [RFC2887]. However, it
also believed that there is sufficient commonality between
various approaches that it should be possible to define a number
building blocks [RFC3048] from which the various RMT protocols can
constructed
One key benefit of this approach is that the same building block
be used multiple times in different protocol instantiations.
key benefit is that building blocks may be upgraded as experience
understanding is gained. For this operation to be possible
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
overall architecture of a protocol instantiation. This
should also be sufficiently detailed so that those wishing to
upon a particular building block or protocol instantiation can do
with a full understanding of the design decisions and tradeoffs
were made earlier
The building block approach also presents some dangers that must
well understood in order to avoid potential specification flaws
The most important danger is related to inappropriate usage
building blocks. Although efforts should be made in order to
a modular and reusable specification of building blocks,
practical reasons this goal is not always fully achievable.
results in the specification of building blocks whose
is context dependent, which in turn creates the potential for
risk of co-dependence incompatibilities between building blocks.
example of such an incompatibility would be situation where
Kermode & Vicisano Informational [Page 2]
RFC 3269 RMT Author Guidelines April 2002
combinations of building blocks A and B works, the combination
building blocks B and C works, however the combination of
blocks A, B, and C does not work
In order to avoid misusage of and incompatibilities between
blocks, any external dependency must be highlighted in the
block specification. Furthermore, the specification must contain
precise applicability statement for the building block. Conversely
any protocol instantiation specification must state how any
block being used in it meets the protocol instantiation'
applicability requirements. These guidelines are not intended
replace the common practice of Internet specification writing, but
augment them in a manner that better fits the RMT framework
1.1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The
This document provides guidelines for authors of the two main
of RMT documents; building block documents and protocol
documents. The guidelines for each are as follows
2.1. Building Block Document
All RMT Building block documents MUST contain sections that cover
following
2.1.1.
Individual building blocks SHOULD be reusable within
protocols and MUST provide functionality not present within
building blocks. If a building block is currently used in a
protocol instantiation, then it MUST specify some functionality
is likely to be reused in another (future) protocol instantiation
The rationale section of a building block document must
define why the particular level of granularity for the
decomposition resulted in that building block being chosen. If
granularity is too small it is highly likely that the building
will be trivial, and therefore require excessive additional effort
realize a working protocol. Conversely, if the level of
is too large, building blocks will only be usable within a
protocol instantiation. The rationale section MUST show that
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.
The functionality section within a building block document
describe all algorithms and functions contained within the
block. In addition, the external interfaces for accessing
algorithms and functions MUST be fully specified so that the
block can be combined with other building blocks and any
functionality specified within a protocol instantiation document
realize a working protocol
2.1.3. Applicability
One of the most important sections of a building block document
be the Applicability Statement. The purpose of this section is
provide sufficient details about the intended use of the
block so that potential authors of protocol instantiations will
able to use the building block in conformance to its
constraints. Also the Applicability Statement section will
future building block document authors to quickly determine
or not their particular need can be met with an existing
block. For this to be possible the Applicability Statement
describe
o Intended scenarios for the building block's use
o The building block's known failure modes, why they occur, and
they can be detected
o A list of environmental considerations that includes but is
limited to whether the building block requires multi-
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
other building blocks
2.1.4. Packet-Header
If a building block implements a functionality whose
requires an exchange of protocol messages between multiple agents
then the building block specification MUST state what kind
information is required and how the exchanged occurs. This
detailed description of the data format and various
requirements, such as timing constraints, and network
(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 "
header fields" without a full bit-level header specification
Generic header fields MAY specify additional requirements, such
representation precision or preferred position within the
header (this last constraint might be dictated by
concerns).
A building block specification MAY specify "abstract messages"
carry particular information for exclusive use within the
block, however, more frequently, it will rely on the
messages specified in the protocol instantiation to carry
information it needs
The building block that provides Generic Router Assist
is an exception to the rule stated above. For efficiency reasons
this building block may fully specify header fields and positions
these fields within the packet-header
2.1.5. Requirements from other Building
Each building block will specify a well defined piece
functionality that is common to multiple protocol instantiations
However, this does not mean that building block definitions will
generated in isolation from other building blocks. For example,
congestion control building block will have specific
regarding loss notification from either a NACK or ACK building block
The "Requirements from other Building Blocks" section is included
capture these requirements so that the authors of related
blocks can determine what functionality they need to provide in
to use a particular building block
Specifically, the "Requirements from other Building Blocks section
MUST provide a complete and exhaustive enumeration of all
requirements that will be made upon other building blocks in
for the building block being specified to operate in its
manner. Requirements that SHOULD be enumerated include but are
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
Protocol instantiations have the ultimate responsibility
addressing security requirements, in conformance to RFC 2357.
Security considerations may not be applicable to generic
blocks other than a specific "security" building block.
Kermode & Vicisano Informational [Page 5]
RFC 3269 RMT Author Guidelines April 2002
building blocks, however, may raise special security issues,
due to the nature of communication required by the building block
due to the intended usage of the building block in a
instantiation. When special security issues are present in
building block, its specification MUST address them explicitly
An example of this might be a building block that involves
of data that is particularly sensitive to security attacks
2.1.7. Codepoint
Certain Building Blocks will specify general frameworks
describing functionality while leaving the detail open
implementation specific algorithms. One example of such a
block is the Forward Error Correction (FEC) building block
describes the framing aspects for FEC message fragments but not
algorithms used to generate the redundant data
2.1.8. Summary
_ Provide justification for the building block's
_ Provide rationale for the building block's
_ Functionality contained within the building
_ External
Applicability
_ Intended
_ Failure modes (including means of detection if known
_ Environmental
_ Incompatibilities / Conflicts with other building
Packet Header
_ Specification of logical packet-header fields (*)
_ Abstract messages specifications (*)
Requirements from other building blocks
_ Mandatory needs from other building
Security
_ Specify as much as possible (with respect to procedures
algorithms and data encoding), without affecting the
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
Protocol Instantiation documents have one purpose: to specify how
can combine multiple building blocks to construct a new
specified working protocol. To that end RMT Protocol
documents MUST contain the following four sections
2.2.1. Applicability
The applicability statement's purpose is to frame the design space
which the fully realized protocol will operate and to thereby
subsequent would-be RMT protocol designers to determine whether
not an existing protocol already meets their needs. For this to
possible the applicability statement MUST adhere to the
guidelines
1) The target application space for which the protocol is
MUST be clearly identified. For example; is the protocol to
used for real-time delivery, or non-real time file transfer
2) The target scale, in terms of maximum number of receivers
session, for which the protocol is intended MUST be
specified. If the protocol has an architectural
resulting from the optimization of another feature, such as
packet acknowledgment, this SHOULD be included
3) The applicability statement MUST identify the
environments for the protocol's use AND list any environments
which the protocol should not be used. Example environments
should be considered include asymmetric networks,
networks, and satellite networks
4) Finally, all protocols have inherent weaknesses that stem from
optimization for a specific feature. These weaknesses
manifest in spectacular failure modes when certain
occur. When known, these conditions and the nature of how
subsequent failure can be detected MUST be included in
applicability statement
2.2.2. Architecture
Protocol Instantiations define how to combine one or more
blocks to create a working protocol. The Architecture
lays out the framework for how this take place. For this
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
with explicit references to their documents that define them
3) An overview of how the aforementioned building blocks are to
joined
4) A discussion of the design tradeoffs made in the selection of
chosen architecture
2.2.3. Conformance
The conformance statement below MUST be included and adhered to
"This Protocol Instantiation document, in conjunction with
following Building Block documents identified in [list of
building block references] completely specifies a working
multicast transport protocol that conforms to the
described in RFC 2357."
Protocol instantiation document authors are specifically
that RFC 2357 requires that any RMT protocol put forward
standardization with the IETF is required to protect the network
as much as is possible. This does not mean that RMT protocols
be held to a higher standard than unicast transport protocols,
that they should be designed to perform at least as well as
transport protocols when it comes to the possibility of
failure
2.2.4. Functionality
Building Block documents will be incomplete in that they will
an abstract framework of a building block's functionality.
algorithmic specifications for each building block along with
additional functionality MUST be provided within the
Instantiation document's functionality definition. Furthermore,
description must show that each building block is used in
with its respective applicability statement. Finally
functionality description must provide a description of the
programming interface for interfacing the protocol instantiation
the applications that will use it
Kermode & Vicisano Informational [Page 8]
RFC 3269 RMT Author Guidelines April 2002
2.2.5. Packet
Once all the functionality has been fully defined, the
Instantiation document must define the packet formats that will
used by the protocol. Each message part and the rules for
concatenation MUST be specified for both IPv4 [RFC791] and IPv
[RFC2460]. Support for IPSEC [RFC2401] MUST be explicitly shown
In recognition of the fact that protocols will evolve and that
protocol numbers are a scarce resource, protocol instantiations
initially define packet formats for use over UDP [RFC768].
or not a particular Reliable Multicast Transport
instantiation becomes sufficiently popular to warrant its
protocol number is an issue which will be deferred until such
that the protocol has been sufficiently widely deployed
understood
2.2.6. Summary
Applicability
_ Target application
_ Target
_ Intended
_ Weaknesses and known failure
Architecture
_ Operational
_ Building blocks
_ Details on how building blocks are
Conformance
_ Inclusion of mandatory
Functionality
_ Building block algorithmic
_ Addition functionality
_ Compliance with building block applicability
_ Abstract program
Packet
_ IPv4 message
_ IPv6 message
_ IPSEC
_ Message
3. IANA
There are no explicit IANA considerations for this document
Kermode & Vicisano Informational [Page 9]
RFC 3269 RMT Author Guidelines April 2002
4.
This document represents an overview of the mandatory
required for the specification of building blocks and
instantiations within the RMT working group. The
presented are a summarization of discussions held between the
Working Group chairs and the participants in the IRTF
Multicast Research Group. Although the name of these
are too numerous to list here, the Working Group chairs would like
thank everyone who has participated in these discussions for
contributions
5.
[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
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
Bulk Data Transfer", RFC 2887, August 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd
S. and M. Luby, "Reliable Multicast Transport
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'
Roger
Motorola Australian Research
Locked Bag 5028
Botany NSW 1455,
Australia
EMail: Roger.Kermode@motorola.
Lorenzo
Cisco Systems
170 West Tasman Dr
San Jose, CA 95134,
EMail: lorenzo@cisco.
Kermode & Vicisano Informational [Page 11]
RFC 3269 RMT Author Guidelines April 2002
7. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Kermode & Vicisano Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
