rfc3269.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


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: [e-mail]


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

   EMail: [e-mail]


































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]