Native ATM Support for ST2+
RFC 1946
Document | Type |
RFC - Informational
(May 1996; No errata)
Was draft-rfced-info-jackowski (individual)
|
|
---|---|---|---|
Author | Steven Jackowski | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) 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