One document matched: draft-ietf-issll-atm-support-00.txt
Internet Draft S. Berson
Expiration: December 1996 ISI
File: File: draft-ietf-issll-atm-support-00.txt
IP Integrated Services Support in ATM
June 13, 1996
Status of 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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
linebreak "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
Integrated Services in the Internet is rapidly becoming a reality.
Meanwhile, ATM technology is appearing in the marketplace. It is an
important problem to integrate ATM networks into this emerging
Integrated Services Internet. "Classical" IP over ATM[11,8] is now
widely deployed, effectively solving the problem of "best effort
service" in internets with ATM links. A key remaining issue is to
provide the Internet Integrated Services (IIS) model over internets
with ATM links. This draft provides guidelines for using ATM VCs
with QoS as part of an Integrated Services Internet.
[NOTE - The .txt version does not currently have all the figures.]
Berson Expiration: December 1996 [Page 1]
Internet Draft Integrated Services and ATM June 1996
Table of Contents
1. Introduction ........................................................2
2. RSVP ................................................................3
2.1 RSVP messages ...................................................4
2.2 Reservation Styles ..............................................4
2.3 RSVP flows ......................................................5
2.4 RSVP flows and VCs ..............................................6
3. Single VC per RSVP Flow .............................................6
3.1 Dynamic QoS .....................................................7
4. Tear down old VC ............................................8
5. Activate timer ..............................................8
5.1 Mixed data and control traffic ..................................12
5.2 Single RSVP VC per RSVP Flow ....................................12
5.3 Multiplexed point-to-multipoint RSVP VCs ........................12
5.4 Multiplexed point-to-point RSVP VCs .............................13
5.5 QoS for RSVP VCs ................................................14
6. Additional issues ...................................................14
7. Conclusions and Future Work .........................................14
Berson Expiration: December 1996 [Page 2]
Internet Draft Integrated Services and ATM June 1996
1. Introduction
[NOTE: This draft discusses RSVP and ATM specifically, but most of
the issues and approaches are not specific to either RSVP or ATM, but
rather would apply to any setup protocol and any Non-Broadcast
Multiple Access (NBMA) network. In those cases where an issue is
specific to either RSVP or ATM, it will be pointed out in the text.
It is the intention of the author in the future to split this draft
into two documents, one dealing with RSVP-specific issues, and the
other with general integrated services issues.]
The Internet currently has one class of service normally referred to
as "best effort." This service is typified by first-come, first-
serve scheduling at each hop in the network. Best effort service has
worked exceptionally well for electronic mail, World Wide Web (WWW)
access, file transfer (e.g. ftp), etc. For real-time traffic such as
voice and video, the current Internet has performed well only across
unloaded networks. In order to provide guaranteed quality real-time
traffic, new classes of service and new protocols are being
introduced in the Internet[10,4], while retaining the existing best
effort service. Signalling for these new services is done by
RSVP[3,12], the Resource ReSerVation Protocol.
Due to extensive telephone company support, ATM is rapidly becoming
an important link layer technology. As this draft was being written,
the current version of ATM signalling was UNI 3.1[9], and UNI 3.1 is
expected to be predominant in the marketplace in the near term.
However, a new version (UNI 4.0) is expected to be standardized soon,
and this draft will be updated as appropriate.
One of the important features of ATM technology is the ability to
request a point-to-point Virtual Circuit (VC) with a specified
Quality of Service (QoS). An additional feature of ATM technology is
the ability to request point-to-multipoint VCs with a specified QoS.
Point-to-multipoint VCs allows leaf nodes to be joined and removed
from the VC dynamically and so provide a mechanism for supporting IP
multicast. It is only natural that RSVP and the Internet Integrated
Services (IIS) model would like to utilize the QoS properties of any
underlying link layer, and this draft concentrates on ATM.
Classical IP over ATM[11] has solved part of this problem, supporting
IP unicast traffic over ATM. Classical IP over ATM is based on a
Logical IP Subnetwork (LIS), which is a separately administered IP
subnetwork. Hosts within a LIS communicate using the ATM network,
while hosts from different subnets communicate only by going through
an IP router (even though it may be possible to open a direct VC
between the two hosts over the ATM network). Classical IP over ATM
provides an Address Resolution Protocol (ATMARP) for ATM edge devices
Berson Expiration: December 1996 [Page 3]
Internet Draft Integrated Services and ATM June 1996
to resolve IP addresses to native ATM addresses. For any pair of
IP/ATM edge devices (i.e. hosts or routers), a single VC is created
on demand and shared for all traffic between the two devices. A
second part of the RSVP and IIS over ATM problem, IP multicast, is
close to being solved with MARS[1], the Multicast Address Resolution
Server. The MARS server generalizes ATMARP by allowing an IP address
to resolve into a list of native ATM addresses, rather than just a
single address.
There is work in progress on alternative IP over ATM models (e.g.
NHRP[7]) but similar solutions to those described here for the
classical model are still expected to apply. But further study is
needed.
A key remaining issue for IP over ATM is the integration of RSVP
signalling and ATM signalling in support of the Internet Integrated
Services (IIS) model. There are two main areas involved in
supporting the IIS model, QoS translation and VC management. QoS
translation concerns mapping a QoS from the IIS model to a proper ATM
QoS, while VC management concentrates on how many VCs are needed and
which traffic flows are routed over which VCs. This draft
concentrates on VC management, and we assume that the QoS for a
single RSVP flow can be acceptably translated to an ATM QoS. This
assumption is reasonable since the traffic parameters for both IIS
and ATM QoS are very similar.
The remainder of this draft is organized as follows. Section 2
describes how source traffic is mapped to RSVP flows and then to VCs.
Section 3 describes the "single homogeneous VC" model where there is
only one VC per RSVP flow even when there are different receivers
requesting different reservations. In particular, this section
describes how the QoS of the single VC must be dynamically changed
over ATM and how to limit excessive signalling using timers. Section
4 examines the case where a single RSVP flow can be fed into several
VCs. In particular, this section describes the need for multiple VCs
particularly for simultaneously supporting a single QoS service as
well as best effort service. Section 5 describes alternatives for
VCs used for RSVP signalling messages. Section 6 discusses some
additional minor issues. Section 7 concludes the draft and describes
continuing and future work.
2. RSVP
[NOTE - this section is RSVP specific]
RSVP[3,12] provides many important features for signalling in the
Internet including receiver initiated reservations, "soft state" in
routers, heterogeneous reservations within a multicast session,
Berson Expiration: December 1996 [Page 4]
Internet Draft Integrated Services and ATM June 1996
dynamic change of reservations, and multiple reservation styles or
modes of sharing. Of particular interest for RSVP and ATM [Note 1]
are reservation styles, dynamic change of reservations, and
heterogeneous reservations within a multicast session. The remainder
of this section describes these features.
2.1 RSVP messages
In RSVP resources are reserved by use of two types of messages,
PATH and RESV. Each RSVP traffic source sends out PATH messages
along the same route (unicast or multicast) as the data traffic
will travel. PATH messages carry information about the source
traffic parameters such as a mean bit rate, and token bucket size.
Using information from PATH messages and obtained from higher
layer protocols, receivers can then make reservations for specific
resources by sending RESV messages along the reverse path of the
PATH messages. Resources will be allocated on the proper outgoing
link of all nodes along the route from traffic source(s) to the
receiver. This is shown in figure with two sources "S1" and
"S2," and two receivers "R1" and "R2."
[IMAGE]
Figure 1: RSVP message flow
Multiple receivers can send RESV messages toward the same traffic
source(s) as shown in figure . The quantities of resources
requested by these receivers may be different. RSVP handles RESV
messages for different quantities of resources by doing "merging".
A node where multiple different reservation messages arrive (from
different receivers) is called a "merge node". In order that RSVP
scale well with the number of receivers of a session, only one
merged RESV message is forwarded from a merge node towards a
source, and this message carries the maximum of the incoming
resource reservation requests. In figure , router "r1" is a merge
node and would send to traffic sources "S1" and "S2" a reservation
message requesting the maximum of the resources requested by
receivers "R1" and "R2."
2.2 Reservation Styles
RSVP provides several different styles of reservations. The
styles that are part of the current version 1 RSVP specification
_________________________
[Note 1] Though ATM is sender oriented, it is worth noting that receiver
initiated reservations were not an issue at all.
Berson Expiration: December 1996 [Page 5]
Internet Draft Integrated Services and ATM June 1996
are shown in figure , while noting that additional styles may be
defined in the future. The reservation style helps determine how
many RSVP flows are needed for a multicast group and which source
traffic uses which flow. Reservation styles can be "distinct",
where each RSVP flow is used by exactly one sender, or "shared",
where multiple senders use the same RSVP flow. Reservation styles
can also have either "explicit sender selection", where a
reservation is established only for senders explicitly listed in
the reservation message, or can have "wildcard sender selection"
where traffic from any sender is selected. Different reservation
styles are suitable for different types of data traffic.
Typically, shared type styles are best for audio conferencing
since there would typically be only one person speaking at a time
independent of the number of senders. Distinct type styles are
typically used for video where each traffic source is continuously
sending, and so sharing is difficult.
Reservations
Sender Selection | Distinct | Shared
-----------------------------------------------------------------
Explicit | Fixed-Filter (FF) Style | Shared-Explicit (SE) Style
Wildcard | (None defined) | Wildcard-Filter (WF) Style
Figure 2: Reservation Styles
Three reservation styles have currently been defined. Fixed filter
style has explicit sender selection and distinct reservations and
is typically used for video conferencing where each video stream
has its own RSVP flow. Wildcard filter style has wildcard sender
selection and shared style and is typically used for audio
conferencing where people naturally take turns speaking. Shared
explicit style has explicit sender selection and shared
reservations and is similar to wildcard style except it provides
better security by explicitly listing senders. Currently, there is
no style defined with wildcard sender selection and distinct
reservations.
[IMAGE]
Figure 3: IP over ATM network
2.3 RSVP flows
As an example, consider a system with two senders (S1 and S2), two
receivers (R1 and R2), and three routers (r1, r2, and r3) as shown
above in figure . Assuming that the two receivers are requesting
Berson Expiration: December 1996 [Page 6]
Internet Draft Integrated Services and ATM June 1996
the same QoS, then the number of RSVP flows at the ATM edge device
"r1" needed to support different reservation styles for this
configuration can be determined. For a wildcard filter style, only
one (point-to-multipoint) flow is needed as all senders for this
group can use the shared reservation across the ATM network. For
styles with explicit sender selection, assume that both senders
are selected. For fixed filter style, three flows are needed, one
QoS flow for each of the two senders explicitly listed and one
best effort service flow to be shared among any other senders.
For the shared explicit style, two flows are needed, one QoS flow
to be shared among all the (i.e. two) explicitly listed senders,
and one best effort service flow to be shared among the remaining
senders.
More generally, the following numbers of RSVP flows are created
for different filter styles. For a reservation with wildcard
filter (WF) style, there is only one RSVP flow, since all senders
to a (multicast or unicast) session are part of the same
reservation. For shared explicit (SE) style, there are two RSVP
flows, one for the senders explicitly listed who receive reserved
service, and one for any other senders who receive ordinary best
effort service. Finally, the number of RSVP flows created by a
fixed filter (FF) style reservation depends on the number of
senders listed in the reservation message. If there are n senders
listed in the message, then there are n+1 RSVP flows created, one
for each of the n senders, and one additional flow for all senders
that are not listed.
2.4 RSVP flows and VCs
There are different approaches to mapping RSVP flows to ATM VCs.
Two approaches are discussed in this draft, while a third remains
for future work. Section 3 examines the VC per flow model, where
each RSVP flow is mapped to a single ATM VC. This ATM VC can be a
point-to-point or point-to-multipoint as appropriate. Section 4
examines the multiple VCs per RSVP flow model where a single flow
can be forwarded into several VCs each with a different QoS.
Other models allowing aggregation of RSVP flows into VCs (VC for
multiple flows model) are being studied and will be briefly
discussed in section 7.
3. Single VC per RSVP Flow
One approach for mapping RSVP flows into VCs is to have a single
(point-to-point or point-to-multipoint) VC for each RSVP flow. The
potential problem with this scheme is that different receivers might
request different qualities of service. In the "single VC per RSVP
flow" model, this heterogeneity problem is handled by using the
Berson Expiration: December 1996 [Page 7]
Internet Draft Integrated Services and ATM June 1996
maximum of the requested resources of all the receivers of a session.
The remainder of this section discusses the issue of dynamically
changing the QoS of a VC. The following section allows more
heterogeneity in reservations by using additional VCs.
3.1 Dynamic QoS
RSVP provides dynamic quality of service (QoS) in that the
resources that a reservation requests may change at any time.
There are several common reasons for a change of reservation QoS.
First, an existing receiver can request a new larger (or smaller)
QoS if the current received quality is unacceptable. Second, a
sender may change its traffic specification (TSpec), which can
trigger a change in the reservation requests of the receivers.
Third, a new sender can start sending to a multicast group with a
larger traffic specification than existing senders, triggering
larger reservations. Finally, a new receiver can make a
reservation that is larger than existing reservations. If the
merge node for the larger reservation is an ATM edge device, a new
larger reservation must be set up across the ATM network.
Since ATM service, as currently defined, does not allow
renegotiating the QoS of a VC, dynamically changing the
reservation means tearing down an established VC, and creating a
new VC with the new QoS. Tearing down a VC and setting up a new
VC in ATM are complex operations that involve a non-trivial amount
of processor time, and have a substantial latency.
To prevent excessive signalling load on an ATM network, timers can
be used. Each ATM edge device is configured with a time parameter
tau that gives the minimum amount of time the edge device will
wait between successive changes of the QoS of a particular VC.
Thus if the QoS of a VC is changed at time t, all messages that
would change the QoS of that VC that arrive before time t+tau
would be queued. If several messages changing the QoS of a VC
arrive during the interval, redundant messages can be discarded.
At time t+tau, the remaining change(s) of QoS, if any, can be
executed. This timer approach would apply more generally to any
network structure, and might be worthwhile to incorporate into
RSVP.
The sequence of events for a single VC would be
1. Wait if timer is active
2. Establish VC with new QoS
Berson Expiration: December 1996 [Page 8]
Internet Draft Integrated Services and ATM June 1996
3. Remap data traffic to new VC
4. Tear down old VC
5. Activate timer
3.2 Limitations
There are two major problems with the single VC per RSVP flow
approach. The first problem is that a user making a small or no
reservation would get a "free ride" across the ATM network on any
person(s) making a larger reservation. The second problem is that
a user may want to join an existing VC at the established QoS
level, but, because of a lack of resources, not be able to join.
The rejected user would still like to receive the traffic on a
best effort basis, which is the standard method of operation in
the Internet. Preserving the homogeneous single VC per RSVP flow
model in this case would mean tearing down the QoS VC, and
replacing it with a single best effort VC. Clearly it is
unacceptable to tear down one customer's existing QoS reservation
because a second customer was not able to join the existing VC. A
solution to both the "free ride" problem and the best effort
service problem involves having multiple VCs carrying identical
traffic which is the subject of the next section.
4. Multiple VCs per RSVP Flow
The previous "single VC per RSVP flow" model had the advantage that
each byte of data traffic was sent over the ATM network exactly once
and each leaf of the VC received identical service. This homogeneous
model is simple but does not take into account the situation that
different users may demand (and be willing to pay for) different
levels of service than others. This section discusses solutions to
heterogeneous reservation requests from different receivers involving
multiple VCs per RSVP flow. Two different approaches are discussed.
The first approach requires at most two VCs per RSVP flow, one for
best effort traffic, and the other for (homogeneous) QoS traffic.
The other approach has one VC per QoS requested, and so potentially
has an unlimited number of VCs per RSVP flow.
4.1 Two VCs per RSVP flow
RSVP supports heterogeneous QoS, meaning that different receivers
of the same multicast group can request a different QoS. But most
importantly, some receivers might have no reservation at all, but
want to receive the traffic on a best effort service basis. The IP
model allows receivers to join a multicast group at any time on a
best effort basis, and it is important that ATM as part of the
Berson Expiration: December 1996 [Page 9]
Internet Draft Integrated Services and ATM June 1996
Internet continue to provide this service. We define the "limited
heterogeneity" model as the case where the receivers of a
multicast session are limited to use either best effort service or
a single alternate quality of service. The alternate QoS can be
chosen either by higher level protocols or by dynamic
renegotiation of QoS as described in the previous section.
[IMAGE]
Figure 4: Limited heterogeneity
In order to support limited heterogeneity, each ATM edge device
participating in a session would need at most two VCs. One VC
would be a point-to-multipoint best effort service VC and would
serve all best effort service IP destinations for this multicast
group. The other VC would be a point to multipoint VC with QoS and
would serve all IP destinations for this multicast group that have
an RSVP reservation established. This is shown in figure where
there are three receivers, R2 requesting best effort service,
while R1 and R3 request distinct reservations. One point-to-
multipoint VC is set up for best effort traffic which serves R2.
Another VC is set up for the QoS traffic to receivers R1 and R3,
using the maximum of R1 and R3's reservation. Note that though
the VC and hence the QoS for R1 and R3 are the same within the ATM
cloud, the reservation outside the ATM cloud (from router r4 to
receiver R3) uses the QoS actually requested by R3.
The disadvantage of the limited heterogeneity scheme is that each
packet will need to be duplicated at the network layer and one
copy sent into each of the 2 VCs. Looking at figure , there are
two VCs going from router r1 to switch s1. Two copies of every
packet will traverse the r1-s1 link. Depending on the network
topology and group membership, there may be a large amount of
duplicate traffic flowing over the ATM links.
Note that two separate VCs for each session will not normally be
needed. First, if all the receivers are making reservations, no
best effort VC is needed. Second, the best effort traffic for all
sessions with the same ATM destinations can be multiplexed on the
same best effort VC. In the ideal case, there will be only one
best effort VC for all the best effort traffic for all sessions on
a single node. This will limit the number of VCs needed.
4.2 Many VCs per RSVP flow
Instead of arbitrarily restricting an RSVP flow to at most two
VCs, rules can be specified as to when a new QoS VC can be created
Berson Expiration: December 1996 [Page 10]
Internet Draft Integrated Services and ATM June 1996
(e.g. when the user is willing to pay). This gives a lot of
flexibility to a service provider. Full heterogeneity is possible
where a separate VC could be created for each distinct QoS for a
multicast session.
While we advocate the limited heterogeneity approach as in section
4.1, different service providers may choose alternate approaches.
RSVP allows for local policy control [6] as well as admission
control. Thus a user can request a reservation with a specific
QoS and with a policy object that, for example, offers to pay for
additional costs setting up a new VC. The policy module at the
entry to a service provider can decide how to satisfy that request
- either by merging the request in with an existing VC or by
creating a new VC for this (and perhaps other) users. This policy
can be on a user-provider basis where a user and a provider have
an agreement on the type of service offered, or on a provider-
provider basis, where two providers have such an agreement. With
the ability to do local policy control, service providers can
provide services best suited to their own resources and their
customers desires.
[IMAGE]
Figure 5: Limited heterogeneity
This is shown in figure . Whereas, in figure , R1 and R3 shared
the same VC across the ATM network; in figure , R1 and R3 have a
separate VC, so each receives precisely the resources requested.
Note that while full heterogeneity gives users exactly what they
request, it requires more resources of the network than limited
heterogeneity. In figure , three copies of each packet are sent
on the link from r1 to s1. Two copies of each packet are then
sent from s1 to s2. As with limited heterogeneity, the exact
amount of bandwidth dedicated to duplicate traffic depends on the
network topology and group membership.
4.3 Making a reservation
For the limited heterogeneity case, making an RSVP reservation
will mean that a leaf of a point to multipoint VC will need to
leave the best effort service VC and join as a new leaf of the QoS
VC. If no QoS VC exists, a new QoS VC is created with the
receiver as a leaf. If the new QoS leaf cannot be created, an
error message will be sent and the user will continue receiving
best effort service. If there is a QoS VC, but the QoS needs to
be increased for the new reservation, a new VC with the larger QoS
Berson Expiration: December 1996 [Page 11]
Internet Draft Integrated Services and ATM June 1996
will be requested (for all QoS receivers). If the new VC request
fails, the old QoS VC will remain, the new reservation will fail,
and the new user will continue to receive best effort service. An
RSVP reservation teardown will mean leaving the QoS VC and joining
the best effort service VC. If no best effort VC exists, then one
would be created.
For the full heterogeneity model, making an RSVP reservation is
similar to the limited heterogeneity case. The difference is that
a change in reservation may attempt to switch a leaf from one QoS
VC to another QoS VC.
5. RSVP VCs
[NOTE - this section is RSVP specific]
One last important issue is providing a data path for the RSVP
messages themselves. As mentioned in section 2, there are two main
types of messages, PATH and RESV. PATH messages are sent to a
multicast address, while RESV messages are sent to a unicast address.
Other RSVP messages are handled similar to either PATH or RESV. So
ATM VCs used for RSVP signalling messages need to provide both
unicast and multicast functionality.
There are several different approaches for how to assign VCs to use
for RSVP signalling messages. The main approaches are:
o use same VC as data
o single VC per session
o single point-to-multipoint VC multiplexed among sessions
o multiple point-to-point VCs multiplexed among sessions
There are several different issues that affect the choice of how to
assign VCs for RSVP signalling. One issue is the number of
additional VCs needed for RSVP signalling. Related to this issue is
the degree of multiplexing on the RSVP VCs. In general more
multiplexing means less VCs. An additional issue is the latency in
dynamically setting up new RSVP signalling VCs. A final issue is
complexity of implementation. The remainder of this section
discusses the issues and tradeoffs among these different approaches
and suggests guidelines for when to use which alternative.
Berson Expiration: December 1996 [Page 12]
Internet Draft Integrated Services and ATM June 1996
5.1 Mixed data and control traffic
In this scheme RSVP signalling messages are sent on the same VCs
as is the data traffic. The main advantage of this scheme is that
no additional VCs are needed beyond what is needed for the data
traffic. An additional advantage is that there is no ATM
signalling latency for PATH messages (which follow the same
routing as the data messages). However there can be a major
problem when data traffic on a VC is nonconforming. With
nonconforming traffic, RSVP signalling messages may be dropped.
While RSVP is resilient to a moderate level of dropped messages,
excessive drops would lead to repeated tearing down and re-
establishing QoS VCs, a very undesirable behavior for ATM. Due to
these problems, this is not a good choice for providing RSVP
signalling messages, even though the number of VCs needed for this
scheme is minimized.
One variation of this scheme that is hopeful but requires further
study is to have a packet scheduling algorithm (before entering
the ATM network) that gives priority to the RSVP signalling
traffic. In this way, the ATM Cell Loss Priority (CLP) bit could
be used to make sure that RSVP signalling messages only rarely get
dropped.
5.2 Single RSVP VC per RSVP Flow
In this scheme, there is a parallel RSVP signalling VC for each
RSVP flow. This scheme results in twice the minimum number of
VCs, but means that RSVP signalling messages have the advantage of
a separate VC. This separate VC means that RSVP signalling
messages have their own traffic contract and compliant signalling
messages are not subject to dropping due to other noncompliant
traffic (such as can happen with the scheme in section 5.1). The
advantage of this scheme is its simplicity - whenever a data VC is
created, a separate RSVP signalling VC is created. The
disadvantage of the extra VC is that extra ATM signalling needs to
be done.
This scheme requires twice the minimum number of VCs and also
additional latency, but is quite simple. This approach would tend
to work well on hosts.
5.3 Multiplexed point-to-multipoint RSVP VCs
In this scheme, there is a single point-to-multipoint RSVP
signalling VC for each unique ingress router and unique set of
egress routers. This scheme allows multiplexing of RSVP
signalling traffic that shares the same ingress router and the
Berson Expiration: December 1996 [Page 13]
Internet Draft Integrated Services and ATM June 1996
same egress routers. This can save on the number of VCs, by
multiplexing, but there are problems when the destinations of the
multiplexed point-to-multipoint VCs are changing. Several
alternatives exist in these cases, that have applicability in
different situations. First, when the egress routers change, the
ingress router can check if it already has a point-to-multipoint
RSVP signalling VC for the new list of egress routers. If the
RSVP signalling VC already exists, then the RSVP signalling
traffic can be switched to this existing VC. If no such VC
exists, one approach would be to create a new VC with the new list
of egress routers. Other approaches include modifying the
existing VC to add an egress router or using a separate new VC for
the new egress routers. When a destination drops out of a group,
an alternative would be to keep sending to the existing VC even
though some traffic is wasted.
The number of VCs used in this scheme is a function of traffic
patterns across the ATM network, but is always less than the
number used with the Single RSVP VC per data VC. In addition,
existing best effort data VCs could be used for RSVP signalling.
Reusing best effort VCs saves on the number of VCs at the cost of
higher probability of RSVP signalling packet loss. One possible
place where this scheme will work well is in the core of the
network where there is the most opportunity to take advantage of
the savings due to multiplexing.
5.4 Multiplexed point-to-point RSVP VCs
In this scheme, multiple point-to-point RSVP signalling VCs are
used for a single point-to-multipoint data VC. This scheme allows
multiplexing of RSVP signalling traffic but requires the same
traffic to be sent on each of several VCs. This scheme is quite
flexible and allows a large amount of multiplexing. Since point-
to-point VCs can set up a reverse channel at the same time as
setting up the forward channel, this scheme could save
substantially on signalling cost. In addition, signalling traffic
could share existing best effort VCs. Sharing existing VCs
reduces the total number of VCs needed, but might cause signalling
traffic drops if there is congestion in the ATM network.
This pt-pt scheme would work well in the core of the network where
there is much opportunity for multiplexing. Also in the core of
the network, RSVP VCs can stay permanently established either as
Permanent Virtual Circuits (PVCs) or as long lived Switched
Virtual Circuits (SVCs). The number of VCs in this scheme will
depend on traffic patterns, but in the core of a network would be
approximately n(n-1)/2 where n is the number of IP nodes in the
network. In the core of the network, this will typically be small
Berson Expiration: December 1996 [Page 14]
Internet Draft Integrated Services and ATM June 1996
compared to the total number of VCs.
5.5 QoS for RSVP VCs
There is an issue for what QoS, if any, to assign to the RSVP VCs.
Two solutions have been covered in section 5.1 and in the shared
best effort VC variation in section 5.4. For other RSVP VC
schemes, a QoS (possibly best effort) will be needed. What QoS to
use partially depends on the expected level of multiplexing that
is being done on the VCs, and the expected reliability of best
effort VCs. Since RSVP signalling is infrequent (typically every
30 seconds), only a relatively small QoS should be needed. This
is important since using a larger QoS risks the VC setup being
rejected for lack of resources. Falling back to best effort when
a QoS call is rejected is possible, but if the ATM net is
congested, there will likely be problems with with RSVP packet
loss on the best effort VC also. Additional experimentation is
needed in this area.
6. Additional issues
There is an issue with VCs timing out as described in RFC1755,
section 3.4 on VC Teardown. RFC1755 recommends tearing down a VC
that is inactive for a certain length of time - 20 minutes is
recommended. This timeout could mean that a valid VC with QoS that
has been established with RSVP might be torn down unexpectedly.
While this behavior is acceptable for best-effort traffic, it is
important that if a reservation has been established on a VC, that
the VC not be torn down. If there is no choice about the VC being
torn down, the RSVP daemon must be notified, so a reservation failure
message can be sent.
Most of the previous discussion has been concerned with meshes of
point-to-multipoint connections. An alternate approach is to use a
MultiCast Server[1] (MCS). An MCS provides a relay node that
forwards the multicast (e.g. PATH) messages. It is expected that all
the previous discussion applies for an MCS as well as meshes, but
further experimentation is needed.
7. Conclusions and Future Work
We have described a scheme for deploying "classical" RSVP over IP
over ATM. We have a prototype system using the limited heterogeneity
model running at ISI and we are experimenting with it now. There are
a number of other issues that are subjects of continuing research.
These issues (and others) are covered in [2], and are briefly
repeated here.
Berson Expiration: December 1996 [Page 15]
Internet Draft Integrated Services and ATM June 1996
One key issue is how to translate an Internet Integrated Services
(IIS) QoS to an ATM QoS. Fortunately, this issue seems to be getting
easier as the IETF and ATM Forum QoS definitions are getting more
similar as they evolve. However there are still potential
differences in traffic shaping and policing models. Additional
coordination between the IETF and the ATM Forum in testing and
standardizing a QoS translation is desirable now.
A second issue is to consider the multiple RSVP flows per VC (or
aggregation) model. With this model, large VCs could be set up
between IP routers in an ATM network. These VCs could be managed the
same as how IIS point-to-point links (e.g. T-1, DS-3) are managed
now. Traffic from multiple sources over multiple multicast groups
might be multiplexed on the same VC. This approach has a number of
advantages. First, there is typically no signalling latency as VCs
would be in existence when the traffic started flowing, so no time is
wasted in setting up VCs. Second, the heterogeneity problem in full
over ATM has been reduced to a solved problem. Finally, the dynamic
QoS problem for ATM has also been reduced to a solved problem. The
problem with this approach is that the choice of what QoS to use for
which of the large VCs is difficult. If chosen poorly, there might be
many VC setups failing while other bandwidth is unused. An additional
problem is that the ability of ATM to do QoS dependent routing is
wasted.
ATM is currently close to a new standard (UNI 4.0) that promises
certain advantages over the current UNI 3.1 version. Current work in
the ATM Forum and ITU promises additional advantages. A final issue
is to keep current with changes in ATM, and to keep this document
up-to-date. Some specific issues are covered in [2,5].
REFERENCES
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks," Internet Draft.
[2] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S.,
"Issues for RSVP and Integrated Services over ATM," Internet Draft.
[3] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification," Internet Draft.
[4] Clark, D., Shenker, S., and Zhang, L., "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture
and Mechanisms," SIGCOMM '92.
[5] Demirtjis, A., Berson, S., Edwards, B., Maher, M., Braden, B., and
Berson Expiration: December 1996 [Page 16]
Internet Draft Integrated Services and ATM June 1996
Mankin, A., "RSVP and ATM Signalling," ATM Forum Contribution 96-
0258.
[6] Herzog, S., "Building Blocks for Accounting and Access Control in
RSVP," Internet Draft.
[7] Katz, D., Piscitello, D., Cole, B., Luciani, J., "NBMA Next Hop
Resolution Protocol (NHRP)," Internet Draft.
[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.
[9] "ATM User-Network Interface (UNI) Specification - Version 3.1",
Prentice Hall.
[10] Braden, R., Clark, D., Shenker, S. "Integrated Services in the
Internet Architecture: an Overview," RFC 1633, June 1994.
[11] Laubach, M., "Classical IP and ARP over ATM," RFC1577, January
1994.
[12] Zhang, L., Deering, S., Estrin, D., Shenker, S., Zappala, D.,
"RSVP: A New Resource ReSerVation Protocol," IEEE Network, September
1993.
Security Considerations
Security considerations have not been addressed in this draft.
Author's Address
Steven Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: berson@isi.edu
Berson Expiration: December 1996 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 15:17:20 |