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