Native ATM Support for ST2+
RFC 1946

Document Type RFC - Informational (May 1996; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1946 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       S. Jackowski
Request for Comments: 1946                        NetManage Incorporated
Category: Informational                                         May 1996

                      Native ATM Support for ST2+

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   As the demand for networked realtime services grows, so does the need
   for shared networks to provide deterministic delivery services. Such
   deterministic delivery services demand that both the source
   application and the network infrastructure have capabilities to
   request, setup, and enforce the delivery of the data. Collectively
   these services are referred to as bandwidth reservation and Quality
   of Service (QoS).

   The IETF is currently working on an integrated services model to
   support realtime services on the Internet  The IETF has not yet
   focused on the integration of ATM and its inherent QoS and bandwidth
   allocation mechanisms for delivery of realtime traffic over shared
   wires. (ATM hardware and interfaces provide the network
   infrastructure for the determinitic data delivery, however the host
   resident protocol stacks and applications need more attention.)

   Current IETF efforts underway in the IP over ATM (ipatm) working
   group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As
   such, RFC 1577 and the ATM Forum's Lan Emulation do not provide
   direct QoS and bandwidth allocation capabilities to  network
   applications. Without providing a mapping of reservations-style QoS
   to ATM signalling, ATM will remain a 'wire' rather than a shared
   media infrastructure component.

   This memo describes a working implementation which enables
   applications to directly invoke ATM services in the following
   environments:

        - ATM to internet,
        - internet to ATM, and
        - internet to internet across ATM.

Jackowski                    Informational                      [Page 1]
RFC 1946              Native ATM Support for ST2+               May 1996

Table of Contents

   1.0     Introduction...............................................2
   2.0     ST-2 and ST-2+.............................................5
   3.0     Implementation Issues for Reservations over ATM............6
   3.1     Addressing.................................................6
   3.2     Changes to Bandwidth and QoS...............................6
   3.3     Multicasting...............................................7
   3.4     Receiver Initiated JOIN Requests to Multicast Groups.......8
   3.5     Computation of QoS Parameters..............................8
   3.6     Use of HELLOs..............................................9
   4.0     Reservation Signalling with ATM............................9
   4.1     Embedded Reservation Signalling within Q.2931.............10
   4.2     In-Band Reservation Signalling............................11
   4.3     Dedicated Virtual Circuits for Reservation Signalling.....12
   4.4     Reservation Signalling via IP over ATM or LAN Emulation...13
   4.5     Summary of Reservation Signalling Options.................14
   5.0     Mapping Reservation QoS to ATM QoS........................15
   5.1     CPCS-SDU Size Computation.................................16
   5.2     PCR Computation...........................................17
   5.3     Maximum End to End Transit Delay..........................17
   5.4     Maximum Bit Error Rate....................................18
   5.5     Accumulated Mean Delay....................................18
   5.6     Accumulated Delay Variance (jitter).......................18
   6.0     Data Stream Transmission..................................18
   7.0     Implementation Considerations and Conclusions.............19
   8.0     Security Considerations...................................20
   9.0     References................................................20
   10.0    Author's Address..........................................21

1.0 Introduction

   The ATM Forum and the IETF seem to approach ATM networking
   differently.

   The ATM forum appeaars to believe that host systems require no
   protocols beyond OSI layer 2 to deal with ATM.  They define a layer 2
   API and Q.2931 signaling for all new applications.

   LAN Emulation, a mechanism to make the ATM interface appear to be a
   LAN/internet, is intended to support 'legacy' network applications.
   LAN emulation does not provide applications any visibility of the ATM
   features, nor does it provide a mechanism to allow applications to
   request specific ATM services. With LAN Emulation, application
   traffic shares virtual circuits with no policing or guarantees of
   service. LAN Emulation simply extends LAN characteristics to ATM.

Jackowski                    Informational                      [Page 2]
Show full document text