rfc2383.txt

RFC 的详细文档！

Network Working Group                                          M. Suzuki
Request for Comments: 2383                                           NTT
Category: Informational                                      August 1998


                             ST2+ over ATM
                Protocol Specification - UNI 3.1 Version

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document specifies an ATM-based protocol for communication
   between ST2+ agents. The ST2+ over ATM protocol supports the matching
   of one hop in an ST2+ tree-structure stream with one ATM connection.
   In this document, ATM is a subnet technology for the ST2+ stream.

   The ST2+ over ATM protocol is designed to achieve resource-
   reservation communications across ATM and non-ATM networks, to extend
   the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
   signaling limitations.

   The specifications of the ST2+ over ATM protocol consist of a
   revision of RFC 1819 ST2+ and specifications of protocol interaction
   between ST2+ and ATM on the user plane, management plane, and control
   plane which correspond to the three planes of the B-ISDN protocol
   reference model.

1. Introduction

1.1 Purpose of Document

   The purpose of this document is to specify an ATM-based protocol for
   communication between ST2+ agents.

   The ST2+ over ATM protocol is designed to support the matching of one
   hop in an ST2+ tree-structure stream with one ATM connection; it is
   not designed to support an entire ST2+ tree-structure stream with a
   point-to-multipoint ATM connection only.




Suzuki                       Informational                      [Page 1]

RFC 2383                     ST2+ over ATM                   August 1998


   Therefore, in this document, ATM is only a subnet technology for the
   ST2+ stream.  This specification is designed to enable resource-
   reservation communications across ATM and non-ATM networks.

1.2 Features of ST2+ over ATM Protocol

   o Enables resource-reservation communications across ATM and non-ATM
     networks.

     ATM native API supports resource-reservation communications only
     within an ATM network; it cannot support interworking with non-ATM
     networks. This is because

     - ATM native API cannot connect terminals without an ATM interface.

     - ATM native API does not support IP addressing and SAP (port)
       addressing systems.

   o Extends UNI 3.1/4.0 signaling functions.

     ST2+ SCMP supports MTU-size negotiation at all hops in an ST2+
     tree-structure stream. UNI 3.1/4.0 supports only max CPCS_SDU
     (i.e., MTU) negotiation with the called party of a point-to-point
     call or with the first leaf of a point-to-multipoint call.

   o Reduces UNI 4.0 LIJ signaling limitations.

     The ST2+ over ATM protocol supports UNI 4.0 LIJ Call Identifier
     notification from the root to the leaf by using an ST2+ SCMP
     extension.  LIJ Call Identifier discovery at the leaf is one of the
     major unsolved problems of UNI 4.0, and the ST2+ over ATM protocol
     provides a solution.

     Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
     support the above feature. It will be supported by the UNI 3.1/4.0
     version.

1.3 Goals and Non-goals of ST2+ over ATM Protocol

   The ST2+ over ATM protocol is designed to achieve the following
   goals.

   o Specify protocol interaction between ST2+ [4] and ATM on the ATM
     Forum Private UNI 3.1/4.0 (Sb point) [10, 11].

     Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
     support UNI 4.0. It will be supported by the UNI 3.1/4.0 version.




Suzuki                       Informational                      [Page 2]

RFC 2383                     ST2+ over ATM                   August 1998


   o Support ST2+ stream across ATM and non-ATM networks.

   o Define one VC on the UNI corresponding to one ST2+ hop; this VC is
     not shared with other ST2+ hops, and also this ST2+ hop is not
     divided into multiple VCs.

   o Support both SVC and PVC.

   o Not require any ATM specification changes.

   o Coexist with RFC 1483 [16] IPv4 encapsulation.

   o Coexist with RFC 1577 [17] ATMarp.

   o Coexist with RFC 1755 [18] ATM signaling for IPv4.

   o Coexist with NHRP [19].

   Because ST2+ is independent of both routing and IP address resolution
   protocols, the ST2+ over ATM protocol does not specify the following
   protocols.

   o IP-ATM address resolution protocol

   o Routing protocol

   Because the ST2+ over ATM protocol is specified for the UNI, it is
   independent of:

   o NNI protocol

   o Router/switch architecture



















Suzuki                       Informational                      [Page 3]

RFC 2383                     ST2+ over ATM                   August 1998


2. Protocol Architecture

   The ST2+ over ATM protocol specifies the interaction between ST2+ and
   ATM on the user, management, and control planes, which correspond to
   the three planes in ITU-T Recommendation I.321 B-ISDN Protocol
   Reference Model [14].

2.1 User Plane Architecture

   The user plane specifies the rules for encapsulating the ST2+ Data
   PDU into the AAL5 [15] PDU. An user plane protocol stack is shown in
   Fig. 2.1.

   +---------------------------------+
   |           RFC 1819 ST2+         |
   |           (ST2+ Data)           |
   +---------------------------------+      Point of ST2+ over ATM
   |/////////////////////////////////| <--- protocol specification of
   +---------------------------------+      user plane
   |                                 |
   |                                 |
   |             I.363.5             |
   |                                 |
   |               AAL5              |
   |                                 |
   |                                 |
   +---------------------------------+
   |           I.361 ATM             |
   +---------------------------------+
   |               PHY               |
   +----------------+----------------+
                    |        UNI
                    +--------||-------

                   Fig. 2.1: User plane protocol stack.
















Suzuki                       Informational                      [Page 4]

RFC 2383                     ST2+ over ATM                   August 1998


   An example of interworking from an ATM network to an IEEE 802.X LAN
   is shown in Fig. 2.2.

      ST2+                               ST2+                   ST2+
     Origin        ATM Cloud      Intermediate Agent           Target
   +---------+                                              +---------+
   |   AP    |--------------------------------------------->|   AP    |
   +---------+                   +-------------------+      +---------+
   |ST2+ Data|------------------>| RFC 1819 ST2+ Data|----->|ST2+ Data|
   +---------+                   +---------+---------+      +---------+
   |I.363 AAL|------------------>|I.363 AAL|  SNAP   |----->|  SNAP   |
   +---------+    +---------+    +---------+---------+      +---------+
   |I.361 ATM|--->|I.361 ATM|--->|I.361 ATM|   LLC   |----->|   LLC   |
   +---------+    +---------+    +---------+---------+      +---------+
   |         |    |         |    |         |IEEE802.X|      |IEEE802.X|
   |   PHY   |--->|   PHY   |--->|   PHY   | & 802.1p|----->| & 802.1p|
   +---------+    +---------+    +---------+---------+      +---------+

                  Fig. 2.2: Example of interworking from
                   an ATM network to an IEEE 802.X LAN.

   The ATM cell supports priority indication using the CLP field;
   indication is also supported by the ST2+ Data PDU by using the Pri
   field.  It may be feasible to map these fields to each other.  The
   ST2+ over ATM protocol specifies an optional function that maps the
   Pri field in the ST header to the CLP field in the ATM cell.
   However, implementors should note that current ATM standardization
   tends not to support tagging.























Suzuki                       Informational                      [Page 5]

RFC 2383                     ST2+ over ATM                   August 1998


2.2 Management Plane Architecture

   The management plane specifies the Null FlowSpec, the Controlled-Load
   Service [5] FlowSpec, and the Guaranteed Service [6] FlowSpec mapping
   rules [8] for UNI 3.1 traffic management.  A management plane
   protocol stack is shown in Fig. 2.3.

   +---------------------------------+
   |          Null FlowSpec          |
   |Controlled-Load Service FlowSpec |
   |   Guaranteed Service FlowSpec   |
   +---------------------------------+      Point of ST2+ over ATM
   |/////////////////////////////////| <--- protocol specification of
   +---------------------------------+      management plane
   |                                 |
   |            UNI 3.1              |
   |                                 |
   |                                 |
   |       Traffic Management        |
   |                                 |
   |                                 |
   |            VBR/UBR              |
   |                                 |
   +---------------------------------+

                Fig. 2.3: Management plane protocol stack.

   Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
   support Guaranteed Services. It will be supported by the UNI 3.1/4.0
   version.

   The ST2+ over ATM protocol specifies the ST FlowSpec format for the
   Integrated Services.  Basically, FlowSpec parameter negotiation,
   except for the MTU, is not supported.  This is because, in the ST2+
   environment, negotiated FlowSpec parameters are not always unique to
   each target.  The current ATM standard does not support heterogeneous
   QoS to receivers.

   The ST2+ over ATM protocol supports FlowSpec changes by using the
   CHANGE message (RFC 1819, Section 4.6.5) if the I-bit in the CHANGE
   message is set to one and if the CHANGE message affects all targets
   in the stream. This is because the UNI 3.1 does not support QoS
   changes. The ST2+ over ATM protocol supports FlowSpec changes by
   releasing old ATM connections and establishing new ones.

   The ST2+ over ATM protocol does not support stream preemption (RFC
   1819, Section 6.3).  This is because the Integrated Services FlowSpec
   does not support the concept of precedence.



Suzuki                       Informational                      [Page 6]

RFC 2383                     ST2+ over ATM                   August 1998


   It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2).  ST2+
   FlowSpec specifies useful services, but requires a datalink layer to
   support heterogeneous QoS to receivers.  The current ATM standard
   does not support heterogeneous QoS to receivers.

2.3 Control Plane Architecture