rfc2380.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 788 行 · 第 1/3 页

                              +----+

             Figure 3: IP Multicast Data Distribution Over ATM

   The goal of RSVP over ATM solutions is to ensure that IP multicast
   data is distributed with appropriate QoS.  Current multicast servers
   [1,2] do not support any mechanisms for communicating QoS
   requirements to a multicast server.  For this reason, RSVP over ATM
   implementations SHOULD support "mesh-mode" distribution for RSVP
   controlled multicast flows.  When using multicast servers that do not
   support QoS requests, a sender MUST set the service, not global,
   break bit(s). Use of the service-specific break bit tells the
   receiver(s) that RSVP and Integrated Services are supported by the
   router but that the service cannot be delivered over the ATM network
   for the specific request.

   In the case of MARS [1], the selection of distribution modes is
   administratively controlled.  Therefore network administrators that
   desire proper RSVP over ATM operation MUST appropriately configure
   their network to support mesh mode distribution for multicast groups
   that will be used in RSVP sessions.  For LANE1.0 networks the only
   multicast distribution option is over the LANE Broadcast and Unknown
   Server which means that the break bit MUST always be set.  For
   LANE2.0 [3] there are provisions that allow for non-server solutions
   with which it may be possible to ensure proper QoS delivery.










Berger                      Standards Track                    [Page 10]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


3.4 Receiver Transitions

   When setting up a point-to-multipoint VCs there will be a time when
   some receivers have been added to a QoS VC and some have not.

   During such transition times it is possible to start sending data on
   the newly established VC. If data is sent both on the new VC and the
   old VC, then data will be delivered with proper QoS to some receivers
   and with the old QoS to all receivers.  Additionally, the QoS
   receivers would get duplicate data.  If data is sent just on the new
   QoS VC, the receivers that have not yet been added will miss data.
   So, the issue comes down to whether to send to both the old and new
   VCs, or to just send to one of the VCs.  In one case duplicate data
   will be received, in the other some data may not be received.  This
   issue needs to be considered for three cases: when establishing the
   first QoS VC, when establishing a VC to support a QoS change, and
   when adding a new end-point to an already established QoS VC.

   The first two cases are essentially the same.  In both, it is
   possible to send data on the partially completed new VC.  In both,
   there is the option of duplicate or lost data.  In order to ensure
   predictable behavior and to conform to the requirement to deliver
   data to all receivers, data MUST NOT be sent on new VCs until all
   parties have been added.  This will ensure that all data is only
   delivered once to all receivers.

   The last case differs from the others and occurs when an end-point
   must be added to an existing QoS VC.  In this case the end-point must
   be both added to the QoS VC and dropped from a best effort VC.  The
   issue is which to do first.  If the add is first requested, then the
   end-point may get duplicate data.  If the drop is requested first,
   then the end-point may miss data.  In order to avoid loss of data,
   the add MUST be completed first and then followed by the drop.  This
   behavior requires receivers to be prepared to receive some duplicate
   packets at times of QoS setup.

4. Security Considerations

   The same considerations stated in [8] and [11] apply to this
   document.  There are no additional security issues raised in this
   document.

5. Acknowledgments

   This work is based on earlier drafts and comments from the ISSLL
   working group.  The author would like to acknowledge their
   contribution, most notably Steve Berson who coauthored one of the
   drafts.



Berger                      Standards Track                    [Page 11]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


6. Author's Address

   Lou Berger
   FORE Systems
   1595 Spring Hill Road
   5th Floor
   Vienna, VA 22182

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









































Berger                      Standards Track                    [Page 12]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


REFERENCES

   [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
       Networks," RFC 2022, November 1996.

   [2] The ATM Forum, "LAN Emulation Over ATM Specification", Version
       1.0.

   [3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI
       Specification", April 1997.

   [4] The ATM Forum, "MPOA Baseline Version 1", May 1997.

   [5] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24,
       RFC 2379, August 1998.

   [6] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
       and Guaranteed-Service with ATM", RFC 2381, August 1998.

   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [8] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.

   [9] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
       J. Krawczyk, "A Framework for Integrated Services and RSVP over
       ATM", RFC 2382, August 1998.

   [10] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
        Layer 5", RFC 1483, July 1993.

   [11] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
        A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
        February 1995.

   [12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0
        Update", RFC 2331, April 1998.












Berger                      Standards Track                    [Page 13]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


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.
























Berger                      Standards Track                    [Page 14]