summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2379.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2379.txt')
-rw-r--r--doc/rfc/rfc2379.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2379.txt b/doc/rfc/rfc2379.txt
new file mode 100644
index 0000000..fb92d84
--- /dev/null
+++ b/doc/rfc/rfc2379.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group L. Berger
+Request for Comments: 2379 FORE Systems
+BCP: 24 August 1998
+Category: Best Current Practice
+
+
+ RSVP over ATM Implementation Guidelines
+
+Status 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 in RFC
+ 2119 [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 this
+
+
+
+Berger 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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+