Movatterモバイル変換

Network Working Group                                          L. BergerRequest for Comments: 2379                                  FORE SystemsBCP: 24                                                      August 1998Category: Best Current PracticeRSVP over ATM Implementation GuidelinesStatus of this Memo   This document specifies an Internet Best Current Practices for the   Internet Community, and requests discussion and suggestions for   improvements.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1998).  All Rights Reserved.Abstract   This memo presents specific implementation guidelines for running   RSVP over ATM switched virtual circuits (SVCs).  The general problem   is discussed in [6].  Implementation requirements are discussed in   [2].  Integrated Services to ATM service mappings are covered in [3].   The full set of documents present the background and information   needed to implement Integrated Services and RSVP over ATM.1. Introduction   This memo discusses running IP over ATM in an environment where SVCs   are used to support QoS flows and RSVP is used as the internet level   QoS signaling protocol.  It applies when using CLIP/ION, LANE2.0 and   MPOA methods for supporting IP over ATM.  The general issues related   to running RSVP[4] over ATM have been covered in several papers   including [6] and other earlier work.  This document is intended as a   companion to [6,2] and as a guide to implementers.  The reader should   be familiar with both documents.   This document provides a recommended set of functionality for   implementations using ATM UNI3.x and 4.0, while allowing for more   sophisticated approaches.  We expect some vendors to additionally   provide some of the more sophisticated approaches described in [6],   and some networks to only make use of such approaches.  The   recommended set of functionality is defined to ensure predictability   and interoperability between different implementations.  Requirements   for RSVP over ATM implementations are provided in [2].Berger                   Best Current Practice                  [Page 1]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998   This document uses the same terms and assumption stated in [2].   Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described inRFC2119 [5].2. Implementation Recommendations   This section provides implementation guidelines for implementation of   RSVP over ATM.  Several recommendations are common for all, RSVP   sessions, both unicast and multicast.  There are also recommendations   that are unique to unicast and multicast session types.2.1 RSVP Message VC Usage   The general issues related to which VC should be used for RSVP   messages is covered in [6]. It discussed several implementation   options including: mixed control and data, single control VC per   session,  single control VC multiplexed among sessions, and multiple   VCs multiplexed among sessions.  QoS for control VCs was also   discussed.  The general discussion is not repeated here and [6]   should be reviewed for detailed information.   RSVP over ATM implementations SHOULD send RSVP control (messages)   over the best effort data path, see figure 1.  It is permissible to   allow a user to override this behavior.  The stated approach   minimizes VC requirements since the best effort data path will need   to exist in order for RSVP sessions to be established and in order   for RSVP reservations to be initiated.  The specific best effort   paths that will be used by RSVP are: for unicast, the same VC used to   reach the unicast destination; and for multicast, the same VC that is   used for best effort traffic destined to the IP multicast group.   Note that for multicast there may be another best effort VC that is   used to carry session data traffic, i.e., for data that is both in   the multicast group and matching a sessions protocol and port.Berger                   Best Current Practice                  [Page 2]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998                            Data Flow ==========>                                   QoS VCs                    +-----+    -------------->   +----+                    |     |  -------------->     |    |                    | Src |                      | R1 |                    |     |   Best Effort VC(s)  |    |                    +-----+  <-----------------> +----+                                 /\                                 ||                                 ||                             RSVP Control                               Messages                  Figure 1: RSVP Control Message VC Usage   The disadvantage of this approach is that best effort VCs may not   provide the reliability that RSVP needs.  However the best effort   path is expected to satisfy RSVP reliability requirements in most   networks. Especially since RSVP allows for a certain amount of packet   loss without any loss of state synchronization.2.2 Aggregation   As discussed in [6], data associated with multiple RSVP sessions can   be sent using the same shared VCs. Implementation of such   "aggregation" models is still a matter for research.  Therefore, RSVP   over ATM implementations SHOULD use independent VCs for each RSVP   reservation.2.3 Short-Cuts   Short-cuts allow ATM attached routers and hosts to directly establish   point-to-point VCs across LIS boundaries, i.e., the VC end-points are   on different IP subnets. Short-cut support for unicast traffic has   been defined in [7] and [1].  The ability for short-cuts and RSVP to   interoperate has been raised as a general question.  The area of   concern is the ability to handle asymmetric short-cuts.  Specifically   how RSVP can handle the case where a downstream short-cut may not   have a matching upstream short-cut.  In this case, which is shown in   figure 2, PATH and RESV messages following different paths.Berger                   Best Current Practice                  [Page 3]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998                       ______                      /      \           +-------- / Router \ <-------+           |         \        /         |   <....... RESVs Follow           |          \______/          |            Hop-by-hop Path           |                            |           |                            |           V           QoS VCs          |        +-----+    ==============>   +----+        |     |  ==============>     |    |        | Src |                      | R1 |        |     |   Best Effort VC(s)  |    |        +-----+  <=================> +----+                     /\                     ::                        Data Paths:                     ::                        ----> Hop-by-hop (routed)               PATHs and Data                  ====> Short-cut              Follow Short-cut                     Path      Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts   Examination of RSVP shows that the protocol already includes   mechanisms that allows support of the asymmetric paths.  The   mechanism is the same one used to support RESV messages arriving at   the wrong router and the wrong interface. RSVP messages are only   processed when they arrive at the proper interface. When messages   arrive on the wrong interface, they are forwarded by RSVP.  The   proper interface is indicated in the NHOP object of the message. So,   existing RSVP mechanisms will support the asymmetric paths that can   occur when using short-cuts.   The short-cut model of VC establishment still poses several issues   when running with RSVP. The major issues are dealing with established   best effort short-cuts, when to establish short-cuts, and QoS only   short-cuts. These issues will need to be addressed by RSVP   implementations.   The key issue to be addressed by RSVP over ATM implementations is   when to establish a short-cut for a QoS data flow.  RSVP over ATM   implementations SHOULD simply follow best effort traffic. When a   short-cut has been established for best effort traffic to a   destination or next-hop, that same end-point SHOULD be used when   setting up RSVP triggered VCs for QoS traffic to the same destination   or next-hop. This will happen naturally when PATH messages are   forwarded over the best effort short-cut.  Note that in thisBerger                   Best Current Practice                  [Page 4]

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: +1 703-245-4527   EMail: lberger@fore.comBerger                   Best Current Practice                  [Page 6]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998REFERENCES   [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 1998Full 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]