RSVP over ATM Implementation Guidelines
RFC 2379
Document | Type |
RFC - Best Current Practice
(August 1998; No errata)
Also known as BCP 24
|
|
---|---|---|---|
Author | Lou Berger | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2379 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 UsageShow full document text