No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
„A QoS Guaranteeing Framework for the Integration of IP and ATM in DIANA “
Abstract
Recently, the Internet community has been working on extensions to the current Internet protocol suite in order to enable service guarantees or differentiation. However, standardised solutions to integrate IP and ATM still are restricted to best-effort service. Therefore, this paper deals with a framework for QoS based interworking between IP and ATM. Network element state with QoS attributes is thereby controlled by RSVP and ATM and an appropriate translation from and to each other. Signalling and traffic control issues related with that translation are of particular concern for this paper. Moreover, the building blocks of an interworking unit prototype architecture as planned by the ACTS DIANA project are presented.
ResearchGate has not been able to resolve any citations for this publication.
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. Internet Draft RSVP Specification May 1996 Contents Braden, Zhang, et al. Expires November 6, 1996 [Page 2] Internet Draft RSVP Specification May 1996 1 Introduction This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93,ISInt93]. The RSVP protocol is used by a host, on behalf of an application data stream, to request a specific quality of service (QoS) from the network. The RSVP protocol is also used by routers to deliver QoS requests to all nodes along the path(s) of the data stream and to establish and maintain state to provide the requested service. RSVP requests will generally, although not necessarily, result in resources being reserved along the ...
This document describes issues and approaches related to aggregationof QoS requests, when RSVP [BZB+97] is the protocol used to conveysuch requests. Aggregation is an important component to providescalable QoS solutions, especially in the core of the backbonewhere the sheer number of flows mandates some form of aggregation.However, aggregation needs to be provided without impacting theability to provide end-to-end QoS guarantees to individual flows.In this document, we review some of ...
and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other 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 "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before April, 1999. Distribution of this draft is unlimited. This document provides a general description of issues related to the definition, configuration and management of services enabled by the differentiated services architecture [DSARCH]. This document should be read along with its companion documents, the differentiated services architecture [DSARCH] and the definition of the DS field [DSHEAD]. A glossary of specialist terms used may be found in [DSARCH].
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. Internet Draft RSVP V1 Specification June 1997 Contents 1 Introduction 4 1.1 Data Flows : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 1.2 Reservation Model : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 1.3 Reservation Styles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10 1.4 Examples of Styles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2 RSVP Protocol Mechanisms 17 2.1 RSVP Messages : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17 2.2 Merging Flowspecs : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 2.3 Soft State : : : : : : : ...
The growing use of multimedia communication applications, with
specific bandwidth and real-time delivery requirements has created the
need for an integrated services Internet in which traditional
best-effort datagram delivery can coexist with additional enhanced
quality of service (QoS) delivery classes. Such classes provide data
flows with QoS commitments with regard to bandwidth, packet loss, and
delay through the reservation of network resources along the data path,
which can be done using the Resource Reservation Protocol (RSVP). This
article is a tutorial on how RSVP can be used by end applications to
ensure that they receive the end-to-end QoS that they require
Tag switching is a way to combine the label-swapping forwarding
paradigm with network-layer routing with particular application to the
Internet. This has several advantages. Tags can have a wide spectrum of
forwarding granularities, so at one end of the spectrum a tag could be
associated with a group of destinations, while at the other end, a tag
could be associated with a single application flow. At the same time,
forwarding based on tag switching, due to its simplicity, is well suited
to high-performance forwarding. These factors facilitate the development
of a routing system that is both functionally rich and scalable. Last,
tag switching simplifies the integration of routers and asynchronous
transfer mode switches by employing common addressing, routing, and
management procedures
Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task. This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. ATM based IP hosts and routers use a Multicast Address Resolution Server (MARS) to support RFC 1112 style Level 2 IP multicast over the ATM Forum's UNI 3.0/3.1 point to multipoint connection service. Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for Armitage Expires August 22nd, 1996 [Page 1] Internet Draft February 22nd, 1996 given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group. The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice ma...
Work in Progress, IETF Integrated Services Working Group, <draft-ietf-issll-atm-imp-guide-04.txt>
- L Berger
- Rsvp Atm Implementation
- Guidelines
L. Berger RSVP over ATM Implementation Guidelines. Work in Progress, IETF Integrated Services
Working Group, <draft-ietf-issll-atm-imp-guide-04.txt>, April 1998.
Aggregation of Internet Integrated Services State Work in Progress, IETF Integrated Services Working Group, <draft-berson-classy-approach-01.ps >
- S Berson
- S Vincent
S. Berson and S. Vincent, Aggregation of Internet Integrated Services State. Work in Progress, IETF
Integrated Services Working Group, <draft-berson-classy-approach-01.ps >, November 1997.
Emulation over ATM-Version 1.0. ATM Forum, AF-LANE 0021
- Atm Forum
- Lan
ATM Forum, LAN Emulation over ATM-Version 1.0. ATM Forum, AF-LANE 0021.000, January 1995.
Multiprotocol over ATM Version 1.0. ATM Forum, AF-MPOA-0087.000
- Atm Forum
ATM Forum, Multiprotocol over ATM Version 1.0. ATM Forum, AF-MPOA-0087.000, July 1997.
ATM Forum Contribution 96-0258
- A Demirtjis
A. Demirtjis et al., RSVP and ATM Signalling. ATM Forum Contribution 96-0258, January 1996.
RSVP over ATM Implementation Requirements Work in Progress, IETF Integrated Services Working Group, <draft-ietf-issll-atm-imp-req-03.txt>
- L Berger
L. Berger, RSVP over ATM Implementation Requirements. Work in Progress, IETF Integrated Services
Working Group, <draft-ietf-issll-atm-imp-req-03.txt>, April 1998.
A Framework for Integrated Services and RSVP over ATM. Work in Progress, IETF, <draftietf-issll-atm-framework-01.txt>
- E Crawley
E. Crawley, A Framework for Integrated Services and RSVP over ATM. Work in Progress, IETF, <draftietf-issll-atm-framework-01.txt>, November 1997.
VENUS-Very Extensive Non-Unicast Service. IETF Request for Comments, RFC 2191
- G Armitage
G. Armitage: VENUS-Very Extensive Non-Unicast Service. IETF Request for Comments, RFC 2191,
September 1997.
ATM Signalling Support for IP over ATM. IETF Request for Comments, RFC 1755
- M Perez
M. Perez et al., ATM Signalling Support for IP over ATM. IETF Request for Comments, RFC 1755,
February 1995.
Traffic Management Specification-Version 4.0. ATM Forum, AF-TM-0056.000
- Atm Forum
ATM Forum, Traffic Management Specification-Version 4.0. ATM Forum, AF-TM-0056.000, April
1996.
Interoperation of Controlled-Load Service and Guaranteed Service with ATM. Work in Progress, IETF Integrated Services Working Group, <draft-ietf-issll-atm-mapping-05.txt>
- M W Garrett
- M Borden
M. W. Garrett and M. Borden, Interoperation of Controlled-Load Service and Guaranteed Service with
ATM. Work in Progress, IETF Integrated Services Working Group, <draft-ietf-issll-atm-mapping-05.txt>,
March 1998.
Provider Architecture for Differentiated Services and Traffic Enginieering (PASTE) Work in Progress, IETF Network Working Group, <draft-li-paste-00.txt>
- T Li
- Y Rekhter
T. Li and Y. Rekhter, Provider Architecture for Differentiated Services and Traffic Enginieering
(PASTE). Work in Progress, IETF Network Working Group, <draft-li-paste-00.txt>, January 1998.
Network Interface (UNI) Signalling Specification-Version 4.0. ATM Forum
- Atm Forum
- User
ATM Forum, ATM User-Network Interface (UNI) Signalling Specification-Version 4.0. ATM Forum,
AF-SIG 0061.000, July 1996.
Application REQuested IP over ATM (AREQUIPA). IETF Request for Comments, RFC 2170
- W Almesberger
- J-Y. Le Boudec
- Ph
- Oechslin
W. Almesberger, J-Y. Le Boudec and Ph. Oechslin, Application REQuested IP over ATM (AREQUIPA).
IETF Request for Comments, RFC 2170, July 1997.
IP over ATM: A Framework Document. IETF Request for Comments, RFC 1932
- R Cole
- D Shur
- C Villamizar
R. Cole, D. Shur and C. Villamizar, IP over ATM: A Framework Document. IETF Request for Comments,
RFC 1932, April 1996.