draft-ietf-issll-atm-framework-00.txt   draft-ietf-issll-atm-framework-01.txt 
Internet Engineering Task Force E. Crawley, Editor Internet Engineering Task Force E. Crawley, Editor
Internet Draft Gigapacket Networks Internet Draft (Argon Networks)
draft-ietf-issll-atm-framework-00.txt L. Berger draft-ietf-issll-atm-framework-01.txt L. Berger
Fore Systems (Fore Systems)
S. Berson S. Berson
ISI (ISI)
F. Baker F. Baker
Cisco Systems (Cisco Systems)
M. Borden M. Borden
New Oak Communications (New Oak Communications)
J. Krawczyk J. Krawczyk
ArrowPoint Communications (ArrowPoint Communications)
July 24, 1997 Novemver 18, 1997
A Framework for Integrated Services and RSVP over ATM A Framework for Integrated Services and RSVP over ATM
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts). distribute working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
skipping to change at line 38 skipping to change at line 38
Internet Drafts as reference material or to cite them other than Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress." as a "working draft" or "work in progress."
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net (US East Coast), Drafts Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Eur4ope), ftp.isi.edu (US West Coast), or nic.nordu.net (Eur4ope), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim). munnari.oz.au (Pacific Rim).
Abstract Abstract
This document outlines the framework and issues related to This document outlines the issues and framework related to
providing IP Integrated Services with RSVP over ATM. It provides providing IP Integrated Services with RSVP over ATM. It provides
an overall approach to the problem(s) and related issues. These an overall approach to the problem(s) and related issues. These
issues and problems are to be addressed in further documents from issues and problems are to be addressed in further documents from
the ISATM subgroup of the ISSLL working group. the ISATM subgroup of the ISSLL working group.
Editor's Note Editor's Note
This document is the merger of two previous documents, draft- This document is the merger of two previous documents, draft-
ietf-issll-atm-support-02.txt by Berger and Berson and draft- ietf-issll-atm-support-02.txt by Berger and Berson and draft-
crawley-rsvp-over-atm-00.txt by Baker, Berson, Borden, Crawley, crawley-rsvp-over-atm-00.txt by Baker, Berson, Borden, Crawley,
and Krawczyk. The former document has been split into this and Krawczyk. The former document has been split into this
skipping to change at line 61 skipping to change at line 61
1. Introduction 1. Introduction
The Internet currently has one class of service normally referred The Internet currently has one class of service normally referred
to as "best effort." This service is typified by first-come, to as "best effort." This service is typified by first-come,
first-serve scheduling at each hop in the network. Best effort first-serve scheduling at each hop in the network. Best effort
service has worked well for electronic mail, World Wide Web (WWW) service has worked well for electronic mail, World Wide Web (WWW)
access, file transfer (e.g. ftp), etc. For real-time traffic access, file transfer (e.g. ftp), etc. For real-time traffic
such as voice and video, the current Internet has performed well such as voice and video, the current Internet has performed well
only across unloaded portions of the network. In order to only across unloaded portions of the network. In order to
provide guaranteed quality real-time traffic, new classes of provide quality real-time traffic, new classes of service and a
service and a QoS signalling protocol are being introduced in the QoS signalling protocol are being introduced in the Internet
Internet [1,6,7], while retaining the existing best effort [1,6,7], while retaining the existing best effort service. The
service. The QoS signalling protocol is RSVP [1], the Resource QoS signalling protocol is RSVP [1], the Resource ReSerVation
ReSerVation Protocol. Protocol and the service models
One of the important features of ATM technology is the ability to One of the important features of ATM technology is the ability to
request a point-to-point Virtual Circuit (VC) with a specified request a point-to-point Virtual Circuit (VC) with a specified
Quality of Service (QoS). An additional feature of ATM Quality of Service (QoS). An additional feature of ATM
technology is the ability to request point-to-multipoint VCs with technology is the ability to request point-to-multipoint VCs with
a specified QoS. Point-to-multipoint VCs allows leaf nodes to be a specified QoS. Point-to-multipoint VCs allows leaf nodes to be
added and removed from the VC dynamically and so provides a added and removed from the VC dynamically and so provides a
mechanism for supporting IP multicast. It is only natural that mechanism for supporting IP multicast. It is only natural that
RSVP and the Internet Integrated Services (IIS) model would like RSVP and the Internet Integrated Services (IIS) model would like
to utilize the QoS properties of any underlying link layer to utilize the QoS properties of any underlying link layer
skipping to change at line 98 skipping to change at line 98
IP/ATM edge devices (i.e. hosts or routers), a single VC is IP/ATM edge devices (i.e. hosts or routers), a single VC is
created on demand and shared for all traffic between the two created on demand and shared for all traffic between the two
devices. A second part of the RSVP and IIS over ATM problem, IP devices. A second part of the RSVP and IIS over ATM problem, IP
multicast, is being solved with MARS [5], the Multicast Address multicast, is being solved with MARS [5], the Multicast Address
Resolution Server. Resolution Server.
MARS compliments ATMARP by allowing an IP address to resolve into MARS compliments ATMARP by allowing an IP address to resolve into
a list of native ATM addresses, rather than just a single a list of native ATM addresses, rather than just a single
address. address.
The ATM Forum's LAN Emulation (LANE) [17 and 20] and The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol
Multiprotocol Over ATM (MPOA) [18] also address the support of IP Over ATM (MPOA) [18] also address the support of IP best effort
best effort traffic over ATM through similar means. traffic over ATM through similar means.
A key remaining issue for IP in an ATM environment is the A key remaining issue for IP in an ATM environment is the
integration of RSVP signalling and ATM signalling in support of integration of RSVP signalling and ATM signalling in support of
the Internet Integrated Services (IIS) model. There are two main the Internet Integrated Services (IIS) model. There are two main
areas involved in supporting the IIS model, QoS translation and areas involved in supporting the IIS model, QoS translation and
VC management. QoS translation concerns mapping a QoS from the VC management. QoS translation concerns mapping a QoS from the
IIS model to a proper ATM QoS, while VC management concentrates IIS model to a proper ATM QoS, while VC management concentrates
on how many VCs are needed and which traffic flows are routed on how many VCs are needed and which traffic flows are routed
over which VCs. over which VCs.
skipping to change at line 125 skipping to change at line 125
further documents. In this document, the modes and models for further documents. In this document, the modes and models for
RSVP operation over ATM will be discussed followed by a RSVP operation over ATM will be discussed followed by a
discussion of management of ATM VCs for RSVP data and control. discussion of management of ATM VCs for RSVP data and control.
Lastly, the topic of encapsulations will be discussed in relation Lastly, the topic of encapsulations will be discussed in relation
to the models presented. to the models presented.
This document is part of a group of documents from the ISATM This document is part of a group of documents from the ISATM
subgroup of the ISSLL working group related to the operation of subgroup of the ISSLL working group related to the operation of
IntServ and RSVP over ATM. [14] discusses the mapping of the IntServ and RSVP over ATM. [14] discusses the mapping of the
IntServ models for Controlled Load and Guaranteed Service to ATM. IntServ models for Controlled Load and Guaranteed Service to ATM.
[15 and 16] discuss implementation requirements and guidelines [15 and 16] discuss detailed implementation requirements and
for RSVP over ATM, respectively. While these documents may not guidelines for RSVP over ATM, respectively. While these
address all the issues raised in this document, they should documents may not address all the issues raised in this document,
provide enough information for development of solutions for they should provide enough information for development of
IntServ and RSVP over ATM. solutions for IntServ and RSVP over ATM.
1.2 Terms 1.2 Terms
The terms "reservation" and "flow" are used in many contexts, Several term used in this document are used in many contexts,
often with different meaning. These terms are used in this often with different meaning. These terms are used in this
document with the following meaning: document with the following meaning:
- Sender is used in this document to mean the ingress point to
the ATM network or "cloud".
- Receiver is used in this document to refer to the egress point
from the ATM network or "cloud".
- Reservation is used in this document to refer to an RSVP - Reservation is used in this document to refer to an RSVP
initiated request for resources. RSVP initiates requests for initiated request for resources. RSVP initiates requests for
resources based on RESV message processing. RESV messages that resources based on RESV message processing. RESV messages that
simply refresh state do not trigger resource requests. simply refresh state do not trigger resource requests.
Resource requests may be made based on RSVP sessions and RSVP Resource requests may be made based on RSVP sessions and RSVP
reservation styles. RSVP styles dictate whether the reserved reservation styles. RSVP styles dictate whether the reserved
resources are used by one sender or shared by multiple resources are used by one sender or shared by multiple
senders. See [1] for details of each. Each new request is senders. See [1] for details of each. Each new request is
referred to in this document as an RSVP reservation, or simply referred to in this document as an RSVP reservation, or simply
reservation. reservation.
skipping to change at line 219 skipping to change at line 223
point-to-point network. The QoS of the PVC must be consistent point-to-point network. The QoS of the PVC must be consistent
and equivalent to the type of traffic and service model used. and equivalent to the type of traffic and service model used.
The devices on either end of the PVC have to provide traffic The devices on either end of the PVC have to provide traffic
control services in order to multiplex multiple flows over the control services in order to multiplex multiple flows over the
same PVC. With PVCs, there is no issue of when or how long it same PVC. With PVCs, there is no issue of when or how long it
takes to set up VCs, since they are made in advance but the takes to set up VCs, since they are made in advance but the
resources of the PVC are limited to what has been pre-allocated. resources of the PVC are limited to what has been pre-allocated.
PVCs that are not fully utilized can tie up ATM network resources PVCs that are not fully utilized can tie up ATM network resources
that could be used for SVCs. that could be used for SVCs.
An additional issue for using PVCs is one of network engineering.
Frequently, multiple PVCs are set up such that if all the PVCs
were running at full capacity, the link would be over-subscribed.
This frequently used "statistical multiplexing gain" makes
providing IIS over PVCs very difficult and unreliable. Any
application of IIS over PVCs has to be assured that the PVCs are
able to receive all the requested QoS.
2.1.1.2 Switched Virtual Circuits (SVCs) 2.1.1.2 Switched Virtual Circuits (SVCs)
SVCs allow paths in the ATM network to be set up "on demand". SVCs allow paths in the ATM network to be set up "on demand".
This allows flexibility in the use of RSVP over ATM along with This allows flexibility in the use of RSVP over ATM along with
some complexity. Parallel VCs can be set up to allow best-effort some complexity. Parallel VCs can be set up to allow best-effort
and better service class paths through the network. The cost and and better service class paths through the network, as shown in
time to set up SVCs can impact their use. For example, it may be Figure 1. The cost and time to set up SVCs can impact their use.
better to initially route QoS traffic over existing VCs until an For example, it may be better to initially route QoS traffic over
SVC with the desired QoS has been set up. Scaling issues can existing VCs until a SVC with the desired QoS can be set up for
come into play if a single VC is used per RSVP flow. An RSVP the flow. Scaling issues can come into play if a single RSVP
flow is a data flow from one or more sources to one or more flow is used per VC, as will be discussed in Section 4.3.1.1. The
receivers as defined by an RSVP filter specification. The number number of VCs in any ATM device may also be limited so the number
of VCs in any ATM device is limited so the number of RSVP flows of RSVP flows that can be supported by a device can be strictly
that can be handled by a device would be strictly limited to the limited to the number of VCs available, if we assume one flow per
number of VCs available, if we assume one VC per flow. VC. Section 4 discusses the topic of VC management for RSVP in
greater detail.
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
Figure 1: Data Flow VC Initiation
While RSVP is receiver oriented, ATM is sender oriented. This
might seem like a problem but the sender or ingress point
receives RSVP RESV messages and can determine whether a new VC
has to be set up to the destination or egress point.
2.1.1.3 Point to MultiPoint 2.1.1.3 Point to MultiPoint
In order to provide QoS for IP multicast, an important feature of In order to provide QoS for IP multicast, an important feature of
RSVP, data flows must be distributed to multiple destinations RSVP, data flows must be distributed to multiple destinations
from a given source. Point-to-multipoint VCs provide such a from a given source. Point-to-multipoint VCs provide such a
mechanism. It is important to map the actions of IP multicasting mechanism. It is important to map the actions of IP multicasting
and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add
party and drop party functions for ATM. Point-to-multipoint VCs party and drop party functions for ATM. Point-to-multipoint VCs
as defined in UNI 3.x have a single service class for all as defined in UNI 3.x have a single service class for all
destinations. This is contrary to the RSVP "heterogeneous destinations. This is contrary to the RSVP "heterogeneous
receiver" concept. It is possible to set up a different VC to receiver" concept. It is possible to set up a different VC to
each receiver requesting a different QoS, but this again can run each receiver requesting a different QoS, as shown in Figure 2.
into scaling and resource problems when managing multiple VCs on This again can run into scaling and resource problems when
the same interface to different destinations. managing multiple VCs on the same interface to different
destinations.
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver
Request Types:
| Src | ----> QoS 1
and QoS 2
| | .........+ +----+ ....> Best-
Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
Figure 2: Types of Multicast Receivers
RSVP sends messages both up and down the multicast distribution RSVP sends messages both up and down the multicast distribution
tree. In the case of a large ATM cloud, this could result in a tree. In the case of a large ATM cloud, this could result in a
RSVP message implosion at an RSVP traffic source with many RSVP message implosion at an ATM ingress point with many
receivers. receivers.
ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf
Initiated Join (LIJ) capability. LIJ allows an ATM end point to Initiated Join (LIJ) capability. LIJ allows an ATM end point to
join into an existing point-to-multipoint VC without necessarily join into an existing point-to-multipoint VC without necessarily
contacting the source of the VC. This will reduce the burden on contacting the source of the VC. This can reduce the burden on
the ATM source point for setting up new branches and more closely the ATM source point for setting up new branches and more closely
matches the receiver-based model of RSVP and IP multicast. matches the receiver-based model of RSVP and IP multicast.
However, many of the same scaling issues exist and the new However, many of the same scaling issues exist and the new
branches added to a point-to-multipoint VC would use the same QoS branches added to a point-to-multipoint VC must use the same QoS
as existing branches. as existing branches.
2.1.1.4 Multicast Servers 2.1.1.4 Multicast Servers
IP-over-ATM has the concept of a multicast server or reflector IP-over-ATM has the concept of a multicast server or reflector
that can accept cells from multiple senders and send them via a that can accept cells from multiple senders and send them via a
point-to-multipoint VC to a set of receivers. This moves the VC point-to-multipoint VC to a set of receivers. This moves the VC
scaling issues noted previously for point-to-multipoint VCs to scaling issues noted previously for point-to-multipoint VCs to
the multicast server. Additionally, the multicast server will the multicast server. Additionally, the multicast server will
need to know how to interpret RSVP packets so it will be able to need to know how to interpret RSVP packets or receive instruction
provide VCs of the appropriate QoS for the flows. from another node so it will be able to provide VCs of the
appropriate QoS for the RSVP flows.
2.1.2 Hop-by-Hop vs. Short Cut 2.1.2 Hop-by-Hop vs. Short Cut
If the ATM "cloud" is made up a number of logical IP subnets 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 (LISs), then it is possible to use "short cuts" from a node on
one LIS directly to a node on another LIS, avoiding router hops one LIS directly to a node on another LIS, avoiding router hops
between the LISs. NHRP [4], is one mechanism for determining the between the LISs. NHRP [4], is one mechanism for determining the
ATM address of the egress point on the ATM network given a ATM address of the egress point on the ATM network given a
destination IP address. It is a topic for further study to destination IP address. It is a topic for further study to
determine if significant benefit is achieved from short cut determine if significant benefit is achieved from short cut
skipping to change at line 296 skipping to change at line 353
2.1.3 Future Models 2.1.3 Future Models
ATM is constantly evolving. If we assume that RSVP and IntServ ATM is constantly evolving. If we assume that RSVP and IntServ
applications are going to be wide-spread, it makes sense to applications are going to be wide-spread, it makes sense to
consider changes to ATM that would improve the operation of RSVP consider changes to ATM that would improve the operation of RSVP
and IntServ over ATM. Similarly, the RSVP protocol and IntServ and IntServ over ATM. Similarly, the RSVP protocol and IntServ
models will continue to evolve and changes that affect them models will continue to evolve and changes that affect them
should also be considered. The following are a few ideas that should also be considered. The following are a few ideas that
have been discussed that would make the integration of the have been discussed that would make the integration of the
IntServ models and RSVP easier or more complete. They are IntServ models and RSVP easier or more complete. They are
presented here to encourage continued development of ideas that presented here to encourage continued development and discussion
can help aid in the integration of RSVP, IntServ, and ATM. of ideas that can help aid in the integration of RSVP, IntServ,
and ATM.
2.1.3.1 Heterogeneous Point-to-MultiPoint 2.1.3.1 Heterogeneous Point-to-MultiPoint
The IntServ models and RSVP support the idea of "heterogeneous The IntServ models and RSVP support the idea of "heterogeneous
receivers"; e.g., not all receivers of a particular multicast receivers"; e.g., not all receivers of a particular multicast
flow are required to ask for the same QoS from the network. flow are required to ask for the same QoS from the network, as
shown in Figure 2.
The most important scenario that can utilize this feature occurs The most important scenario that can utilize this feature occurs
when some receivers in an RSVP session ask for a specific QoS when some receivers in an RSVP session ask for a specific QoS
while others receive the flow with a best-effort service. In while others receive the flow with a best-effort service. In
some cases where there are multiple senders on a shared- some cases where there are multiple senders on a shared-
reservation flow (e.g., an audio conference), an individual reservation flow (e.g., an audio conference), an individual
receiver only needs to reserve enough resources to receive one receiver only needs to reserve enough resources to receive one
sender at a time. However, other receivers may elect to reserve sender at a time. However, other receivers may elect to reserve
more resources, perhaps to allow for some amount of "over- more resources, perhaps to allow for some amount of "over-
speaking" or in order to record the conference (post processing speaking" or in order to record the conference (post processing
skipping to change at line 360 skipping to change at line 419
2.1.3.3 QoS Renegotiation 2.1.3.3 QoS Renegotiation
Another change that would help RSVP over ATM is the ability to Another change that would help RSVP over ATM is the ability to
request a different QoS for an active VC. This would eliminate request a different QoS for an active VC. This would eliminate
the need to setup and tear down VCs as the QoS changed. RSVP the need to setup and tear down VCs as the QoS changed. RSVP
allows receivers to change their reservations and senders to allows receivers to change their reservations and senders to
change their traffic descriptors dynamically. This, along with change their traffic descriptors dynamically. This, along with
the merging of reservations, can create a situation where the QoS the merging of reservations, can create a situation where the QoS
needs of a VC can change. Allowing changes to the QoS of an needs of a VC can change. Allowing changes to the QoS of an
existing VC would allow these features to work without creating a existing VC would allow these features to work without creating a
new VC. In the ITU-T ATM specifications [??REF??], some cell new VC. In the ITU-T ATM specifications [24,25], some cell rates
rates can be renegotiated. It is unclear if this is sufficient can be renegotiated or changed. Specifically, the Peak Cell Rate
for the QoS renegotiation needs of the IntServ models. (PCR) of an existing VC can be changed and, in some cases, QoS
parameters may be renegotiated during the call setup phase. It is
unclear if this is sufficient for the QoS renegotiation needs of
the IntServ models.
2.1.3.4 Group Addressing 2.1.3.4 Group Addressing
The model of one-to-many communications provided by point-to- The model of one-to-many communications provided by point-to-
multipoint VCs does not really match the many-to-many multipoint VCs does not really match the many-to-many
communications provided by IP multicasting. A scaleable mapping communications provided by IP multicasting. A scaleable mapping
from IP multicast addresses to an ATM "group address" can address from IP multicast addresses to an ATM "group address" can address
this problem. this problem.
2.1.3.5 Label Switching 2.1.3.5 Label Switching
skipping to change at line 386 skipping to change at line 448
switched networks for IP by encapsulating the data with a header switched networks for IP by encapsulating the data with a header
that is used by the interior switches to achieve faster that is used by the interior switches to achieve faster
forwarding lookups. [22] discusses a framework for this work. forwarding lookups. [22] discusses a framework for this work.
It is unclear how this work will affect IntServ and RSVP over It is unclear how this work will affect IntServ and RSVP over
label switched networks but there may be some interactions. label switched networks but there may be some interactions.
2.1.4 QoS Routing 2.1.4 QoS Routing
RSVP is explicitly not a routing protocol. However, since it RSVP is explicitly not a routing protocol. However, since it
conveys QoS information, it may prove to be a valuable input to a conveys QoS information, it may prove to be a valuable input to a
routing protocol that could make path determinations based on QoS routing protocol that can make path determinations based on QoS
and network load information. In other words, instead of asking and network load information. In other words, instead of asking
for just the IP next hop for a given destination address, it for just the IP next hop for a given destination address, it
might be worthwhile for RSVP to provide information on the QoS might be worthwhile for RSVP to provide information on the QoS
needs of the flow if routing has the ability to use this needs of the flow if routing has the ability to use this
information in order to determine a route. Other forms of QoS information in order to determine a route. Other forms of QoS
routing have existed in the past such as using the IP TOS and routing have existed in the past such as using the IP TOS and
Precedence bits to select a path through the network. Some have Precedence bits to select a path through the network. Some have
discussed using these same bits to select one of a set of discussed using these same bits to select one of a set of
parallel ATM VCs as a form of QoS routing. The work in this area parallel ATM VCs as a form of QoS routing. ATM routing has also
is just starting and there are numerous issues to consider. considered the problem of QoS routing through the Private
[23], as part of the work of the QoSR working group frame the Network-to-Network Interface (PNNI) [26] routing protocol for
issues for QoS Routing in the Internet. routing ATM VCs on a path that can support their needs. The work
in this area is just starting and there are numerous issues to
consider. [23], as part of the work of the QoSR working group
frame the issues for QoS Routing in the Internet.
2.2 Reliance on Unicast and Multicast Routing 2.2 Reliance on Unicast and Multicast Routing
RSVP was designed to support both unicast and IP multicast RSVP was designed to support both unicast and IP multicast
applications. This means that RSVP needs to work closely with applications. This means that RSVP needs to work closely with
multicast and unicast routing. Unicast routing over ATM has been multicast and unicast routing. Unicast routing over ATM has been
addressed [10] and [11]. MARS [5] provides multicast address addressed [10] and [11]. MARS [5] provides multicast address
resolution for IP over ATM networks, an important part of the resolution for IP over ATM networks, an important part of the
solution for multicast but still relies on multicast routing solution for multicast but still relies on multicast routing
protocols to connect multicast senders and receivers on different protocols to connect multicast senders and receivers on different
skipping to change at line 420 skipping to change at line 485
2.3 Aggregation of Flows 2.3 Aggregation of Flows
Some of the scaling issues noted in previous sections can be Some of the scaling issues noted in previous sections can be
addressed by aggregating several RSVP flows over a single VC if addressed by aggregating several RSVP flows over a single VC if
the destinations of the VC match for all the flows being the destinations of the VC match for all the flows being
aggregated. However, this causes considerable complexity in the aggregated. However, this causes considerable complexity in the
management of VCs and in the scheduling of packets within each VC management of VCs and in the scheduling of packets within each VC
at the root point of the VC. Note that the rescheduling of flows at the root point of the VC. Note that the rescheduling of flows
within a VC is not possible in the switches in the core of the within a VC is not possible in the switches in the core of the
ATM network. Additionally, virtual paths (VPs) could be used for ATM network. Virtual Paths (VPs) can be used for aggregating
aggregating multiple VCs. multiple VCs. This topic is discussed in greater detail as it
applies to multicast data distribution in section 4.2.3.4
2.4 Mapping QoS Parameters 2.4 Mapping QoS Parameters
The mapping of QoS parameters from the IntServ models to the ATM The mapping of QoS parameters from the IntServ models to the ATM
service classes is an important issue in making RSVP and IntServ service classes is an important issue in making RSVP and IntServ
work over ATM. [14] addresses these issues very completely for work over ATM. [14] addresses these issues very completely for
the Controlled Load and Guaranteed Service models. An additional the Controlled Load and Guaranteed Service models. An additional
issue is that while some guidelines can be developed for mapping issue is that while some guidelines can be developed for mapping
the parameters of a given service model to the traffic the parameters of a given service model to the traffic
descriptors of an ATM traffic class, implementation variables, descriptors of an ATM traffic class, implementation variables,
policy, and cost factors can make strict standards problematic. policy, and cost factors can make strict mapping problematic.
So, a set of workable mappings that can be applied to different
network requirements and scenarios is needed as long as the
mappings can satisfy the needs of the service model(s).
2.5 Directly Connected ATM Hosts 2.5 Directly Connected ATM Hosts
It is obvious that the needs of hosts that are directly connected It is obvious that the needs of hosts that are directly connected
to ATM networks must be considered for RSVP and IntServ over ATM. to ATM networks must be considered for RSVP and IntServ over ATM.
Functionality for RSVP over ATM must not assume that an ATM host Functionality for RSVP over ATM must not assume that an ATM host
has all the functionality of a router, but such things as MARS has all the functionality of a router, but such things as MARS
and NHRP clients might be worthwhile features. and NHRP clients would be worthwhile features. A host must
managed VCs just like any other ATM sender or receiver as
described later in section 4.
2.6 Accounting and Policy Issues 2.6 Accounting and Policy Issues
Since RSVP and IntServ create classes of preferential service, Since RSVP and IntServ create classes of preferential service,
some form of administrative control and/or cost allocation is some form of administrative control and/or cost allocation is
needed to control abuse. There are certain types of policies needed to control access. There are certain types of policies
specific to ATM and IP over ATM that need to be studied to specific to ATM and IP over ATM that need to be studied to
determine how they interoperate with the IP policies being determine how they interoperate with the IP and IntServ policies
developed. Typical IP policies would be that only certain users being developed. Typical IP policies would be that only certain
are allowed to make reservations. This policy would translate users are allowed to make reservations. This policy would
well to IP over ATM due to the similarity to the mechanisms used translate well to IP over ATM due to the similarity to the
for Call Admission Control (CAC). There may be a need for mechanisms used for Call Admission Control (CAC). There may be a
policies specific to IP over ATM. For example, since signalling need for policies specific to IP over ATM. For example, since
costs in ATM are high relative to IP, an IP over ATM specific signalling costs in ATM are high relative to IP, an IP over ATM
policy might restrict the ability to change the prevailing QoS in specific policy might restrict the ability to change the
a VC. If VCs are relatively scarce, there also might be specific prevailing QoS in a VC. If VCs are relatively scarce, there also
accounting costs in creating a new VC. The work so far has been might be specific accounting costs in creating a new VC. The
preliminary, and much work remains to be done. The policy work so far has been preliminary, and much work remains to be
mechanisms outlined in [12] and [13] provide the basic mechanisms done. The policy mechanisms outlined in [12] and [13] provide
for implementing policies for RSVP and IntServ over any media, the basic mechanisms for implementing policies for RSVP and
not just ATM. IntServ over any media, not just ATM.
3. RSVP VC Management 3. Framework for IntServ and RSVP over ATM
This section goes into more detail on the issues related to the Now that we have defined some of the issues for IntServ and RSVP
over ATM, we can formulate a framework for solutions. The
problem breaks down to two very distinct areas; the mapping of
IntServ models to ATM service categories and QoS parameters and
the operation of RSVP over ATM.
Mapping IntServ models to ATM service categories and QoS
parameters is a matter of determining which categories can
support the goals of the service models and matching up the
parameters and variables between the IntServ description and the
ATM description(s). Since ATM has such a wide variety of service
categories and parameters, more than one ATM service category
should be able to support each of the two IntServ models. This
will provide a good bit of flexibility in configuration and
deployment. [14] examines this topic completely.
The operation of RSVP over ATM requires careful management of VCs
in order to match the dynamics of the RSVP protocol. VCs need to
be managed for both the RSVP QoS data and the RSVP signalling
messages. The remainder of this document will discuss several
approaches to managing VCs for RSVP and [15] and [16] discuss
their application for implementations in term of interoperability
requirement and implementation guidelines.
4. RSVP VC Management
This section provides more detail on the issues related to the
management of SVCs for RSVP and IntServ. management of SVCs for RSVP and IntServ.
3.1 VC Initiation 4.1 VC Initiation
There is an apparent mismatch between RSVP and ATM. Specifically, As discussed in section 2.1.1.2, there is an apparent mismatch
RSVP control is receiver oriented and ATM control is sender between RSVP and ATM. Specifically, RSVP control is receiver
oriented. This initially may seem like a major issue, but really oriented and ATM control is sender oriented. This initially may
is not. While RSVP reservation (RESV) requests are generated at seem like a major issue, but really is not. While RSVP
the receiver, actual allocation of resources takes place at the reservation (RESV) requests are generated at the receiver, actual
subnet sender. For data flows, this means that subnet senders allocation of resources takes place at the subnet sender. For
will establish all QoS VCs and the subnet receiver must be able data flows, this means that subnet senders will establish all QoS
to accept incoming QoS VCs. These restrictions are consistent VCs and the subnet receiver must be able to accept incoming QoS
with RSVP version 1 processing rules and allow senders to use VCs, as illustrated in Figure 1. These restrictions are
different flow to VC mappings and even different QoS consistent with RSVP version 1 processing rules and allow senders
renegotiation techniques without interoperability problems. All to use different flow to VC mappings and even different QoS
RSVP over ATM approaches that have VCs initiated and controlled renegotiation techniques without interoperability problems.
by the subnet senders will interoperate.
The use of the reverse path provided by point-to-point VCs by The use of the reverse path provided by point-to-point VCs by
receivers is for further study. There are two related issues. The receivers is for further study. There are two related issues. The
first is that use of the reverse path requires the VC initiator first is that use of the reverse path requires the VC initiator
to set appropriate reverse path QoS parameters. The second issue to set appropriate reverse path QoS parameters. The second issue
is that reverse paths are not available with point-to-multipoint is that reverse paths are not available with point-to-multipoint
VCs, so reverse paths could only be used to support unicast RSVP VCs, so reverse paths could only be used to support unicast RSVP
reservations. reservations.
3.2 Policy 4.2 Data VC Management
RSVP allows for local policy control [13,14] 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 reservation. The policy module
at the entry to a provider can decide how to satisfy that request
- either by merging the request in with an existing reservation
or by creating a new reservation for this (and perhaps other)
users. This policy can be on a per 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, providers can offer services best suited to their own
resources and their customers needs. Policy is expected to be
provided as a generic API which will return values indicating
what action should be taken for a specific reservation request.
The API is expected to have access to the reservation tables with
the QoS for each reservation. The RSVP Policy and Integrity
objects will be passed to the policy() call. Four possible return
values are expected. The request can be rejected. The request can
be accepted as is. The request can be accepted but at a different
QoS. The request can cause a change of QoS of an existing
reservation. The information returned from this call is be used
to call the admission control interface.
3.3 Data VC Management
Any RSVP over ATM implementation must map RSVP and RSVP Any RSVP over ATM implementation must map RSVP and RSVP
associated data flows to ATM Virtual Circuits (VCs). LAN associated data flows to ATM Virtual Circuits (VCs). LAN
Emulation [17], Classical IP [10] and, more recently, NHRP [4] Emulation [17], Classical IP [10] and, more recently, NHRP [4]
discuss mapping IP traffic onto ATM SVCs, but they only cover a discuss mapping IP traffic onto ATM SVCs, but they only cover a
single QoS class, i.e., best effort traffic. When QoS is single QoS class, i.e., best effort traffic. When QoS is
introduced, VC mapping must be revisited. For RSVP controlled QoS introduced, VC mapping must be revisited. For RSVP controlled QoS
flows, one issue is VCs to use for QoS data flows. flows, one issue is VCs to use for QoS data flows.
In the Classic IP over ATM and current NHRP models, a single In the Classic IP over ATM and current NHRP models, a single
point-to-point VC is used for all traffic between two ATM point-to-point VC is used for all traffic between two ATM
attached hosts (routers and end-stations). It is likely that attached hosts (routers and end-stations). It is likely that
such a single VC will not be adequate or optimal when supporting such a single VC will not be adequate or optimal when supporting
data flows with multiple QoS types. RSVP's basic purpose is to data flows with multiple QoS types. RSVP's basic purpose is to
install support for flows with multiple QoS types, so it is install support for flows with multiple QoS types, so it is
essential for any RSVP over ATM solution to address VC usage for essential for any RSVP over ATM solution to address VC usage for
QoS data flows. QoS data flows, as shown in Figure 1.
RSVP reservation styles will also need to be taken into account RSVP reservation styles must also be taken into account in any VC
in any VC usage strategy. usage strategy.
This section describes issues and methods for management of VCs This section describes issues and methods for management of VCs
associated with QoS data flows. When establishing and maintaining associated with QoS data flows. When establishing and maintaining
VCs, the subnet sender will need to deal with several VCs, the subnet sender will need to deal with several
complicating factors including multiple QoS reservations, complicating factors including multiple QoS reservations,
requests for QoS changes, ATM short-cuts, and several multicast requests for QoS changes, ATM short-cuts, and several multicast
specific issues. The multicast specific issues result from the specific issues. The multicast specific issues result from the
nature of ATM connections. The key multicast related issues are nature of ATM connections. The key multicast related issues are
heterogeneity, data distribution, receiver transitions, and end- heterogeneity, data distribution, receiver transitions, and end-
point identification. point identification.
3.3.1 Reservation to VC Mapping 4.2.1 Reservation to VC Mapping
There are various approaches available for mapping reservations There are various approaches available for mapping reservations
on to VCs. A distinguishing attribute of all approaches is how on to VCs. A distinguishing attribute of all approaches is how
reservations are combined on to individual VCs. When mapping reservations are combined on to individual VCs. When mapping
reservations on to VCs, individual VCs can be used to support a reservations on to VCs, individual VCs can be used to support a
single reservation, or reservation can be combined with others on single reservation, or reservation can be combined with others on
to "aggregate" VCs. In the first case, each reservation will be to "aggregate" VCs. In the first case, each reservation will be
supported by one or more VCs. Multicast reservation requests may supported by one or more VCs. Multicast reservation requests may
translate into the setup of multiple VCs as is described in more translate into the setup of multiple VCs as is described in more
detail in section 3.3.2. Unicast reservation requests will detail in section 4.2.2. Unicast reservation requests will
always translate into the setup of a single QoS VC. In both always translate into the setup of a single QoS VC. In both
cases, each VC will only carry data associated with a single cases, each VC will only carry data associated with a single
reservation. The greatest benefit if this approach is ease of reservation. The greatest benefit if this approach is ease of
implementation, but it comes at the cost of increased (VC) setup implementation, but it comes at the cost of increased (VC) setup
time and the consumption of greater number of VC and associated time and the consumption of greater number of VC and associated
resources. We refer to the other case, when reservations are not resources.
combined, as the "aggregation" model. With this model, large VCs
could be set up between IP routers and hosts in an ATM network. When multiple reservations are combined onto a single VC, it is
These VCs could be managed much like IP Integrated Service (IIS) referred to as the "aggregation" model. With this model, large
point-to-point links (e.g. T-1, DS-3) are managed now. Traffic VCs could be set up between IP routers and hosts in an ATM
from multiple sources over multiple RSVP sessions might be network. These VCs could be managed much like IP Integrated
multiplexed on the same VC. This approach has a number of Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed
advantages. First, there is typically no signalling latency as now. Traffic from multiple sources over multiple RSVP sessions
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 VCs would be in existence when the traffic started flowing, so no
time is wasted in setting up VCs. Second, the heterogeneity time is wasted in setting up VCs. Second, the heterogeneity
problem (section 3.3.2) in full over ATM has been reduced to a problem (section 4.2.2) in full over ATM has been reduced to a
solved problem. Finally, the dynamic QoS problem (section 3.3.6) solved problem. Finally, the dynamic QoS problem (section 4.2.7)
for ATM has also been reduced to a solved problem. for ATM has also been reduced to a solved problem.
This approach can be used with point-to-point and point-to- The aggregation model can be used with point-to-point and point-
multipoint VCs. The problem with the aggregation approach is to-multipoint VCs. The problem with the aggregation model is
that the choice of what QoS to use for which of the VCs is that the choice of what QoS to use for the VCs may be difficult,
difficult, but is made easier since the VCs can be changed as without knowledge of the likely reservation types and sizes but
needed. The advantages of this scheme makes this approach an is made easier since the VCs can be changed as needed.
item for high priority study.
3.3.2 Heterogeneity 4.2.2 Unicast Data VC Management
Heterogeneity occurs when receivers request different qualities Unicast data VC management is much simpler than multicast data VC
management but there are still some similar issues. If one
considers unicast to be a devolved case of multicast, then
implementing the multicast solutions will cover unicast.
However, some may want to consider unicast-only implementations.
In these situations, the choice of using a single flow per VC or
aggregation of flows onto a single VC remains but the problem of
heterogeneity discussed in the following section is removed.
4.2.3 Multicast Heterogeneity
As mentioned in section 2.1.3.1 and shown in figure 2, multicast
heterogeneity occurs when receivers request different qualities
of service within a single session. This means that the amount of service within a single session. This means that the amount
of requested resources differs on a per next hop basis. A related of requested resources differs on a per next hop basis. A related
type of heterogeneity occurs due to best-effort receivers. In type of heterogeneity occurs due to best-effort receivers. In
any IP multicast group, it is possible that some receivers will any IP multicast group, it is possible that some receivers will
request QoS (via RSVP) and some receivers will not. In shared request QoS (via RSVP) and some receivers will not. In shared
media, like Ethernet, receivers that have not requested resources media networks, like Ethernet, receivers that have not requested
can typically be given identical service to those that have resources can typically be given identical service to those that
without complications. This is not the case with ATM. In ATM have without complications. This is not the case with ATM. In
networks, any additional end-points of a VC must be explicitly ATM networks, any additional end-points of a VC must be
added. There may be costs associated with adding the best-effort explicitly added. There may be costs associated with adding the
receiver, and there might not be adequate resources. An RSVP best-effort receiver, and there might not be adequate resources.
over ATM solution will need to support heterogeneous receivers An RSVP over ATM solution will need to support heterogeneous
even though ATM does not currently provide such support directly. receivers even though ATM does not currently provide such support
directly.
RSVP heterogeneity is supported over ATM in the way RSVP RSVP heterogeneity is supported over ATM in the way RSVP
reservations are mapped into ATM VCs. There are four alternative reservations are mapped into ATM VCs. There are four alternative
approaches this mapping. There are multiple models for supporting approaches this mapping. There are multiple models for supporting
RSVP heterogeneity over ATM. Section 3.3.2.1 examines the RSVP heterogeneity over ATM. Section 4.2.3.1 examines the
multiple VCs per RSVP reservation (or full heterogeneity) model multiple VCs per RSVP reservation (or full heterogeneity) model
where a single reservation can be forwarded into several VCs each where a single reservation can be forwarded onto several VCs each
with a different QoS. Section 3.3.2.2 presents a limited with a different QoS. Section 4.2.3.2 presents a limited
heterogeneity model where exactly one QoS VC is used along with a heterogeneity model where exactly one QoS VC is used along with a
best effort VC. Section 3.3.2.3 examines the VC per RSVP best effort VC. Section 4.2.3.3 examines the VC per RSVP
reservation (or homogeneous) model, where each RSVP reservation reservation (or homogeneous) model, where each RSVP reservation
is mapped to a single ATM VC. Section 3.3.2.4 describes the is mapped to a single ATM VC. Section 4.2.3.4 describes the
aggregation model allowing aggregation of multiple RSVP aggregation model allowing aggregation of multiple RSVP
reservations into a single VC. Further study is being done on reservations into a single VC.
the aggregation model.
3.3.2.1 Full Heterogeneity Model 4.2.3.1 Full Heterogeneity Model
RSVP supports heterogeneous QoS, meaning that different receivers RSVP supports heterogeneous QoS, meaning that different receivers
of the same multicast group can request a different QoS. But of the same multicast group can request a different QoS. But
importantly, some receivers might have no reservation at all and importantly, some receivers might have no reservation at all and
want to receive the traffic on a best effort service basis. The want to receive the traffic on a best effort service basis. The
IP model allows receivers to join a multicast group at any time 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 on a best effort basis, and it is important that ATM as part of
the Internet continue to provide this service. We define the the Internet continue to provide this service. We define the
"full heterogeneity" model as providing a separate VC for each "full heterogeneity" model as providing a separate VC for each
distinct QoS for a multicast session including best effort and distinct QoS for a multicast session including best effort and
one or more qualities of service. one or more qualities of service.
Note that while full heterogeneity gives users exactly what they Note that while full heterogeneity gives users exactly what they
request, it requires more resources of the network than other request, it requires more resources of the network than other
possible approaches. The exact amount of bandwidth used for possible approaches. The exact amount of bandwidth used for
duplicate traffic depends on the network topology and group duplicate traffic depends on the network topology and group
membership. membership.
3.3.2.2 Limited Heterogeneity Model 4.2.3.2 Limited Heterogeneity Model
We define the "limited heterogeneity" model as the case where the We define the "limited heterogeneity" model as the case where the
receivers of a multicast session are limited to use either best receivers of a multicast session are limited to use either best
effort service or a single alternate quality of service. The effort service or a single alternate quality of service. The
alternate QoS can be chosen either by higher level protocols or alternate QoS can be chosen either by higher level protocols or
by dynamic renegotiation of QoS as described below. by dynamic renegotiation of QoS as described below.
In order to support limited heterogeneity, each ATM edge device In order to support limited heterogeneity, each ATM edge device
participating in a session would need at most two VCs. One VC participating in a session would need at most two VCs. One VC
would be a point-to-multipoint best effort service VC and would would be a point-to-multipoint best effort service VC and would
skipping to change at line 665 skipping to change at line 748
As with full heterogeneity, a disadvantage of the limited As with full heterogeneity, a disadvantage of the limited
heterogeneity scheme is that each packet will need to be heterogeneity scheme is that each packet will need to be
duplicated at the network layer and one copy sent into each of duplicated at the network layer and one copy sent into each of
the 2 VCs. Again, the exact amount of excess traffic will depend the 2 VCs. Again, the exact amount of excess traffic will depend
on the network topology and group membership. If any of the on the network topology and group membership. If any of the
existing QoS VC end-points cannot upgrade to the new QoS, then existing QoS VC end-points cannot upgrade to the new QoS, then
the new reservation fails though the resources exist for the new the new reservation fails though the resources exist for the new
receiver. receiver.
3.3.2.3 Homogeneous and Modified Homogeneous Models 4.2.3.3 Homogeneous and Modified Homogeneous Models
We define the "homogeneous" model as the case where all receivers We define the "homogeneous" model as the case where all receivers
of a multicast session use a single quality of service VC. Best- of a multicast session use a single quality of service VC. Best-
effort receivers also use the single RSVP triggered QoS VC. The effort receivers also use the single RSVP triggered QoS VC. The
single VC can be a point-to-point or point-to-multipoint as single VC can be a point-to-point or point-to-multipoint as
appropriate. The QoS VC is sized to provide the maximum resources appropriate. The QoS VC is sized to provide the maximum resources
requested by all RSVP next-hops. requested by all RSVP next-hops.
This model matches the way the current RSVP specification This model matches the way the current RSVP specification
addresses heterogeneous requests. The current processing rules addresses heterogeneous requests. The current processing rules
skipping to change at line 709 skipping to change at line 792
cases. It is possible to extend the homogeneous model to both cases. It is possible to extend the homogeneous model to both
ensure that data is always sent to best-effort receivers and also ensure that data is always sent to best-effort receivers and also
to avoid replication in the normal case. This extension is to to avoid replication in the normal case. This extension is to
add special handling for the case where a best-effort receiver add special handling for the case where a best-effort receiver
cannot be added to the QoS VC. In this case, a best effort VC cannot be added to the QoS VC. In this case, a best effort VC
can be established to any receivers that could not be added to can be established to any receivers that could not be added to
the QoS VC. Only in this special error case would senders be the QoS VC. Only in this special error case would senders be
required to replicate data. We define this approach as the required to replicate data. We define this approach as the
"modified homogeneous" model. "modified homogeneous" model.
3.3.2.4 Aggregation 4.2.3.4 Aggregation
The last scheme is the multiple RSVP reservations per VC (or The last scheme is the multiple RSVP reservations per VC (or
aggregation) model. With this model, large VCs could be set up aggregation) model. With this model, large VCs could be set up
between IP routers and hosts in an ATM network. These VCs could between IP routers and hosts in an ATM network. These VCs could
be managed much like IP Integrated Service (IIS) point-to-point be managed much like IP Integrated Service (IIS) point-to-point
links (e.g. T-1, DS-3) are managed now. Traffic from multiple links (e.g. T-1, DS-3) are managed now. Traffic from multiple
sources over multiple RSVP sessions might be multiplexed on the sources over multiple RSVP sessions might be multiplexed on the
same VC. This approach has a number of advantages. First, there same VC. This approach has a number of advantages. First, there
is typically no signalling latency as VCs would be in existence is typically no signalling latency as VCs would be in existence
when the traffic started flowing, so no time is wasted in setting when the traffic started flowing, so no time is wasted in setting
up VCs. Second, the heterogeneity problem in full over ATM has up VCs. Second, the heterogeneity problem in full over ATM has
been reduced to a solved problem. Finally, the dynamic QoS been reduced to a solved problem. Finally, the dynamic QoS
problem for ATM has also been reduced to a solved problem. This problem for ATM has also been reduced to a solved problem. This
approach can be used with point-to-point and point-to-multipoint approach can be used with point-to-point and point-to-multipoint
VCs. The problem with the aggregation approach is that the choice VCs. The problem with the aggregation approach is that the choice
of what QoS to use for which of the VCs is difficult, but is made of what QoS to use for which of the VCs is difficult, but is made
easier since the VCs can be changed as needed. The advantages of easier if the VCs can be changed as needed.
this scheme makes this approach an item for high priority study.
3.3.3 Multicast End-Point Identification 4.2.4 Multicast End-Point Identification
Implementations must be able to identify ATM end-points Implementations must be able to identify ATM end-points
participating in an IP multicast group. The ATM end-points will participating in an IP multicast group. The ATM end-points will
be IP multicast receivers and/or next-hops. Both QoS and best- be IP multicast receivers and/or next-hops. Both QoS and best-
effort end-points must be identified. RSVP next-hop information effort end-points must be identified. RSVP next-hop information
will provide QoS end-points, but not best-effort end-points. will provide QoS end-points, but not best-effort end-points.
Another issue is identifying end-points of multicast traffic Another issue is identifying end-points of multicast traffic
handled by non-RSVP capable next-hops. In this case a PATH handled by non-RSVP capable next-hops. In this case a PATH
message travels through a non-RSVP egress router on the way to message travels through a non-RSVP egress router on the way to
the next hop RSVP node. When the next hop RSVP node sends a RESV the next hop RSVP node. When the next hop RSVP node sends a RESV
skipping to change at line 765 skipping to change at line 847
the list of best-effort receivers. There is no straightforward the list of best-effort receivers. There is no straightforward
solution to uniquely identifying end-points of multicast traffic solution to uniquely identifying end-points of multicast traffic
handled by non-RSVP next hops. The preferred solution is to use handled by non-RSVP next hops. The preferred solution is to use
multicast routing protocols that support unique end-point multicast routing protocols that support unique end-point
identification. In cases where such routing protocols are identification. In cases where such routing protocols are
unavailable, all IP routers that will be used to support RSVP unavailable, all IP routers that will be used to support RSVP
over ATM should support RSVP. To ensure proper behavior, over ATM should support RSVP. To ensure proper behavior,
implementations should, by default, only establish RSVP-initiated implementations should, by default, only establish RSVP-initiated
VCs to RSVP capable end-points. VCs to RSVP capable end-points.
3.3.4 Multicast Data Distribution 4.2.5 Multicast Data Distribution
Two models are planned for IP multicast data distribution over Two models are planned for IP multicast data distribution over
ATM. In one model, senders establish point-to-multipoint VCs to ATM. In one model, senders establish point-to-multipoint VCs to
all ATM attached destinations, and data is then sent over these all ATM attached destinations, and data is then sent over these
VCs. This model is often called "multicast mesh" or "VC mesh" VCs. This model is often called "multicast mesh" or "VC mesh"
mode distribution. In the second model, senders send data over mode distribution. In the second model, senders send data over
point-to-point VCs to a central point and the central point point-to-point VCs to a central point and the central point
relays the data onto point-to-multipoint VCs that have been relays the data onto point-to-multipoint VCs that have been
established to all receivers of the IP multicast group. This established to all receivers of the IP multicast group. This
model is often referred to as "multicast server" mode model is often referred to as "multicast server" mode
skipping to change at line 788 skipping to change at line 870
In the Classical IP context, multicast server support is provided In the Classical IP context, multicast server support is provided
via MARS [5]. MARS does not currently provide a way to via MARS [5]. MARS does not currently provide a way to
communicate QoS requirements to a MARS multicast server. communicate QoS requirements to a MARS multicast server.
Therefore, RSVP over ATM implementations must, by default, Therefore, RSVP over ATM implementations must, by default,
support "mesh-mode" distribution for RSVP controlled multicast support "mesh-mode" distribution for RSVP controlled multicast
flows. When using multicast servers that do not support QoS flows. When using multicast servers that do not support QoS
requests, a sender must set the service, not global, break requests, a sender must set the service, not global, break
bit(s). bit(s).
3.3.5 Receiver Transitions 4.2.6 Receiver Transitions
When setting up a point-to-multipoint VCs there will be a time
when some receivers have been added to a QoS VC and some have
not. During such transition times it is possible to start
sending data on the newly established VC. The issue is when to
start send data on the new VC. If data is sent both on the new
VC and the old VC, then data will be delivered with proper QoS to
some receivers and with the old QoS to all receivers. This means
the QoS receivers would get duplicate data. If data is sent just
on the new QoS VC, the receivers that have not yet been added
will lose information. So, the issue comes down to whether to
send to both the old and new VCs, or to send to just one of the
VCs. In one case duplicate information will be received, in the
other some information may not be received.
This issue needs to be considered for three cases: when When setting up a point-to-multipoint VCs for multicast RSVP
establishing the first QoS VC, when establishing a VC to support sessions, there will be a time when some receivers have been
a QoS change, and when adding a new end-point to an already added to a QoS VC and some have not. During such transition
established QoS VC. times it is possible to start sending data on the newly
established VC. The issue is when to start send data on the new
VC. If data is sent both on the new VC and the old VC, then data
will be delivered with proper QoS to some receivers and with the
old QoS to all receivers. This means the QoS receivers can get
duplicate data. If data is sent just on the new QoS VC, the
receivers that have not yet been added will lose information.
So, the issue comes down to whether to send to both the old and
new VCs, or to send to just one of the VCs. In one case
duplicate information will be received, in the other some
information may not be received.
This issue needs to be considered for three cases:
- When establishing the first QoS VC
- When establishing a VC to support a QoS change
- When adding a new end-point to an already established QoS VC
The first two cases are very similar. It both, it is possible to The first two cases are very similar. It both, it is possible to
send data on the partially completed new VC, and the issue of send data on the partially completed new VC, and the issue of
duplicate versus lost information is the same. The last case is duplicate versus lost information is the same. The last case is
when an end-point must be added to an existing QoS VC. In this when an end-point must be added to an existing QoS VC. In this
case the end-point must be both added to the QoS VC and dropped case the 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 from a best-effort VC. The issue is which to do first. If the
add is first requested, then the end-point may get duplicate add is first requested, then the end-point may get duplicate
information. If the drop is requested first, then the end-point information. If the drop is requested first, then the end-point
may loose information. may loose information.
In order to ensure predictable behavior and delivery of data to In order to ensure predictable behavior and delivery of data to
all receivers, data can only be sent on a new VCs once all all receivers, data can only be sent on a new VCs once all
parties have been added. This will ensure that all data is only parties have been added. This will ensure that all data is only
delivered once to all receivers. This approach does not quite delivered once to all receivers. This approach does not quite
apply for the last case. In the last case, the add operation apply for the last case. In the last case, the add operation
should be completed first, then the drop operation. This means should be completed first, then the drop operation. This means
that receivers must be prepared to receive some duplicate packets that receivers must be prepared to receive some duplicate packets
at times of QoS setup. at times of QoS setup.
3.3.6 Dynamic QoS 4.2.7 Dynamic QoS
RSVP provides dynamic quality of service (QoS) in that the RSVP provides dynamic quality of service (QoS) in that the
resources that are requested may change at any time. There are resources that are requested may change at any time. There are
several common reasons for a change of reservation QoS. First, several common reasons for a change of reservation QoS.
an existing receiver can request a new larger (or smaller) QoS.
Second, a sender may change its traffic specification (TSpec), 1. An existing receiver can request a new larger (or smaller)
which can trigger a change in the reservation requests of the QoS.
receivers. Third, a new sender can start sending to a multicast 2. A sender may change its traffic specification (TSpec), which
group with a larger traffic specification than existing senders, can trigger a change in the reservation requests of the
triggering larger reservations. Finally, a new receiver can make receivers.
a reservation that is larger than existing reservations. If the 3. A new sender can start sending to a multicast group with a
limited heterogeneity model is being used and the merge node for larger traffic specification than existing senders, triggering
the larger reservation is an ATM edge device, a new larger larger reservations.
reservation must be set up across the ATM network. Since ATM 4. A new receiver can make a reservation that is larger than
service, as currently defined in UNI 3.x and UNI 4.0, does not existing reservations.
allow renegotiating the QoS of a VC, dynamically changing the
If the limited heterogeneity model is being used and 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 in UNI 3.x and UNI 4.0, does
not allow renegotiating the QoS of a VC, dynamically changing the
reservation means creating a new VC with the new QoS, and tearing reservation means creating a new VC with the new QoS, and tearing
down an established VC. Tearing down a VC and setting up a new VC down an established VC. Tearing down a VC and setting up a new VC
in ATM are complex operations that involve a non-trivial amount in ATM are complex operations that involve a non-trivial amount
of processor time, and may have a substantial latency. There are of processing time, and may have a substantial latency. There are
several options for dealing with this mismatch in service. A several options for dealing with this mismatch in service. A
specific approach will need to be a part of any RSVP over ATM specific approach will need to be a part of any RSVP over ATM
solution. solution.
The default method for supporting changes in RSVP reservations is The default method for supporting changes in RSVP reservations is
to attempt to replace an existing VC with a new appropriately to attempt to replace an existing VC with a new appropriately
sized VC. During setup of the replacement VC, the old VC must be sized VC. During setup of the replacement VC, the old VC must be
left in place unmodified. The old VC is left unmodified to left in place unmodified. The old VC is left unmodified to
minimize interruption of QoS data delivery. Once the replacement minimize interruption of QoS data delivery. Once the replacement
VC is established, data transmission is shifted to the new VC, VC is established, data transmission is shifted to the new VC,
skipping to change at line 909 skipping to change at line 996
larger than any existing reservation, both dynamic QoS and larger than any existing reservation, both dynamic QoS and
heterogeneity need to be addressed. A key issue is whether to heterogeneity need to be addressed. A key issue is whether to
first add the new next-hop or to change to the new QoS. This is a first add the new next-hop or to change to the new QoS. This is a
fairly straight forward special case. Since the older, smaller fairly straight forward special case. Since the older, smaller
reservation does not support the new next-hop, the dynamic QoS reservation does not support the new next-hop, the dynamic QoS
process should be initiated first. Since the new QoS is only process should be initiated first. Since the new QoS is only
needed by the new next-hop, it should be the first end-point of needed by the new next-hop, it should be the first end-point of
the new VC. This way signalling is minimized when the setup to the new VC. This way signalling is minimized when the setup to
the new next-hop fails. the new next-hop fails.
3.3.7 Short-Cuts 4.2.8 Short-Cuts
Short-cuts [4] allow ATM attached routers and hosts to directly Short-cuts [4] allow ATM attached routers and hosts to directly
establish point-to-point VCs across LIS boundaries, i.e., the VC establish point-to-point VCs across LIS boundaries, i.e., the VC
end-points are on different IP subnets. The ability for short- end-points are on different IP subnets. The ability for short-
cuts and RSVP to interoperate has been raised as a general cuts and RSVP to interoperate has been raised as a general
question. The area of concern is the ability to handle question. An area of concern is the ability to handle asymmetric
asymmetric short-cuts. Specifically how RSVP can handle the case short-cuts. Specifically how RSVP can handle the case where a
where a downstream short-cut may not have a matching upstream downstream short-cut may not have a matching upstream short-cut.
short-cut. In this case, PATH and RESV messages following In this case, PATH and RESV messages following different paths.
different paths.
Examination of RSVP shows that the protocol already includes Examination of RSVP shows that the protocol already includes
mechanisms that will support short-cuts. The mechanism is the mechanisms that will support short-cuts. The mechanism is the
same one used to support RESV messages arriving at the wrong same one used to support RESV messages arriving at the wrong
router and the wrong interface. The key aspect of this mechanism router and the wrong interface. The key aspect of this mechanism
is RSVP only processing messages that arrive at the proper is RSVP only processing messages that arrive at the proper
interface and RSVP forwarding of messages that arrive on the interface and RSVP forwarding of messages that arrive on the
wrong interface. The proper interface is indicated in the NHOP wrong interface. The proper interface is indicated in the NHOP
object of the message. So, existing RSVP mechanisms will support object of the message. So, existing RSVP mechanisms will support
asymmetric short-cuts. The short-cut model of VC establishment asymmetric short-cuts. The short-cut model of VC establishment
skipping to change at line 944 skipping to change at line 1030
The key issue to be addressed by any RSVP over ATM solution is The key issue to be addressed by any RSVP over ATM solution is
when to establish a short-cut for a QoS data flow. The default when to establish a short-cut for a QoS data flow. The default
behavior is to simply follow best-effort traffic. When a short- behavior is to simply follow best-effort traffic. When a short-
cut has been established for best-effort traffic to a destination cut has been established for best-effort traffic to a destination
or next-hop, that same end-point should be used when setting up or next-hop, that same end-point should be used when setting up
RSVP triggered VCs for QoS traffic to the same destination or RSVP triggered VCs for QoS traffic to the same destination or
next-hop. This will happen naturally when PATH messages are next-hop. This will happen naturally when PATH messages are
forwarded over the best-effort short-cut. Note that in this forwarded over the best-effort short-cut. Note that in this
approach when best-effort short-cuts are never established, RSVP approach when best-effort short-cuts are never established, RSVP
triggered QoS short-cuts will also never be established. triggered QoS short-cuts will also never be established. More
study is expected in this area.
3.3.8 VC Teardown 4.2.9 VC Teardown
RSVP can identify from either explicit messages or timeouts when RSVP can identify from either explicit messages or timeouts when
a data VC is no longer needed. Therefore, data VCs set up to a data VC is no longer needed. Therefore, data VCs set up to
support RSVP controlled flows should only be released at the support RSVP controlled flows should only be released at the
direction of RSVP. VCs must not be timed out due to inactivity by direction of RSVP. VCs must not be timed out due to inactivity by
either the VC initiator or the VC receiver. This conflicts with either the VC initiator or the VC receiver. This conflicts with
VCs timing out as described in RFC 1755 [11], section 3.4 on VC VCs timing out as described in RFC 1755 [11], section 3.4 on VC
Teardown. RFC 1755 recommends tearing down a VC that is inactive Teardown. RFC 1755 recommends tearing down a VC that is inactive
for a certain length of time. Twenty minutes is recommended. This for a certain length of time. Twenty minutes is recommended. This
timeout is typically implemented at both the VC initiator and the timeout is typically implemented at both the VC initiator and the
skipping to change at line 975 skipping to change at line 1062
VC being torn down, the RSVP daemon must be notified, so a VC being torn down, the RSVP daemon must be notified, so a
reservation failure message can be sent. reservation failure message can be sent.
For VCs initiated at the request of RSVP, the configurable For VCs initiated at the request of RSVP, the configurable
inactivity timer mentioned in [11] must be set to "infinite". inactivity timer mentioned in [11] must be set to "infinite".
Setting the inactivity timer value at the VC initiator should not Setting the inactivity timer value at the VC initiator should not
be problematic since the proper value can be relayed internally be problematic since the proper value can be relayed internally
at the originator. Setting the inactivity timer at the VC at the originator. Setting the inactivity timer at the VC
receiver is more difficult, and would require some mechanism to receiver is more difficult, and would require some mechanism to
signal that an incoming VC was RSVP initiated. To avoid this signal that an incoming VC was RSVP initiated. To avoid this
complexity and to conform to \cite{kn:1755up}, implementations complexity and to conform to [11] implementations must not use an
must not use an inactivity timer to clear received connections. inactivity timer to clear received connections.
3.4 RSVP Control Management 4.3 RSVP Control Management
One last important issue is providing a data path for the RSVP One last important issue is providing a data path for the RSVP
messages themselves. There are two main types of messages in messages themselves. There are two main types of messages in
RSVP, PATH and RESV. PATH messages are sent to a multicast RSVP, PATH and RESV. PATH messages are sent to unicast or
address, while RESV messages are sent to a unicast address. Other multicast addresses, while RESV messages are sent only to unicast
addresses. Other RSVP messages are handled similar to either PATH
1 1
RSVP messages are handled similar to either PATH or RESV . So or RESV . So ATM VCs used for RSVP signalling messages need to
ATM VCs used for RSVP signalling messages need to provide both provide both unicast and multicast functionality. There are
unicast and multicast functionality. There are several different several different approaches for how to assign VCs to use for
approaches for how to assign VCs to use for RSVP signalling RSVP signalling messages.
messages.
The main approaches are: The main approaches are:
- use same VC as data - use same VC as data
- single VC per session - single VC per session
- single point-to-multipoint VC multiplexed among sessions - single point-to-multipoint VC multiplexed among sessions
1
This can be slightly more complicated for RERR messages
- multiple point-to-point VCs multiplexed among sessions - multiple point-to-point VCs multiplexed among sessions
There are several different issues that affect the choice of how There are several different issues that affect the choice of how
to assign VCs for RSVP signalling. One issue is the number of to assign VCs for RSVP signalling. One issue is the number of
additional VCs needed for RSVP signalling. Related to this issue additional VCs needed for RSVP signalling. Related to this issue
is the degree of multiplexing on the RSVP VCs. In general more is the degree of multiplexing on the RSVP VCs. In general more
multiplexing means less VCs. An additional issue is the latency multiplexing means fewer VCs. An additional issue is the latency
in dynamically setting up new RSVP signalling VCs. A final issue in dynamically setting up new RSVP signalling VCs. A final issue
is complexity of implementation. The remainder of this section is complexity of implementation. The remainder of this section
discusses the issues and tradeoffs among these different discusses the issues and tradeoffs among these different
approaches and suggests guidelines for when to use which approaches and suggests guidelines for when to use which
alternative. alternative.
3.4.1 Mixed data and control traffic 1
This can be slightly more complicated for RERR messages
4.3.1 Mixed data and control traffic
In this scheme RSVP signalling messages are sent on the same VCs 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 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 no additional VCs are needed beyond what is needed for the data
traffic. An additional advantage is that there is no ATM traffic. An additional advantage is that there is no ATM
signalling latency for PATH messages (which follow the same signalling latency for PATH messages (which follow the same
routing as the data messages). However there can be a major routing as the data messages). However there can be a major
problem when data traffic on a VC is nonconforming. With problem when data traffic on a VC is nonconforming. With
nonconforming traffic, RSVP signalling messages may be dropped. nonconforming traffic, RSVP signalling messages may be dropped.
While RSVP is resilient to a moderate level of dropped messages, While RSVP is resilient to a moderate level of dropped messages,
excessive drops would lead to repeated tearing down and re- excessive drops would lead to repeated tearing down and re-
establishing QoS VCs, a very undesirable behavior for ATM. Due to establishing of QoS VCs, a very undesirable behavior for ATM. Due
these problems, this is not a good choice for providing RSVP to these problems, this may not be a good choice for providing
signalling messages, even though the number of VCs needed for RSVP signalling messages, even though the number of VCs needed
this scheme is minimized. One variation of this scheme is to use for this scheme is minimized. One variation of this scheme is to
the best effort data path for signalling traffic. In this scheme, use the best effort data path for signalling traffic. In this
there is no issue with nonconforming traffic, but there is an scheme, there is no issue with nonconforming traffic, but there
issue with congestion in the ATM network. RSVP provides some is an issue with congestion in the ATM network. RSVP provides
resiliency to message loss due to congestion, but RSVP control some resiliency to message loss due to congestion, but RSVP
messages should be offered a preferred class of service. A control messages should be offered a preferred class of service.
related variation of this scheme that is hopeful but requires A related variation of this scheme that is hopeful but requires
further study is to have a packet scheduling algorithm (before further study is to have a packet scheduling algorithm (before
entering the ATM network) that gives priority to the RSVP entering the ATM network) that gives priority to the RSVP
signalling traffic. This can be difficult to do at the IP layer. signalling traffic. This can be difficult to do at the IP layer.
3.4.1.1 Single RSVP VC per RSVP Reservation 4.3.1.1 Single RSVP VC per RSVP Reservation
In this scheme, there is a parallel RSVP signalling VC for each In this scheme, there is a parallel RSVP signalling VC for each
RSVP reservation. This scheme results in twice the minimum number RSVP reservation. This scheme results in twice the number of VCs,
of VCs, but means that RSVP signalling messages have the but means that RSVP signalling messages have the advantage of a
advantage of a separate VC. This separate VC means that RSVP separate VC. This separate VC means that RSVP signalling messages
signalling messages have their own traffic contract and compliant have their own traffic contract and compliant signalling messages
signalling messages are not subject to dropping due to other are not subject to dropping due to other noncompliant traffic
noncompliant traffic (such as can happen with the scheme in (such as can happen with the scheme in section 4.3.1). The
section 3.4.1). The advantage of this scheme is its simplicity - advantage of this scheme is its simplicity - whenever a data VC
whenever a data VC is created, a separate RSVP signalling VC is is created, a separate RSVP signalling VC is created. The
created. The disadvantage of the extra VC is that extra ATM disadvantage of the extra VC is that extra ATM signalling needs
signalling needs to be done. Additionally, this scheme requires to be done. Additionally, this scheme requires twice the minimum
twice the minimum number of VCs and also additional latency, but number of VCs and also additional latency, but is quite simple.
is quite simple.
3.4.1.2 Multiplexed point-to-multipoint RSVP VCs 4.3.1.2 Multiplexed point-to-multipoint RSVP VCs
In this scheme, there is a single point-to-multipoint RSVP In this scheme, there is a single point-to-multipoint RSVP
signalling VC for each unique ingress router and unique set of signalling VC for each unique ingress router and unique set of
egress routers. This scheme allows multiplexing of RSVP egress routers. This scheme allows multiplexing of RSVP
signalling traffic that shares the same ingress router and the signalling traffic that shares the same ingress router and the
same egress routers. This can save on the number of VCs, by same egress routers. This can save on the number of VCs, by
multiplexing, but there are problems when the destinations of the multiplexing, but there are problems when the destinations of the
multiplexed point-to-multipoint VCs are changing. Several multiplexed point-to-multipoint VCs are changing. Several
alternatives exist in these cases, that have applicability in alternatives exist in these cases, that have applicability in
different situations. First, when the egress routers change, the different situations. First, when the egress routers change, the
skipping to change at line 1085 skipping to change at line 1170
network, but is always less than the number used with the Single network, but is always less than the number used with the Single
RSVP VC per data VC. In addition, existing best effort data VCs RSVP VC per data VC. In addition, existing best effort data VCs
could be used for RSVP signalling. Reusing best effort VCs saves could be used for RSVP signalling. Reusing best effort VCs saves
on the number of VCs at the cost of higher probability of RSVP on the number of VCs at the cost of higher probability of RSVP
signalling packet loss. One possible place where this scheme signalling packet loss. One possible place where this scheme
will work well is in the core of the network where there is the will work well is in the core of the network where there is the
most opportunity to take advantage of the savings due to most opportunity to take advantage of the savings due to
multiplexing. The exact savings depend on the patterns of multiplexing. The exact savings depend on the patterns of
traffic and the topology of the ATM network. traffic and the topology of the ATM network.
3.4.1.3 Multiplexed point-to-point RSVP VCs 4.3.1.3 Multiplexed point-to-point RSVP VCs
In this scheme, multiple point-to-point RSVP signalling VCs are In this scheme, multiple point-to-point RSVP signalling VCs are
used for a single point-to-multipoint data VC. This scheme used for a single point-to-multipoint data VC. This scheme
allows multiplexing of RSVP signalling traffic but requires the allows multiplexing of RSVP signalling traffic but requires the
same traffic to be sent on each of several VCs. This scheme is same traffic to be sent on each of several VCs. This scheme is
quite flexible and allows a large amount of multiplexing. quite flexible and allows a large amount of multiplexing.
Since point-to-point VCs can set up a reverse channel at the same 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 time as setting up the forward channel, this scheme could save
substantially on signalling cost. In addition, signalling substantially on signalling cost. In addition, signalling
skipping to change at line 1109 skipping to change at line 1194
network. This point-to-point scheme would work well in the core network. This point-to-point scheme would work well in the core
of the network where there is much opportunity for multiplexing. of the network where there is much opportunity for multiplexing.
Also in the core of the network, RSVP VCs can stay permanently Also in the core of the network, RSVP VCs can stay permanently
established either as Permanent Virtual Circuits (PVCs) or as established either as Permanent Virtual Circuits (PVCs) or as
long lived Switched Virtual Circuits (SVCs). The number of VCs in long lived Switched Virtual Circuits (SVCs). The number of VCs in
this scheme will depend on traffic patterns, but in the core of a 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 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 IP nodes in the network. In the core of the network, this will
typically be small compared to the total number of VCs. typically be small compared to the total number of VCs.
3.4.2 QoS for RSVP VCs 4.3.2 QoS for RSVP VCs
There is an issue for what QoS, if any, to assign to the RSVP
VCs. 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
RSVP packet loss on the best effort VC also. Additional
experimentation is needed in this area.
Implementations must, by default, send RSVP control (messages)
over the best effort data path, see figure. This approach
minimizes VC requirements since the best effort data path will
need to exist in order for RSVP sessions to be established and in
order for RSVP reservations to be initiated.
The specific best effort paths that will be used by RSVP are: for
unicast, the same VC used to reach the unicast destination; and
for multicast, the same VC that is used for best effort traffic
destined to the IP multicast group. Note that there may be
another best effort VC that is used to carry session data
traffic.
The disadvantage of this approach is that best effort VCs may not There is an issue of what QoS, if any, to assign to the RSVP
provide the reliability that RSVP needs. However the best-effort signalling VCs. For other RSVP VC schemes, a QoS (possibly best
path is expected to satisfy RSVP reliability requirements in most effort) will be needed. What QoS to use partially depends on the
networks. Especially since RSVP allows for a certain amount of expected level of multiplexing that is being done on the VCs, and
packet loss without any loss of state synchronization. In all the expected reliability of best effort VCs. Since RSVP
cases, RSVP control traffic should be offered a preferred class signalling is infrequent (typically every 30 seconds), only a
of service. 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 RSVP packet loss on the best effort VC
also. Additional experimentation is needed in this area.
4. Encapsulation 5. Encapsulation
Since RSVP is a signalling protocol used to control flows of IP Since RSVP is a signalling protocol used to control flows of IP
data packets, encapsulation for both RSVP packets and associated data packets, encapsulation for both RSVP packets and associated
IP data packets must be defined. There are currently two IP data packets must be defined. There are currently two
encapsulation options for running IP over ATM, RFC 1483 and LANE. encapsulation options for running IP over ATM, RFC 1483 and LANE.
There is also the possibility of future encapsulation options, There is also the possibility of future encapsulation options,
such as MPOA [18]. The first option is described in RFC 1483 such as MPOA[18]. The first option is described in RFC 1483[19]
[19] and is currently used for "Classical" IP over ATM and NHRP. and is currently used for "Classical" IP over ATM and NHRP.
The second option is LAN Emulation, as described in [17]. LANE The second option is LAN Emulation, as described in [17]. LANE
encapsulation does not currently include a QoS signalling encapsulation does not currently include a QoS signalling
interface. If LANE encapsulation is needed, LANE QoS signalling interface. If LANE encapsulation is needed, LANE QoS signalling
would first need to be defined by the ATM Forum. It is possible would first need to be defined by the ATM Forum. It is possible
that LANE 2.0 will include the required QoS support. that LANE 2.0 will include the required QoS support.
The default behavior for implementations must be to use a 6. Security Considerations
consistent encapsulation scheme for all IP over ATM packets.
This includes RSVP packets and associated IP data packets. So,
encapsulation used on QoS data VCs and related control VCs must,
by default, be the same as used by best-effort VCs.
5. Security Considerations
The same considerations stated in [1] and [11] apply to this The same considerations stated in [1] and [11] apply to this
document. There are no additional security issues raised in this document. There are no additional security issues raised in this
document. document.
6. References 7. References
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. Resource
Jamin. Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification. Internet Draft, draft-ietf-rsvp-spec-14. Specification RFC 2209, September 1997.
November 1996. [2] M. Borden, E. Crawley, B. Davie, S. Batsell. Integration of
[2] M. Borden, E. Crawley, B. Davie, S. Batsell.
Integration of
Real-time Services in an IP-ATM Network Architecture. Real-time Services in an IP-ATM Network Architecture.
Request for Comments (Informational) RFC 1821, August 1995. Request for Comments (Informational) RFC 1821, August 1995.
[3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A [3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A Framework
Framework
Document. Request for Comments (Informational), RFC 1932, Document. Request for Comments (Informational), RFC 1932,
April 1996. April 1996.
[4] D. Katz, D. Piscitello, B. Cole, J. Luciani. [4] D. Katz, D. Piscitello, B. Cole, J. Luciani. NBMA Next Hop
NBMA Next Hop
Resolution Protocol (NHRP). Internet Draft, draft-ietf-rolc- Resolution Protocol (NHRP). Internet Draft, draft-ietf-rolc-
nhrp-11.txt, March 1997. nhrp-12.txt, October 1997.
[5] G. Armitage, Support for Multicast over UNI [5] G. Armitage, Support for Multicast over UNI 3.0/3.1 based ATM
3.0/3.1 based ATM
Networks. RFC 2022. November 1996. Networks. RFC 2022. November 1996.
[6] S. Shenker, C. Partridge. Specification of [6] S. Shenker, C. Partridge. Specification of Guaranteed Quality
Guaranteed Quality of Service. RFC 2212, September 1997.
of Service. Internet Draft, draft-ietf-intserv-guaranteed- [7] J. Wroclawski. Specification of the Controlled-Load Network
svc-07.txt, February 1997. Element Service. RFC 2211, September 1997.
[7] J. Wroclawski. Specification of the [8] ATM Forum. ATM User-Network Interface Specification Version
Controlled-Load Network
Element Service. Internet Draft, draft-ietf-intserv-ctrl-
load-svc-05.txt, May 1997.
[8] ATM Forum. ATM User-Network Interface
Specification Version
3.0. Prentice Hall, September 1993 3.0. Prentice Hall, September 1993
[9] ATM Forum. ATM User Network Interface (UNI) [9] ATM Forum. ATM User Network Interface (UNI) Specification
Specification
Version 3.1. Prentice Hall, June 1995. Version 3.1. Prentice Hall, June 1995.
[10]M . Laubach, Classical IP and ARP over ATM.
Request for [10] M. Laubach, Classical IP and ARP over ATM. Request for
Comments (Proposed Standard) RFC1577, January 1994. Comments (Proposed Standard) RFC1577, January 1994.
[11]M . Perez, A. Mankin, E. Hoffman, G. Grossman, [11] M. Perez, A. Mankin, E. Hoffman, G. Grossman, A. Malis, ATM
A. Malis, ATM
Signalling Support for IP over ATM, Request for Comments Signalling Support for IP over ATM, Request for Comments
(Proposed Standard) RFC1755, February 1995. (Proposed Standard) RFC1755, February 1995.
[12]S . Herzog. RSVP Extensions for Policy [12] S. Herzog. RSVP Extensions for Policy Control. Internet
Control. Internet
Draft, draft-ietf-rsvp-policy-ext-02.txt, April 1997. Draft, draft-ietf-rsvp-policy-ext-02.txt, April 1997.
[13]S . Herzog. Local Policy Modules (LPM): Policy [13] S. Herzog. Local Policy Modules (LPM): Policy Control for
Control for
RSVP, Internet Draft, draft-ietf-rsvp-policy-lpm-01.txt, RSVP, Internet Draft, draft-ietf-rsvp-policy-lpm-01.txt,
November 1996. November 1996.
[14] M. Borden, M. Garrett. Interoperation of Controlled-Load and
[14]M . Borden, M. Garrett. Interoperation of
Controlled-Load and
Guaranteed Service with ATM, Internet Draft, draft-ietf- Guaranteed Service with ATM, Internet Draft, draft-ietf-
issll-atm-mapping-02.txt, March 1997. issll-atm-mapping-03.txt, August 1997.
[15]L . Berger. RSVP over ATM Implementation [15] L. Berger. RSVP over ATM Implementation Requirements.
Requirements.
Internet Draft, draft-ietf-issll-atm-imp-req-00.txt, July Internet Draft, draft-ietf-issll-atm-imp-req-00.txt, July
1997. 1997.
[16]L . Berger. RSVP over ATM Implementation [16] L. Berger. RSVP over ATM Implementation Guidelines. Internet
Guidelines. Internet
Draft, draft-ietf-issll-atm-imp-guide-01.txt, July 1997. Draft, draft-ietf-issll-atm-imp-guide-01.txt, July 1997.
[17]A TM Forum Technical Committee. LAN Emulation [17] ATM Forum Technical Committee. LAN Emulation over ATM,
over ATM,
Version 1.0 Specification, af-lane-0021.000, January 1995. Version 1.0 Specification, af-lane-0021.000, January 1995.
[18]A TM Forum Technical Committee. Baseline Text [18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-
for MPOA, af-95-
0824r9, September 1996. 0824r9, September 1996.
[19]J . Heinanen. Multiprotocol Encapsulation over [19] J. Heinanen. Multiprotocol Encapsulation over ATM Adaptation
ATM Adaptation
Layer 5, RFC 1483, July 1993. Layer 5, RFC 1483, July 1993.
[20]A TM Forum Technical Committee. LAN Emulation [20] ATM Forum Technical Committee. LAN Emulation over ATM Version
over ATM Version 2 - LUNI Specification, December 1996.
2 - LUNI Specification, December 1996. [zzz Need to update
this ref.]
[21]A TM Forum Technical Committee. Traffic Management [21]A TM Forum Technical Committee. Traffic Management
Specification v4.0, af-tm-0056.000, April 1996. Specification v4.0, af-tm-0056.000, April 1996.
[22]R . Callon, et al. A Framework for [22] R. Callon, et al. A Framework for Multiprotocol Label
Multiprotocol Label Switching, Internet Draft, draft-ietf-mpls-framework-01.txt,
Switching, Internet Draft, draft-ietf-mpls-framework-00.txt, July 1997.
May 1997. [23] B. Rajagopalan, R. Nair, H. Sandick, E. Crawley. A Framework
[23]B . Rajagopalan, R. Nair, H. Sandick, E.
Crawley. A Framework
for QoS-based Routing in the Internet, Internet Draft, draft- for QoS-based Routing in the Internet, Internet Draft, draft-
ietf-qosr-framework-00.txt, March 1997. ietf-qosr-framework-01.txt, July 1997.
[24] ITU-T. Digital Subscriber Signaling System No. 2-Connection
7. Author's Address modification: Peak cell rate modification by the connection
owner, ITU-T Recommendation Q.2963.1, July 1996.
[25] ITU-T. Digital Subscriber Signaling System No. 2-Connection
characteristics negotiation during call/connection
establishment phase, ITU-T Recommendation Q.2962, July 1996.
[26] ATM Forum Technical Committee. Private Network-Network
8. Author's Address
Eric S. Crawley Eric S. Crawley
Gigapacket Networks Argon Networks
25 Porter Road 25 Porter Road
Littleton, Ma 01460 Littleton, Ma 01460
+1 508 486-0665 +1 508 486-0665
esc@gigapacket.com esc@argon-net.com
Lou Berger Lou Berger
FORE Systems FORE Systems
6905 Rockledge Drive 6905 Rockledge Drive
Suite 800 Suite 800
Bethesda, MD 20817 Bethesda, MD 20817
+1 301 571-2534 +1 301 571-2534
lberger@fore.com lberger@fore.com
Steven Berson Steven Berson
USC Information Sciences Institute USC Information Sciences Institute
 End of changes. 106 change blocks. 
350 lines changed or deleted 388 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/