Network Working Group E. Crawley, Editor Request for Comments: 2382 Argon Networks Category: Informational L. Berger Fore Systems S. Berson ISI F. Baker Cisco Systems M. Borden Bay Networks J. Krawczyk ArrowPoint Communications August 1998 A Framework for Integrated Services and RSVP over ATM Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group. 1. Introduction The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first- serve scheduling at each hop in the network. Best effort service has worked well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded portions of the network. In order to provide quality real-time traffic, new classes of service and a QoS signalling protocol are Crawley, et. al. Informational [Page 1] RFC 2382 Integrated Services and RSVP over ATM August 1998 being introduced in the Internet [1,6,7], while retaining the existing best effort service. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol and the service models One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be added and removed from the VC dynamically and so provides a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer including ATM, and this memo concentrates on ATM. Classical IP over ATM [10] has solved part of this problem, supporting IP unicast best effort traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within an LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is being solved with MARS [5], the Multicast Address Resolution Server. MARS compliments ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address. The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also address the support of IP best effort traffic over ATM through similar means. A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows