As per Relevance of the word multicast, we have this rfc below:
Network Working Group M.
Request for Comments: 1821 E.
Category: Informational Bay
B.
S.
August 1995
Integration of Real-time Services in an IP-ATM Network
Status of the
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The IETF is currently developing an integrated service model which
designed to support real-time services on the Internet
Concurrently, the ATM Forum is developing Asynchronous Transfer
networking which similarly provides real-time networking support.
use of ATM in the Internet as a link layer protocol is
occurring, and both the IETF and the ATM Forum are
specifications for IP over ATM. The purpose of this paper is
provide a clear statement of what issues need to be addressed
interfacing the IP integrated services environment with an
service environment so as to create a seamless interface between
two in support of end users desiring real-time networking services
Table of
1.0 Introduction 2
2.0 Problem Space Overview 3
2.1 Initial Assumptions 3
2.2 Topologies Under Consideration 4
2.3 Providing QoS in IP over ATM - a walk-though 5
3.0 Service Model Issues 6
3.1 Traffic Characterization 7
3.2 QoS Characterization 8
4.0 Resource Reservation Styles 10
4.1 RSVP 10
4.2 ST-II 13
4.3 Mapping IP flows to ATM Connections 15
5.0 End System Issues 16
6.0 Routing Issues 16
Borden, et al Informational [Page 1]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
6.1 Multicast routing 17
6.2 QoS Routing 17
6.3 Mobile Routing 18
7.0 Security Issues 19
8.0 Future Directions 20
9.0 References 22
10.0 Authors' Addresses 24
1.0
The traditional network service on the Internet is best-
datagram transmission. In this service, packets from a source
sent to a destination, with no guarantee of delivery. For
applications that require a guarantee of delivery, the TCP
will trade packet delay for correct reception by retransmitting
packets that fail to reach the destination. For
computer-communication applications such as FTP and Telnet in
correct delivery is more important than timeliness, this service
satisfactory. However, a new class of application which uses
media (voice, video, and computer data) has begun to appear on
Internet. Examples of this class of application are
teleconferencing, video-on-demand, and distributed simulation.
these applications can operate to some extent using best-
delivery, trading packet delay for correct reception is not
acceptable trade-off. Operating in the traditional mode for
applications results in reduced quality of the received
and, potentially, inefficient use of bandwidth. To remedy
problem the IETF is developing a real-time service environment
which multiple classes of service are offered [6]. This
will greatly extend the existing best-effort service model to
the needs of multimedia applications with real-time constraints
At the same time that this effort is underway in the IETF
Asynchronous Transfer Mode (ATM) is being developed, initially as
replacement for the current telephone network protocols, but
recently as a link-layer protocol for computer communications. As
was developed from the beginning with telephone voice applications
mind, a real-time service environment is an integral part of
protocol. With the approval of UNI 3.1 by the ATM Forum, the
standards now have several categories of service. Given the
acceptance of ATM by the long-line carriers, the use of ATM in
Internet is, if not guaranteed, highly likely. The question
becomes, how can we successfully interface between the real-
services offered by ATM and the new,integrated service
soon to be available in the IP protocol suite. The current IP
ATM standards assume no real-time IP protocols. It is the purpose
this RFC to clearly delineate what the issues are in
real-time services in an IP-over-ATM network [10,15,19,20,21].
Borden, et al Informational [Page 2]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
In the IP-over-ATM environment, as in many others, multicast
adds an additional set of challenges. While the major focus of
paper is quality of service (QoS) issues, it is unwise at best
ignore multicast when considering these issues, especially since
many of the applications that motivate the provision of real time
also require efficient multicast support. We will therefore try
keep considerations of multicast in the foreground in the
discussion
One of the primary motivations for this document is a belief by
authors that ATM should, if possible, be used as more than a
line replacement. That is to say, while it is possible for
Internet to be overlaid on constant bit rate (CBR), permanent
circuits (PVCs), thus reducing IP over ATM to a previously
problem, we believe that this is unlikely to be the most
way to use ATM services as they are offered by carriers or as
appear in LANs. For example, a carrier offering a CBR service
assume that the peak bit rate can be used continuously with
degradation in quality and so resources must be allocated to
connection to provide that service, even if the peak rate is in
rarely used. This is likely to make a CBR service more expensive
a variable bit rate service of the same peak capacity. Another
to view this is that the new IP service model will allow us
associate information about the bandwidth requirements
applications with individual flows; surely it is not wise to
this information when we request a service from an ATM subnet
While we believe that there is a range of capabilities in
networks that can be effectively used by a real-time Internet, we
not believe that just because ATM has a capability, the Internet
use it. Thus, our goal in this RFC is to begin to explore how
Internet with real time service capability might make most
use of ATM networks. Since there are a number of problems to
resolved to achieve this effective use, our major goal at this
is to describe the scope of the problems that need to be addressed
2.0 Problem Space
In this section we aim to describe in high level terms the scope
the problem that will be explored in more detail in later sections
2.1 Initial
We begin by assuming that an Integrated Services Internet, i.e.,
Internet with a range of qualities of service to support both real
time and non-real-time applications, will eventually happen. A
of working groups are trying to make this happen,
Borden, et al Informational [Page 3]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
* the Integrated Services group (int-serv), which is working to
a new IP service model, including a set of services suited to
range of real-time applications
* the Resource reservation Setup Protocol group (rsvp), which
defining a resource reservation protocol [7] by which
appropriate service for an application can be requested from
network
* the Internet Streams Protocol V2 group (ST-II), which is
[27], a stream-oriented internet protocol that provides a range
service qualities
In addition, the IETF IP over ATM working group and the ATM
Multiprotocol over ATM group are working to define a model
protocols to make use of the ATM layer
Since these groups have not yet generated standards, we will need
do some amount of extrapolation to predict the problems that
arise for IP over ATM. We also assume that the standards
developed in the ATM Forum will largely determine the service
for ATM. Again, some extrapolation may be needed. Given
assumptions, this paper aims to explore ways in which a
Integrated Services Internet might make effective use of ATM as
seems likely to be deployed
2.2 Topologies Under
Figure 1 shows a generic internetwork that includes ATM and non-
subnetworks. This paper aims to outline the problems that must
addressed to enable suitable quality of service to be provided end
to-end across such a network. The problem space, therefore,
* communication across an 'ATM-only' network between two
directly connected to the ATM network
* communication between ATM-connected hosts which involves
some non-ATM subnets
* communication between a host on a non-ATM subnet and a host
connected to ATM
* communication between two hosts, neither of which has a direct
connection, but which may make use of one or more ATM networks
some part of the path
Borden, et al Informational [Page 4]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
[H
| [H
________|________________________ |
| | |
________|__ ______|___|____
| | | |
| ATM [R] [R] ATM |
| Cloud | | Cloud |___[H
| | Non-ATM Internet | |
| | [R] |
|________[R] |_____________|
| | |
| | |
[H] |________________________________|
|
|
[H
[H] =
[R] =
Figure 1
In the last case, the entities connected to the ATM network are
routers, and it is their job to manage the QoS provided by the
network(s) in such a way that the desired end-to-end QoS is
to the hosts. While we wish to describe the problem space in a
that covers all of these scenarios, the last is perhaps the
general, so we will use it for most illustrative purposes.
particular, we are explicitly not interested in ways of providing
that are applicable only to a subset of these situations. We
that addressing these four situations is sufficiently general
cover other situations such as those in which several ATM and non-
networks are traversed
It is worth mentioning that the ATM networks in this case might
local or wide area, private or public. In some cases,
distinction may be significant, e.g., because there may be
implications to a particular approach to providing QoS
2.3 Providing QoS in IP over ATM - a walk-
To motivate the following discussion, this section walks through
example of what might happen when an application with a certain
of QoS needs starts up. For this example, we will use the fourth
mentioned above, i.e., two hosts connected to non-ATM networks
making use of an ATM backbone
Borden, et al Informational [Page 5]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
A generic discussion of this situation is made difficult by the
that the reservation of resources in the Internet may be sender
receiver initiated, depending on the specifics of the setup protocol
We will attempt to gloss over this distinction for now, although
will return to it in Section 4. We will assume a unicast
and that the traffic characteristics and the QoS requirements (
as delay, loss, throughput) of the application are known to at
one host. That host launches a request for the desired QoS and
description of the expected traffic into the network; at some
this request hits a router at the edge of the ATM network. The
must examine the request and decide if it can use an
connection over the ATM network to honor the request or whether
must establish a new connection. In the latter case, it must use
QoS and traffic characterizations to decide what sort of
connection to open and to describe the desired service to the
network. It must also decide where to open the connection to.
the connection is opened, the request is forwarded across the
network to the exit router and then proceeds across the non-ATM
of the network by the normal means
We can see from the above description that there are several sets
issues to be discussed
* How does the IP service model, with certain service classes
associated styles of traffic and QoS characterization, map
the ATM service model
* How does the IP reservation model (whatever it turns out to be)
onto ATM signalling
* How does IP over ATM routing work when service quality is added
the picture
These issues will be discussed in the following sections
3.0 Service Model
There are several significant differences between the ways in
IP and ATM will provide QoS. When IP commits to provide a
QoS to an application according to the Internet service model,
must be able to request an appropriate QoS from the ATM network
the ATM service model. Since these service models are by no means
same, a potentially complex mapping must be performed for the
layer to meet its commitments. The details of the
between ATM and IP and the problems presented by these
are described below
Borden, et al Informational [Page 6]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
We may think of a real-time service model as containing the
components
* a way to characterize traffic (sometimes called the Tspec);
* a way to characterize the desired quality of service (the Rspec).
We label these components as traffic characterization and
characterization. Each of these components is discussed in turn
the following sections
As well as these aspects of the service model, both ATM and IP
have a number of mechanisms by which the model is implemented.
mechanisms include admission control, policing, and
scheduling. A particularly important mechanism is the one by
end-nodes communicate their QoS needs and traffic characteristics
the network, and the network communicates admission control
to the end-nodes. This is referred to as resource reservation
signalling, and is the subject of Section 4. In fact, it seems to
the only mechanism where significant issues of IP/ATM
arise. The details of admission control, policing and
scheduling are largely internal to a single network element and we
not foresee significant problems caused by the integration of IP
ATM. For example, while there may be plenty of challenges
designing effective approaches to admission control for both IP
ATM, it is not apparent that there are any special challenges for
IP over ATM environment. As the walk-through of Section 2.3
described, a reservation request from a host would at some
encounter the edge of the ATM cloud. At this point, either a
connection needs to be set up across the ATM cloud, or the router
decide to carry the requested traffic over an existing
circuit. If the ATM cloud cannot create a new connection
requested, this would presumably result in an admission
failure which would cause the router to deny the reservation request
3.1 Traffic
The traffic characterization provided by an application or user
used by the network to make decisions about how to provide
desired quality of service to this application and to assess
effect the new flow will have on the service provided to
flows. Clearly this information feeds into the admission
decision process
In the Internet community, it is assumed that traffic will in
be bursty and that bursty traffic can be characterized by a `
bucket'. While ATM does not expect all traffic to be bursty (
Continuous Bit Rate class being defined specifically for non-
Borden, et al Informational [Page 7]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
traffic), it uses an essentially equivalent formulation for
characterization of traffic that is bursty, referred to as
Generic Cell Rate Algorithm (GCRA). However, ATM in some classes
requires specification of peak cell rate, whereas peak rates are
currently included in the IP traffic characterizations. It may
possible to use incoming interface speeds to determine an
peak rate
One of the functions that must be performed in order to carry
traffic over an ATM network is therefore a mapping from
characterization of the traffic as supplied to IP to
characterization that is acceptable for ATM. While the similarity
the two characterizations suggests that this is straightforward
there is considerable flexibility in the mapping of parameters
IP to ATM. As an extreme example, a router at the edge of an
cloud that expects to receive bursts of IP packets on a non-
interface, with the bursts described by some token bucket parameters
could actually inject ATM cells at a constant rate into the
network. This may be achieved without significant buffering if
ATM link speed is faster than the point-to-point link speed
alternatively, it could be achieved by buffering out the
of the arriving traffic. It seems more reasonable to map an IP
(or a group of flows) with variable bandwidth requirements onto
ATM connection that accommodates variable bit rate traffic
Determining how best to map the IP traffic to ATM connections in
way is an area that warrants investigation
A potential complication to this process is the fact that the
bucket parameters are specified at the edge of the IP network,
that the specification of the GCRA parameters at the entry to an
network will frequently happen at a router in the middle of an
network. Thus the actual burstiness that is encountered at the
may differ from that described by the IP token bucket parameters,
the burstiness changes as the traffic traverses a network.
seriousness of this problem needs to be understood to
efficient resource utilization
3.2 QoS
In addition to specifying the traffic that they will submit to
network, applications must specify the QoS they require from
network. Since the goal is to carry IP efficiently over ATM networks
it is necessary to establish mechanisms by which QoS
for IP traffic can be translated into QoS specifications that
meaningful for an ATM network
Borden, et al Informational [Page 8]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
The proposed method of QoS specification for the Internet is
specify a `service class' and some set of parameters, depending
the service class. The currently proposed service classes
* guaranteed, which provides a mathematically guaranteed
bound [23];
* predictive delay, which provides a probabilistic delay
[24];
* controlled delay, which merely tries to provide several levels
delay which applications may choose between [25].
These are in addition to the existing `best-effort' class. More
service classes are expected in the future. ATM has five
classes
* CBR (constant bit rate), which emulates a leased line,
very tightly constrained delay and designed for applications
can use a fixed bandwidth pipe
* VBR (variable bit rate)-real-time which attempts to constrain
for applications whose bandwidth requirements vary
* VBR-non-real-time, intended for variable bandwidth
without tight delay constraints
* UBR (unspecified bit rate) which most closely approximates the
effort service of traditional IP
* ABR (available bit rate) which uses a complex feedback
to control loss
Each class requires some associated parameters to be specified, e.g.,
CBR requires a peak rate. Observe that these classes are by no
in direct correspondence with the IP classes. In some cases,
classes require parameters which are not provided at the IP level
such as loss rate, to be specified. It may be necessary to
reasonable default values in these cases
The major problem here is this: given traffic in a particular
service class with certain QoS parameters, how should it be
across an ATM network in such a way that it both meets its
commitments and makes efficient use of the ATM network's resources
For example, it would be possible to transport any class of
traffic over an ATM network using the constant bit rate (CBR)
class, thus using the ATM network like a point-to-point link.
would allow IP to meet its service commitments, but would be
Borden, et al Informational [Page 9]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
inefficient use of network resources in any case where the IP
was at all bursty (which is likely to be most cases). A
reasonable approach might be to map all IP traffic into a
bit rate (VBR) class; certainly this class has the flexibility
accommodate bursty IP traffic more efficiently than CBR
At present, the IETF is not working on any service classes in
loss rate is considered as part of the QoS specification. As long
that is the case, the fact that ATM allows target loss rates to
specified is essentially not an issue. However, we may
expect that as the IP service model is further refined,
classes that include specifications of loss may be defined. At
point, it will be necessary to be able to map between loss rates
the IP level and loss rates at the ATM level. It has already
shown that relatively small loss rates in an ATM network
translate to high loss rates in IP due to the fact that each
cell can cause the loss of an entire IP packet. Schemes to
this problem, which include the proposed approach to implementing
ABR class, as well as other solutions [22], have been proposed.
is clearly likely to be an important issue in the future
4.0 Resource Reservation
ATM uses a signalling protocol (Q.2931) both to establish
connections and to allocate resources to those connections. It
many of the characteristics of a 'conventional' signalling protocol
such as being sender-driven and relying on hard-state in switches
maintain connections. Some of the key characteristics are listed
the table below. In the current standards, the QoS associated with
connection at setup time cannot be changed subsequently (i.e., it
static); in a unicast connection, resources are allocated in
directions along the path, while in the multicast case, they
allocated only from the sender to the receivers. In this case,
senders receive the same QoS
Two protocols have been proposed for resource reservation in IP.
first (chronologically) is ST-II, the other is RSVP. Each of these
and its relationship to ATM, is discussed in the following sections
4.1
IP has traditionally provided connectionless service. To
real-time services in a connectionless world, RSVP has been
to enable network resources to be reserved for a connectionless
stream. ATM, on the other hand, provides a connection-
service, where resource reservations are made at connection
time, using a user-network interface (UNI) and a network-
interface (NNI) signalling protocol
Borden, et al Informational [Page 10]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Receiver-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Soft state | Hard state |
| | (refresh/time-out) | (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Separate from | Concurrent with |
| | route establishment | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------
The principles used in the design of RSVP differ from those of ATM
the following respects
* Resource reservations in IP hosts and routers are represented
soft state, i.e., reservations are not permanent, but time
after some period. Reservations must be refreshed to
time-out, and may also be explicitly deleted. In ATM, resources
reserved for the duration of a connection, which must be
and reliably deleted
* The soft state approach of RSVP allows the QoS reserved for a
to be changed at any time, whereas ATM connections have a
QoS that is fixed at setup time
* RSVP is a simplex protocol, i.e., resources are reserved in
direction only. In ATM, connections (and associated reservations
are bi-directional in point-to-point calls and uni-directional
point-to-multipoint calls
Borden, et al Informational [Page 11]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
* Resource reservation is receiver-initiated in RSVP. In ATM
resources are reserved by the end system setting up the connection
In point-to-multipoint calls, connection setup (and hence
reservation) must be done by the sender
* RSVP has explicit support for sessions containing multiple senders
namely the ability to select a subset of senders, and
dynamically switch between senders. No such support is
by ATM
* RSVP has been designed independently of other
components, in particular routing. Moreover, route setup
resource reservation are done at different times. In ATM,
reservation and route setup are done at the same time (
setup time).
The differences between RSVP and ATM state establishment,
described above, raise numerous problems. For example, since point
to-point connections are bidirectional in ATM, and since
can be made in both directions, receiver-initiated
reservations in RSVP can be simulated in ATM by having the
set up the connection and reserve resources in the backward
only. However, this is potentially wasteful of connection
since connections are only ever used to transfer data in
direction even though communication between the two parties may
bidirectional. One option is to use a `point-to-multipoint'
connection with only one receiver. Of course, the fact that the
reservation request is made by the receiver(s) means that
request must be somehow communicated to the sender on the
network. This is somewhat analogous to the receiver-oriented
operation of IP multicast and the problems of implementing it
ATM, as discussed in Section 6. In general, the efficiency of
proposed connection management scheme needs to be investigated
both unicast and multicast contexts for a range of
requirements, especially at a large scale
The use by RSVP of `soft state' as opposed to explicit
means that routers at the ATM network's edges need to manage
opening and closing of ATM connections when RSVP reservations
made and released (or time out). The optimal scheme for
setup and tear-down will depend on the cost of setting up
connection versus the cost of keeping the connection open
possible future use by another stream, and is likely to be
class-dependent. For example, connections may be left open for
by best-effort traffic (subject to sufficient connections
available), since no resources are explicitly reserved. On the
hand, connections supporting the real-time service classes are
to be expensive to leave open since resources may be allocated
Borden, et al Informational [Page 12]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
when the connection is idle. Again, the cost incurred will depend
the class. For example, the cost of an open, idle `guaranteed'
connection is likely to be significantly more expensive than
connection providing predictive or controlled delay service.
that connections can be reused for traffic of the same class
compatible QoS requirements, and that it may sometimes be possible
use a `higher quality' class to substitute for a lower quality one
Another characteristic of RSVP which presents problems for ATM is
use of PATH messages to convey information to receivers before
reservation is made. This works in IP because routing is
independently of reservation. Delivery of PATH messages across an
network is therefore likely to require a mechanism for setting
connections without reservations being made. The connection
needs to be of sufficient quality to deliver PATH messages
reliably; in some circumstances, a low quality best effort
may be inadequate for this task. A related issue is the problem
advertising services prior to reservations. The OPWA model (one
with advertising) requires network elements to advertise the QoS
they are able to provide so that receivers can decide what level
reservation to request. Since these advertisements may be made
to any resources having been reserved in the ATM network, it is
clear how to make meaningful advertisements of the QoS that might
provided across the ATM cloud
Finally, the multiparty model of communication is
different in RSVP and ATM. Emulating RSVP receiver-initiation
ATM point-to-multipoint connections is likely to cause severe
problems as the number of receivers becomes large. Also,
functions of RSVP are not currently provided by ATM. For example
there is no support for different receiver requirements
capabilities-all receivers in a session receive the same QoS,
is fixed at the time the first receiver is added to the
tree. It is likely that ATM support for multi-party sessions will
enhanced in later versions of the standards. It is necessary for
support to evolve in a manner compatible with RSVP and IP
routing protocols if large ATM clouds are to be
successfully
4.2 ST-
ST-II [27] and ST2+ [12] (referred to generically as ST hereafter
have data distribution and resource reservation schemes that
similar to ATM in many respects
* ST is connection oriented using "hard state". Senders set
simplex data flows to all receivers closely matching point-to
multipoint connections in ATM. Routing decisions are made
Borden, et al Informational [Page 13]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
the connection is made and are not changed unless there is
failure in the path. Positive acknowledgment is required from
receivers. ST2+ [12] adds a receiver-based JOIN mechanism that
reduce the burden on senders to track all receivers
* ST reserves network resources at connection setup time. The
CONNECT message contains a flowspec indicating the resources to
reserved for the stream. Agents along the path may change
flowspec based on restrictions they may need to impose on
stream. The final flowspec is returned to the sender in the
message from each receiver or target
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Sender-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Hard state | Hard state |
| | (explicit disconnect)| (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Concurrent with | Concurrent with |
| | stream setup | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------
These similarities make mapping ST services to ATM simpler than
but the mapping is still not trivial. The task of mapping the
flowspec into an ATM service class still has to be worked out.
may be policy issues related to opening a new VC for each
versus aggregating flows over an existing VC
Borden, et al Informational [Page 14]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
Additionally, ST has some differences with UNI 3.1 that can
problems when integrating the two protocols
* In ST, changes to active stream reservations are allowed.
example, if the flowspec received from the target is not
for the stream, the sender can send a CHANGE message, requesting
different QoS. UNI 3.1 does not allow changes to the QoS of a
after it is set up. Future ATM UNI specifications are
allowing changes to a VC after set up but this is still preliminary
In the meantime, policies for over reservation or aggregation
a larger VC may be needed
* ST uses simplex streams that flow in only one direction. This
fine for UNI 3.1 point-to-multipoint connections since the data
is only in one direction. When mapping a point-to-point
connection to a standard point-to-point ATM VC, the reverse
connection is wasted
This can be solved simply by using only point-to-multipoint VCs,
if there is only one receiver
4.3 Mapping IP flows to ATM
In general, there will be a great deal of flexibility in how one
flows at the IP level to connections at the ATM level. For example
one could imagine setting up an ATM connection when a
message arrives at the edge of an ATM cloud and then tearing it
as soon as the reservation times out. However, to minimize latency
perhaps for economic reasons, it may be preferable to keep the
connection up for some period in case it is needed. Similarly, it
be possible or desirable to map multiple IP flows to a single
connection or vice versa
An interesting situation arises when a reservation request
received for an existing route across the cloud but which, when
to the existing reservations using that connection, would exceed
capacity of that connection. Since the current ATM standards do
allow the QoS of a connection to be changed, there are two options
tear down the old connection and create a new one with the new
larger allocation of resources, or simply add a new connection
accommodate the extra traffic. It is possible that the former
lead to more efficient resource utilization. However, one would
wish to tear down the first connection before the second
admitted, and the second might fail admission control because of
resources allocated to the first. The difficulties of this
seem to argue for evolution of ATM standards to support
modification on an existing connection
Borden, et al Informational [Page 15]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
5.0 End System
In developing an integrated IP-ATM environment the applications
to be as oblivious as possible of the details of the environment:
applications should not need to know about the network topology
work properly. This can be facilitated first by a common
programing interface (API) and secondly by common flow and
specifications [18].
An example of a common API that is gaining momentum is the
sockets interface. This is a UNIX standard and, with Winsock2,
also become a PC standard. With the IETF integrated
environment just beginning to appear in the commercial marketplace
the ability to standardize on one common interface for both IP
ATM applications is still possible and must be seriously and
pursued to insure interoperability
Since the IP integrated service and ATM environments offer
QoS service types, an application should specify
information in its flow specification so that regardless of
topology of the network, the network can choose an acceptable
type to meet the applicationUs needs. Making the application
sufficient information to quantify a QoS service and allowing
network to choose the QoS service type is essential to freeing
application from requiring a set network topology and allowing
network to fully utilize the features of IP and ATM
6.0 Routing
There is a fundamental difference between the routing
for IP and ATM that can cause problems for real-time IP services
ATM computes a route or path at connection setup time and leaves
path in place until the connection is terminated or there is
failure in the path. An ATM cell only carries
identifying the connection and no information about the actual
and destination of the cell. In order to forward cells, an
device needs to consult a list of the established connections
map to the next hop device, without checking the final destination
In contrast, routing decisions in IP are based on the
address contained in every packet. This means that an IP router,
it receives each packet, has to consult a table that contains
routes to all possible destinations and the routing decision is
based on the final destination of the packet. This makes IP
very robust in the face of path changes and link failures at
expense of the extra header information and the potentially
table lookup. However, if an IP path has been selected for a
QoS, changes in the route may mean a change in the QoS of the path
Borden, et al Informational [Page 16]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
6.1 Multicast
Considerable research has gone into overlaying IP multicast
onto ATM. In the MARS (Multicast Address Resolution Server)
[1], a server is designated for the Logical IP Subnet (LIS) to
the ATM addresses of the hosts in the IP multicast group, much
the ATM ARP server [15]. When a host or router wishes to send to
multicast group on the LIS, a query is made to the MARS and a list
the ATM address of the hosts or routers in the group is returned.
sending host can then set up point-to-point or point-to-
VCs to the other group members. When a host or a router joins an
multicast group, it notified the MARS. Each of the current senders
the group is then notified of the new group member so that the
member can be added to the point to multipoint VC's
As the number of LIS hosts and multicast groups grows, the number
VCs needed for a one-to-one mapping of VCs to multicast groups
get very large. Aggregation of multicast groups onto the same VC
be necessary to avoid VC explosion. Aggregation is
complicated by the QoS that may be needed for particular senders in
multicast group. There may be a need to aggregate all the
flows requiring a certain QoS to a set of VCs, and parallel VCs
be necessary to add flows of the same QoS
6.2 QoS
Most unicast and multicast IP routing protocols compute the
path to a destination based solely on a hop count or metric.
[16] and MOSPF [17] allow computation based on different IP Type
Service (TOS) levels as well as link metrics, but no current
routing protocols take into consideration the wide range of levels
quality of service that are available in ATM or in the
Services models. In many routing protocols, computing all the
for just the shortest path for a large network is
expensive so repeating this process for multiple QoS levels might
prohibitively expensive
In ATM, the Private Network-to-Network Interface (PNNI) protocol [13]
communicates QoS information along with routing information, and
network nodes can utilize this information to establish paths for
required QoS. Integrated PNNI (I-PNNI) [9] has been proposed as a
to pass the QoS information available in ATM to other
protocols in an IP environment
Wang & Crowcroft [28] suggest that only bandwidth and delay
are necessary for QoS routing and this would work well for
a route that required a particular QoS at some setup time, but
goes against the connectionless Internet model. One possible
Borden, et al Informational [Page 17]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
to the exhaustive computation of all possible routes with
possible QoS values would be to compute routes for a common set
QoS values and only then compute routes for uncommon QoS values
needed, extracting a performance penalty only on the first packets
a flow with an uncommon QoS. Sparse multicast routing protocols
compute a multicast path in advance or on the first packets from
sender (such as CBT [5] and MOSPF [17]) could also use QoS
information to set up a delivery tree that will have
resources
However, no multicast routing protocols allow the communication
QoS information at tree setup time. Obtaining a tree with
QoS is intended to be handled by RSVP, usually after the
tree has been set up, and may require recomputation of
distribution tree to provide the requested QoS.One way to solve
problem is to add some "hints" to the multicast routing protocols
they can get an idea of the QoS that the multicast group will
at group initiation time and set up a distribution tree to
the desired QoS. The CBT protocol [5] has some TBD fields in
control headers to support resource reservation. Such
could also be added to a future IGMP [11] JOIN message that
include information on the PIM Rendezvous Point (RP) or CBT Core
Another alternative is to recompute the multicast distribution
based on the RSVP messages but this has the danger of losing
during the recomputation. However, this can leave a timing
where other reservations can come along during the tree
and use the resources of the new path as well as the old path
leaving the user with no path to support the QoS desired
If unicast routing is used to support multicast routing, we have
same problem of only knowing a single path to a given
with no QoS information. If the path suggested by unicast
does not have the resources to support the QoS desired, there are
choices available. Schemes that use an alternate route to "guess"
a better path have been suggested and can work for certain
but an underlying routing protocol that provides QoS information
necessary for a complete solution. As mentioned earlier, I-PNNI
the potential to provide enough information to compute paths for
requested QoS
6.3 Mobile
In developing an integrated IP-ATM network, potential new
areas need to be included in the planning stages. One such area
mobile networking. Under the heading of mobile networks are
satellite extensions of the ATM cloud, mobile hosts that can join
IP subnetwork at random, and a true mobile network in which
Borden, et al Informational [Page 18]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
network components including routers and/or switches are mobile
The IP-ATM real-time service environment must be extended to
mobile networks so as to allow mobile users to access the
services as fixed network users. In doing so, a number of
exist that need to be addressed. The principle problems are
mobile networks have constrained bandwidth compared to fiber
mobile links and are less stable than fixed fiber links. The
of these limitations affect IP and ATM differently. In
one or more constrained components into the ATM cloud,the effects
congestion control in the overall network are unknown. One
envision significant buffering problems when a disadvantaged user
a mobile link attempts to access information from a high speed
stream. Likewise, as ATM uses out of band signalling to set up
connection, the stability of the mobile links that may
significant fading or complete loss of connectivity could have
significant effect on ATM performance
For QoS, fading on a link will appear as a varying channel capacity
This will result in time-dependent fluctuations of available links
support a level of service. Current routing protocols are
designed to operate in a rapidly changing topology. QoS
protocols that can operate in a rapidly changing topology
required and need to be developed
7.0 Security
In a quality of service environment where network resources
reserved, hence potentially depriving other users access to
resources for some time period, authentication of the requesting
is essential. This problem is greatly increased in a combined IP-
topology where the requesting host can access the network
through the IP or the ATM portion of the network. Differences in
security architectures between IP and ATM can lead to
to reserve resources without proper authorization to do so. A
security framework over the combined IP-ATM topology would
desirable. In lieu of this, the use of trusted edge
requesting the QoS services are required as a near term solution
Significant progress in developing a common security framework for
is underway in the IETF [2]. The use of authentication headers
conjunction with appropriate key management is currently
considered as a long range solution to providing QoS security [3,8].
In developing this framework, the reality of ATM portions of
Internet should be taken into account. Of equal importance, the
Forum ad-hoc security group should take into account the current
on an IP security architecture to ensure compatibility
Borden, et al Informational [Page 19]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
8.0 Future
Clearly, there are some challenging issues for real-time IP-
services and some areas are better understood than others.
example, mechanisms such as policing, admission control and packet
cell scheduling can be dealt with mostly independently within IP
ATM as appropriate. Thus, while there may be hard problems to
solved in these areas that need to be addressed in either the IP
ATM communities, there are few serious problems that
specifically in the IP over ATM environment. This is because IP
not particularly care what mechanisms a network element (such as
ATM network) uses to provide a certain QoS; what matters is
the ATM service model is capable of offering services that
support the end-to-end IP service model. Most of the hard
for IP over ATM therefore revolve around the service models for
and ATM. The one piece of mechanism that is important in an IP/
context is signalling or resource reservation, a topic we return
below
The following paragraphs enumerate some of the areas in which
believe significant work is needed. The work falls into three areas
extending the IP over ATM standards; extensions to the ATM
model; and extensions to the IP service model. In general, we
that practical experience with providing IP QoS over ATM will
more enhancements to the service models
We need to define ways of mapping the QoS and
characterizations (Tspecs and Rspecs) of IP flows to
characterizations for ATM connections. An agreement is needed
that some sort of uniform approach is taken. Whatever agreement
made for such mappings, it needs to be done so that when
several networks, the requested QoS is obtained end-to-end (
admission is possible). Practical experience should be gained
these mappings to establish that the ATM service classes can in
provide suitable QoS to IP flows in a reasonably efficient way
Enhancement of the ATM service classes may be necessary,
experience is needed to determine what is appropriate
We need to determine how the resource reservation models of IP (
and ST-II) interact with ATM signalling. Mechanisms for
appropriate connection state with suitable QoS in ATM networks
are part of a larger integrated services Internet need to be defined
It is possible that the current IP/ATM mechanisms such as ARP
and MARS can be extended to help to manage this state
There is a need for better QoS routing. While this functionality
needed even in the pure ATM or pure IP environment, there is also
eventual need for integrated QoS routing between ATM and IP.
Borden, et al Informational [Page 20]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
research and practical experience is needed in the areas of
routing in IP in order to support more than the shortest best-
path, especially when this path may traverse ATM networks. In
IP networks, there are multiple paths between a given source
destination pair but current routing technologies only pay
to the current shortest path. As resources on the shortest path
reserved, it will be necessary and viable to explore other paths
order to provide QoS to a flow
Enrichment of the ATM model to support dynamic QoS would greatly
the IP over ATM situation. At present, the QoS objectives for ATM
established at call set-up and then fixed for the duration of a call
It would be advantageous to have the ability to provide a dynamic
in ATM, so that an existing call could be modified to provide
services
Another possible area of enhancement to the ATM service model is
the area of multicasting. The multicast QoS offered is equal for
receivers, and thus may be determined by the least favorable
through the tree or by the most demanding receiver. Furthermore
there is no current provision for multipoint to
connections. This limitation may rule out some of the
envisioned in the IP service model
There are areas of potential enrichment of the IP model as well
While the receiver-based approach of RSVP has nice scaling
and handles receiver heterogeneity well, it is not clear that it
ideal for all applications or for establishing state in ATM networks
It is possible that a sender-oriented mode for RSVP might ease
IP/ATM integration task
Since the widespread availability of QoS raises new security
(e.g., denial of service by excessive resource reservation), it
prudent that the IP and ATM communities work closely to
compatible approaches to handling these issues
This list is almost certainly incomplete. As work progresses
define IP over ATM standards to support QoS and to
integrated services internetworks that include ATM, more issues
likely to arise. However, we believe that this paper has
the major issues that need to be taken into consideration at
time by those who are defining the standards and
implementations
Borden, et al Informational [Page 21]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
9.0
1. Armitage, G., "Support for Multicast over UNI 3.1 based
Networks", Work in Progress, Bellcore, February 1995.
2. Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, NRL, August 1995.
3. Atkinson, R., "IP Authentication Header", RFC 1826, NRL
August 1995.
4. Ballardie, A., and J. Crowcroft, "Multicast-Specific
Threats and Counter-Measures", Proceedings of ISOC Symposium
Network and Distributed System Security, San Diego, Feb. 1995,
pp. 2-16.
5. Ballardie, T., Jain, N., Reeve, S. "Core Based Trees (CBT
Multicast, Protocol Specification", Work In Progress,
College London, Bay Networks, June, 1995.
6. Braden, R., Clark, D., and S. Shenker, "Integrated Services
the Internet Architecture: an Overview", RFC 1633, ISI/MIT/
PARC, July 1994.
7. Braden, R., Zhang, L., Estrin, Herzog, D., and S. Jamin
"Resource ReSerVation Protocol (RSVP) - Version 1
Specification", Work in Progress, ISI/PARC/UCS, July 1995.
8. Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of
Workshop on Security in the Internet Architecture", RFC 1636, ISI
MIT, TIS, INRIA, June 1994.
9. Callon, R., and B. Salkewicz, An Outline for Integrated PNNI
IP Routing", ATM Forum/ 95-0649, Bay Networks, July 1995.
10. Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A
Document", Work in Progress, AT&T Bell Laboratories/ ANS,
1995.
11. Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, Stanford University, August 1989.
12. Delgrossi, L., and L. Berger, Editors, "Internet Stream
Version 2 (ST-2) Protocol Specification - Version ST2+", RFC 1819,
ST2 Working Group, August 1995.
13. Dykeman, D., Ed., "PNNI Draft Specification", ATM Forum/94-0471R8,
IBM Zurich Research Lab, May 1995.
Borden, et al Informational [Page 22]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
14. Goyal, P., Lam, S., and Vin, H., "Determining End-to-End
Bounds in Heterogeneous Networks," 5th International Workshop
Network and Operating System Support for Digital Audio and Video
April, 1995.(Available via URL http://www.cs.utexas.edu/users/dmcl
15. Laubach, M., "Classical IP and ARP over ATM", RFC 1577, HP
January 1994.
16. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.
17. Moy, J., "Multicast Extensions to OSPF," RFC 1584, Proteon,
1994.
18. Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN
September 1992.
19. Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D.
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
ISI, Fore, Motorola Codex, Ascom Timeplex, February 1995.
20. Perkins, D., and Liaw, Fong-Ching, "Beyond Classical IP-
IP and ATM Architecture Overview", ATM Forum/94-0935, Fore Systems
September 1994.
21. Perkins, D. and Liaw, Fong-Ching, "Beyond Classical IP-
IP and ATM Protocol Specifications", ATM Forum/94-0936,
Systems, September 1994.
22. Romanow, A., and S. Floyd, "The Dynamics of TCP Traffic over
Networks", Proceedings of ACM SIGCOMM U94, London, August 1994,
pp.79-88.
23. Shenker, S., and C. Partridge. "Specification of Guaranteed
of Service", Work in Progress, Xerox/BBN, July 1995.
24. Shenker, S., and C. Partridge. "Specification of Predictive
of Service", Work in Progress, Xerox/BBN, March 1995.
25. Shenker, S., C. Partridge and J. Wroclawski. "Specification
Controlled Delay Quality of Service", Work in Progress
Xerox/BBN/MIT, June 1995.
26. Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP
A Transport Protocol for Real-time Applications", Work in Progress
GMD/ISI/Xerox/LBL, March 1995.
27. Topolcic, C., "Experimental Internet Stream Protocol, Version 2
(ST-II)", RFC 1190, BBN, October 1990.
Borden, et al Informational [Page 23]
RFC 1821 Real-time Service in IP-ATM Networks August 1995
28. Wang, Z., and J. Crowcroft, "QoS Routing for Supporting
Reservation", University College of London white paper, 1995.
10. Authors'
Eric S.
Marty
Bay
3 Federal
Billerica, Ma 01821
508-670-8888
esc@baynetworks.
mborden@baynetworks.
Bruce S.
445 South
Morristown, New Jersey 07960-6438
201-829-4838
bsd@bellcore.
Stephen G.
Naval Research
Code 5521
Washington, DC 20375-5337
202-767-3834
sgb@saturn.nrl.navy.
Borden, et al Informational [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
