Internet Engineering Task Force R. O. Onvural
INTERNET DRAFT V. Srinivasan
IBM
26 February 1996
A Framework for Supporting RSVP Flows Over ATM Networks
draft-onvural-srinivasan-rsvp-atm-00.txt
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
Rim).
Abstract
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
delay
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
flowspec.
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
service.
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
addresses.
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
RCE1
2. RCE1 issues a MARS_REQUEST to the MARS to resolve the IP
multicast address of the destination group included in the PATH
message
3. MARS responds with the ATM address(es) of the members of the
group
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
processing
- Forwarding PATH messages towards the receivers
- Assigning a multicast tree id to this flow, if one was not assigned
already
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
study.
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
requirements.
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
have:
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
needed.
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
connections.
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
models.
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
framework.
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
1995.
[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
BUA/664
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
BUA/664
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]