A Framework for Integrated Services and RSVP over ATM
RFC 2382

Document Type RFC - Informational (August 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2382 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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 are routed over which VCs.

Crawley, et. al.             Informational                      [Page 2]
Show full document text