[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                            R. O. Onvural
INTERNET DRAFT                                             V. Srinivasan
                                                        26 February 1996

        A Framework for Supporting RSVP Flows Over ATM Networks

Status of This Memo

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the internet-drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific


   The RSVP and Integrated Services working groups have been working
   towards the goal of an "Integrated Services Internet" where
   applications can request a Quality of Service (QoS) from the
   network in order to meet their end-to-end service requirements
   [1].  This document reviews various issues related to running RSVP
   and Integrated Service models over ATM and presents a model to
   address some of these issues.  It is intended as a starting point for
   building an architectural framework to support RSVP/ATM Interworking.

Onvural, Srinivasan           Expires 31 August 1996            [Page i]

Internet Draft         RSVP over ATM Framework          26 February 1996

1. Introduction

   The focus of much recent work has been on identifying issues
   related to the efficient transport of RSVP flows over ATM networks
   [10,11,12,13,14,15,16].  This document proposes an architectural
   framework for supporting RSVP flows over ATM networks.  Various areas
   addressed include:

   i) support for heterogeneous receivers
   ii) support for IntServ service models
   iii) mapping IP layer traffic parameters to ATM traffic parameters
   iv) support for RSVP merging capability
   v) support for RSVP filter specs
   vi) mapping RSVP best effort service to ATM tagging function
   vi) moving among different service levels
   vii) mapping guaranteed service delays to ATM maximum cell transfer

   At the time of writing this document, much activity is in progress
   within the IETF and ATM Forum in addressing issues related to
   RSVP-based services over ATM networks.  Consequently, these topics
   may not yet be covered in detail in this version of the document,
   but will be included in future revisions.  These topics include
   API issues, multicast short cuts and QoS routing, detailed traffic
   management mechanisms, end-system (host) considerations, and the role
   of network management, to name a few.

   The document is organized as follows:  Section 2 is an overview of
   RSVP features, particularly as they relate to RSVP/ATM interworking.
   The intserv service models are reviewed in Section 3.  Current
   capabilities provided in various ATM standards are visited in Section
   4.  The proposed model is introduced in section 5.

2. IETF Model Overview

   The IETF model to support real-time services uses the specification
   of a signaling protocol by the RSVP working group, and of service
   categories developed by the Integrated Services (intserv) working
   group.  RSVP is a set up protocol used for resource reservation,
   designed to support integrated services over Internet [2].  It is
   an Internet style signaling protocol used by the hosts and network
   elements to request a specific Quality of Service (QoS) on behalf of
   an application data stream.  IETF service categories defined by the
   intserv model allow a rich set of requirements to support different
   types of services over Internet.

Onvural, Srinivasan           Expires 31 August 1996            [Page 1]

Internet Draft         RSVP over ATM Framework          26 February 1996

   The various features of RSVP can be summarized as follows:
   1.  RSVP requests resources in only one direction, e.g., for a
   simplex data stream.
   2.  RSVP operates on top of IP (either IPv4 or IP6), occupying the
   place of a transport protocol in the protocol stack.  However, it is
   not used to transport application data.
   3.  RSVP is receiver-oriented.  The receiver of a data flow initiates
   and maintains the resource reservation used for that flow.
   4.  It can be used to make resource reservations for both unicast and
   many-to-many multicast applications.
   5.  It provides features to dynamically adapt to changing group
   membership and changing routes.
   6.  RSVP is not a routing protocol and requires the services of
   unicast and multicast routing protocols.
   7.  It uses "soft state" in the routers.  It generates periodic
   refresh messages to maintain the state along the reserved path(s);
   the state will automatically time out and be deleted in the absence
   of refreshes.
   8.  RSVP provides different reservation models or "styles" to fit a
   variety of applications.  It provides transparent operation through
   routers that do not support it.

   In the remainder of this section, we briefly discuss several of
   these features of RSVP. RSVP defines a session as a data flow with
   a particular destination and transport-layer protocol, and treats
   each session independently.  An RSVP reservation request consists of
   a flow descriptor, composed of a flowspec and a filter spec.  The
   flowspec includes the specification of a service class and two sets
   of numeric parameters:  an "Rspec" that defines the desired QoS and
   a "Tspec" that describes the data flow.  Filter specs may be used to
   select arbitrary subsets of the packets in a given session.  Such
   subsets might be defined in terms of senders (i.e., sender IP address
   and generalized source port), in terms of a higher-level protocol,
   or generally in terms of any fields in any protocol headers in the
   packet.  Following the notation used in the RSVP specification, we
   use the terms "upstream" vs.  "downstream", "previous hop" vs.  "next
   hop", and "incoming interface" vs "outgoing interface" with respect
   to the direction of data flows.  RSVP reservation request messages
   originate at receivers and are passed upstream towards the sender(s).

   When a reservation request is received at a node, two general actions
   are taken:
   (i) Make a reservation:  The flowspec and the filter spec are
   first used by the admission control module that determines the
   admissibility of the request.  If this test fails, the reservation
   is rejected and RSVP returns an error message to the appropriate
   receiver(s).  If admission control succeeds, the node uses the

Onvural, Srinivasan           Expires 31 August 1996            [Page 2]

Internet Draft         RSVP over ATM Framework          26 February 1996

   flowspec to set up the packet scheduler for the desired QoS and the
   filter spec to set the packet classifier to select the appropriate
   data packets.  (ii) Forward the request upstream:  The reservation
   request is propagated upstream towards the appropriate senders.
   The set of sender hosts to which a given reservation request is
   propagated is called the "scope" of that request.

   The reservation request that a node forwards upstream may differ from
   the request that it received from downstream.  In particular, it is
   possible for the traffic control mechanism to modify the flowspec
   hop-by-hop.  Reservations for the same sender (or a particular group
   of senders) from different downstream branches of the multicast
   tree(s) are merged as reservations travel upstream.  In this case,
   a node forwards upstream only the reservation request with the
   "maximum" flowspec.  In particular, a successful reservation request
   propagates as far as the closest point(s) along the sink tree to
   the sender(s) where there is an existing reservation level equal to
   or greater than that being requested.  At that point, the arriving
   request is dropped in favor of the equal or larger reservation in
   place.  The basic RSVP reservation model is "one pass":  a receiver
   sends a reservation request upstream, and each node in the path
   either accepts or rejects the request.  This scheme provides no easy
   way for a receiver to find out the resulting end-to-end service.
   RSVP supports an enhancement to one-pass service known as "One Pass
   With Advertising" (OPWA) [2].  With OPWA, RSVP control packets are
   sent downstream, following the data paths, to gather information that
   may be used to predict the end-to-end QoS. These advertisements are
   delivered by RSVP to the receiver hosts and perhaps to the receiver
   applications.  They may then be used by the receiver to construct, or
   to dynamically adjust, an appropriate reservation request.

   A reservation request includes a set of control options, collectively
   called the reservation style.  There are two options defined:  (i)
   distinct or shared and (ii) explicit or wildcard.  The first option
   concerns the treatment of reservations for different senders within
   the same session:  establish a distinct reservation for each upstream
   sender or make a single reservation that is shared among selected
   senders.  The second option controls the selection of senders:  an
   explicit list of senders or a wildcard that implicitly selects all
   the senders to the session.

   Wildcard-Filter (WF) Style:  A single reservation is made for
   the flows of all upstream senders in a particular group.  This
   reservation may be thought of as a shared "pipe", whose size is the
   largest of the resource requests from all receivers, independent
   of the number of senders using it.  Symbolically, WF-style
   reservation request is represented by WF( * Q) where the asterisk
   represents wildcard sender selection and Q represents the flowspec.

Onvural, Srinivasan           Expires 31 August 1996            [Page 3]

Internet Draft         RSVP over ATM Framework          26 February 1996

   Fixed-Filter (FF) Style:  A distinct reservation is required for
   each sender.  A sender doesn't share the same reservation with
   other senders' packets for the same session.  The total reservation
   on a link for a given session is the total of all FF reservations
   in the session.  On the other hand, FF reservations requested by
   different receivers from the same sender are merged to share a single
   reservation.  Symbolically, an FF reservation request is represented
   by FF( SQ), where S is the selected sender and Q is the corresponding

   Shared Explicit (SE) Style:  A single shared reservation is created
   into which flows from a particular group of upstream senders are
   mixed.  Similar to the FF style, the SE style allows a receiver
   to explicitly specify the set of senders.  Symbolically, an SE
   reservation request is represented by SE( (S1,S2,...)Q ), where S1,
   S2, ...  is the list of senders and Q is the corresponding flow spec.
   Both WF and SE are shared reservations, appropriate for multicast
   applications in which it is unlikely that multiple data sources
   transmits simultaneously, for example audio conferencing.  The FF
   style creates independent reservations for the flows from different
   senders, e.g., video conferencing.

   There are two fundamental RSVP message types:  RESV and PATH. Each
   RSVP sender host transmits RSVP PATH messages downstream along
   the uni-/multicast routes provided by the routing protocol(s),
   following the paths of the data.  PATH messages cause path states
   to be established in each node along the way.  A PATH message may
   optionally carry a package of OPWA advertising information, known as
   an Adspec.  An Adspec received in a PATH message is passed to the
   local traffic control, which returns an updated Adspec which is then
   forwarded downstream.  Each sender host periodically sends a PATH
   message containing a description of each data stream it originates.
   The PATH message travels from a sender to receiver(s) along the
   same path(s) used by the data packets.  The IP source address of a
   PATH message is an address of the sender it describes, while the
   destination address is the DestAddress for the session.  These
   addresses assure that the message will be correctly routed through a
   non-RSVP cloud.  Each receiver host sends RSVP reservation request
   (RESV) messages upstream towards the senders.  RESV messages are sent
   hop-by-hop; each RSVP-speaking node forwards a RESV message to the
   unicast address of a previous RSVP hop.  These reservation messages
   must follow exactly the reverse of the routes the data packets
   will use, upstream to all the sender hosts included in the sender
   selection.  RESV messages must be delivered to the sender hosts
   themselves so that the hosts can set up appropriate traffic control
   parameters for the first hop.  The IP destination address of a RESV
   message is the unicast address of a previous-hop node, obtained from
   the path state.  The IP source address is an address of the node

Onvural, Srinivasan           Expires 31 August 1996            [Page 4]

Internet Draft         RSVP over ATM Framework          26 February 1996

   that sent the message.  In addition to PATH and RESV messages, two
   messages are used to terminate a session:  PTEAR and RTEAR. A PTEAR
   message deletes path state, and a RTEAR message deletes reservation
   state.  RSVP also includes error messages to report exception events.

   In the following section, we briefly discuss the various service
   specifications being studied by the intserv working group of the
   IETF. These services use RSVP as the signaling mechanism to obtain
   QoS from the network.  We also identify some of the issues involved
   in supporting the intserv services over ATM networks.

3. Integrated Services Overview

   The IETF's Integrated Services (intserv) working group is studying
   several service specifications in the form of Internet Drafts
   [4,5,6,7].  The purpose of these services is to support the transport
   of audio, video, real time, and data traffic within a single network
   infrastructure.  The current intserv service specifications include:
   Guaranteed Delay, Controlled Delay, Predictive, and Controlled Load.

   Packet delay is the only QoS metric that is quantified within the
   intserv model.  Packet loss, in general, is required to be "low,"
   without any quantitative measures provided or specified as a no-loss

   The Guaranteed Delay class [4] provides firm bounds on the maximum
   end-to-end packet transfer delay for each session using this
   service.  Every packet from a session conforming to its declared
   traffic behavior is guaranteed a deterministic (with probability
   1) end-to-end delay bound by this service.  A rate is reserved at
   each node that a session from this class traverses.  The end-to-end
   bound, then, is comprised of three parts:  the delay experienced by
   a perfect fluid source with a dedicated "pipe" across the network
   with a bandwidth equal to the reserved rate, and two error terms that
   account for deviations from the fluid model and fixed delays along
   the path.  The Guaranteed Delay class provides a lossless service.

   Controlled Delay service [5] offers applications several levels of
   delays to choose from.  Currently, these levels of services are
   defined in a way that service level 1 is expected to be better than
   service level 2, which in turn is expected to be better than service
   level 3.  The delay experienced by packets is controlled in the
   sense that all three levels of services have better average delays
   than that of best effort service.  However, no assurances about
   the absolute levels of delay are made.  For each level of service,
   a network element provides an estimate of the maximum delay that

Onvural, Srinivasan           Expires 31 August 1996            [Page 5]

Internet Draft         RSVP over ATM Framework          26 February 1996

   packets experience over a time period T. Three such intervals are
   defined:  1 sec, 60 sec, and 3600 sec.

   In order to obtain estimates of the packet delays over the different
   time intervals, it is necessary for the network element to take
   measurements and average these over some set of time intervals.
   There is no requirement, however, for these measurements to be exact.

   The Predictive Service class [6] in the intserv model is designed for
   applications which desire a reserved rate with low packet loss and a
   maximum bound on end-to-end delay.  It differs from the guaranteed
   delay class however in that occasional late or lost packets can be
   tolerated.  The delay bound is required to be quantified.  However,
   as is the case with the other intserv specifications, the allowable
   rate of packet loss (except for Guaranteed Delay, which is a lossless
   service) and delay bound violation is not quantified but simply
   required to be "very low." Similar to the Controlled Delay class,
   the Predictive Service specification defines three logical levels
   of service, each associated with a delay bound with level 1 having
   the smallest delay and level 3 having the largest.  Each Predictive
   Service module advertises the delay bound as well as measurements of
   the maximum delay over three different time scales for each of the
   three levels (twelve quantities in total).  The reservation required
   by an application is specified by the delay level its flow must use
   at each node along its path.

   The Controlled Load class is the most minimal of the intserv services
   in terms of the guarantees provided to sessions.  There is only a
   single level of service associated with this class -- a session can
   expect to receive, under all conditions, service closely resembling
   the service which the same session would receive using best-effort
   delivery under "unloaded" network conditions [7].  The term
   "unloaded" refers to a "not heavily loaded or congested" network.

4. ATM Standards Overview

   The ATM Forum Traffic Management (TM) Specification 4.0 [11] enhances
   the QoS support in an ATM network by extending UNI 3.1 QoS service
   categories to include individual QoS parameters.  In addition, it
   defines an Available Bit Rate (ABR) service to support best effort
   traffic effectively in the network.  Various ATM service categories
   defined in UNI 4.0 are Constant Bit Rate (CBR), Real-Time Variable
   Bit Rate (rt-VBR), Non Real-Time Variable Bit Rate (nrt-VBR),
   Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). There are
   also four QoS Classes used to map application requirements, ranging
   from the very strict circuit emulation to the much less stringent
   connectionless data transfer, to an ATM connection.  Together, QoS

Onvural, Srinivasan           Expires 31 August 1996            [Page 6]

Internet Draft         RSVP over ATM Framework          26 February 1996

   Classes and service categories map connection traffic characteristics
   and QoS requirements to network behavior.

   Various features included in UNI 4.0 include [9]:

   Point-to-point Calls
   Point-to-multipoint Calls
   Leaf Initiated Join Capability
   Notification of end-to-end Connection Completion
   ATM Anycast capability (Note 1)
   Multiple signalling channels
   Switched Virtual Path (VP) service
   Proxy signalling
   Frame Discard Capability (Note 3)
   ABR Signaling for Point-to-point Calls
   Generic Identifier Transport
   Traffic Parameter Negotiation
   Signalling of Individual QoS Parameters
   Supplementary Services
   Direct Dialing In (DDI)
   Multiple Subscriber Number (MSN)
   Subaddressing (SUB) (Note 2)
   User-user Signalling (UUS)

   Note 1 - This feature is optional for public networks/switching
   systems and is mandatory for private networks/switching systems.
   Note 2 - This feature is mandatory for networks/switching systems
   (public and private) that support only native E.164 address formats.
   Note 3 - Transport of the Frame Discard indication is Mandatory.

   Similarly, various capabilities are available in ITU Q.29xx
   Recommendations.  Q.2962 allows the negotiation of the peak cell
   rate during the call set up.  Q.2963 allows peak rate renegotiation
   (potentially sustainable cell rate and burst size) after the
   connection set up.  Q.298x allows multiple connections to be
   established for a call.  Q.2957 provides user-to-user signaling
   thereby allowing information exchange during the set up or when the
   connection is in an active state.

5. Overview of the Working Model

5.1. Objectives

   The RSVP/ATM interworking function model is developed with the
   following objectives:

Onvural, Srinivasan           Expires 31 August 1996            [Page 7]

Internet Draft         RSVP over ATM Framework          26 February 1996

   1.  Use existing RFCs and Internet Drafts while imposing minimal, if
   any, changes to them;
   2.  Use currently available ATM standards (that are developed by both
   ATM Forum and ITU) with minimal, if any, changes to them, and
   3.  Define the required functions in the context of a RSVP
   Coordination Entity (RCE) thereby allowing a variety of physical
   configurations that may be configured depending on the specifics of a
   particular environment.

5.2. Model and Scope of Operation

   In the proposed model, we consider a network of RSVP-capable routers
   and hosts with an ATM network providing connectivity between them.
   These routers are connected to an ATM network via a UNI, and hence
   are required to support SVC signaling.  The scope of the ATM cloud
   is assumed to be identical to that of a single MARS cluster [17].
   We assume that the ATM cloud is served by a MARS that provides
   resolution of IP multicast addresses to ATM addresses of IP endpoints
   in the cluster.

   The interworking function is developed based on a logical function
   called a RSVP Coordination Entity (RCE).

   An RCE is required to perform the following functions:

   1.  ATM multicast.
   2.  Support ATM UNI (other interfaces such as PNNI may be supported
   through simple extensions).
   3.  RSVP capabilities:  in this context, RSVP capabilities refer to
   the ability of the network element to understand, act upon, update
   and generate RSVP control messages, as required by the RSVP protocol.
   4.  Interact with the MARS to resolve IP multicast addresses to ATM

   RCEs are used to efficiently support various RSVP features over ATM.
   In particular, various capabilities provided in an RCE include:

   1.  Efficient merging of RSVP flows:  RCEs are points along the
   end-to-end paths of single or multiple RSVP flows where RSVP merging
   capability, based on RSVP filters, is provided.  There may be one or
   more RCEs along an end-to-end path.
   2.  Efficient establishment and maintenance of multicast trees at the
   ATM layer.
   3.  Support for receiver heterogeneity in order to provide different
   levels of QoS.
   4.  Translation of Tspec into ATM traffic parameters.
   5.  Translation of Rspec into ATM quality of service framework.

Onvural, Srinivasan           Expires 31 August 1996            [Page 8]

Internet Draft         RSVP over ATM Framework          26 February 1996

   There may be one or more RCEs present within a MARS cluster.
   There is no restriction on where the RCE function may reside.  In
   particular, an RCE may be physically resident at a host, a router, or
   an ATM switch.  The actual placement of RCE(s) may depend on various
   administrative and performance constraints.

   For illustrative purposes, let us consider a MARS cluster with a
   Sender, S1, an RCE (RCE1) and a receiver, R1.

   1.  S1 originates (or forwards) a PATH message on a control VCC to
   2.  RCE1 issues a MARS_REQUEST to the MARS to resolve the IP
   multicast address of the destination group included in the PATH
   3.  MARS responds with the ATM address(es) of the members of the
   4.  RCE1 assigns a multicast tree id to this session as identified in
   the path message (if one does not exist already)
   5.  RCE1 uses control VCCs to forward the PATH message to the
   endpoints specified in the MARS response message.  These control VCCs
   are point-to-point virtual channels.
   6.  Endpoints process the PATH message as defined in the RSVP
   protocol At this time, there are no resources reserved in the ATM
   network for this session.
   7.  R1 initiates a RESV message to be transferred back to RCE1.  A
   LEAF INITIATED JOIN message is generated at the receiver's interface
   with the root option (i.e., the message will be forwarded to the
   root) where the root of the multicast tree is RCE1.  This requires
   the use of an additional information element at the LEAF INITIATED
   JOIN message.
   8.  RCE1 performs RSVP processing based on the information element
   included in the LEAF INITIATED JOIN message, sets up a new multicast
   tree or extends an existing multicast tree to that leaf, and forwards
   the RESV message (if needed) upstream.  Alternatively, RCE1 could use
   a control VCC to send the RESV message to LNE1.

   Various details of RCE processing such as updating the PATH message,
   etc.  are omitted in this example for reasons of clarity.  In
   particular, topics that need elaboration include:

   (a) Control connections and their usage.
   (b) Data connections:  establishment, tear-down, and usage.
   (c) Advertisement of a single multicast identifier or Generic Call
   Identifier that corresponds to an RSVP session identifier.
   (d) Handling of RESV messages.
   (e) The operation of multiple RCEs.

   We address these issues in the following sections.

Onvural, Srinivasan           Expires 31 August 1996            [Page 9]

Internet Draft         RSVP over ATM Framework          26 February 1996

5.3. The RCE Model

   Consider a MARS cluster with multiple RCEs.  Without loss of
   generality, network elements that have a PATH message for
   transmission over the ATM network are referred to as Senders.
   The PATH message may have originated external to the ATM cloud.
   Accordingly, the ATM end station (i.e., a router, a host, a switch)
   that accesses the ATM cloud for an RSVP session does not have to be
   actual originator of the PATH message.  Nevertheless, we will refer
   to this network element as a Sender (for the ATM cloud).  Similarly,
   we will use the term Receiver to refer to the network element
   attached to the ATM network from which the RSVP messages leave the
   ATM cloud.  Each Sender may have a control VCC to one or more RCEs
   (either a PVC or an SVC). However, only one RCE is chosen to handle
   the PATH messages at any given time.  The RCE that serves a Sender
   may be configured dynamically by means of:

   1.  A preassigned VCC to determine the address of the RCE (perhaps
   from a configuration server), or
   2.  ATM ILMI procedures may be used dynamically.

   Control connections between a Sender and an RCE are bidirectional
   point-to-point connections.  Upon receiving a PATH message from a
   Sender, an RCE performs various functions that include:

   - Processing and updating PATH messages as required in RSVP
   - Forwarding PATH messages towards the receivers
   - Assigning a multicast tree id to this flow, if one was not assigned

   In forwarding the PATH message, an RCE uses the appropriate control
   VCC towards the destination.  If there are one or more other RCEs
   on the route from the RCE that first forwarded the PATH message
   towards the receiver(s), these other RCEs may or may not be required
   to process and update the PATH message.  Either option has its
   advantages and disadvantages and these need to be carefully weighed
   before this decision can be made.  However, no resource reservation
   is made in the ATM network as the PATH message travels from its
   Sender towards the Receiver.  The control VCCs are long-lived and may
   use ABR, UBR, or VBR traffic class with parameters requiring minimal
   resource reservation.

   Processing and updating a PATH message involves saving path state
   in the RCE and updating the Adspec, if present.  The Adspec cannot
   be updated accurately at this stage as no end-to-end path has been
   established yet (a path from the Sender to RCE is not established as
   well).  Hence, the best RCE can do at this stage is to update the

Onvural, Srinivasan           Expires 31 August 1996           [Page 10]

Internet Draft         RSVP over ATM Framework          26 February 1996

   Adspec with an estimate.  Different approaches to update Adspec are
   reviewed in [8].

   When a RESV message arrives at the edge of an ATM network, the
   Receiver can use either UNI 4.0 Leaf Initiated Join (LIJ) procedures
   to add itself to the multicast tree, or it may use control VCCs to
   transport RESV messages to the root of the tree.  The root of this
   tree is the first RCE to which the Sender transmitted its initial
   PATH message.

   NOTE: Extensions to multiple RCE environment in which the LIJ
   request travels towards the root via more than one RCE (and perhaps
   stops being forwarded by one of these RCEs based on the RSVP filter
   spec/merge functions) can be incorporated relatively easily and will
   be included in the future versions of this document.

   LIJ has two modes:  with or without root notification.  In this
   proposal, we use the LIJ with root-prompted join mode in which the
   root handles the join request.  Furthermore, we assume here that an
   information element to carry the related contents of the RESV message
   is made available in the LIJ capability.  Which fields of the RESV
   message are to be included in this information element is for further

   Alternatively, the RESV message can be sent to the RCE using the
   same bidirectional control VCC on which the PATH message arrived to
   the receiver.  This would require the receiver to maintain an an
   association (in a table) between RSVP sessions and control VCCs in
   order to be able to send the RESV message to the same RCE from which
   the PATH was received.

   The choice of using the LIJ mechanism with appropriate information
   elements, or a control VCC to send the RESV message, will depend
   on the particular environment.  For instance, in environments that
   support UNI 4.0, it might be simpler to leverage the LIJ function
   provided by UNI 4.0.  On the other hand, in environments that support
   UNI 3.0/3.1 which do not include LIJ capability, the control VCC
   option is more appropriate.

   As discussed in the next section, we assume there are only a few
   different service levels that needs to be supported in a service
   model.  For example, there are only three levels of services in the
   controlled delay and predictive service models.  Controlled load
   only has a single service level.  While Guaranteed delay service can
   have a very large number of different rates requested in the Rspec,
   we assume it is possible to categorize different rates that may be
   requested for an application to a few distinct values.  Based on
   this framework, RCE can establish different multicast trees, so that

Onvural, Srinivasan           Expires 31 August 1996           [Page 11]

Internet Draft         RSVP over ATM Framework          26 February 1996

   a particular multicast tree will support receivers with the same
   service requirement within a session.  It is noted that only one
   multicast tree identifier is used by an RSVP session.  Although there
   will be multiple multicast trees used to support different service
   levels, each tree does not support the LIJ capability (i.e., they are
   not made visible outside the ATM cloud).

   When the root RCE receives the corresponding indication to add a new
   leaf, it first processes the RESV message to determine the type of
   the service requested by the receiver.  The next step is to determine
   the multicast tree that best matches the service requirement of the
   receiver.  Then, an ADD PARTY message is sent to add the Receiver to
   the corresponding multicast tree.

5.3.1. Control Connections and Their Usage

   Control VCCs can be established using permanent VCCs or switched
   VCCs.  Most likely, these VCCs will use UBR or ABR traffic class
   service.  These connections are used only to pass the PATH and RESV
   messages from one edge of the network to another.  RCEs also use
   control VCCs to communicate with each other (i.e., forward RSVP
   messages and related information).

   Control VCCs are bidirectional, point-to-point connections.

5.3.2. Data connections

   Data connections that originate at RCEs are always point-to-multipoint
   connections.  Data connections that originate at the Senders,
   established to an RCE, are always point-to-point VCCs.  The traffic
   category and QoS class requested for a connection depends on receiver

5.3.3. Advertisement of a single multicast identifier

   An RCE can advertise a single multicast identifier that corresponds
   to an RSVP session identifier.  This needs to be handled by network
   management or by other off line means.

5.3.4. Handling RESV messages

   There is no need to keep forwarding RESV messages for established
   sessions within an ATM cloud.  If the connection is terminated for
   some reason within the ATM cloud, this will be reported to one or

Onvural, Srinivasan           Expires 31 August 1996           [Page 12]

Internet Draft         RSVP over ATM Framework          26 February 1996

   more UNIs in the network and the RSVP user will be notified.  If a
   connection is terminated outside the ATM cloud, then the Receiver
   will receive this message and terminate the connection using ATM
   signaling procedures.  If the RESV message is for a change in the
   service quality, then this will be treated as if it is a new RESV
   message, as discussed later in this document.

5.3.5. Operation of Multiple RCEs

   The details of the operation of multiple RCEs within an ATM cloud are
   for further study.

5.4. Supporting RSVP features over ATM

5.4.1. Heterogeneous Receivers

   RSVP provides means to support "heterogeneous receivers".  That is,
   different receivers of a particular flow may ask different service
   levels from the network.  ATM architecture, on the other hand,
   require all receivers of a point-to-multipoint connection to have
   the same QoS. One trivial way to support heterogeneous receivers
   in ATM is to establish different point-to-point connections to
   each receiver that take into consideration the QoS requirement of
   the application explicitly.  Another alternative is to establish
   a point-to-multipoint connection with the most stringent QoS
   requirements of all receivers.  The first solution requires managing
   potentially very large number of point-to-point VCs and does not
   scale well.  The latter proposal solves this scalability problem but
   results in overallocation of resources in the ATM network.  Although
   there can be thousands of receivers in a session, different levels of
   quality of service that may be requested by receivers are expected to
   be a small number.  In particular, for each intserv service model, we

   Guaranteed service

   This is a lossless service in which end-to-end delay experienced by
   packets in a flow is guaranteed to be less than or equal to a maximum
   value specified by the receiver.  This value is specified by the
   receiver as a clearing rate R. Although the granularity of R is 1
   byte/sec in the RSVP spec, different R's that may be specified for a
   particular application may be classified into a few values.

   Controlled Delay Service

Onvural, Srinivasan           Expires 31 August 1996           [Page 13]

Internet Draft         RSVP over ATM Framework          26 February 1996

   Currently, three levels of services are defined in the controlled
   service such that service level 1 is expected to be better than
   service level 2, which in turn is expected to be better than service
   level 3.  The delay experienced by packets is controlled in the
   sense that all three levels of services have better average delays
   than that of best effort service.  However, no assurances about the
   absolute levels of delay can be made.  It is possible to provision
   these three levels of delays in the ATM network that meet the service
   requirements of the controlled service.  In this case, receivers
   request only one of three possible service values.  The delay values
   provided in each service level may be updated using ILMI or offline
   (network management) at time intervals when the network can not
   provide the specified delay values (for new connections) or when it
   can provide significantly better delay values.

   Predictive Service

   Predictive service offers applications a number of long term
   end-to-end delays to choose from.  Similar to controlled service,
   different values of delay values provided in the ATM network may
   be pre-specified and updated as needed.  The number of different
   delay values provided in the ATM network to support this service is
   expected to be a small number as well.

   Controlled Load Service

   There is only a single level of service associated with this class
   -- a session can expect to receive, under all conditions, a service
   closely resembling the service which the same session would receive
   using best-effort delivery under "unloaded" network conditions.
   Again the delay value associated with this service in the ATM network
   can be easily provisioned and updated over long intervals of time as

   Assuming that different delay values that may be requested by a
   receiver for each IntServ service model can be classified into a
   smaller set, the service requirement of a flow from a particular
   receiver can be supported in the current ATM signaling easily by
   associating the QoS requirements of service models to ATM QoS classes
   and using UNI 4.0 maximum cell transfer delay, maximum cell delay
   variation, cell loss ratio parameters.

5.4.2. Moving between different service levels

   RSVP allows receivers to change their previously requested service
   levels depending on their service requirement and their observation
   of the performance they are currently receiving.  Accordingly,

Onvural, Srinivasan           Expires 31 August 1996           [Page 14]

Internet Draft         RSVP over ATM Framework          26 February 1996

   applications can move to a higher level (better delay) or to a lower
   level throughout the duration of their session.  One trivial method
   to support this requirement is to terminate the existing connection
   and establish a new ATM connection based on the most recent service
   requirement.  This solution may impose a significant signaling
   load to the ATM network, thereby restricting establishment of new

   In the proposed model, handling service modifications is more
   efficient than terminating/establishing end-to-end connections.  In
   particular, service intelligence can be easily incorporated into the
   RCE to support this RSVP feature.  For example, if there is already
   a multicast tree established for the most recently requested service
   level, then this request can be easily satisfied by dropping the
   leaf from the current tree and adding it to another that matches the
   request most closely.  This would impose minimal signaling load to
   the network while meeting the service requirement.

5.4.3. Best Effort Service when resources are not available

   Another RSVP feature allows receivers to receive the flow in a
   best-effort manner.  In particular, RSVP prevents denial-of-service
   attacks via reservations by not allowing the network elements to
   simply drop non-conforming packets.  Both Guaranteed and Controlled
   Load service models assign non-conformant packets to best-effort
   status (which may result in packet drops if there is congestion).
   The ATM service model has a similar feature in which non-conforming
   traffic is tagged and allowed to enter the network.  Marked ATM cells
   are dropped in the intermediate switches if there is not enough
   resource available to transmit these cells without causing service
   degradation to conforming traffic.  The number of non-conforming
   cells before a connection is classified non-compliant is network
   specific.  Hence, it is possible to support RSVP best effort packets
   in ATM using ATM's tagging feature.  Early Packet Discard (EPD)
   schemes may be used in the network elements to increase the effective
   resource utilization without impacting the service quality to the
   receiver (as if one or more cells of a packet is dropped in the
   network, the rest of the information carried in arrived cells at the
   receiver may not be useful for the application).

5.4.4. Flow aggregation

   Flow aggregation occurs in the proposed model only at the RCEs.
   Each RCE terminates incoming flows and originating outgoing flows.
   Accordingly, supporting flow aggregation can be achieved easily at
   the RCEs by multiplexing traffic from incoming connections (VCs) to

Onvural, Srinivasan           Expires 31 August 1996           [Page 15]

Internet Draft         RSVP over ATM Framework          26 February 1996

   an outgoing connection (VC). The multiplexing needs to take into
   consideration the service levels provided in each outgoing connection
   and may be required to use more than one VC to support different
   service requirements.

5.4.5. Mapping RSVP parameters

   RSVP Tspec maps into ATM traffic parameters in a straightforward
   manner.  Tspec also specifies which ATM traffic class may be used
   for the connection.  Tspec includes the peak rate of the connection
   and the leaky bucket parameters that matches (after the values are
   adjusted) the ATM traffic parameters.  If the peak rate is equal to
   the token generation rate (or close enough), CBR service category
   may be used.  Otherwise, it is a variable bit rate connection.  ATM
   defines three different variable bit rate traffic classes i.e.,
   VBR, UBR, ABR. The choice among these three would depend on the
   service requirement of the receiver which requires for the RCE to
   wait for the RESV message.  Rspec in the RESV message may then be
   used to determine which ATM traffic category may be used for the ATM
   connection, together with the QoS profiles defined in the network
   associated with each QoS class.  Note that ATM traffic categories
   and QoS classes do not have a one-to-one relationship and may be
   combined in any way that fits the application requirements.  RSVP
   Rspec does not map into any ATM QoS class directly.  However, as
   discussed in section 4.2.1, it is possible to pre-define and manage
   semi-dynamically various service profiles that can match RSVP service

5.4.6. Directly attached ATM hosts

   In this framework, an ATM host with RCE functionality may use RSVP
   without the need to support other routing functions (i.e., it does
   not have to be a router).

5.4.7. Packet level/cell level traffic parameter mapping

   The RSVP TSpec can be mapped to ATM traffic descriptors in a
   straightforward manner.  A description of this mapping is provided in
   [8].  Briefly summarizing, if we ignore the segmentation overhead and
   effects of the granularity of ATM cell size, the following mapping
   can be used:

   SCR = r / 48; MBS = b / 48; PCR = P / 48,

Onvural, Srinivasan           Expires 31 August 1996           [Page 16]

Internet Draft         RSVP over ATM Framework          26 February 1996

   where r and b are the token generation rate and bucket depth, and
   P corresponds to the minimum of the incoming link and the actual
   peak rate of the flow (currently, the TSpec does not include a peak
   rate for any intserv service classes; inclusion of this parameter
   is currently under study).  The above relations can be modified to
   include the effect of segmentation overhead as:

   SCR = ar; MBS = ab; PCR = aP

   where a = (1 + ceil(p / 48)) / p represents the worst case overhead
   due to the ATM segmentation with AAL5 and a minimum packets size of p
   (in bytes).  The "ceil" operator corresponds to the ceiling function.
   Further refinements to these relations can be found in [8].

6. Summary

   The main objective of this document is to outline a framework to
   provide RSVP/ATM interworking.  The proposed approach takes advantage
   of the ATM transfer capabilities while supporting RSVP features
   efficiently.  There are several areas that needs to be satisfactorily
   addressed for this document to be complete.  However, several
   of the related issues have been studied and various solutions do
   exist to fill in the gaps.  We believe those areas that are yet to
   be addressed may be satisfactorily resolved within the proposed

7. Acknowledgments

   Rao Cherukuri, Dean Skidmore and Wayne Pace have patiently spent long
   hours with us, discussing several ideas presented in this document
   and their contributions are greatly appreciated.

8. References

   [1] R. Braden, D. Clark, S. Shenker, Integrated Services in the
   Internet Architecture:  an Overview, RFC 1633, June 1994.

   [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin., Resource
   ReSerVation Protocol (RSVP) -- Version 1 Functional Specification.
   Internet Draft, draft-ietf-rsvp-spec-10.  February 1996.

   [3] R. Cole, D. Shur, C. Villamizar.  IP over ATM: A Framework
   Document.  Internet Draft, draft-ietf-ipatm-framework-doc-07,
   February 1996.

Onvural, Srinivasan           Expires 31 August 1996           [Page 17]

Internet Draft         RSVP over ATM Framework          26 February 1996

   [4] S. Shenker and C. Partridge.  "Specification of Guaranteed
   Quality of Service (draft-ietf-intserv-guaranteed- svc-03.txt)."
   INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services
   WG, November 1995.

   [5] S. Shenker, C. Partridge, and JJ. Wroclawski.  "Specification of
   Controlled Delay Quality of Service (draft-ietf-intserv-control-del-svc-02.txt)."
   INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services
   WG, November 1995.

   [6] S. Shenker, C. Partridge, B. Davie, and L. Breslau.
   "Specification of Predictive Quality of Service (draft-ietf-intserv-predictive-svc-01.txt)."
   INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services
   WG, November 1995.

   [7] J. Wroclawski.  "Specification of the Controlled-Load Network
   Element Service (draft-ietf-intserv-ctrl-load- svc-01.txt)."
   INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services
   WG, November 1995.

   [8] A. Birman, V. Firoiu, R. Guerin, and D. Kandlur.  "Provisioning
   of RSVP-Based Services over Large ATM Networks." IBM Research Report
   No.  RC 20250, October 1995.  Available from IBM Research Web Server
   (CyberJournal) at URL: http://www.watson.ibm.com:8080/.

   [9] "Draft of UNI Signalling 4.0", ATM Forum/95-1434R8, December

   [10] M. Borden, E. Crawley, B. Davie, and S. Batsell.  "Integration
   of Real-time Services in an IP-ATM Network Architecture," RFC 1821,
   August 1995.

   [11] "Traffic Management Specification 4.0", ATM Forum/95-0013R10,
   December 1995.

   [12] ATM Forum Contribution 96-0096, "Issues in Mapping INTSERV
   service specifications to ATM Service Categories", R. Onvural, S.
   Rampal, V. Srinivasan, R. Balay

   [13] ATM Forum Contribution 96-0094, "Issues in Extending Unicast and
   Multicast RSVP Flows Across ATM Networks", R. Guerin, D. Kandlur

   [14] ATM Forum Contribution 96-0097, "RSVP and Integrated Services
   over ATM and API", R. Guerin, V. Srinivasan, D. Skidmore, R.
   Cherukuri, D. Kandlur, R. Onvural

   [15] ATM Forum Contribution 96-0160, "Interworking between IETF RSVP
   Signaling Protocol and ATM Signaling", R. Cherukuri and D. Skidmore

Onvural, Srinivasan           Expires 31 August 1996           [Page 18]

Internet Draft         RSVP over ATM Framework          26 February 1996

   [16] ATM Forum Contribution 96-0258, "RSVP and MPOA", S. Berson

   [17] G. Armitage, "Support for Multicast over UNI 3.1 based ATM
   Networks", Internet Draft, IP over ATM Working Group, draft-ietf-
   ipatm-ipmc-12.txt, February 1996.

9. Authors' Address

          Raif O. Onvural
          IBM Corporation
          Research Triangle Park, NC 27709

          Phone:   +1-919-254-4687
          Fax:     +1-919-254-5410
          E-mail:  onvural@vnet.ibm.com

          Vijay Srinivasan
          IBM Corporation
          Research Triangle Park, NC 27709

          Phone:   +1-919-254-2730
          Fax:     +1-919-254-5410
          E-mail:  vijay@raleigh.ibm.com

Onvural, Srinivasan           Expires 31 August 1996           [Page 19]