rfc2379.txt

RFC 的详细文档！


RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


   approach, when best effort short-cuts are never established, RSVP
   triggered QoS short-cuts will also never be established.

2.4 Data VC Management for Heterogeneous Sessions

   Heterogeneous sessions can only occur with multicast RSVP sessions.
   The issues relating to data VC management of heterogeneous sessions
   are covered in detail in [6] and are not repeated in this document.
   In summary, heterogeneity occurs when receivers request different
   levels of QoS within a single session and also when some receivers do
   not request any QoS.  Both types of heterogeneity are shown in figure
   3.

                                    +----+
                           +------> | R1 |
                           |        +----+
                           |
                           |        +----+
              +-----+ -----+   +--> | R2 |
              |     | ---------+    +----+        Receiver Request Types:
              | Src |                             ---->  QoS 1 and QoS 2
              |     | .........+    +----+        ....>  Best-Effort
              +-----+ .....+   +..> | R3 |
                           :        +----+
                       /\  :
                       ||  :        +----+
                       ||  +......> | R4 |
                       ||           +----+
                     Single
                  IP Mulicast
                     Group

                    Figure 3: Types of Multicast Receivers

   [6] provides four models for dealing with heterogeneity: full
   heterogeneity,  limited heterogeneity, homogeneous, and modified
   homogeneous models.  The key issue to be addressed by an
   implementation is providing requested QoS downstream. One of, or some
   combination of, the discussed models [6] may be used to provide the
   requested QoS.  Unfortunately, none of the described models is the
   right answer for all cases.  For some networks, e.g.  public WANs, it
   is likely that the limited heterogeneous model or a hybrid limited-
   full heterogeneous model will be desired.  In other networks, e.g.
   LANs, it is likely that a the modified homogeneous model will be
   desired.






Berger                   Best Current Practice                  [Page 5]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


   Since there is not one model that satisfies all cases,
   implementations SHOULD implement one of either the limited
   heterogeneity model or the modified homogeneous model.
   Implementations SHOULD support both approaches and provide the
   ability to select which method is actually used, but are not required
   to do so.

3. Security Considerations

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

4. 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.

5. Author's Address

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

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






















Berger                   Best Current Practice                  [Page 6]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


REFERENCES

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

   [2] Berger, L., "RSVP over ATM Implementation Requirements",
       RFC 2380, August 1998.

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

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

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

   [6] 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.

   [7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next
       Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

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
























Berger                   Best Current Practice                  [Page 7]

RFC 2379        RSVP over ATM Implementation Guidelines      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                   Best Current Practice                  [Page 8]