rfc1946.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/4 页

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]

RFC 1946              Native ATM Support for ST2+               May 1996


   Thus far, the IETF, through  RFC 1577[1]  treats an ATM network as a
   wire.  The ipatm working group has explicitly left issues of specific
   QoS handling out of their specifications and working documents.
   Current approaches do not give the application access to individual
   virtualcircuits and their associated guaranteed bandwidth and QoS.
   Instead, all IP traffic between two hosts shares virtual circuits
   with no granularity assigned to application-specific traffic or QoS
   requirements.

   Thus, neither LAN Emulation nor RFC 1577 (IP over ATM) uses the
   features of ATM that make it a unique and desirable technology.  RFC
   1821 (Integration of Realtime Services in an IP-ATM Network
   Architecture) [2] raises many of the issues associated with current
   IETF efforts towards integrating ATM into the Internet, but it does
   not propose any solutions.

   This document offers a  framework for provision of native ATM
   circuits for applications which require bandwidth guarantees and QoS.
   It identifies  the requirements of  a native ATM protocol which is
   complementary to standard IP and describes one working
   implementation.

   This document recognizes  the fact that it is critical that such a
   native ATM  protocol  is consistent in the four topologies described
   in [2]:

   *       Communication across an ATM-only network between two hosts
           directly connected to the ATM network,
   *       Communication between ATM connected hosts which involves some
           non-ATM subnets,
   *       Communication between a host on a non-ATM subnet and a host
           directly connected to ATM,
   *       Communication between two hosts, neither of which has a direct
           ATM connection, but which may make use of one or more ATM
           networks for some part of the path.

   That is, to the host systems, the underlying type of network remains
   transparent even when QoS is involved in internet, ATM, and mixed
   networking environments.  To make this consistency possible, the
   'native ATM' protocol must also be:

   *       Multicast capable, to optimize transmission overhead and
           support ATM multipoint facilities,
   *       Routable, to enable transmissions across subnets and
           internets,
   *       QoS knowledgeable, to take advantage of ATM QoS facilities,
   *       Capable of Bandwidth/QoS Reservation to allocate proper
           facilities for application traffic as it travels across



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


           different types of networks: to effectively extend virtual
           circuits across internets, and
   *       Capable of policing to ensure proper packet scheduling
           behavior and to protect guaranteed services at merge points.

   Clearly the protocol should support reservations.  Reservation
   protocols enable creation of  'virtual circuits'  with guaranteed
   bandwidth and QoS on the LAN or internet, and simultaneously can act
   as signaling mechanisms to routers or ATM interfaces to request
   provisioning of circuits. Use of a reservation protocol makes
   characteristics of  mixed networks (LANs, internet, ATM, ISDN)
   transparent to the host systems.   That is, a reservation will allow
   the host or router to provision ATM circuits which match the
   reservation, but in mixed networks, will allow routers and host to
   provide bandwidth reservation and QoS across the non-ATM interfaces
   as well.  Effectively, the reservation maps ATM virtual circuits to
   reservations on subnets and internets.

   This creates a consistent End-to-End, QoS-guaranteed service for
   mixed network topologies.

   While it is beyond the scope of this document, the same requirements
   apply to mixed ISDN networks and are currently being explored by the
   ITU for their H.323, H.223, and T.123 standards.

   Arguably, the reservation protocol that provides this end-to-end
   guaranteed service should be connection-oriented to facilitate
   mapping of real connections (ATM or ISDN) with virtual connections on
   the LAN/internet.  [2] points out the shortcomings of IP and RSVP [3]
   in the ATM environment. Most notable among these are the difficulty
   of mapping connectionless traffic to ATM connections, the constant
   softstate refreshes of RSVP (and merging of RESV messages), the
   receiver orientation of  RSVP, and the dependence on IP multicast.

   [6] is an excellent document that proposes solutions to many of the
   issues raised in [2], but the solutions recommend modifications to
   the current RSVP and ATM implementations.  Recently, issues of
   incompatibility with the current IP over ATM model, VC explosions due
   to use of multicast groups and VC explosions due to features
   associated with heterogeneous receivers suggest that the current
   version of RSVP may be inappropriate for ATM implementations.

   Since ATM is connection-oriented, hard state, and origin-oriented for
   transmission, signaling, and multicast, and is bandwidth and QoS
   knowledgeable, perhaps the simplest and most elegant approach to a
   native protocol for ATM would include a protocol that shares these
   characteristics.




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


   In surveying protocols described in IETF RFCs and Internet Drafts,
   only two seem to meet these requirements: Experimental Internet
   Stream Protocol: Version 2 (RFC 1190) [4] and Internet STream
   Protocol Version 2+ (RFC 1819) [5]; ST2 and ST2+ respectively.

2.0 ST2 and ST2+

   Both ST2 and ST2+ have been given the Internet Protocol Version 5
   (IPv5) designation.  In fact, ST2+ is an updated version of ST2.
   Both protocols are origin-oriented reservation and multicast
   protocols that provide bandwidth and QoS guarantees through
   internets.  Unlike IPv4 or IPv6, ST2 and ST2+ are connection-
   oriented, subscribing to the philosophy that once a connection is
   established, protocol and routing overhead can be substantially
   reduced.  This carries forward to QoS and Bandwidth Reservation as
   well, simplifying the implementation of QoS guarantees. THESE
   PROTOCOLS WERE INTENDED TO COMPLEMENT STANDARD CONNECTIONLESS IP,
   RECOGNIZING THAT WHILE MOST INTERNET TRAFFIC BENEFITS FROM
   CONNECTIONLESS NETWORKING, PERFORMANCE AND QoS GUARANTEES COULD BE
   ACHIEVED MOST EASILY WITH INTERNET CONNECTIONS.

   Both ST2 and ST2+ really consist of two protocols: SCMP and ST.  SCMP
   is analogous to ICMP in that it is the control and signaling
   protocol, while ST is the low-overhead streaming protocol.   ST-2
   uses standard IP addresses during connection setup, but then reduces
   header overhead by including a stream identifier in each data packet.

   ST2+ includes simplification of many of the original ST2 features as
   well as clarification of the ST2 specification.  Among these
   simplifications and clarifications are:

   1) Much simpler connection setup.
   2) Flow Specification independence and consolidation of experimental
      Flow Specifications.
   3) Clarification on the implementation of Groups of Streams.
   4) Clarification of leaf-initiated JOINs in multicast trees (several
      ST2 implementations had done this).

   While there continues to be a  dramatic increase in the use of ST2
   for videoconferencing, video on demand, telemetry applications and
   networked virtual reality, ST2+  has no commercial implementations
   and is not yet supported by any router vendors.  This is because ST2+
   was released as an RFC late in the summer of 1995.  It is expected
   that several implementations will appear over the coming months.  As
   such, the approach described in this document applies to both
   protocols, and, in fact, would be valid for any other similar
   protocol used to establish 'native' ATM circuits.  Since ST2 and ST2+
   are so similar, this document will refer to  'the ST2 protocols'



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


   generically in describing an implementation approach to both.  Where
   particular features of ST2+ are required or affect implementation,
   'ST2+ ' will be used specifically.

3.0 Implementation Issues for Reservations over ATM

   As described above, ST is a connection-oriented, hard state, origin-
   oriented multicast protocol and thus maps fairly well to ATM.
   However, ST-2 has several features that may be difficult to support