rfc1946.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/4 页

   For ST-2+, the header is larger than for ST-2, so the CPCS-SDU size
   is:

        CPCS-SDUsize = PDUbytes + 12 + 8.







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


5.2 PCR Computation

   The Peak Cell Rate (PCR) computation is only slightly more complex.
   The PCR will be the peak packet rate divided by the ATM payload size.

   Since PDU rates in ST-2 are specified in tenths of packets per
   second, AAL 5 requires an 8 byte trailer, and the ATM payload size is
   48 bytes, the computation for PCR proceeds as follows:

        The requested maximum byte transmission rate for ST-2 is:

                PDUbytes * PDUrate * 10.

        Accounting for the AAL 5 and ST headers, the maximum byte rate
        is:

                Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.

        Translating into cells and  eliminating the possibility of a
        fractional PDU:

                PCR = ((PDUbytes + 8 + 8 + 48) / 48) * PDUrate * 10.

   For ST-2+, not only is the header size 12 bytes, but the Rate is in
   messages per second, not tenths of packets per second.  Thus, the PCR
   for ST-2+ is:

                PCR = ((PDUbytes + 12 + 8 + 48) / 48) * PDUrate.

5.3 Maximum End to End Transit Delay.

   The End to End Transit Delay is a little more complex.   The
   requested end to end delay must account for not only the PDU size as
   requested by the user, but the additional 8-byte AAL 5 header as
   well.  The translation of the user-requested LimitOn Delay is
   preserved as long as the delay computation is based on the  CPCS-SDU
   size instead of the PDU size.

   In addition to the end to end delay introduced by the ATM network,
   there is additional delay created by the fragmentation of packets.
   Reassembly of these packets can only be accomplished at the rate at
   which they are received.  The time (in milliseconds) required to
   receive  a cell (inter-cell arrival time) is:

           T = 1000 / PCR.






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


   The number of cells in a CPCS-SDU is:

           C = (CPCS-SDUsize + 48) / 48.

   Thus the delay for a packet is:

           LimitonDelay = (C - 1) * T + MaxCellTransitDelay.

   Therefore, the requested Maximum End to End  Transit delay is:

           MaxCellTransitDelay = Limiton Delay - (C-1) * T.

5.4 Maximum Bit Error Rate

   Q.2931 signaling does not offer the ability to directly specify the
   requested bit error rate or a corresponding cell error rate.
   Instead, this service is supposed to be offered through selection of
   QoS class.

   Since these classes have few actual implementations, at this time,
   there is no effective mapping for bit error rate.

5.5 Accumulated Mean Delay

   ST allows accumulation of the Mean Delay generated by each ST agent
   node and intervening circuits.  With an ATM circuit each agent should
   factor in the overhead of the ATM connection.  The delay associated
   with the ATM circuit is reflected in the Q.2931 CONNECT message as
   the Cummulative Transit Delay.  Since this is a cell-based
   computation, the delay experienced for an ST packet, including the
   CPCS-SDU header and ST header is, as computed in Section 5.3:

        Delay = (C - 1) * T + CummulativeTransit Delay.

5.6 Accumulated Delay Variance (Jitter)

   Cell Delay Variance is not currently available as a Q.2931 parameter.

   Thus, we can assume  that the reassembly of cells into packets will
   be consistent, since the cell transmission rate should be constant
   for each packet.  As such, except as noted by the specific ATM
   service, the ST agent should use its standard mechanisms for tracking
   packet arrival times and use this for Accumulated Delay Variance.

6.0 Data Stream Transmission

   Once virtual circuits for data transmission are established though
   one of the mechanisms described in section 4, the ST data must be



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


   transmitted over the connection.  RFC 1483 describes mechanisms for
   encapsulating packet transmissions over AAL5.  While the LLC
   encapsulation could be used, it is not necessary.  If it is used, the
   computations in section 5 should be redone to include the LLC headers
   in addition to the AAL5 trailer currently used.  These new values
   should be substituted for the QoS values in the SETUP message.

   Instead, ST data packets can be encapsulated in standard AAL5 format
   with an 8 byte trailer and sent directly over the data virtual
   circuit.   The mechanisms for computing the QoS values in the SETUP
   message are described in section 5.

7.0 Implementation Experience and Conclusions

   All of the signaling mechanisms described in Section 4 were
   implemented and tested in a mixed ATM network/routed LAN environment.

   Initially it appeared that the best approach was to do signaling via
   IP over ATM or LANE.  However, because it required IP encapsulation
   of the SCMP packets (for IP over ATM), and because some applications
   use the accumulated values in the flowspecs (which are not guaranteed
   to be accurate in LANE and IP/ATM), using virtual circuits dedicated
   to SCMP signaling  turned out to be the best implementation for
   taking full advantage of the ATM features.

   Also, the issue of mapping ATM address to E.164 NSAP addresses was
   resolved through an external signaling mechanism (the User Data field
   of the ST-2 CONNECT and ACCEPT messages).  It appears that ATM
   vendors need to implement a consistent addressing mechanism
   throughout their interfaces.

   From a performance point of view, using ST over ATM provided more
   than triple the performance of raw IP.  The differences became
   increasingly clear as more simultaneous applications were run.  This
   resulted in dedicated virtual circuits for the ST traffic while the
   IP traffic suffered (saw inconsistent performance) over shared
   circuits.  Even more dramatic were results in mixed network
   environments where all traffic shared the same LAN/router
   connections, and, when both IP and ST traffic was sent, the ST
   traffic maintained its quality while the IP traffic saw increasing
   variation in performance.

   Clearly, using a connection-oriented, origin-oriented reservation
   protocol to provide consistent end-to-end guaranteed QoS and
   bandwidth in mixed ATM/internet environments is not only feasible, it
   results in dramatic performance and quality improvements for
   transmission of realtime traffic.




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


8.0 Security Considerations

   This memo raises no security considerations.  However, with their
   connection-oriented and origin controlled natures, ST-2 and ST-2+
   lend themselves to better internet security.  Discussion of this is
   beyond the scope of this document.

9.0 References

   [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett
       Packard Laboratories, December, 1993.

   [2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
       of Real-time Services in an IP-ATM network Architecture", RFC
       1821, August 1995.

   [3] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin,
       "Resource ReSerVation Protocol (RSVP Version 1 Functional
       Specification", Work in Progress, November 1995.

   [4] Topolcic, C., "Experimental Internet Stream Protocol: Version 2
       (ST-II)", RFC 1190, October 1990.

   [5] DelGrossi, L., and L. Berger, "Internet STream Protocol Version
       2+", RFC 1819, July 1995.

   [6] V. Firoiu, R. Guerin, D. Kandlur, A. Birman "Provisioning of
       RSVP-based Services over a Large ATM Network', IBM T.J. Watson
       Research Center, October 1995.

   [7] S. Damaskos, A. Anastassios Gavras, "Connection Oriented
       Protocols over ATM: A Case Study", German National Research
       Corporation for Mathematics and Data Processing (GMD) and
       Research Centre for Open Communications Systems (FOKUS), February
       1994.

   [8] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC 1483, July 1993.

   [9] M. Graf, T. Kober, H. Stuttgen, "ST-II over ATM Implementation
       Issues", IBM European Networking Center, October 1995.










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


10.0 Author's Address

       Steve Jackowski
       NetManage Incorporated
       269 Mt. Hermon Road, Suite 201
       Scotts Valley, Ca 95066

       Phone:  [phone]
       Fax:    [phone]
       EMail:  [e-mail]









































Jackowski                    Informational                     [Page 21]