draft-ietf-issll-atm-framework-02.txt   draft-ietf-issll-atm-framework-03.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-02.txt L. Berger draft-ietf-issll-atm-framework-03.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
(Bay Networks) (Bay Networks)
J. Krawczyk J. Krawczyk
(ArrowPoint Communications) (ArrowPoint Communications)
February 9, 1998 April 2, 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 Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts). documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress." "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ds.internic.net (US East Coast), nic.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Eur4ope), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract Abstract
This document outlines the issues and framework related to providing IP This document outlines the issues and framework related to providing IP
Integrated Services with RSVP over ATM. It provides an overall approach Integrated Services with RSVP over ATM. It provides an overall approach
to the problem(s) and related issues. These issues and problems are to to the problem(s) and related issues. These issues and problems are to
be addressed in further documents from the ISATM subgroup of the ISSLL be addressed in further documents from 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-ietf- This document is the merger of two previous documents, draft-ietf-
skipping to change at line 62 skipping to change at line 64
The Internet currently has one class of service normally referred to as The Internet currently has one class of service normally referred to as
"best effort." This service is typified by first-come, first-serve "best effort." This service is typified by first-come, first-serve
scheduling at each hop in the network. Best effort service has worked scheduling at each hop in the network. Best effort service has worked
well for electronic mail, World Wide Web (WWW) access, file transfer well for electronic mail, World Wide Web (WWW) access, file transfer
(e.g. ftp), etc. For real-time traffic such as voice and video, the (e.g. ftp), etc. For real-time traffic such as voice and video, the
current Internet has performed well only across unloaded portions of current Internet has performed well only across unloaded portions of
the network. In order to provide quality real-time traffic, new the network. In order to provide quality real-time traffic, new
classes of service and a QoS signalling protocol are being introduced classes of service and a QoS signalling protocol are being introduced
in the Internet [1,6,7], while retaining the existing best effort in the Internet [1,6,7], while retaining the existing best effort
service. The QoS signalling protocol is RSVP [1], the Resource service. The QoS signalling protocol is RSVP [1], the Resource
7ReSerVation Protocol and the service models ReSerVation 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 Quality request a point-to-point Virtual Circuit (VC) with a specified Quality
of Service (QoS). An additional feature of ATM technology is the of Service (QoS). An additional feature of ATM technology is the
ability to request point-to-multipoint VCs with a specified QoS. ability to request point-to-multipoint VCs with a specified QoS.
Point-to-multipoint VCs allows leaf nodes to be added and removed from Point-to-multipoint VCs allows leaf nodes to be added and removed from
the VC dynamically and so provides a mechanism for supporting IP the VC dynamically and so provides a mechanism for supporting IP
multicast. It is only natural that RSVP and the Internet Integrated multicast. It is only natural that RSVP and the Internet Integrated
Services (IIS) model would like to utilize the QoS properties of any Services (IIS) model would like to utilize the QoS properties of any
underlying link layer including ATM, and this draft concentrates on underlying link layer including ATM, and this draft concentrates on
skipping to change at line 478 skipping to change at line 479
strict mapping problematic. So, a set of workable mappings that can be strict mapping problematic. So, a set of workable mappings that can be
applied to different network requirements and scenarios is needed as applied to different network requirements and scenarios is needed as
long as the mappings can satisfy the needs of the service model(s). long as the mappings can satisfy the needs of the service model(s).
2.5 Directly Connected ATM Hosts 2.5 Directly Connected ATM Hosts
It is obvious that the needs of hosts that are directly connected to It is obvious that the needs of hosts that are directly connected 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 has Functionality for RSVP over ATM must not assume that an ATM host has
all the functionality of a router, but such things as MARS and NHRP all the functionality of a router, but such things as MARS and NHRP
clients would be worthwhile features. A host must managed VCs just clients would be worthwhile features. A host must manage VCs just like
like any other ATM sender or receiver as described later in section 4. any other ATM sender or receiver as described later in section 4.
2.6 Accounting and Policy Issues 2.6 Accounting and Policy Issues
Since RSVP and IntServ create classes of preferential service, some Since RSVP and IntServ create classes of preferential service, some
form of administrative control and/or cost allocation is needed to form of administrative control and/or cost allocation is needed to
control access. There are certain types of policies specific to ATM control access. There are certain types of policies specific to ATM
and IP over ATM that need to be studied to determine how they and IP over ATM that need to be studied to determine how they
interoperate with the IP and IntServ policies being developed. Typical interoperate with the IP and IntServ policies being developed. Typical
IP policies would be that only certain users are allowed to make IP policies would be that only certain users are allowed to make
reservations. This policy would translate well to IP over ATM due to reservations. This policy would translate well to IP over ATM due to
skipping to change at line 1001 skipping to change at line 1002
initiated. To avoid this complexity and to conform to [11] initiated. To avoid this complexity and to conform to [11]
implementations must not use an inactivity timer to clear received implementations must not use an 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 messages One last important issue is providing a data path for the RSVP messages
themselves. There are two main types of messages in RSVP, PATH and themselves. There are two main types of messages in RSVP, PATH and
RESV. PATH messages are sent to unicast or multicast addresses, while RESV. PATH messages are sent to unicast or multicast addresses, while
RESV messages are sent only to unicast addresses. Other RSVP messages RESV messages are sent only to unicast addresses. Other RSVP messages
1 are handled similar to either PATH or RESV, although this might be more
are handled similar to either PATH or RESV . So ATM VCs used for RSVP complicated for RERR messages. So ATM VCs used for RSVP signalling
signalling messages need to provide both unicast and multicast messages need to provide both unicast and multicast functionality.
functionality. There are several different approaches for how to assign There are several different approaches for how to assign VCs to use for
VCs to use for RSVP signalling messages. 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 to There are several different issues that affect the choice of how to
assign VCs for RSVP signalling. One issue is the number of additional assign VCs for RSVP signalling. One issue is the number of additional
VCs needed for RSVP signalling. Related to this issue is the degree of VCs needed for RSVP signalling. Related to this issue is the degree of
skipping to change at line 1030 skipping to change at line 1031
these different approaches and suggests guidelines for when to use these different approaches and suggests guidelines for when to use
which alternative. which alternative.
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 as is In this scheme RSVP signalling messages are sent on the same VCs as is
the data traffic. The main advantage of this scheme is that no the data traffic. The main advantage of this scheme is that no
additional VCs are needed beyond what is needed for the data traffic. additional VCs are needed beyond what is needed for the data traffic.
An additional advantage is that there is no ATM signalling latency for An additional advantage is that there is no ATM signalling latency for
PATH messages (which follow the same routing as the data messages). PATH messages (which follow the same routing as the data messages).
However there can be a major problem when data traffic on a VC is However there can be a major problem when data traffic on a VC is
nonconforming. With nonconforming traffic, RSVP signalling messages may nonconforming. With nonconforming traffic, RSVP signalling messages may
be dropped. While RSVP is resilient to a moderate level of dropped be dropped. While RSVP is resilient to a moderate level of dropped
messages, excessive drops would lead to repeated tearing down and re- messages, 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 to
these problems, this may not be a good choice for providing RSVP these problems, this may not be a good choice for providing RSVP
signalling messages, even though the number of VCs needed for this signalling messages, even though the number of VCs needed for this
scheme is minimized. One variation of this scheme is to use the best scheme is minimized. One variation of this scheme is to use the best
1
This can be slightly more complicated for RERR messages
effort data path for signalling traffic. In this scheme, there is no effort data path for signalling traffic. In this scheme, there is no
issue with nonconforming traffic, but there is an issue with congestion issue with nonconforming traffic, but there is an issue with congestion
in the ATM network. RSVP provides some resiliency to message loss due in the ATM network. RSVP provides some resiliency to message loss due
to congestion, but RSVP control messages should be offered a preferred to congestion, but RSVP control messages should be offered a preferred
class of service. A related variation of this scheme that is hopeful class of service. A related variation of this scheme that is hopeful
but requires further study is to have a packet scheduling algorithm but requires further study is to have a packet scheduling algorithm
(before entering the ATM network) that gives priority to the RSVP (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
 End of changes. 8 change blocks. 
17 lines changed or deleted 17 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/