rfc2357.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   section).

5. Technical Criteria for Reliable Multicast

   The Internet-Draft must (in itself or a companion draft):

   a. Analyze the behavior of the protocol.
      The vulnerabilities and performance problems must be shown through
      analysis. Especially the protocol behavior must be explained in
      detail with respect to scalability, congestion control, error
      recovery, and robustness.

      For example the following questions should be answered:

         How scalable is the protocol to the number of senders or
         receivers in a group, the number of groups, and wide dispersion
         of group members?

         Identify the mechanisms which limit scalability and estimate
         those limits.

         How does the protocol protect the Internet from congestion? How
         well does it perform? When does it fail?




Mankin, et. al.              Informational                      [Page 6]

RFC 2357             Evaluating Reliable Multicast             June 1998


         Under what circumstances will the protocol fail to perform the
         functions needed by the applications it serves?
         Is there a congestion control mechanism? How well does it
         perform? When does it fail?  Note that congestion control
         mechanisms that operate on the network more aggressively than
         TCP will face a great burden of proof that they don't threaten
         network stability.

   b. Include a description of trials and/or simulations which support
      the development of the protocol and the answers to the above
      questions.

   c. Include an analysis of whether the protocol has congestion
      avoidance mechanisms strong enough to cope with deployment in the
      Global Internet, and if not, clearly document the circumstances in
      which congestion harm can occur.  How are these circumstances to
      be prevented?

   d. Include a description of any mechanisms which contain the traffic
      within limited network environments. If the analysis in a or c
      shows that the protocol has potential to damage the Internet, then
      the analysis must include a discussion of ways to limit the scope
      or otherwise contain the protocol.  We recognize that the
      confinement of Internet applications is an open research area.

   e. Reliable multicast protocols must include an analysis of how they
      address a number of security and privacy concerns.  If the
      protocol can be used in different modes of secure operation, then
      each mode must be analyzed.

         The analysis must document which of the various parties --
         senders, routers (more generally, data forwarders), receivers,
         retransmission sources -- must be trusted in order to ensure
         secure operation and privacy of the transmitted data, to what
         degree, and why.  (One issue to address here are "man-in-the-
         middle" attacks.)

         To what degree can data be manipulated so that at least a
         subset of the receivers receive different copies?  Does the
         protocol allow a group of receivers to determine whether they
         all received the same data?

         What limitations are placed on the retransmission mechanism to
         prevent it from being abused to flood network links with
         excessive traffic? Which parties must be trusted to ensure
         this, and to what degree, and why? The presumption will be that
         either a congestion control mechanism will inherently limit the
         volume of retransmission traffic, and that this limiting



Mankin, et. al.              Informational                      [Page 7]

RFC 2357             Evaluating Reliable Multicast             June 1998


         influence is robust under concerted attack; or that
         retransmission requests will be signed in a cryptographically
         strong manner so that abuses of the mechanism can be traced
         back to their source.  Protocols that do not provide either of
         these forms of protection face a great burden of proof that
         they don't threaten network stability.

         What sort of key management does the protocol require, and
         provide for?

6. Security Considerations

   This memo specifies in Section 5.e. that reliable multicast
   Internet-Drafts reviewed by the Transport Area Directors must
   explicitly explore the security aspects of the proposed design.

7. Acknowledgments

   Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike
   Reiter gave especially helpful comments on drafts of this document.

8. References

   [RMMinutes 1997]  Minutes the Second Reliable Multicast Research
   Group Meeting.  September 1997.  http://www.east.isi.edu/rm

   [Floyd97]  Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang,
   L.,  A Reliable Multicast Framework for Light-weight Sessions and
   Application Level Framing. IEEE/ACM Transactions on Networking,
   December 1997  An online version of the paper is at
   http://ee.lbl.gov/floyd/srm-paper.html.

   [InetStdProc96]  Bradner, S., "The Internet Standards Process --
   Revision 3", RFC 2026, October 1996.

   [DiffServBOF97]  [6] http://www.ietf.org/proceedings/97apr -
   Transport Area - FDDIFS BOF, April 1997.

   [DeprRFCs]  Freier, A., "Multicast Transport Protocol", RFC 1301,
   February 1992. and Braudes, R., and S. Zabele, "Requirements for
   Multicast Protocols", RFC 1458, May 1993.

   [DiotCrow97] Diot, C., Crowcroft, J., Multicast Transport Survey.
   Journal of Selected Areas in Communications, 1997.

   [Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey
   and Taxonomy.  To appear in IEEE Communications, 1998.




Mankin, et. al.              Informational                      [Page 8]

RFC 2357             Evaluating Reliable Multicast             June 1998


   [Routing91] Hinden, R., and Internet Engineering Task Force,
   "Internet Routing Protocol Standardization Criteria", RFC 1264,
   October 1991.

   [CongAvoid97] Stevens, W., "TCP Slow Start, Congestion Avoidance,
   Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January
   1997.

   [Jacobson 1988]  Jacobson, V.,  Congestion Avoidance and Control,
   Proceedings of SIGCOMM '88, August 1988, pp. 314-329.  An updated
   version of this paper is available at
   "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".







































Mankin, et. al.              Informational                      [Page 9]

RFC 2357             Evaluating Reliable Multicast             June 1998


9. Authors' Addresses

   Allison Mankin - Past TSV Area Director
   USC/ISI East
   4350 N. Fairfax Dr., Suite 620
   Arlington VA 22203
   USA

   Phone: [phone]
   EMail: [e-mail]


   Allyn Romanow - Past TSV Area Director
   MCI Corporation
   2560 North First Street
   San Jose, CA 9531
   USA

   Phone: [phone]
   EMail: [e-mail]


   Scott Bradner - TSV Co-Area Director
   Harvard University
   1350 Mass. Ave., Rm. 876
   Cambridge MA 02138
   USA

   Phone: [phone]
   EMail: [e-mail]


   Vern Paxson - TSV Co-Area Director
   MS 50B/2239
   Lawrence Berkeley National Laboratory
   University of California
   Berkeley, CA 94720
   USA

   Phone: [phone]
   EMail: [e-mail]










Mankin, et. al.              Informational                     [Page 10]

RFC 2357             Evaluating Reliable Multicast             June 1998


10.  Full Copyright Statement

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
























Mankin, et. al.              Informational                     [Page 11]