As per Relevance of the word reservation, we have this rfc below:
Network Working Group E. Crawley,
Request for Comments: 2382 Argon
Category: Informational L.
Fore
S.
F.
Cisco
M.
Bay
J.
ArrowPoint
August 1998
A Framework for Integrated Services and RSVP over
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document outlines the issues and framework related to
IP Integrated Services with RSVP over ATM. It provides an
approach to the problem(s) and related issues. These issues
problems are to be addressed in further documents from the
subgroup of the ISSLL working group
1.
The Internet currently has one class of service normally referred
as "best effort." This service is typified by first-come, first
serve scheduling at each hop in the network. Best effort service
worked well for electronic mail, World Wide Web (WWW) access,
transfer (e.g. ftp), etc. For real-time traffic such as voice
video, the current Internet has performed well only across
portions of the network. In order to provide quality real-
traffic, new classes of service and a QoS signalling protocol
Crawley, et. al. Informational [Page 1]
RFC 2382 Integrated Services and RSVP over ATM August 1998
being introduced in the Internet [1,6,7], while retaining
existing best effort service. The QoS signalling protocol is
[1], the Resource ReSerVation Protocol and the service
One of the important features of ATM technology is the ability
request a point-to-point Virtual Circuit (VC) with a
Quality of Service (QoS). An additional feature of ATM technology
the ability to request point-to-multipoint VCs with a specified QoS
Point-to-multipoint VCs allows leaf nodes to be added and
from the VC dynamically and so provides a mechanism for supporting
multicast. It is only natural that RSVP and the Internet
Services (IIS) model would like to utilize the QoS properties of
underlying link layer including ATM, and this memo concentrates
ATM
Classical IP over ATM [10] has solved part of this problem
supporting IP unicast best effort traffic over ATM. Classical
over ATM is based on a Logical IP Subnetwork (LIS), which is
separately administered IP subnetwork. Hosts within an
communicate using the ATM network, while hosts from different
communicate only by going through an IP router (even though it may
possible to open a direct VC between the two hosts over the
network). Classical IP over ATM provides an Address
Protocol (ATMARP) for ATM edge devices to resolve IP addresses
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
all traffic between the two devices. A second part of the RSVP
IIS over ATM problem, IP multicast, is being solved with MARS [5],
the Multicast Address Resolution Server
MARS compliments ATMARP by allowing an IP address to resolve into
list of native ATM addresses, rather than just a single address
The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol
ATM (MPOA) [18] also address the support of IP best effort
over ATM through similar means
A key remaining issue for IP in an ATM environment is the
of RSVP signalling and ATM signalling in support of the
Integrated Services (IIS) model. There are two main areas
in supporting the IIS model, QoS translation and VC management.
translation concerns mapping a QoS from the IIS model to a proper
QoS, while VC management concentrates on how many VCs are needed
which traffic flows are routed over which VCs
Crawley, et. al. Informational [Page 2]
RFC 2382 Integrated Services and RSVP over ATM August 1998
1.1 Structure and Related
This document provides a guide to the issues for IIS over ATM. It
intended to frame the problems that are to be addressed in
documents. In this document, the modes and models for RSVP
over ATM will be discussed followed by a discussion of management
ATM VCs for RSVP data and control. Lastly, the topic
encapsulations will be discussed in relation to the models presented
This document is part of a group of documents from the ISATM
of the ISSLL working group related to the operation of IntServ
RSVP over ATM. [14] discusses the mapping of the IntServ models
Controlled Load and Guaranteed Service to ATM. [15 and 16]
detailed implementation requirements and guidelines for RSVP
ATM, respectively. While these documents may not address all
issues raised in this document, they should provide
information for development of solutions for IntServ and RSVP
ATM
1.2
Several term used in this document are used in many contexts,
with different meaning. These terms are used in this document
the following meaning
- Sender is used in this document to mean the ingress point to
ATM network or "cloud".
- Receiver is used in this document to refer to the egress point
the ATM network or "cloud".
- Reservation is used in this document to refer to an RSVP
request for resources. RSVP initiates requests for resources
on RESV message processing. RESV messages that simply refresh
do not trigger resource requests. Resource requests may be
based on RSVP sessions and RSVP reservation styles. RSVP
dictate whether the reserved resources are used by one sender
shared by multiple senders. See [1] for details of each. Each
request is referred to in this document as an RSVP reservation,
simply reservation
- Flow is used to refer to the data traffic associated with
particular reservation. The specific meaning of flow is RSVP
dependent. For shared style reservations, there is one flow
session. For distinct style reservations, there is one flow
sender (per session).
2. Issues Regarding the Operation of RSVP and IntServ over
The issues related to RSVP and IntServ over ATM fall into
general classes
Crawley, et. al. Informational [Page 3]
RFC 2382 Integrated Services and RSVP over ATM August 1998
- How to make RSVP run over ATM now and in the
- When to set up a virtual circuit (VC) for a specific Quality
Service (QoS) related to
- How to map the IntServ models to ATM QoS
- How to know that an ATM network is providing the QoS necessary
a
- How to handle the many-to-many connectionless features of
multicast and RSVP in the one-to-many connection-oriented world
2.1 Modes/Models for RSVP and IntServ over
[3] Discusses several different models for running IP over
networks. [17, 18, and 20] also provide models for IP in
environments. Any one of these models would work as long as the
control packets (IP protocol 46) and data packets can follow the
IP path through the network. It is important that the RSVP
messages follow the same IP path as the data such that
PATH state may be installed in the routers along the path. For
ATM subnetwork, this means the ingress and egress points must be
same in both directions for the RSVP control and data messages.
that the RSVP protocol does not require symmetric routing. The
state installed by RSVP allows the RESV messages to "retrace"
hops that the PATH message crossed. Within each of the models for
over ATM, there are decisions about using different types of
distribution in ATM as well as different connection initiation.
following sections look at some of the different ways QoS
can be set up for RSVP
2.1.1 UNI 3.x and 4.0
In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9]
and 4.0 specification, both permanent and switched virtual
(PVC and SVC) may be established with a specified service
(CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0)
specific traffic descriptors in point-to-point and point-to
multipoint configurations. Additional QoS parameters are
available in UNI 3.x and those that are available are vendor
specific. Consequently, the level of QoS control available
standard UNI 3.x networks is somewhat limited. However, using
building blocks, it is possible to use RSVP and the IntServ models
ATM 4.0 with the Traffic Management (TM) 4.0 specification [21]
allows much greater control of QoS. [14] provides the details
mapping the IntServ models to UNI 3.x and 4.0 service categories
traffic parameters
Crawley, et. al. Informational [Page 4]
RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.1.1 Permanent Virtual Circuits (PVCs
PVCs emulate dedicated point-to-point lines in a network, so
operation of RSVP can be identical to the operation over any point
to-point network. The QoS of the PVC must be consistent
equivalent to the type of traffic and service model used.
devices on either end of the PVC have to provide traffic
services in order to multiplex multiple flows over the same PVC
With PVCs, there is no issue of when or how long it takes to set
VCs, since they are made in advance but the resources of the PVC
limited to what has been pre-allocated. PVCs that are not
utilized can tie up ATM network resources that could be used
SVCs
An additional issue for using PVCs is one of network engineering
Frequently, multiple PVCs are set up such that if all the PVCs
running at full capacity, the link would be over-subscribed.
frequently used "statistical multiplexing gain" makes providing
over PVCs very difficult and unreliable. Any application of IIS
PVCs has to be assured that the PVCs are able to receive all
requested QoS
2.1.1.2 Switched Virtual Circuits (SVCs
SVCs allow paths in the ATM network to be set up "on demand".
allows flexibility in the use of RSVP over ATM along with
complexity. Parallel VCs can be set up to allow best-effort
better service class paths through the network, as shown in Figure 1.
The cost and time to set up SVCs can impact their use. For example
it may be better to initially route QoS traffic over existing
until a SVC with the desired QoS can be set up for the flow.
issues can come into play if a single RSVP flow is used per VC,
will be discussed in Section 4.3.1.1. The number of VCs in any
device may also be limited so the number of RSVP flows that can
supported by a device can be strictly limited to the number of
available, if we assume one flow per VC. Section 4 discusses
topic of VC management for RSVP in greater detail
Crawley, et. al. Informational [Page 5]
RFC 2382 Integrated Services and RSVP over ATM August 1998
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS
/\
||
VC ||
Figure 1: Data Flow VC
While RSVP is receiver oriented, ATM is sender oriented. This
seem like a problem but the sender or ingress point receives
RESV messages and can determine whether a new VC has to be set up
the destination or egress point
2.1.1.3 Point to
In order to provide QoS for IP multicast, an important feature
RSVP, data flows must be distributed to multiple destinations from
given source. Point-to-multipoint VCs provide such a mechanism.
is important to map the actions of IP multicasting and RSVP (e.g
IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop
functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x
UNI 4.0 have a single service class for all destinations. This
contrary to the RSVP "heterogeneous receiver" concept. It
possible to set up a different VC to each receiver requesting
different QoS, as shown in Figure 2. This again can run into
and resource problems when managing multiple VCs on the
interface to different destinations
Crawley, et. al. Informational [Page 6]
RFC 2382 Integrated Services and RSVP over ATM August 1998
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
IP
Figure 2: Types of Multicast
RSVP sends messages both up and down the multicast distribution tree
In the case of a large ATM cloud, this could result in a RSVP
implosion at an ATM ingress point with many receivers
ATM 4.0 expands on the point-to-multipoint VCs by adding a
Initiated Join (LIJ) capability. LIJ allows an ATM end point to
into an existing point-to-multipoint VC without
contacting the source of the VC. This can reduce the burden on
ATM source point for setting up new branches and more closely
the receiver-based model of RSVP and IP multicast. However, many
the same scaling issues exist and the new branches added to a point
to-multipoint VC must use the same QoS as existing branches
2.1.1.4 Multicast
IP-over-ATM has the concept of a multicast server or reflector
can accept cells from multiple senders and send them via a point-to
multipoint VC to a set of receivers. This moves the VC
issues noted previously for point-to-multipoint VCs to the
server. Additionally, the multicast server will need to know how
interpret RSVP packets or receive instruction from another node so
will be able to provide VCs of the appropriate QoS for the
flows
Crawley, et. al. Informational [Page 7]
RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.2 Hop-by-Hop vs. Short
If the ATM "cloud" is made up a number of logical IP subnets (LISs),
then it is possible to use "short cuts" from a node on one
directly to a node on another LIS, avoiding router hops between
LISs. NHRP [4], is one mechanism for determining the ATM address
the egress point on the ATM network given a destination IP address
It is a topic for further study to determine if significant
is achieved from short cut routes vs. the extra state required
2.1.3 Future
ATM is constantly evolving. If we assume that RSVP and
applications are going to be wide-spread, it makes sense to
changes to ATM that would improve the operation of RSVP and
over ATM. Similarly, the RSVP protocol and IntServ models
continue to evolve and changes that affect them should also
considered. The following are a few ideas that have been
that would make the integration of the IntServ models and RSVP
or more complete. They are presented here to encourage
development and discussion of ideas that can help aid in
integration of RSVP, IntServ, and ATM
2.1.3.1 Heterogeneous Point-to-
The IntServ models and RSVP support the idea of "
receivers"; e.g., not all receivers of a particular multicast
are required to ask for the same QoS from the network, as shown
Figure 2.
The most important scenario that can utilize this feature occurs
some receivers in an RSVP session ask for a specific QoS while
receive the flow with a best-effort service. In some cases
there are multiple senders on a shared-reservation flow (e.g.,
audio conference), an individual receiver only needs to
enough resources to receive one sender at a time. However,
receivers may elect to reserve more resources, perhaps to allow
some amount of "over-speaking" or in order to record the
(post processing during playback can separate the senders by
source addresses).
In order to prevent denial-of-service attacks via reservations,
service models do not allow the service elements to simply drop non
conforming packets. For example, Controlled Load service model [7]
assigns non-conformant packets to best-effort status (which
result in packet drops if there is congestion).
Crawley, et. al. Informational [Page 8]
RFC 2382 Integrated Services and RSVP over ATM August 1998
Emulating these behaviors over an ATM network is problematic
needs to be studied. If a single maximum QoS is used over a point
to-multipoint VC, resources could be wasted if cells are sent
certain links where the reassembled packets will eventually
dropped. In addition, the "maximum QoS" may actually cause
degradation in service to the best-effort branches
The term "variegated VC" has been coined to describe a point-to
multipoint VC that allows a different QoS on each branch.
approach seems to match the spirit of the Integrated Service and
models, but some thought has to be put into the cell drop
when traversing from a "bigger" branch to a "smaller" one.
"best-effort for non-conforming packets" behavior must also
retained. Early Packet Discard (EPD) schemes must be used so
all the cells for a given packet can be discarded at the same
rather than discarding only a few cells from several packets
all the packets useless to the receivers
2.1.3.2 Lightweight
Q.2931 signalling is very complete and carries with it a
burden for signalling in all possible public and private connections
It might be worth investigating a lighter weight signalling
for faster connection setup in private networks
2.1.3.3 QoS
Another change that would help RSVP over ATM is the ability
request a different QoS for an active VC. This would eliminate
need to setup and tear down VCs as the QoS changed. RSVP
receivers to change their reservations and senders to change
traffic descriptors dynamically. This, along with the merging
reservations, can create a situation where the QoS needs of a VC
change. Allowing changes to the QoS of an existing VC would
these features to work without creating a new VC. In the ITU-T
specifications [24,25], some cell rates can be renegotiated
changed. Specifically, the Peak Cell Rate (PCR) of an existing
can be changed and, in some cases, QoS parameters may be
during the call setup phase. It is unclear if this is sufficient
the QoS renegotiation needs of the IntServ models
2.1.3.4 Group
The model of one-to-many communications provided by point-to
multipoint VCs does not really match the many-to-many
provided by IP multicasting. A scaleable mapping from IP
addresses to an ATM "group address" can address this problem
Crawley, et. al. Informational [Page 9]
RFC 2382 Integrated Services and RSVP over ATM August 1998
2.1.3.5 Label
The MultiProtocol Label Switching (MPLS) working group is
methods for optimizing the use of ATM and other switched networks
IP by encapsulating the data with a header that is used by
interior switches to achieve faster forwarding lookups. [22]
discusses a framework for this work. It is unclear how this
will affect IntServ and RSVP over label switched networks but
may be some interactions
2.1.4 QoS
RSVP is explicitly not a routing protocol. However, since it
QoS information, it may prove to be a valuable input to a
protocol that can make path determinations based on QoS and
load information. In other words, instead of asking for just the
next hop for a given destination address, it might be worthwhile
RSVP to provide information on the QoS needs of the flow if
has the ability to use this information in order to determine
route. Other forms of QoS routing have existed in the past such
using the IP TOS and Precedence bits to select a path through
network. Some have discussed using these same bits to select one
a set of parallel ATM VCs as a form of QoS routing. ATM routing
also considered the problem of QoS routing through the
Network-to-Network Interface (PNNI) [26] routing protocol for
ATM VCs on a path that can support their needs. The work in
area is just starting and there are numerous issues to consider
[23], as part of the work of the QoSR working group frame the
for QoS Routing in the Internet
2.2 Reliance on Unicast and Multicast
RSVP was designed to support both unicast and IP
applications. This means that RSVP needs to work closely
multicast and unicast routing. Unicast routing over ATM has
addressed [10] and [11]. MARS [5] provides multicast
resolution for IP over ATM networks, an important part of
solution for multicast but still relies on multicast
protocols to connect multicast senders and receivers on
subnets
2.3 Aggregation of
Some of the scaling issues noted in previous sections can
addressed by aggregating several RSVP flows over a single VC if
destinations of the VC match for all the flows being aggregated
However, this causes considerable complexity in the management of
and in the scheduling of packets within each VC at the root point
Crawley, et. al. Informational [Page 10]
RFC 2382 Integrated Services and RSVP over ATM August 1998
the VC. Note that the rescheduling of flows within a VC is
possible in the switches in the core of the ATM network.
Paths (VPs) can be used for aggregating multiple VCs. This topic
discussed in greater detail as it applies to multicast
distribution in section 4.2.3.4
2.4 Mapping QoS
The mapping of QoS parameters from the IntServ models to the
service classes is an important issue in making RSVP and IntServ
over ATM. [14] addresses these issues very completely for
Controlled Load and Guaranteed Service models. An additional
is that while some guidelines can be developed for mapping
parameters of a given service model to the traffic descriptors of
ATM traffic class, implementation variables, policy, and cost
can make strict mapping problematic. So, a set of workable
that can be applied to different network requirements and
is needed as long as the mappings can satisfy the needs of
service model(s).
2.5 Directly Connected ATM
It is obvious that the needs of hosts that are directly connected
ATM networks must be considered for RSVP and IntServ over ATM
Functionality for RSVP over ATM must not assume that an ATM host
all the functionality of a router, but such things as MARS and
clients would be worthwhile features. A host must manage VCs
like any other ATM sender or receiver as described later in
4.
2.6 Accounting and Policy
Since RSVP and IntServ create classes of preferential service,
form of administrative control and/or cost allocation is needed
control access. There are certain types of policies specific to
and IP over ATM that need to be studied to determine how
interoperate with the IP and IntServ policies being developed
Typical IP policies would be that only certain users are allowed
make reservations. This policy would translate well to IP over
due to the similarity to the mechanisms used for Call
Control (CAC).
There may be a need for policies specific to IP over ATM.
example, since signalling costs in ATM are high relative to IP, an
over ATM specific policy might restrict the ability to change
prevailing QoS in a VC. If VCs are relatively scarce, there
might be specific accounting costs in creating a new VC. The work
far has been preliminary, and much work remains to be done.
Crawley, et. al. Informational [Page 11]
RFC 2382 Integrated Services and RSVP over ATM August 1998
policy mechanisms outlined in [12] and [13] provide the
mechanisms for implementing policies for RSVP and IntServ over
media, not just ATM
3. Framework for IntServ and RSVP over
Now that we have defined some of the issues for IntServ and RSVP
ATM, we can formulate a framework for solutions. The problem
down to two very distinct areas; the mapping of IntServ models to
service categories and QoS parameters and the operation of RSVP
ATM
Mapping IntServ models to ATM service categories and QoS
is a matter of determining which categories can support the goals
the service models and matching up the parameters and
between the IntServ description and the ATM description(s).
ATM has such a wide variety of service categories and parameters
more than one ATM service category should be able to support each
the two IntServ models. This will provide a good bit of
in configuration and deployment. [14] examines this
completely
The operation of RSVP over ATM requires careful management of VCs
order to match the dynamics of the RSVP protocol. VCs need to
managed for both the RSVP QoS data and the RSVP signalling messages
The remainder of this document will discuss several approaches
managing VCs for RSVP and [15] and [16] discuss their application
implementations in term of interoperability requirement
implementation guidelines
4. RSVP VC
This section provides more detail on the issues related to
management of SVCs for RSVP and IntServ
4.1 VC
As discussed in section 2.1.1.2, there is an apparent
between RSVP and ATM. Specifically, RSVP control is receiver
and ATM control is sender oriented. This initially may seem like
major issue, but really is not. While RSVP reservation (RESV
requests are generated at the receiver, actual allocation
resources takes place at the subnet sender. For data flows,
means that subnet senders will establish all QoS VCs and the
receiver must be able to accept incoming QoS VCs, as illustrated
Figure 1. These restrictions are consistent with RSVP version 1
processing rules and allow senders to use different flow to
mappings and even different QoS renegotiation techniques
Crawley, et. al. Informational [Page 12]
RFC 2382 Integrated Services and RSVP over ATM August 1998
interoperability problems
The use of the reverse path provided by point-to-point VCs
receivers is for further study. There are two related issues.
first is that use of the reverse path requires the VC initiator
set appropriate reverse path QoS parameters. The second issue is
reverse paths are not available with point-to-multipoint VCs,
reverse paths could only be used to support unicast
reservations
4.2 Data VC
Any RSVP over ATM implementation must map RSVP and RSVP
data flows to ATM Virtual Circuits (VCs). LAN Emulation [17],
Classical IP [10] and, more recently, NHRP [4] discuss mapping
traffic onto ATM SVCs, but they only cover a single QoS class, i.e.,
best effort traffic. When QoS is introduced, VC mapping must
revisited. For RSVP controlled QoS flows, one issue is VCs to use
QoS data flows
In the Classic IP over ATM and current NHRP models, a single point
to-point VC is used for all traffic between two ATM attached
(routers and end-stations). It is likely that such a single VC
not be adequate or optimal when supporting data flows with
.bp QoS types. RSVP's basic purpose is to install support for
with multiple QoS types, so it is essential for any RSVP over
solution to address VC usage for QoS data flows, as shown in
1.
RSVP reservation styles must also be taken into account in any
usage strategy
This section describes issues and methods for management of
associated with QoS data flows. When establishing and
VCs, the subnet sender will need to deal with several
factors including multiple QoS reservations, requests for
changes, ATM short-cuts, and several multicast specific issues.
multicast specific issues result from the nature of ATM connections
The key multicast related issues are heterogeneity,
distribution, receiver transitions, and end-point identification
4.2.1 Reservation to VC
There are various approaches available for mapping reservations on
VCs. A distinguishing attribute of all approaches is
reservations are combined on to individual VCs. When
reservations on to VCs, individual VCs can be used to support
single reservation, or reservation can be combined with others on
Crawley, et. al. Informational [Page 13]
RFC 2382 Integrated Services and RSVP over ATM August 1998
"aggregate" VCs. In the first case, each reservation will
supported by one or more VCs. Multicast reservation requests
translate into the setup of multiple VCs as is described in
detail in section 4.2.2. Unicast reservation requests will
translate into the setup of a single QoS VC. In both cases, each
will only carry data associated with a single reservation.
greatest benefit if this approach is ease of implementation, but
comes at the cost of increased (VC) setup time and the consumption
greater number of VC and associated resources
When multiple reservations are combined onto a single VC, it
referred to as the "aggregation" model. With this model, large
could be set up between IP routers and hosts in an ATM network.
VCs could be managed much like IP Integrated Service (IIS) point-to
point links (e.g. T-1, DS-3) are managed now. Traffic from
sources over multiple RSVP sessions might be multiplexed on the
VC. This approach has a number of advantages. First, there
typically no signalling latency as VCs would be in existence when
traffic started flowing, so no time is wasted in setting up VCs
Second, the heterogeneity problem (section 4.2.2) in full over
has been reduced to a solved problem. Finally, the dynamic
problem (section 4.2.7) for ATM has also been reduced to a
problem
The aggregation model can be used with point-to-point and point-to
multipoint VCs. The problem with the aggregation model is that
choice of what QoS to use for the VCs may be difficult,
knowledge of the likely reservation types and sizes but is
easier since the VCs can be changed as needed
4.2.2 Unicast Data VC
Unicast data VC management is much simpler than multicast data
management but there are still some similar issues. If one
unicast to be a devolved case of multicast, then implementing
multicast solutions will cover unicast. However, some may want
consider unicast-only implementations. In these situations,
choice of using a single flow per VC or aggregation of flows onto
single VC remains but the problem of heterogeneity discussed in
following section is removed
4.2.3 Multicast
As mentioned in section 2.1.3.1 and shown in figure 2,
heterogeneity occurs when receivers request different qualities
service within a single session. This means that the amount
requested resources differs on a per next hop basis. A related
of heterogeneity occurs due to best-effort receivers. In any
Crawley, et. al. Informational [Page 14]
RFC 2382 Integrated Services and RSVP over ATM August 1998
multicast group, it is possible that some receivers will request
(via RSVP) and some receivers will not. In shared media networks
like Ethernet, receivers that have not requested resources
typically be given identical service to those that have
complications. This is not the case with ATM. In ATM networks,
additional end-points of a VC must be explicitly added. There may
costs associated with adding the best-effort receiver, and
might not be adequate resources. An RSVP over ATM solution will
to support heterogeneous receivers even though ATM does not
provide such support directly
RSVP heterogeneity is supported over ATM in the way RSVP
are mapped into ATM VCs. There are four alternative approaches
mapping. There are multiple models for supporting RSVP
over ATM. Section 4.2.3.1 examines the multiple VCs per
reservation (or full heterogeneity) model where a single
can be forwarded onto several VCs each with a different QoS.
4.2.3.2 presents a limited heterogeneity model where exactly one
VC is used along with a best effort VC. Section 4.2.3.3 examines
VC per RSVP reservation (or homogeneous) model, where each
reservation is mapped to a single ATM VC. Section 4.2.3.4
the aggregation model allowing aggregation of multiple
reservations into a single VC
4.2.3.1 Full Heterogeneity
RSVP supports heterogeneous QoS, meaning that different receivers
the same multicast group can request a different QoS.
importantly, some receivers might have no reservation at all and
to receive the traffic on a best effort service basis. The IP
allows receivers to join a multicast group at any time on a
effort basis, and it is important that ATM as part of the
continue to provide this service. We define the "full heterogeneity
model as providing a separate VC for each distinct QoS for
multicast session including best effort and one or more qualities
service
Note that while full heterogeneity gives users exactly what
request, it requires more resources of the network than
possible approaches. The exact amount of bandwidth used for
traffic depends on the network topology and group membership
4.2.3.2 Limited Heterogeneity
We define the "limited heterogeneity" model as the case where
receivers of a multicast session are limited to use either
effort service or a single alternate quality of service.
alternate QoS can be chosen either by higher level protocols or
Crawley, et. al. Informational [Page 15]
RFC 2382 Integrated Services and RSVP over ATM August 1998
dynamic renegotiation of QoS as described below
In order to support limited heterogeneity, each ATM edge
participating in a session would need at most two VCs. One VC
be a point-to-multipoint best effort service VC and would serve
best effort service IP destinations for this RSVP session
The other VC would be a point to multipoint VC with QoS and
serve all IP destinations for this RSVP session that have an
reservation established
As with full heterogeneity, a disadvantage of the
heterogeneity scheme is that each packet will need to be
at the network layer and one copy sent into each of the 2 VCs
Again, the exact amount of excess traffic will depend on the
topology and group membership. If any of the existing QoS VC end
points cannot upgrade to the new QoS, then the new reservation
though the resources exist for the new receiver
4.2.3.3 Homogeneous and Modified Homogeneous
We define the "homogeneous" model as the case where all receivers
a multicast session use a single quality of service VC. Best-
receivers also use the single RSVP triggered QoS VC. The single
can be a point-to-point or point-to-multipoint as appropriate.
QoS VC is sized to provide the maximum resources requested by
RSVP next- hops
This model matches the way the current RSVP specification
heterogeneous requests. The current processing rules and
control interface describe a model where the largest
reservation for a specific outgoing interface is used in
allocation, and traffic is transmitted at the higher rate to
next-hops. This approach would be the simplest method for RSVP
ATM implementations
While this approach is simple to implement, providing better
best-effort service may actually be the opposite of what the
desires. There may be charges incurred or resources that
wrongfully allocated. There are two specific problems. The
problem is that a user making a small or no reservation would share
QoS VC resources without making (and perhaps paying for) an
reservation. The second problem is that a receiver may not
any data. This may occur when there is insufficient resources to
a receiver. The rejected user would not be added to the single
and it would not even receive traffic on a best effort basis
Crawley, et. al. Informational [Page 16]
RFC 2382 Integrated Services and RSVP over ATM August 1998
Not sending data traffic to best-effort receivers because of
receiver's RSVP request is clearly unacceptable. The
described limited heterogeneous model ensures that data is
sent to both QoS and best-effort receivers, but it does so
requiring replication of data at the sender in all cases. It
possible to extend the homogeneous model to both ensure that data
always sent to best-effort receivers and also to avoid replication
the normal case. This extension is to add special handling for
case where a best- effort receiver cannot be added to the QoS VC.
this case, a best effort VC can be established to any receivers
could not be added to the QoS VC. Only in this special error
would senders be required to replicate data. We define this
as the "modified homogeneous" model
4.2.3.4
The last scheme is the multiple RSVP reservations per VC (
aggregation) model. With this model, large VCs could be set
between IP routers and hosts in an ATM network. These VCs could
managed much like IP Integrated Service (IIS) point-to-point
(e.g. T-1, DS-3) are managed now. Traffic from multiple sources
multiple RSVP sessions might be multiplexed on the same VC.
approach has a number of advantages. First, there is typically
signalling latency as VCs would be in existence when the
started flowing, so no time is wasted in setting up VCs. Second
the heterogeneity problem in full over ATM has been reduced to
solved problem. Finally, the dynamic QoS problem for ATM has
been reduced to a solved problem. This approach can be used
point-to-point and point-to-multipoint VCs. The problem with
aggregation approach is that the choice of what QoS to use for
of the VCs is difficult, but is made easier if the VCs can be
as needed
4.2.4 Multicast End-Point
Implementations must be able to identify ATM end-points
in an IP multicast group. The ATM end-points will be IP
receivers and/or next-hops. Both QoS and best-effort end-points
be identified. RSVP next-hop information will provide QoS end
points, but not best-effort end-points. Another issue is
end-points of multicast traffic handled by non-RSVP capable next
hops. In this case a PATH message travels through a non-RSVP
router on the way to the next hop RSVP node. When the next hop
node sends a RESV message it may arrive at the source over
different route than what the data is using. The source will get
RESV message, but will not know which egress router needs the QoS
For unicast sessions, there is no problem since the ATM end-
will be the IP next-hop router. Unfortunately, multicast routing
Crawley, et. al. Informational [Page 17]
RFC 2382 Integrated Services and RSVP over ATM August 1998
not be able to uniquely identify the IP next-hop router. So it
possible that a multicast end-point can not be identified
In the most common case, MARS will be used to identify all end-
of a multicast group. In the router to router case, a
routing protocol may provide all next-hops for a particular
group. In either case, RSVP over ATM implementations must obtain
full list of end-points, both QoS and non-QoS, using the
mechanisms. The full list can be compared against the
identified end-points to determine the list of best-effort receivers
There is no straightforward solution to uniquely identifying end
points of multicast traffic handled by non-RSVP next hops.
preferred solution is to use multicast routing protocols that
unique end-point identification. In cases where such
protocols are unavailable, all IP routers that will be used
support RSVP over ATM should support RSVP. To ensure
behavior, implementations should, by default, only establish RSVP
initiated VCs to RSVP capable end-points
4.2.5 Multicast Data
Two models are planned for IP multicast data distribution over ATM
In one model, senders establish point-to-multipoint VCs to all
attached destinations, and data is then sent over these VCs.
model is often called "multicast mesh" or "VC mesh"
distribution. In the second model, senders send data over point-to
point VCs to a central point and the central point relays the
onto point-to-multipoint VCs that have been established to
receivers of the IP multicast group. This model is often referred
as "multicast server" mode distribution. RSVP over ATM solutions
ensure that IP multicast data is distributed with appropriate QoS
In the Classical IP context, multicast server support is provided
MARS [5]. MARS does not currently provide a way to communicate
requirements to a MARS multicast server. Therefore, RSVP over
implementations must, by default, support "mesh-mode"
for RSVP controlled multicast flows. When using multicast
that do not support QoS requests, a sender must set the service,
global, break bit(s).
4.2.6 Receiver
When setting up a point-to-multipoint VCs for multicast
sessions, there will be a time when some receivers have been added
a QoS VC and some have not. During such transition times it
possible to start sending data on the newly established VC.
issue is when to start send data on the new VC. If data is sent
on the new VC and the old VC, then data will be delivered with
Crawley, et. al. Informational [Page 18]
RFC 2382 Integrated Services and RSVP over ATM August 1998
QoS to some receivers and with the old QoS to all receivers.
means the QoS receivers can get duplicate data. If data is sent
on the new QoS VC, the receivers that have not yet been added
lose information. So, the issue comes down to whether to send
both the old and new VCs, or to send to just one of the VCs. In
case duplicate information will be received, in the other
information may not be received
This issue needs to be considered for three cases
- When establishing the first QoS
- When establishing a VC to support a QoS
- When adding a new end-point to an already established QoS
The first two cases are very similar. It both, it is possible
send data on the partially completed new VC, and the issue
duplicate versus lost information is the same. The last case is
an end-point must be added to an existing QoS VC. In this case
end-point must be both added to the QoS VC and dropped from a best
effort VC. The issue is which to do first. If the add is
requested, then the end-point may get duplicate information. If
drop is requested first, then the end-point may loose information
In order to ensure predictable behavior and delivery of data to
receivers, data can only be sent on a new VCs once all parties
been added. This will ensure that all data is only delivered once
all receivers. This approach does not quite apply for the last case
In the last case, the add operation should be completed first,
the drop operation. This means that receivers must be prepared
receive some duplicate packets at times of QoS setup
4.2.7 Dynamic
RSVP provides dynamic quality of service (QoS) in that the
that are requested may change at any time. There are several
reasons for a change of reservation QoS
1. An existing receiver can request a new larger (or smaller) QoS
2. A sender may change its traffic specification (TSpec), which
trigger a change in the reservation requests of the receivers
3. A new sender can start sending to a multicast group with a
traffic specification than existing senders, triggering
reservations
4. A new receiver can make a reservation that is larger than
reservations
Crawley, et. al. Informational [Page 19]
RFC 2382 Integrated Services and RSVP over ATM August 1998
If the limited heterogeneity model is being used and the merge
for the larger reservation is an ATM edge device, a new
reservation must be set up across the ATM network. Since ATM service
as currently defined in UNI 3.x and UNI 4.0, does not
renegotiating the QoS of a VC, dynamically changing the
means creating a new VC with the new QoS, and tearing down
established VC. Tearing down a VC and setting up a new VC in ATM
complex operations that involve a non-trivial amount of
time, and may have a substantial latency. There are several
for dealing with this mismatch in service. A specific approach
need to be a part of any RSVP over ATM solution
The default method for supporting changes in RSVP reservations is
attempt to replace an existing VC with a new appropriately sized VC
During setup of the replacement VC, the old VC must be left in
unmodified. The old VC is left unmodified to minimize interruption
QoS data delivery. Once the replacement VC is established,
transmission is shifted to the new VC, and the old VC is then closed
If setup of the replacement VC fails, then the old QoS VC
continue to be used. When the new reservation is greater than the
reservation, the reservation request should be answered with
error. When the new reservation is less than the old reservation
the request should be treated as if the modification was successful
While leaving the larger allocation in place is suboptimal,
maximizes delivery of service to the user. Implementations
retry replacing the too large VC after some appropriate elapsed time
One additional issue is that only one QoS change can be processed
one time per reservation. If the (RSVP) requested QoS is
while the first replacement VC is still being setup, then
replacement VC is released and the whole VC replacement process
restarted. To limit the number of changes and to avoid
signalling load, implementations may limit the number of changes
will be processed in a given period. One implementation
would have each ATM edge device configured with a time parameter
(which can change over time) that gives the minimum amount of
the edge device will wait between successive changes of the QoS of
particular VC. Thus if the QoS of a VC is changed at time t,
messages that would change the QoS of that VC that arrive before
t+T would be queued. If several messages changing the QoS of a
arrive during the interval, redundant messages can be discarded.
time t+T, the remaining change(s) of QoS, if any, can be executed
This timer approach would apply more generally to any
structure, and might be worthwhile to incorporate into RSVP
Crawley, et. al. Informational [Page 20]
RFC 2382 Integrated Services and RSVP over ATM August 1998
The sequence of events for a single VC would
- Wait if timer is
- Establish VC with new
- Remap data traffic to new
- Tear down old
- Activate
There is an interesting interaction between
reservations and dynamic QoS. In the case where a RESV message
received from a new next-hop and the requested resources are
than any existing reservation, both dynamic QoS and
need to be addressed. A key issue is whether to first add the
next-hop or to change to the new QoS. This is a fairly
forward special case. Since the older, smaller reservation does
support the new next-hop, the dynamic QoS process should be
first. Since the new QoS is only needed by the new next-hop,
should be the first end-point of the new VC. This way signalling
minimized when the setup to the new next-hop fails
4.2.8 Short-
Short-cuts [4] allow ATM attached routers and hosts to
establish point-to-point VCs across LIS boundaries, i.e., the
end-points are on different IP subnets. The ability for short-
and RSVP to interoperate has been raised as a general question.
area of concern is the ability to handle asymmetric short-cuts
Specifically how RSVP can handle the case where a downstream short
cut may not have a matching upstream short-cut. In this case,
and RESV messages following different paths
Examination of RSVP shows that the protocol already
mechanisms that will support short-cuts. The mechanism is the
one used to support RESV messages arriving at the wrong router
the wrong interface. The key aspect of this mechanism is RSVP
processing messages that arrive at the proper interface and
forwarding of messages that arrive on the wrong interface.
proper interface is indicated in the NHOP object of the message. So
existing RSVP mechanisms will support asymmetric short-cuts.
short-cut model of VC establishment still poses several issues
running with RSVP. The major issues are dealing with
best-effort short-cuts, when to establish short-cuts, and QoS
short-cuts. These issues will need to be addressed by
implementations
The key issue to be addressed by any RSVP over ATM solution is
to establish a short-cut for a QoS data flow. The default behavior
to simply follow best-effort traffic. When a short-cut has
Crawley, et. al. Informational [Page 21]
RFC 2382 Integrated Services and RSVP over ATM August 1998
established for best-effort traffic to a destination or next-hop
that same end-point should be used when setting up RSVP triggered
for QoS traffic to the same destination or next-hop. This will
naturally when PATH messages are forwarded over the best-
short-cut. Note that in this approach when best-effort short-
are never established, RSVP triggered QoS short-cuts will also
be established. More study is expected in this area
4.2.9 VC
RSVP can identify from either explicit messages or timeouts when
data VC is no longer needed. Therefore, data VCs set up to
RSVP controlled flows should only be released at the direction
RSVP. VCs must not be timed out due to inactivity by either the
initiator or the VC receiver. This conflicts with VCs timing out
described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755
recommends tearing down a VC that is inactive for a certain length
time. Twenty minutes is recommended. This timeout is
implemented at both the VC initiator and the VC receiver. Although
section 3.1 of the update to RFC 1755 [11] states that
timers must not be used at the VC receiver
When this timeout occurs for an RSVP initiated VC, a valid VC
QoS will be torn down unexpectedly. While this behavior
acceptable for best-effort traffic, it is important that
controlled VCs not be torn down. If there is no choice about the
being torn down, the RSVP daemon must be notified, so a
failure message can be sent
For VCs initiated at the request of RSVP, the configurable
timer mentioned in [11] must be set to "infinite". Setting
inactivity timer value at the VC initiator should not be
since the proper value can be relayed internally at the originator
Setting the inactivity timer at the VC receiver is more difficult
and would require some mechanism to signal that an incoming VC
RSVP initiated. To avoid this complexity and to conform to [11]
implementations must not use an inactivity timer to clear
connections
4.3 RSVP Control
One last important issue is providing a data path for the
messages themselves. There are two main types of messages in RSVP
PATH and RESV. PATH messages are sent to unicast or
addresses, while RESV messages are sent only to unicast addresses
Other RSVP messages are handled similar to either PATH or RESV
although this might be more complicated for RERR messages. So
VCs used for RSVP signalling messages need to provide both
Crawley, et. al. Informational [Page 22]
RFC 2382 Integrated Services and RSVP over ATM August 1998
and multicast functionality. There are several different
for how to assign VCs to use for RSVP signalling messages
The main approaches are
- use same VC as
- single VC per
- single point-to-multipoint VC multiplexed among
- multiple point-to-point VCs multiplexed among
There are several different issues that affect the choice of how
assign VCs for RSVP signalling. One issue is the number of
VCs needed for RSVP signalling. Related to this issue is the
of multiplexing on the RSVP VCs. In general more multiplexing
fewer VCs. An additional issue is the latency in dynamically
up new RSVP signalling VCs. A final issue is complexity
implementation. The remainder of this section discusses the
and tradeoffs among these different approaches and
guidelines for when to use which alternative
4.3.1 Mixed data and control
In this scheme RSVP signalling messages are sent on the same VCs
is the data traffic. The main advantage of this scheme is that
additional VCs are needed beyond what is needed for the data traffic
An additional advantage is that there is no ATM signalling
for PATH messages (which follow the same routing as the
messages). However there can be a major problem when data traffic
a VC is nonconforming. With nonconforming traffic, RSVP
messages may be dropped. While RSVP is resilient to a moderate
of dropped messages, excessive drops would lead to repeated
down and re-establishing of QoS VCs, a very undesirable behavior
ATM. Due to these problems, this may not be a good choice
providing RSVP signalling messages, even though the number of
needed for this scheme is minimized. One variation of this scheme
to use the best effort data path for signalling traffic. In
scheme, there is no issue with nonconforming traffic, but there is
issue with congestion in the ATM network. RSVP provides
resiliency to message loss due to congestion, but RSVP
messages should be offered a preferred class of service. A
variation of this scheme that is hopeful but requires further
is to have a packet scheduling algorithm (before entering the
network) that gives priority to the RSVP signalling traffic. This
be difficult to do at the IP layer
Crawley, et. al. Informational [Page 23]
RFC 2382 Integrated Services and RSVP over ATM August 1998
4.3.1.1 Single RSVP VC per RSVP
In this scheme, there is a parallel RSVP signalling VC for each
reservation. This scheme results in twice the number of VCs,
means that RSVP signalling messages have the advantage of a
VC. This separate VC means that RSVP signalling messages have
own traffic contract and compliant signalling messages are
subject to dropping due to other noncompliant traffic (such as
happen with the scheme in section 4.3.1). The advantage of
scheme is its simplicity - whenever a data VC is created, a
RSVP signalling VC is created. The disadvantage of the extra VC
that extra ATM signalling needs to be done. Additionally, this
requires twice the minimum number of VCs and also additional latency
but is quite simple
4.3.1.2 Multiplexed point-to-multipoint RSVP
In this scheme, there is a single point-to-multipoint RSVP
VC for each unique ingress router and unique set of egress routers
This scheme allows multiplexing of RSVP signalling traffic
shares the same ingress router and the same egress routers. This
save on the number of VCs, by multiplexing, but there are
when the destinations of the multiplexed point-to-multipoint VCs
changing. Several alternatives exist in these cases, that
applicability in different situations. First, when the egress
change, the ingress router can check if it already has a point-to
multipoint RSVP signalling VC for the new list of egress routers.
the RSVP signalling VC already exists, then the RSVP
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
routers. Other approaches include modifying the existing VC to add
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
keep sending to the existing VC even though some traffic is wasted
The number of VCs used in this scheme is a function of
patterns across the ATM network, but is always less than the
used with the Single RSVP VC per data VC. In addition, existing
effort data VCs could be used for RSVP signalling. Reusing
effort VCs saves on the number of VCs at the cost of
probability of RSVP signalling packet loss. One possible place
this scheme will work well is in the core of the network where
is the most opportunity to take advantage of the savings due
multiplexing. The exact savings depend on the patterns of
and the topology of the ATM network
Crawley, et. al. Informational [Page 24]
RFC 2382 Integrated Services and RSVP over ATM August 1998
4.3.1.3 Multiplexed point-to-point RSVP
In this scheme, multiple point-to-point RSVP signalling VCs are
for a single point-to-multipoint data VC. This scheme
multiplexing of RSVP signalling traffic but requires the same
to be sent on each of several VCs. This scheme is quite flexible
allows a large amount of multiplexing
Since point-to-point VCs can set up a reverse channel at the
time as setting up the forward channel, this scheme could
substantially on signalling cost. In addition, signalling
could share existing best effort VCs. Sharing existing best
VCs reduces the total number of VCs needed, but might
signalling traffic drops if there is congestion in the ATM network
This point-to-point scheme would work well in the core of the
where there is much opportunity for multiplexing. Also in the core
the network, RSVP VCs can stay permanently established either
Permanent Virtual Circuits (PVCs) or as long lived Switched
Circuits (SVCs). The number of VCs in this scheme will depend
traffic patterns, but in the core of a network would be
n(n-1)/2 where n is the number of IP nodes in the network. In
core of the network, this will typically be small compared to
total number of VCs
4.3.2 QoS for RSVP
There is an issue of what QoS, if any, to assign to the
signalling VCs. For other RSVP VC schemes, a QoS (possibly
effort) will be needed. What QoS to use partially depends on
expected level of multiplexing that is being done on the VCs, and
expected reliability of best effort VCs. Since RSVP signalling
infrequent (typically every 30 seconds), only a relatively small
should be needed. This is important since using a larger QoS
the VC setup being rejected for lack of resources. Falling back
best effort when a QoS call is rejected is possible, but if the
net is congested, there will likely be problems with RSVP packet
on the best effort VC also. Additional experimentation is needed
this area
5.
Since RSVP is a signalling protocol used to control flows of IP
packets, encapsulation for both RSVP packets and associated IP
packets must be defined. The methods for transmitting IP packets
ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all
on the encapsulations defined in RFC1483 [19]. RFC1483 specifies
encapsulations, LLC Encapsulation and VC-based multiplexing.
former allows multiple protocols to be encapsulated over the same
Crawley, et. al. Informational [Page 25]
RFC 2382 Integrated Services and RSVP over ATM August 1998
and the latter requires different VCs for different protocols
For the purposes of RSVP over ATM, any encapsulation can be used
long as the VCs are managed in accordance to the methods outlined
Section 4. Obviously, running multiple protocol data streams
the same VC with LLC encapsulation can cause the same problems
running multiple flows over the same VC
While none of the transmission methods directly address the issue
QoS, RFC1755 [11] does suggest some common values for VC setup
best-effort traffic. [14] discusses the relationship of the RFC1755
setup parameters and those needed to support IntServ flows in
detail
6. Security
The same considerations stated in [1] and [11] apply to
document. There are no additional security issues raised in
document
7.
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2209, September 1997.
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "
of Realtime Services in an IP-ATM Network Architecture",
1821, August 1995.
[3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A
Document", RFC 1932, April 1996.
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332,
April 1998.
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks", RFC 2022, November 1996.
[6] Shenker, S., and C. Partridge, "Specification of
Quality of Service", RFC 2212, September 1997.
[7] Wroclawski, J., "Specification of the Controlled-Load
Element Service", RFC 2211, September 1997.
[8] ATM Forum. ATM User-Network Interface Specification Version 3.0.
Prentice Hall, September 1993.
Crawley, et. al. Informational [Page 26]
RFC 2382 Integrated Services and RSVP over ATM August 1998
[9] ATM Forum. ATM User Network Interface (UNI) Specification
3.1. Prentice Hall, June 1995.
[10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225,
1998.
[11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis
"ATM Signalling Support for IP over ATM", RFC 1755,
1995.
[12] Herzog, S., "RSVP Extensions for Policy Control", Work
Progress
[13] Herzog, S., "Local Policy Modules (LPM): Policy Control
RSVP", Work in Progress
[14] Borden, M., and M. Garrett, "Interoperation of Controlled-
and Guaranteed Service with ATM", RFC 2381, August 1998.
[15] Berger, L., "RSVP over ATM Implementation Requirements",
2380, August 1998.
[16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379,
August 1998.
[17] ATM Forum Technical Committee. LAN Emulation over ATM,
1.0 Specification, af-lane-0021.000, January 1995.
[18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-
0824r9, September 1996.
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.
[20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2
- LUNI Specification, December 1996.
[21] ATM Forum Technical Committee. Traffic Management
v4.0, af-tm-0056.000, April 1996.
[22] Callon, R., et al., "A Framework for Multiprotocol
Switching, Work in Progress
[23] Rajagopalan, B., Nair, R., Sand