home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-suzuki-st2-over-atm-02.txt < prev    next >
Text File  |  1997-10-14  |  99KB  |  2,801 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                   Muneyoshi Suzuki
  6. INTERNET DRAFT                                                       NTT
  7. Expires April 14, 1998                                  October 14, 1997
  8.  
  9.  
  10.                              ST2+ over ATM
  11.                 Protocol Specification - UNI 3.1 Version
  12.                    <draft-suzuki-st2-over-atm-02.txt>
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six months
  22.    and may be updated, replaced, or obsoleted by other documents at any
  23.    time.  It is inappropriate to use Internet-Drafts as reference
  24.    material or to cite them other than as "work in progress".
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  28.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  29.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.    ftp.isi.edu (US West Coast).
  31.  
  32.  
  33. Abstract
  34.  
  35.    This document specifies an ATM-based protocol for communication
  36.    between ST2+ agents. The ST2+ over ATM protocol supports the matching
  37.    of one hop in an ST2+ tree-structure stream with one ATM connection.
  38.    In this document, ATM is a subnet technology for the ST2+ stream.
  39.  
  40.    The ST2+ over ATM protocol is designed to achieve resource-
  41.    reservation communications across ATM and non-ATM networks, to extend
  42.    the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
  43.    signaling limitations.
  44.  
  45.    The specifications of the ST2+ over ATM protocol consist of a
  46.    revision of RFC 1819 ST2+ and specifications of protocol interaction
  47.    between ST2+ and ATM on the user plane, management plane, and control
  48.    plane which correspond to the three planes of the B-ISDN protocol
  49.    reference model.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Suzuki                    Expires April, 1998                   [Page 1]
  57.  
  58. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  59.  
  60.  
  61. 1. Introduction
  62.  
  63. 1.1 Purpose of Document
  64.  
  65.    The purpose of this document is to specify an ATM-based protocol for
  66.    communication between ST2+ agents.
  67.  
  68.    The ST2+ over ATM protocol is designed to support the matching of one
  69.    hop in an ST2+ tree-structure stream with one ATM connection; it is
  70.    not designed to support an entire ST2+ tree-structure stream with a
  71.    point-to-multipoint ATM connection only.
  72.  
  73.    Therefore, in this document, ATM is only a subnet technology for the
  74.    ST2+ stream.  This specification is designed to enable resource-
  75.    reservation communications across ATM and non-ATM networks.
  76.  
  77.  
  78. 1.2 Features of ST2+ over ATM Protocol
  79.  
  80.    o Enables resource-reservation communications across ATM and non-ATM
  81.      networks.
  82.  
  83.      ATM native API supports resource-reservation communications only
  84.      within an ATM network; it cannot support interworking with non-ATM
  85.      networks. This is because
  86.  
  87.      - ATM native API cannot connect terminals without an ATM interface.
  88.  
  89.      - ATM native API does not support IP addressing and SAP (port)
  90.        addressing systems.
  91.  
  92.    o Extends UNI 3.1/4.0 signaling functions.
  93.  
  94.      ST2+ SCMP supports MTU-size negotiation at all hops in an ST2+
  95.      tree-structure stream. UNI 3.1/4.0 supports only max CPCS_SDU
  96.      (i.e., MTU) negotiation with the called party of a point-to-point
  97.      call or with the first leaf of a point-to-multipoint call.
  98.  
  99.    o Reduces UNI 4.0 LIJ signaling limitations.
  100.  
  101.      The ST2+ over ATM protocol supports UNI 4.0 LIJ Call Identifier
  102.      notification from the root to the leaf by using an ST2+ SCMP
  103.      extension.  LIJ Call Identifier discovery at the leaf is one of the
  104.      major unsolved problems of UNI 4.0, and the ST2+ over ATM protocol
  105.      provides a solution.
  106.  
  107.      Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  108.      support the above feature. It will be supported by the UNI 3.1/4.0
  109.  
  110.  
  111.  
  112. Suzuki                    Expires April, 1998                   [Page 2]
  113.  
  114. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  115.  
  116.  
  117.      version.
  118.  
  119.  
  120. 1.3 Goals and Non-goals of ST2+ over ATM Protocol
  121.  
  122.    The ST2+ over ATM protocol is designed to achieve the following
  123.    goals.
  124.  
  125.    o Specify protocol interaction between ST2+ [4] and ATM on the ATM
  126.      Forum Private UNI 3.1/4.0 (Sb point) [10, 11].
  127.  
  128.      Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  129.      support UNI 4.0. It will be supported by the UNI 3.1/4.0 version.
  130.  
  131.    o Support ST2+ stream across ATM and non-ATM networks.
  132.  
  133.    o Define one VC on the UNI corresponding to one ST2+ hop; this VC is
  134.      not shared with other ST2+ hops, and also this ST2+ hop is not
  135.      divided into multiple VCs.
  136.  
  137.    o Support both SVC and PVC.
  138.  
  139.    o Not require any ATM specification changes.
  140.  
  141.    o Coexist with RFC 1483 [16] IPv4 encapsulation.
  142.  
  143.    o Coexist with RFC 1577 [17] ATMarp.
  144.  
  145.    o Coexist with RFC 1755 [18] ATM signaling for IPv4.
  146.  
  147.    o Coexist with NHRP [19].
  148.  
  149.    Because ST2+ is independent of both routing and IP address resolution
  150.    protocols, the ST2+ over ATM protocol does not specify the following
  151.    protocols.
  152.  
  153.    o IP-ATM address resolution protocol
  154.  
  155.    o Routing protocol
  156.  
  157.    Because the ST2+ over ATM protocol is specified for the UNI, it is
  158.    independent of:
  159.  
  160.    o NNI protocol
  161.  
  162.    o Router/switch architecture
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Suzuki                    Expires April, 1998                   [Page 3]
  169.  
  170. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  171.  
  172.  
  173. 2. Protocol Architecture
  174.  
  175.    The ST2+ over ATM protocol specifies the interaction between ST2+ and
  176.    ATM on the user, management, and control planes, which correspond to
  177.    the three planes in ITU-T Recommendation I.321 B-ISDN Protocol
  178.    Reference Model [14].
  179.  
  180.  
  181. 2.1 User Plane Architecture
  182.  
  183.    The user plane specifies the rules for encapsulating the ST2+ Data
  184.    PDU into the AAL5 [15] PDU. An user plane protocol stack is shown in
  185.    Fig. 2.1.
  186.  
  187.    +---------------------------------+
  188.    |           RFC 1819 ST2+         |
  189.    |           (ST2+ Data)           |
  190.    +---------------------------------+      Point of ST2+ over ATM
  191.    |/////////////////////////////////| <--- protocol specification of
  192.    +---------------------------------+      user plane
  193.    |                                 |
  194.    |                                 |
  195.    |             I.363.5             |
  196.    |                                 |
  197.    |               AAL5              |
  198.    |                                 |
  199.    |                                 |
  200.    +---------------------------------+
  201.    |           I.361 ATM             |
  202.    +---------------------------------+
  203.    |               PHY               |
  204.    +----------------+----------------+
  205.                     |        UNI
  206.                     +--------||-------
  207.  
  208.                    Fig. 2.1: User plane protocol stack.
  209.  
  210.    An example of interworking from an ATM network to an IEEE 802.X LAN
  211.    is shown in Fig. 2.2.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224. Suzuki                    Expires April, 1998                   [Page 4]
  225.  
  226. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  227.  
  228.  
  229.       ST2+                               ST2+                   ST2+
  230.      Origin        ATM Cloud      Intermediate Agent           Target
  231.    +---------+                                              +---------+
  232.    |   AP    |--------------------------------------------->|   AP    |
  233.    +---------+                   +-------------------+      +---------+
  234.    |ST2+ Data|------------------>| RFC 1819 ST2+ Data|----->|ST2+ Data|
  235.    +---------+                   +---------+---------+      +---------+
  236.    |I.363 AAL|------------------>|I.363 AAL|  SNAP   |----->|  SNAP   |
  237.    +---------+    +---------+    +---------+---------+      +---------+
  238.    |I.361 ATM|--->|I.361 ATM|--->|I.361 ATM|   LLC   |----->|   LLC   |
  239.    +---------+    +---------+    +---------+---------+      +---------+
  240.    |         |    |         |    |         |IEEE802.X|      |IEEE802.X|
  241.    |   PHY   |--->|   PHY   |--->|   PHY   | & 802.1p|----->| & 802.1p|
  242.    +---------+    +---------+    +---------+---------+      +---------+
  243.  
  244.                   Fig. 2.2: Example of interworking from
  245.                    an ATM network to an IEEE 802.X LAN.
  246.  
  247.    The ATM cell supports priority indication using the CLP field;
  248.    indication is also supported by the ST2+ Data PDU by using the Pri
  249.    field.  It may be feasible to map these fields to each other.  The
  250.    ST2+ over ATM protocol specifies an optional function that maps the
  251.    Pri field in the ST header to the CLP field in the ATM cell.
  252.    However, implementors should note that current ATM standardization
  253.    tends not to support tagging.
  254.  
  255.  
  256. 2.2 Management Plane Architecture
  257.  
  258.    The management plane specifies the Null FlowSpec, the Controlled-Load
  259.    Service [5] FlowSpec, and the Guaranteed Service [6] FlowSpec mapping
  260.    rules [8] for UNI 3.1 traffic management.  A management plane
  261.    protocol stack is shown in Fig. 2.3.
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Suzuki                    Expires April, 1998                   [Page 5]
  281.  
  282. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  283.  
  284.  
  285.    +---------------------------------+
  286.    |          Null FlowSpec          |
  287.    |Controlled-Load Service FlowSpec |
  288.    |   Guaranteed Service FlowSpec   |
  289.    +---------------------------------+      Point of ST2+ over ATM
  290.    |/////////////////////////////////| <--- protocol specification of
  291.    +---------------------------------+      management plane
  292.    |                                 |
  293.    |            UNI 3.1              |
  294.    |                                 |
  295.    |                                 |
  296.    |       Traffic Management        |
  297.    |                                 |
  298.    |                                 |
  299.    |            VBR/UBR              |
  300.    |                                 |
  301.    +---------------------------------+
  302.  
  303.                 Fig. 2.3: Management plane protocol stack.
  304.  
  305.    Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  306.    support Guaranteed Services. It will be supported by the UNI 3.1/4.0
  307.    version.
  308.  
  309.    The ST2+ over ATM protocol specifies the ST FlowSpec format for the
  310.    Integrated Services.  Basically, FlowSpec parameter negotiation,
  311.    except for the MTU, is not supported.  This is because, in the ST2+
  312.    environment, negotiated FlowSpec parameters are not always unique to
  313.    each target.  The current ATM standard does not support heterogeneous
  314.    QoS to receivers.
  315.  
  316.    The ST2+ over ATM protocol supports FlowSpec changes by using the
  317.    CHANGE message (RFC 1819, Section 4.6.5) if the I-bit in the CHANGE
  318.    message is set to one and if the CHANGE message affects all targets
  319.    in the stream. This is because the UNI 3.1 does not support QoS
  320.    changes. The ST2+ over ATM protocol supports FlowSpec changes by
  321.    releasing old ATM connections and establishing new ones.
  322.  
  323.    The ST2+ over ATM protocol does not support stream preemption (RFC
  324.    1819, Section 6.3).  This is because the Integrated Services FlowSpec
  325.    does not support the concept of precedence.
  326.  
  327.    It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2).  ST2+
  328.    FlowSpec specifies useful services, but requires a datalink layer to
  329.    support heterogeneous QoS to receivers.  The current ATM standard
  330.    does not support heterogeneous QoS to receivers.
  331.  
  332.  
  333.  
  334.  
  335.  
  336. Suzuki                    Expires April, 1998                   [Page 6]
  337.  
  338. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  339.  
  340.  
  341. 2.3 Control Plane Architecture
  342.  
  343.    The control plane specifies the relationship between ST2+ SCMP and
  344.    PVC management for ST2+ data and the protocol interaction between
  345.    ST2+ SCMP and UNI 3.1 signaling [10]. A control plane protocol stack
  346.    is shown in Fig. 2.4.
  347.  
  348.    +---------------------------------+
  349.    |           RFC 1819 ST2+         |
  350.    |           (ST2+ SCMP)           |
  351.    +---------------------------------+      Point of ST2+ over ATM
  352.    |/////////////////////////////////| <--- protocol specification of
  353.    +----------------+----------------+      control plane
  354.    |    IEEE 802    |UNI3.1 Signaling|
  355.    |      SNAP      +----------------+
  356.    +----------------+  Q.2130 SSCF   |
  357.    |   ISO 8802-2   +----------------+
  358.    |    LLC Type1   |  Q.2110 SSCOP  |
  359.    +----------------+----------------+
  360.    |          I.363.5 AAL5           |
  361.    +---------------------------------+
  362.    |           I.361 ATM             |
  363.    +---------------------------------+
  364.    |               PHY               |
  365.    +----------------+----------------+
  366.                     |        UNI
  367.                     +--------||-------
  368.  
  369.                   Fig. 2.4: Control plane protocol stack.
  370.  
  371.    The ST2+ SCMP PDU is mapped to the AAL5 PDU based on the RFC 1483 LLC
  372.    encapsulation format. The ST2+ over ATM protocol does not cover a VC
  373.    (SVC/PVC) that transfers ST2+ SCMP. VCs for IPv4 transfer may be used
  374.    for ST2+ SCMP transfer, and implementations may provide particular
  375.    VCs for ST2+ SCMP transfer. Selection of these VCs depends on the
  376.    implementation.
  377.  
  378.    Implementors should note that when ST2+ data and SCMP belong to a
  379.    stream, the routing directions on the ST2+ layer must be the same.
  380.    Implementors should also note that ST2+ and IPv4 directions for
  381.    routing to the same IP destination address are not always the same.
  382.  
  383.    The ST2+ over ATM protocol supports both SVC and PVC for ST2+ Data
  384.    PDU transfer.  If SVC is used, the ST2+ and ATM layers establish a
  385.    connection sequentially by using respectively ST2+ SCMP and UNI 3.1
  386.    signaling. An example of ST2+ SCMP and UNI 3.1 signaling message
  387.    flows for establishing and releasing of ST2+ data connections is
  388.    shown in Fig. 2.5, where (S) means an ST2+ entity and (Q) means a UNI
  389.  
  390.  
  391.  
  392. Suzuki                    Expires April, 1998                   [Page 7]
  393.  
  394. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  395.  
  396.  
  397.    3.1 signaling entity.
  398.  
  399.                            ATM SW      ATM SW
  400.        +------------+ UNI  +----+ NNI  +----+ UNI  +------------+
  401.    ____|Intermediate|--||--| \/ |______| \/ |--||--|Intermediate|____
  402.        | (Upstream) |      | /\ |      | /\ |      |(Downstream)|
  403.        +------------+      +----+      +----+      +------------+
  404.                                   SCMP
  405.    ------->(S)<------------------------------------------>(S)<-------
  406.              \     UNI Sig.                   UNI Sig.    /
  407.    CONNECT  | (Q)<--------->(Q)<-------->(Q)<--------->(Q) |
  408.    -------->|                                              |
  409.    ACK <----|--------------------CONNECT------------------>| CONNECT
  410.             |<---------------------ACK---------------------|-------->
  411.             |                                              |<--- ACK
  412.             |                                              | ACCEPT
  413.             |                                              |<--------
  414.             |<-------------------ACCEPT--------------------|---> ACK
  415.             |----------------------ACK-------------------->|
  416.             |                                              |
  417.             |->|----SETUP--->|            |             |  |
  418.             |  |<-CALL PROC--|----------->|----SETUP--->|->|
  419.             |  |             |            |<----CONN----|<-|
  420.    ACCEPT   |  |<----CONN----|<-----------|--CONN ACK-->|->|
  421.    <--------|<-|--CONN ACK-->|            |             |  |
  422.    ACK ---->|                                              |
  423.             |                                              |
  424.    -------\ |--------------------------------------------\ |-------\
  425.            >|                   ST2+ Data                 >|        >
  426.    -------/ |--------------------------------------------/ |-------/
  427.             |                                              |
  428.    DISCONN  |                                              |
  429.    -------->|                                              |
  430.    ACK <----|-------------------DISCONNECT---------------->|
  431.             |<---------------------ACK---------------------|
  432.             |                                              |
  433.             |->|---RELEASE-->|            |             |  |
  434.             |<-|<--REL COMP--|----------->|---RELEASE-->|->| DISCONN
  435.             |  |             |            |<--REL COMP--|<-|-------->
  436.             |                                              |<--- ACK
  437.  
  438.     Fig. 2.5: Example of ST2+ SCMP and UNI 3.1 signaling message flows.
  439.  
  440.    UNI 3.1/4.0 specifies PVC, point-to-point SVC, and point-to-
  441.    multipoint SVC as VC styles. However, in actual ATM network
  442.    environments, especially public ATM WANs, only PVC and bi-directional
  443.    point-to-point SVC may be supported.  To support the diverse VC
  444.    styles, the ST2+ over ATM protocol supports the following VC styles
  445.  
  446.  
  447.  
  448. Suzuki                    Expires April, 1998                   [Page 8]
  449.  
  450. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  451.  
  452.  
  453.    for ST2+ Data PDU transfer.
  454.  
  455.    o PVC
  456.  
  457.    o Reuse of reverse channel of bi-directional point-to-point SVC that
  458.      is used by existing stream.
  459.  
  460.    o Point-to-point SVC initiated from upstream side.
  461.  
  462.    o Point-to-multipoint SVC initiated from upstream side.
  463.  
  464.    o Point-to-point SVC initiated from downstream side.
  465.  
  466.    o Point-to-multipoint SVC initiated from downstream side (LIJ).
  467.  
  468.      Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  469.      support LIJ.  LIJ will be supported by the UNI 3.1/4.0 version.
  470.  
  471.    The second style is needed in environments supporting bi-directional
  472.    point-to-point SVC only.  The selection of PVC and SVC styles in the
  473.    ST2+ agent is based on preconfigured implementation-dependent rules.
  474.  
  475.    SVC supports both upstream and downstream call initiation styles.
  476.    Implementors should note that this is independent of the sender-
  477.    oriented and receiver-oriented ST2+ stream-building process (RFC
  478.    1819, Section 4.1.1).  This is because the ST2+ over ATM protocol
  479.    specifies the process for establishing ST2+ data hops on the UNI, and
  480.    because the ST2+ stream building process belongs to another layer.
  481.    The SVC initiation side should be determined based on the operational
  482.    and billing policies between ST2+ agents; this is basically
  483.    independent of the sender-oriented and receiver-oriented ST2+
  484.    stream-building process.
  485.  
  486.    An example of ST2+ SCMP interworking is shown in Fig. 2.6.
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504. Suzuki                    Expires April, 1998                   [Page 9]
  505.  
  506. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  507.  
  508.  
  509.                          _____
  510.                         /     \
  511.                        (Origin )
  512.                         \     /
  513.                        A ~~|~~ A
  514.                        |   =   | UNI Signaling
  515.                        |   |   |
  516.                        | +-+-+ V
  517.                        | | X |   ATM SW
  518.                        | +-+-+ A
  519.                   SCMP |   |   | NNI Signaling
  520.                        | +-+-+ V
  521.                        | | X |   ATM SW
  522.                        | +-+-+ A
  523.                        |   |   |
  524.                        |   =   | UNI Signaling
  525.                        V   |   V
  526.                      +-----+------+   IEEE 802.X & 802.1p
  527.                      |            |<---------------------+
  528.                      |Intermediate|--------------------+ |
  529.                      |            |<-----------------+ | |
  530.                      +------------+      L2 Signaling| | |
  531.                        A   |   A                     | | |
  532.                        |   =   | UNI Signaling       | | | SCMP
  533.                        |   |   |                     | | |
  534.                        | +-+-+ V                     | | |
  535.                        | | X |   ATM SW              V | |
  536.                        | +-+-+ A                   +---+-|-+
  537.                   SCMP |   |   | NNI Signaling     |  \ /| |
  538.                        | +-+-+ V                   |   X | |LAN SW
  539.                        | | X |   ATM SW            |  / \| |
  540.                        | +-+-+ A                   +---+-|-+
  541.                        |   |   |                     A | |
  542.                        |   =   | UNI Signaling       | | |
  543.                        V __|__ V                     V_|_V
  544.                         /     \                     /     \
  545.                        (Target )                   (Target )
  546.                         \     /                     \     /
  547.                          ~~~~~                       ~~~~~
  548.  
  549.                Fig. 2.6: Example of ST2+ SCMP interworking.
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560. Suzuki                    Expires April, 1998                  [Page 10]
  561.  
  562. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  563.  
  564.  
  565. 3. Revision of RFC 1819 ST2+
  566.  
  567.    To specify the ST2+ over ATM protocol, the functions in RFC 1819 ST2+
  568.    must be extended to support ATM.  However, it is difficult for the
  569.    current ATM standard to support part of the specifications in RFC
  570.    1819 ST2+. This section specifies the extended, restricted,
  571.    unsupported, and modified functions in RFC 1819 ST2+.  Errata for RFC
  572.    1819 appears in Appendix A.
  573.  
  574.  
  575. 3.1 Extended Functions of RFC 1819 ST2+
  576.  
  577. 3.1.1 ST FlowSpec for Controlled-Load Service
  578.  
  579.    The ST2+ over ATM protocol specifies the ST FlowSpec format for the
  580.    Integrated Services.  Basically, FlowSpec parameter negotiation,
  581.    except for the MTU, is not supported.  The ST2+ intermediate agent
  582.    and the target decide whether to accept or refuse the FlowSpec
  583.    parameters, except for the MTU.  Therefore, each of the FlowSpec
  584.    parameter values other than MTU is the same at each target in the
  585.    stream.
  586.  
  587.    The format of the ST FlowSpec for the Controlled-Load Service is
  588.    shown in Fig. 3.1.
  589.  
  590.     0                   1                   2                   3
  591.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  592.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  593.    |   PCode = 1   |  PBytes = 36  | ST FS Ver = 8 |   0(unused)   |
  594.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  595.    | Ver=0 |      0(reserved)      |      Overall Length = 7       |
  596.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  597.    |  SVC Number   |0| 0(reserved) |        SVC Length = 6         |
  598.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  599.    |Param Num = 127|   Flags = 0   |       Param Length = 5        |
  600.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  601.    |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
  602.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  603.    |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
  604.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  605.    |   Peak Data Rate [p] (32-bit IEEE floating point number)      |
  606.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  607.    |                   Minimum Policed Unit [m]                    |
  608.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  609.    |                   Maximum Packet Size [M]                     |
  610.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  611.  
  612.        Fig. 3.1: Format of ST FlowSpec for Controlled-Load Service.
  613.  
  614.  
  615.  
  616. Suzuki                    Expires April, 1998                  [Page 11]
  617.  
  618. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  619.  
  620.  
  621.      The PCode field identifies common SCMP elements.  The PCode value
  622.      for the ST2+ FlowSpec is 1.
  623.  
  624.      The PBytes field for the Controlled-Load Service is 36 bytes.
  625.  
  626.      The ST FS Ver (ST FlowSpec Version) field identifies the ST
  627.      FlowSpec version.  The ST FlowSpec version number for the
  628.      Integrated Services is 8.
  629.  
  630.      The Ver (Message Format Version) field identifies the Integrated
  631.      Services FlowSpec message format version.  The current version is
  632.      zero.
  633.  
  634.      The Overall Length field for the Controlled-Load Service is 7
  635.      words.
  636.  
  637.      The SVC Number (Service ID Number) field identifies the Integrated
  638.      Services.  If the Integrated Services FlowSpec appears in the
  639.      CONNECT or CHANGE message, the value of the SVC Number field is 1.
  640.      If it appears in the ACCEPT, NOTIFY, or STATUS-RESPONSE message,
  641.      the value of the SVC Number field is 5.
  642.  
  643.      The SVC Length (Service-specific Data Length) field for the
  644.      Controlled-Load Service is 6 words.
  645.  
  646.      The Param Num (Parameter Number) field is 127.
  647.  
  648.      The Flags (Per-parameter Flags) field is zero.
  649.  
  650.      The Param Length (Length of Per-parameter Data) field is 5 words.
  651.  
  652.      Definitions of the Token Bucket Rate [r], the Token Bucket Size
  653.      [b], the Peak Data Rate [p], the Minimum Policed Unit [m], and the
  654.      Maximum Packet Size [M] fields are given in [5].  See section 5 of
  655.      [5] for details.
  656.  
  657.    The ST2+ agent, that creates the FlowSpec element in the SCMP
  658.    message, must assign valid values to all fields. The other agents
  659.    must not modify any values in the element.
  660.  
  661.    The MaxMsgSize field in the CONNECT message is assigned by the origin
  662.    or the intermediate agent acting as origin, and updated by each agent
  663.    based on the MTU value of the datalink layer.
  664.  
  665.    The negotiated value of MaxMsgSize is set back to the origin or the
  666.    intermediate agent acting as origin using the [M] field and the
  667.    MaxMsgSize field in the ACCEPT message that corresponds to the
  668.    CONNECT message.
  669.  
  670.  
  671.  
  672. Suzuki                    Expires April, 1998                  [Page 12]
  673.  
  674. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  675.  
  676.  
  677.    In the original definition of the Controlled-Load Service, the value
  678.    of the [m] field must be less than or equal to the value of the [M]
  679.    field.  However, in the ST FlowSpec for the Controlled-Load Service,
  680.    if the value of the [m] field is more than that of the [M] field, the
  681.    value of the [m] field is regarded as the same value as the [M]
  682.    field, and must not generate an error. This is because there is a
  683.    possibility that the value of the [M] field in the ACCEPT message may
  684.    be decreased by negotiation.
  685.  
  686.    In the ST2+ SCMP messages, the value of the [M] field must be equal
  687.    to or less than 65,535.  In the ACCEPT message that responds to
  688.    CONNECT, or the NOTIFY message that contains the FlowSpec field, the
  689.    value of the [M] field must be equal to the MaxMsgSize field in the
  690.    message.  If these values are not the same, FlowSpec is regarded as
  691.    an error.
  692.  
  693.    If the ST2+ agent receives the CONNECT message that contains
  694.    unacceptable FlowSpec, the agent must generate a REFUSE message.
  695.  
  696. 3.1.2 ST FlowSpec for Guaranteed Service
  697.  
  698.    Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  699.    support Guaranteed Services. It will be supported by the UNI 3.1/4.0
  700.    version.
  701.  
  702. 3.1.3 VC-type common SCMP element
  703.  
  704.    The ST2+ over ATM protocol specifies an additional common SCMP
  705.    element that designates the VC type used to support the diverse VC
  706.    styles.  The CONNECT and CHANGE messages that establish a hop with a
  707.    VC must contain a VC-type common SCMP element.  This element is valid
  708.    between neighboring ST2+ agents, but must not propagate beyond the
  709.    previous-hop or next-hop ST2+ agent.
  710.  
  711.    The format of the VC-type common SCMP element is shown in Fig. 3.2.
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728. Suzuki                    Expires April, 1998                  [Page 13]
  729.  
  730. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  731.  
  732.  
  733.     0                   1                   2                   3
  734.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  735.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  736.    |   PCode = 8   |  PBytes = 20  |            VCType             |
  737.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  738.    |                          PVCIdentifer                         |
  739.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.    |          0(unused)            |           UniqueID            |
  741.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.    |                        OriginIPAddress                        |
  743.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.    |                        LIJCallIdentifer                       |
  745.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  746.  
  747.              Fig. 3.2: Format of VC-type common SCMP element.
  748.  
  749.      The PCode field identifies the common SCMP elements. The PCode
  750.      value for the VC type is 8.
  751.  
  752.      The PBytes field for the VC type is 20 bytes.
  753.  
  754.      The VCType field identifies the VC type.  The correspondence
  755.      between the value in this field and the meaning is as follows:
  756.  
  757.        0: ST2+ data stream uses a PVC.
  758.  
  759.        1: ST2+ data stream uses the reverse channel of the bi-
  760.           directional point-to-point SVC used by the existing stream.
  761.  
  762.        2: ST2+ data stream is established by a point-to-point SVC
  763.           initiated from the upstream side.
  764.  
  765.        3: ST2+ data stream is established by a point-to-multipoint SVC
  766.           initiated from the upstream side.
  767.  
  768.        4: ST2+ data stream is established by a point-to-point SVC
  769.           initiated from the downstream side.
  770.  
  771.        5: ST2+ data stream is established by a point-to-multipoint SVC
  772.           initiated from the downstream side.
  773.  
  774.        Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  775.        support VCType 5. It will be supported by the UNI 3.1/4.0
  776.        version.
  777.  
  778.      The PVCIdentifer field identifies the PVC identifier uniquely
  779.      assigned between neighboring ST2+ agents. This field is valid only
  780.      when the VCType field is zero.
  781.  
  782.  
  783.  
  784. Suzuki                    Expires April, 1998                  [Page 14]
  785.  
  786. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  787.  
  788.  
  789.      The UniqueID and OriginIPAddress fields identify the reverse
  790.      channel of the bi-directional point-to-point SVC that is used by
  791.      this SID.  These fields are valid only when the VCType field is 1.
  792.  
  793.      The LIJCallIdentifer field identifies the LIJ Call Identifier for
  794.      point-to-multipoint SVC. This field is valid only when the VCType
  795.      field is 5.
  796.  
  797. 3.1.4 Reason Code
  798.  
  799.    The extension of the Reason Code (RFC 1819, Section 10.5.3) to the
  800.    ST2+ over ATM protocol is shown below.
  801.  
  802.      57 CantChange   Partial changes not supported.
  803.      58 NoRecover    Stream recovery not supported.
  804.  
  805.  
  806. 3.2 Restricted Functions of RFC 1819 ST2+
  807.  
  808. 3.2.1 FlowSpec changes
  809.  
  810.    In the following case, the ST2+ over ATM protocol supports stream
  811.    FlowSpec changes by using the CHANGE message.
  812.  
  813.    o The I-bit is set to 1 and the G-bit is set to 1.
  814.  
  815.    In the following case, the CHANGE fails and a REFUSE message, with
  816.    the E and N-bits set to 1 and the ReasonCode set to CantChange, is
  817.    propagated upstream.
  818.  
  819.    o The I and/or G-bits are set to zero.
  820.  
  821.  
  822. 3.3 Unsupported Functions of RFC 1819 ST2+
  823.  
  824. 3.3.1 ST2+ FlowSpec
  825.  
  826.    The ST2+ over ATM protocol does not support the ST2+ FlowSpec (RFC
  827.    1819, Section 9.2).  The ST2+ FlowSpec specifies useful services, but
  828.    requires the datalink layer to support heterogeneous QoS to
  829.    receivers.  The current ATM standard does not support heterogeneous
  830.    QoS to receivers.
  831.  
  832. 3.3.2 Stream preemption
  833.  
  834.    The ST2+ over ATM protocol does not support stream preemption (RFC
  835.    1819, Section 6.3).  This is because the Integrated Services FlowSpec
  836.    does not support the concept of precedence.
  837.  
  838.  
  839.  
  840. Suzuki                    Expires April, 1998                  [Page 15]
  841.  
  842. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  843.  
  844.  
  845. 3.3.3 HELLO message
  846.  
  847.    Implementations may not support the HELLO message (RFC 1819, Section
  848.    10.4.7) and thus ST2+ agent failure detection using the HELLO message
  849.    (RFC 1819, Section 6.1.2). This is because ATM has an adequate
  850.    failure detection mechanism, and the HELLO message is not sufficient
  851.    for detecting link failure in the ST2+ over ATM protocol, because the
  852.    ST2+ data and the ST2+ SCMP are forwarded through another VC.
  853.  
  854. 3.3.4 Stream recovery
  855.  
  856.    Implementors must select the NoRecover option of the CONNECT message
  857.    (RFC 1819, Section 4.4.1) with the S-bit set to 1.  This is because
  858.    the descriptions of the stream recovery process in RFC 1819 (Sections
  859.    5.3.2, 6.2, and 6.2.1) are unclear and incomplete. It is thus
  860.    possible that if a link failure occurs and several ST2+ agents detect
  861.    it simultaneously, the recovery process may encounter problems.
  862.  
  863.    The ST2+ over ATM protocol does not support stream recovery. If
  864.    recovery is needed, the application should support it. A CONNECT
  865.    message in which the NoRecover option is not selected will fail; a
  866.    REFUSE message in which the N-bit is set to 1 and the ReaseonCode is
  867.    set to NoRecover is then propagated upstream.
  868.  
  869. 3.3.5 Subnet Resources Sharing
  870.  
  871.    The ST2+ over ATM protocol does not support subnet resources sharing
  872.    (RFC 1819, Section 7.1.4).  This is because ATM does not support the
  873.    concept of the MAC layer.
  874.  
  875. 3.3.6 IP encapsulation of ST
  876.  
  877.    The ST2+ over ATM protocol does not support IP encapsulation of ST
  878.    (RFC 1819, Section 8.7), because there is no need to implement IP
  879.    encapsulation in this protocol.
  880.  
  881. 3.3.7 IP Multicasting
  882.  
  883.    The ST2+ over ATM protocol does not support IP multicasting (RFC
  884.    1819, Section 8.8), because this protocol does not support IP
  885.    encapsulation of ST.
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896. Suzuki                    Expires April, 1998                  [Page 16]
  897.  
  898. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  899.  
  900.  
  901. 3.4 Modified Functions of RFC 1819 ST2+
  902.  
  903.    The ST2+ receiver-oriented stream creation procedure has some fatal
  904.    problems: the value of the LnkReferecnce field in the CONNECT message
  905.    that is a response to a JOIN message is not valid, ST2+ agent cannot
  906.    update the LnkReference field in the JOIN-REJECT message, and ST2+
  907.    agent cannot deliver the JOIN-REJECT message to the target because
  908.    the JOIN-REJECT message does not contain a TargetList field.  To
  909.    solve these problems, the ST2+ over ATM protocol modifies the ST2+
  910.    protocol processing rules.
  911.  
  912. 3.4.1 Modifications of Message Processing Rules
  913.  
  914.    Modifications of the CONNECT, JOIN, and JOIN-REJECT message
  915.    processing rules in the ST2+ over ATM protocol are described in the
  916.    following.
  917.  
  918.    o The target that creates a JOIN message assigns the same value as in
  919.      the Reference field to the LnkReference field.
  920.  
  921.    o The agent that creates a CONNECT message as a response to a JOIN
  922.      message assigns the same value as in the LnkReference field in the
  923.      JOIN message to the LnkReference field.  In other cases, the value
  924.      of the LnkReference field in a CONNECT message is zero.
  925.  
  926.    o The agent that creates a JOIN-REJECT message assigns the same value
  927.      as in the LnkReference field in the JOIN message to the
  928.      LnkReference field.
  929.  
  930.    o An intermediate agent must not modify the value of the LnkReference
  931.      field in the CONNECT, JOIN, or JOIN-REJECT message.  Note that this
  932.      rule differs from the LnkReference field processing rule in the
  933.      ACCEPT and REFUSE messages.
  934.  
  935. 3.4.2 Modified JOIN-REJECT Control Message
  936.  
  937.    The modified JOIN-REJECT control message in the ST2+ over ATM
  938.    protocol is shown in Fig. 3.3
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952. Suzuki                    Expires April, 1998                  [Page 17]
  953.  
  954. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  955.  
  956.  
  957.      0                   1                   2                   3
  958.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  959.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  960.     |  OpCode = 9   |       0       |           TotalBytes          |
  961.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  962.     |           Reference           |          LnkReference         |
  963.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  964.     |                         SenderIPAddress                       |
  965.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  966.     |           Checksum            |           ReasonCode          |
  967.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  968.     |                       GeneratorIPAddress                      |
  969.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  970.     :                          TargetList                           :
  971.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  972.  
  973.                   Fig. 3.3: JOIN-REJECT Control Message.
  974.  
  975.    The TargetList is assigned the same TargetList in the JOIN message as
  976.    the one that corresponds to the JOIN-REJECT message.
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008. Suzuki                    Expires April, 1998                  [Page 18]
  1009.  
  1010. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1011.  
  1012.  
  1013. 4. Protocol Specification of the User Plane
  1014.  
  1015.    This section specifies the AAL5 PDU encapusulation for the ST2+ Data
  1016.    PDU.
  1017.  
  1018.  
  1019. 4.1 Service Primitives Provided by User Plane
  1020.  
  1021. 4.1.1 Overview of interactions
  1022.  
  1023.    The ST2+ data layer entity on the user plane of the ST2+ over ATM
  1024.    protocol provides the following services to the upper layer.
  1025.  
  1026.    o st2p_unitdata.req
  1027.  
  1028.    o st2p_unitdata.ind
  1029.  
  1030. 4.1.1.1 St2p_unitdata.req
  1031.  
  1032.    The st2p_unitdata.req primitive sends a request for an ST2+ Data PDU
  1033.    transfer to the ST2+ data layer entity.  The semantics of the
  1034.    primitive are as follows:
  1035.  
  1036.    st2p_unitdata.req (
  1037.            pri,
  1038.            sid,
  1039.            data
  1040.            )
  1041.  
  1042.    The pri parameter specifies priority of ST2+ Data PDU.  The sid
  1043.    parameter specifies SID of ST2+ Data PDU.  The data parameter
  1044.    specifies ST2+ data to be transferred.
  1045.  
  1046. 4.1.1.2 St2p_unitdata.ind
  1047.  
  1048.    The st2p_unitdata.ind primitive indicates an ST2+ Data PDU delivery
  1049.    from the ST2+ data layer entity.  The semantics of the primitive are
  1050.    as follows:
  1051.  
  1052.    st2p_unitdata.ind (
  1053.            pri [optional],
  1054.            sid,
  1055.            data,
  1056.            status [optional]
  1057.            )
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064. Suzuki                    Expires April, 1998                  [Page 19]
  1065.  
  1066. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1067.  
  1068.  
  1069.    The pri parameter indicates priority of ST2+ Data PDU, if AAL5 is
  1070.    used for encapsulating the ST2+ Data PDU.  The sid parameter
  1071.    indicates SID of ST2+ Data PDU.  The data parameter indicates
  1072.    delivered ST2+ data.  The status is an optional parameter that
  1073.    indicates whether the delivered ST2+ data is corrupt or not.
  1074.  
  1075.  
  1076. 4.2 Service Primitives Provided by AAL5
  1077.  
  1078. 4.2.1 Requirements for AAL5
  1079.  
  1080.    The requirements for the AAL5 layer on the ST2+ over ATM user plane
  1081.    are as follows:
  1082.  
  1083.    o The SSCS must be null.
  1084.  
  1085.    o Implementations must use message-mode service.
  1086.  
  1087.      Note: Selection of the corrupted SDU delivery option on the
  1088.      receiver side depends on the implementation, so the receiver may or
  1089.      may not be able to select this option.
  1090.  
  1091. 4.2.2 Overview of Interactions
  1092.  
  1093.    The AAL5 layer entity on the ST2+ over ATM user plane provides the
  1094.    following services to the ST2+ data layer.
  1095.  
  1096.    o AAL5_UNITDATA.req
  1097.  
  1098.    o AAL5_UNITDATA.ind
  1099.  
  1100. 4.2.2.1 AAL5_UNITDATA.req
  1101.  
  1102.    The AAL5_UNITDATA.req primitive sends a request for an AAL5 data
  1103.    (AAL5 CPCS_SDU) transfer from the ST2+ data layer entity to the AAL5
  1104.    layer entity.  The semantics of the primitive are as follows:
  1105.  
  1106.    AAL5_UNITDATA.req (
  1107.            DATA,
  1108.            CPCS_LP,
  1109.            CPCS_UU
  1110.            )
  1111.  
  1112.    The DATA parameter specifies the AAL5 data to be transferred.  The
  1113.    CPCS_LP parameter specifies the value of the CLP field in the ATM
  1114.    cell.  The CPCS_UU parameter specifies the user-to-user data to be
  1115.    transferred.
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Suzuki                    Expires April, 1998                  [Page 20]
  1121.  
  1122. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1123.  
  1124.  
  1125. 4.2.2.2 AAL5_UNITDATA.ind
  1126.  
  1127.    The AAL5_UNITDATA.ind indicates an AAL5 data (AAL5 CPCS_SDU) delivery
  1128.    from the AAL5 layer entity to the ST2+ data layer entity.  The
  1129.    semantics of the primitive are as follows:
  1130.  
  1131.    AAL5_UNITDATA.ind (
  1132.            DATA,
  1133.            CPCS_LP,
  1134.            CPCS_UU,
  1135.            STATUS [optional]
  1136.            )
  1137.  
  1138.    The DATA parameter indicates the delivered AAL5 data.  The CPCS_LP
  1139.    parameter indicates the value of the CLP field in the ATM cell.  The
  1140.    CPCS_UU parameter indicates the delivered user-to-user data.  The
  1141.    STATUS parameter indicates whether the delivered AAL5 data is corrupt
  1142.    or not.  The STATUS parameter is an optional parameter, and valid
  1143.    only when the corrupted SDU delivery option is selected.
  1144.  
  1145.  
  1146. 4.3 AAL5 Encapsulation for ST2+ Data PDU
  1147.  
  1148. 4.3.1 Mapping from st2_unitdata.req to AAL5_UNITDATA.req
  1149.  
  1150.    The ST2+ Data PDU is directly assigned to the DATA parameter in
  1151.    AAL5_UNITDATA.req.  That is, as shown in Fig. 4.1, the ST2+ Data PDU
  1152.    is mapped to the payload of AAL5 CPCS_PDU.
  1153.  
  1154.    +-------+---------------------------+
  1155.    |  ST   |        ST2+ data          |               ST2+
  1156.    | header|                           |               Data PDU
  1157.    +-------+---------------------------+
  1158.    :                                   :
  1159.    :                                   :
  1160.    +---------------------------------------+--------+
  1161.    |             CPCS_PDU              |PAD|CPCS_PDU|  AAL5
  1162.    |             payload               |   |trailer |  CPCS_PDU
  1163.    +---------------------------------------+--------+
  1164.  
  1165.          Fig. 4.1: Mapping of ST2+ data to AAL5 CPCS_PDU payload.
  1166.  
  1167.    The value of CPCS_LP in AAL5_UNITDATA.req depends on the
  1168.    implementation: 1 (low priority) or zero (high priority) may be
  1169.    assigned permanently, or they may be assigned depending on the value
  1170.    of pri in st2_unitdata.req.
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Suzuki                    Expires April, 1998                  [Page 21]
  1177.  
  1178. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1179.  
  1180.  
  1181.    The value of the CPCS_UU indication field in AAL5_UNITDATA.req is set
  1182.    to zero.
  1183.  
  1184. 4.3.2 Mapping from AAL5_UNITDATA.ind to st2p_unitdata.ind
  1185.  
  1186.    The DATA parameter in AL5_UNITDATA.ind is directly assigned to the
  1187.    ST2+ Data PDU.  That is, the payload in AAL5 CPCS_PDU is mapped to
  1188.    the ST2+ Data PDU.
  1189.  
  1190.    If the value of STATUS in AAL5_UNITDATA.ind is valid, it is assigned
  1191.    to the status in st2p_unitdata.ind.
  1192.  
  1193. 4.3.3 Value of MTU
  1194.  
  1195.    The value of MTU is Maximum CPCS_SDU size.
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232. Suzuki                    Expires April, 1998                  [Page 22]
  1233.  
  1234. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1235.  
  1236.  
  1237. 5. Protocol Specification of the Management Plane
  1238.  
  1239.    The management plane specifies the Null FlowSpec, the Controlled-Load
  1240.    Service FlowSpec, and the Guaranteed Service FlowSpec mapping rules
  1241.    for UNI 3.1 traffic management.
  1242.  
  1243. 5.1 Mapping of the Null FlowSpec
  1244.  
  1245.    The Null FlowSpec is mapped to the UBR (VBR with the Best Effort
  1246.    Indicator).
  1247.  
  1248.    The value of the PCR (CLP=0+1) is shown in section 6.7.2.
  1249.  
  1250. 5.2 Mapping of the Controlled-Load Service FlowSpec
  1251.  
  1252.    The Controlled-Load FlowSpec is mapped to the VBR whose PCR
  1253.    (CLP=0+1), SCR (CLP=0+1), and MBS (CLP=0+1) are specified.
  1254.  
  1255.    The value of the PCR (CLP=0+1) is shown in section 6.7.2.
  1256.  
  1257.    Let scr be the calculated value of the SCR (CLP=0+1).  Based on the
  1258.    value of the [r] field in the Controlled-Load FlowSpec, it is given
  1259.    by:
  1260.                            scr = ([r] / 48) * S,
  1261.  
  1262.    where S is the coefficient of segmentation, and in an implementation,
  1263.    it must be configurable to any value between 1.0 and 56.0.  The
  1264.    recommended default value is 1.2.  The value of the SCR (CLP=0+1) is
  1265.    a minimum integer equal to or more than the calculated value of the
  1266.    scr.
  1267.  
  1268.    Let mbs be the calculated value of the MBS (CLP=0+1).  Based on the
  1269.    value of the [b] field in the Controlled-Load FlowSpec, it is given
  1270.    by:
  1271.                            mbs = ([b] / 48) * S.
  1272.  
  1273.    The value of the MBS (CLP=0+1) is a minimum integer equal to or more
  1274.    than the calculated value of the mbs.
  1275.  
  1276.    The values of the [p] and [m] fields in the Controlled-Load FlowSpec
  1277.    are ignored.
  1278.  
  1279. 5.3 Mapping of the Guaranteed Service FlowSpec
  1280.  
  1281.    Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
  1282.    support Guaranteed Services. It will be supported by the UNI 3.1/4.0
  1283.    version.
  1284.  
  1285.  
  1286.  
  1287.  
  1288. Suzuki                    Expires April, 1998                  [Page 23]
  1289.  
  1290. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1291.  
  1292.  
  1293. 6. Protocol Specification of the Control Plane
  1294.  
  1295.    This section specifies the relationship between ST2+ SCMP and PVC
  1296.    management for ST2+ data, and the protocol interaction between ST2+
  1297.    SCMP and UNI 3.1 signaling.
  1298.  
  1299.  
  1300. 6.1 AAL5 Encapsulation for ST2+ SCMP PDU
  1301.  
  1302.    This subsection describes AAL5 PDU encapsulation for the ST2+ SCMP
  1303.    PDU.  AAL5 encapsulation based on RFC 1483 and on the RFC 1483
  1304.    extension are specified.  Selection of which one to use depends on
  1305.    the implementation.
  1306.  
  1307.    The ST2+ over ATM protocol does not cover a VC (SVC/PVC) that
  1308.    transfers ST2+ SCMP. VCs for IPv4 transfer may be used for ST2+ SCMP
  1309.    transfer, and implementations may provide particular VCs for ST2+
  1310.    SCMP transfer. Selection of these VCs depends on the implementation.
  1311.  
  1312. 6.1.1 RFC 1483 base encapsulation
  1313.  
  1314.    The RFC 1483 base encapsulation is shown in Fig. 6.1: the ST2+ SCMP
  1315.    PDU with the RFC 1483 LLC encapsulation for routed protocol format is
  1316.    mapped to the payload in AAL5 CPCS_PDU.  Implementors should note
  1317.    that this is not same as AAL5 encapsulation for the ST2+ Data PDU
  1318.    (the LLC is required).
  1319.  
  1320.                +------+----------------+
  1321.                |  ST  |   ST2+ SCMP    |               ST2+
  1322.                |header|                |               SCMP PDU
  1323.                +------+----------------+
  1324.                :                       :
  1325.    +---+---+---+-----------------------+
  1326.    |LLC|OUI|PID|     Information       |               IEEE 802 SNAP
  1327.    |   |   |   |                       |               ISO 8802-2 LLC
  1328.    +---+---+---+-----------------------+
  1329.    :                                   :
  1330.    +---------------------------------------+--------+
  1331.    |             CPCS_PDU              |PAD|CPCS_PDU|  AAL5
  1332.    |             payload               |   |trailer |  CPCS_PDU
  1333.    +---------------------------------------+--------+
  1334.  
  1335.        Fig. 6.1: Mapping of ST2+ SCMP PDU to AAL5 CPCS_PDU payload.
  1336.  
  1337.    The value of the LLC is 0xAA-AA-03, the value of the OUI is 0x00-00-
  1338.    00, and the value of the PID is 0x08-00.  The classification of the
  1339.    IPv4 and the ST2+ SCMP is determined by the IP version number, which
  1340.    is located in the first four bits of the IPv4 or ST headers.
  1341.  
  1342.  
  1343.  
  1344. Suzuki                    Expires April, 1998                  [Page 24]
  1345.  
  1346. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1347.  
  1348.  
  1349. 6.1.2 RFC 1483 extension base encapsulation
  1350.  
  1351.    The RFC 1483 extension base encapsulation is the same as for RFC 1483
  1352.    base encapsulation, except that the value of the OUI is 0x00-00-5E
  1353.    (IANA) and the value of the PID is 0xXX-XX (TBD).
  1354.  
  1355.    The RFC 1483 base encapsulation for the SCMP is ideal, but requires
  1356.    modifying the IPv4 processing in the driver software of the WS or PC.
  1357.    Therefore, the RFC 1483 base encapsulation may be difficult to
  1358.    implement.  This encapsulation is designed to solve this problem.
  1359.  
  1360.  
  1361. 6.2 Service Primitives Provided by Control Plane
  1362.  
  1363.    RFC 1819 ST2+ does not specify SCMP state machines.  And the ST2+
  1364.    over ATM protocol does not correspond to SCMP state machines.
  1365.    Therefore, the control plane specification assumes the following.
  1366.  
  1367.    o The ST2+ agent has ST2+ SCMP layer entities that correspond to the
  1368.      next hops and the previous hop in the stream.
  1369.  
  1370.    o The SCMP layer entity terminates ACK, ERROR, and timeout processing
  1371.      and provides reliable SCMP delivery.
  1372.  
  1373.    o The origin consists of an upper layer entity, ST2+ SCMP layer
  1374.      entities for next hops, and a routing machine that delivers SCMP
  1375.      messages between these entities.
  1376.  
  1377.    o The intermediate agent consists of ST2+ SCMP layer entities for a
  1378.      previous hop and for next hops and a routing machine that delivers
  1379.      SCMP messages between these entities.
  1380.  
  1381.    o The target consists of an upper layer entity, an ST2+ SCMP layer
  1382.      entity for a previous hop, and a routing machine that delivers SCMP
  1383.      messages between these entities.
  1384.  
  1385.    At least, the ST2+ SCMP layer entity for the next hop provides the
  1386.    following services to the routing machine.
  1387.  
  1388.    o connect.req
  1389.      This primitive sends a request for a CONNECT message transfer to
  1390.      the ST2+ SCMP layer entity.
  1391.  
  1392.    o change.req
  1393.      This primitive sends a request for a CHANGE message transfer to the
  1394.      ST2+ SCMP layer entity.
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400. Suzuki                    Expires April, 1998                  [Page 25]
  1401.  
  1402. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1403.  
  1404.  
  1405.    o accept.ind
  1406.      This primitive indicates an ACCEPT message delivery from the ST2+
  1407.      SCMP layer entity.
  1408.  
  1409.    o disconnect.req
  1410.      This primitive sends a request for a DISCONNECT message transfer to
  1411.      the ST2+ SCMP layer entity.
  1412.  
  1413.    o refuse.ind
  1414.      This primitive indicates a REFUSE message delivery from the ST2+
  1415.      SCMP layer entity, or indicates detection of an abnormal status
  1416.      such as an illegal message or timeout in the ST2+ SCMP layer
  1417.      entity.
  1418.  
  1419.    At least, the ST2+ SCMP layer entity for the previous hop provides
  1420.    the following services to the routing machine.
  1421.  
  1422.    o connect.ind
  1423.      This primitive indicates a CONNECT message delivery from the ST2+
  1424.      SCMP layer entity.
  1425.  
  1426.    o change.ind
  1427.      This primitive indicates a CHANGE message delivery from the ST2+
  1428.      SCMP layer entity.
  1429.  
  1430.    o accept.req
  1431.      This primitive sends a request for an ACCEPT message transfer to
  1432.      the ST2+ SCMP layer entity.
  1433.  
  1434.    o disconnect.ind
  1435.      This primitive indicates a DISCONNECT message delivery from the
  1436.      ST2+ SCMP layer entity, or indicates detection of an abnormal
  1437.      status such as an illegal message or timeout in the ST2+ SCMP layer
  1438.      entity.
  1439.  
  1440.    o refuse.req
  1441.      This primitive sends a request for a REFUSE message transfer to the
  1442.      ST2+ SCMP layer entity.
  1443.  
  1444.  
  1445. 6.3 Service Primitives Provided by UNI 3.1 Signaling
  1446.  
  1447.    The UNI 3.1 signaling layer entity on the ST2+ over ATM control plane
  1448.    provides the following services to the ST2+ SCMP layer entity.  The
  1449.    ST2+ over ATM protocol does not specify the UNI 3.1 signaling state
  1450.    machines.  These are defined in [10, 12, 13].
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456. Suzuki                    Expires April, 1998                  [Page 26]
  1457.  
  1458. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1459.  
  1460.  
  1461.    o setup.req
  1462.      This primitive sends a request for a SETUP message transfer from
  1463.      the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
  1464.      The ST2+ SCMP layer entity that sent this primitive receives an
  1465.      acknowledgment.  If the setup succeeds the acknowledgment is a
  1466.      setup.conf primitive and if the setup fails it is a release.ind or
  1467.      release.conf primitive.
  1468.  
  1469.    o setup.conf
  1470.      This primitive indicates a CONNECT message delivery from the UNI
  1471.      3.1 signaling layer entity to the ST2+ SCMP layer entity.
  1472.  
  1473.    o setup.ind
  1474.      This primitive indicates a SETUP message delivery from the UNI 3.1
  1475.      signaling layer entity to the ST2+ SCMP layer entity.  The ST2+
  1476.      SCMP layer entity that received this primitive sends an
  1477.      acknowledgment.  If the setup is accepted the acknowledgment is a
  1478.      setup.resp primitive and if the setup is rejected it is a
  1479.      release.resp primitive if the state of the UNI 3.1 signaling layer
  1480.      entity is U6; otherwise it is a release.req primitive.
  1481.  
  1482.    o setup.resp
  1483.      This primitive sends a request for a CONNECT message transfer from
  1484.      the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
  1485.      The ST2+ SCMP layer entity that sent this primitive receives an
  1486.      acknowledgment.  If the setup is completed the acknowledgment is a
  1487.      setup-complete.ind primitive and if the setup fails it is a
  1488.      release.ind or release.conf primitive.
  1489.  
  1490.    o setup-complete.ind
  1491.      This primitive indicates a CONNECT ACKNOWLEDGE message delivery
  1492.      from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer
  1493.      entity.
  1494.  
  1495.    o release.req
  1496.      This primitive sends a request for a RELEASE message transfer from
  1497.      the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
  1498.      The ST2+ SCMP layer entity that sent this primitive receives an
  1499.      acknowledgment that is a release.conf primitive.
  1500.  
  1501.    o release.conf
  1502.      This primitive indicates a RELEASE COMPLETE message delivery, or
  1503.      indicates a RELEASE message delivery when the status of the UNI 3.1
  1504.      signaling layer entity is U11, or indicates detection of an
  1505.      abnormal status such as an illegal message or timeout in the UNI
  1506.      3.1 signaling layer entity, from the UNI 3.1 signaling layer entity
  1507.      to the ST2+ SCMP layer entity.
  1508.  
  1509.  
  1510.  
  1511.  
  1512. Suzuki                    Expires April, 1998                  [Page 27]
  1513.  
  1514. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1515.  
  1516.  
  1517.    o release.ind
  1518.      This primitive indicates a RELEASE message delivery from the UNI
  1519.      3.1 signaling layer entity to the ST2+ SCMP layer entity when the
  1520.      status of the UNI 3.1 signaling layer entity is other than U11.
  1521.      The ST2+ SCMP layer entity that received this primitive sends an
  1522.      acknowledgment that is a release.resp primitive.  And this
  1523.      primitive also indicates detection of an abnormal status such as an
  1524.      illegal message or timeout in the UNI 3.1 signaling layer entity
  1525.      and then a REFUSE message is transferred.  In this case, the ST2+
  1526.      SCMP layer entity that received this primitive receives a
  1527.      release.conf primitive in succession.
  1528.  
  1529.    o release.resp
  1530.      This primitive sends a request for a RELEASE COMPLETE message
  1531.      transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling
  1532.      layer entity.
  1533.  
  1534.    o add-party.req
  1535.      This primitive sends a request for an ADD PARTY message transfer
  1536.      from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer
  1537.      entity.  The ST2+ SCMP layer entity that sent this primitive
  1538.      receives an acknowledgment.  If the setup is succeeds the
  1539.      acknowledgment is an add-party.conf primitive and if the setup
  1540.      fails it is a drop-party.conf primitive.
  1541.  
  1542.    o add-party.conf
  1543.      This primitive indicates an ADD PARTY ACKNOWLEDGE message delivery
  1544.      from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer
  1545.      entity.
  1546.  
  1547.    o drop-party.req
  1548.      This primitive sends a request for a DROP PARTY message transfer
  1549.      from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer
  1550.      entity.  The ST2+ SCMP layer entity that sent this primitive
  1551.      receives an acknowledgment that is a drop-party.conf primitive.
  1552.  
  1553.    o drop-party.conf
  1554.      This primitive indicates an ADD PARTY REJECT message delivery, or
  1555.      indicates a DROP PARTY ACKNOWLEDGE message delivery, or indicates
  1556.      detection of an abnormal status such as an illegal message or
  1557.      timeout in the UNI 3.1 signaling layer entity, from the UNI 3.1
  1558.      signaling layer entity to the ST2+ SCMP layer entity.
  1559.  
  1560.    o drop-party.ind
  1561.      This primitive indicates a DROP PARTY message delivery from the UNI
  1562.      3.1 signaling layer entity to the ST2+ SCMP layer entity.  The ST2+
  1563.      SCMP layer entity that sent this primitive receives an
  1564.      acknowledgment that is a drop-party.resp primitive.
  1565.  
  1566.  
  1567.  
  1568. Suzuki                    Expires April, 1998                  [Page 28]
  1569.  
  1570. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1571.  
  1572.  
  1573.    o drop-party.resp
  1574.      This primitive sends a request for a DROP PARTY ACKNOWLEDGE message
  1575.      transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling
  1576.      layer entity.
  1577.  
  1578.  
  1579. 6.4 VC Style Selection Criteria
  1580.  
  1581.    The ST2+ over ATM protocol supports PVC, the reverse channel of bi-
  1582.    directional SVC, point-to-point SVC, and point-to-multipoint SVC for
  1583.    ST2+ Data PDU transfer.  And SVC supports both upstream and
  1584.    downstream call initiation styles.
  1585.  
  1586.    A 32-bit PVC identifier that is unique between neighboring ST2+
  1587.    agents is assigned to each PVC.  And the reverse channel of the bi-
  1588.    directional point-to-point SVC used by the existing stream is
  1589.    identified by the SID of the stream that occupies the forward
  1590.    channel.
  1591.  
  1592.    When the ST2+ agent sets up a stream or changes QoS, the ST2+ agent
  1593.    must select one VC style from these SVC and PVC styles as a hop that
  1594.    is part of the stream.  In the ST2+ over ATM protocol, VC style
  1595.    selection criteria depend on the implementation.
  1596.  
  1597.    This subsection describes examples of VC style selection criteria for
  1598.    the ST2+ over ATM protocol as a reference for implementors.  Note
  1599.    that the following descriptions in this subsection are not part of
  1600.    the ST2+ over ATM protocol specification.
  1601.  
  1602. 6.4.1 Examples of PVC selection criteria
  1603.  
  1604.    At least, the ST2+ agent may have to manage the following information
  1605.    for each PVC that can be used by ST2+ Data PDU transfer.
  1606.  
  1607.    o PVC identifier
  1608.  
  1609.    o ATM interface identifier in the ST2+ agent
  1610.  
  1611.    o VPI/VCI
  1612.  
  1613.    o State of VC: e.g. enabled or disabled, occupied or vacant
  1614.  
  1615.    o QoS of VC
  1616.  
  1617.    o Nexthop IP address
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624. Suzuki                    Expires April, 1998                  [Page 29]
  1625.  
  1626. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1627.  
  1628.  
  1629.    When a PVC is selected for a hop of a stream, at least confirmations,
  1630.    that is the state of the PVC is vacant and the next hop IP address
  1631.    and QoS are consistent with the requirements from the stream, may be
  1632.    needed.
  1633.  
  1634.    It is also feasible to introduce access lists to each PVC and to
  1635.    consider the access lists in the selection process.  Examples of an
  1636.    access list are shown in the following.
  1637.  
  1638.    o Permit or deny use by a stream whose the previous hop is specified.
  1639.  
  1640.    o Permit or deny use by a stream whose the origin is specified.
  1641.  
  1642.    o Permit or deny use by a stream whose the SID is specified.
  1643.  
  1644.    o Permit or deny use by a stream whose the target is specified.
  1645.  
  1646.    o Permit or deny use by a stream whose the target and SAP are
  1647.      specified.
  1648.  
  1649.    o Any combination of the above.
  1650.  
  1651. 6.4.2 Examples of reverse channel of bi-directional SVC selection
  1652.    criteria
  1653.  
  1654.    At least, the ST2+ agent may have to manage the following information
  1655.    for each reverse channel of bi-directional SVCs.
  1656.  
  1657.    o SID of the stream that occupies the forward channel
  1658.  
  1659.    o ATM interface identifier in the ST2+ agent
  1660.  
  1661.    o VPI/VCI
  1662.  
  1663.    o State of the reverse channel in the VC: e.g. enabled or disabled,
  1664.      occupied or vacant
  1665.  
  1666.    o QoS of VC
  1667.  
  1668.    o Nexthop IP address
  1669.  
  1670.    When a reverse channel of the bi-directional point-to-point SVC used
  1671.    by the existing stream is selected for a hop of a stream, at least
  1672.    confirmations, that is the state of the channel is vacant and the
  1673.    next hop IP address and QoS are consistent with the requirements from
  1674.    the stream, may be needed.
  1675.  
  1676.    It is also feasible to introduce selection rules to the ST2+ agent.
  1677.  
  1678.  
  1679.  
  1680. Suzuki                    Expires April, 1998                  [Page 30]
  1681.  
  1682. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1683.  
  1684.  
  1685.    Examples of selection rule are shown in the following.
  1686.  
  1687.    o Permit reuse of the reverse channel by a stream whose the origin is
  1688.      one of targets in the stream that occupies the forward channel.
  1689.  
  1690.    o Permit reuse of the reverse channel by a stream whose one of
  1691.      targets is the origin in the stream that occupies the forward
  1692.      channel.
  1693.  
  1694.    o Permit reuse of the reverse channel by a stream whose the previous
  1695.      hop is one of the next hops in the stream that occupies the forward
  1696.      channel.
  1697.  
  1698.    o Any combination of the avobe.
  1699.  
  1700. 6.4.3 Examples of SVC selection criteria
  1701.  
  1702.    When an SVC is used for a hop of a stream, at first, the ST2+ agent
  1703.    must select point-to-point or point-to-multipoint SVC.  Examples of
  1704.    this selection rule are shown in the following.
  1705.  
  1706.    o If the network supports only point-to-point SVC, select it.
  1707.  
  1708.    o If the network supports point-to-multipoint SVC, select it.
  1709.  
  1710.    If point-to-point SVC is selected, the ST2+ agent must select
  1711.    upstream or downstream call initiation style.  Examples of this
  1712.    selection rule are shown in the following.
  1713.  
  1714.    o A VC for a stream whose previous hop is specified is initiated from
  1715.      upstream or downstream.
  1716.  
  1717.    o A VC for a stream whose next hop is specified is initiated from
  1718.      upstream or downstream.
  1719.  
  1720.    o A VC for a stream whose origin is specified is initiated from
  1721.      upstream or downstream.
  1722.  
  1723.    o A VC for a stream whose SID is specified is initiated from upstream
  1724.      or downstream.
  1725.  
  1726.    o A VC for a stream whose target is specified is initiated from
  1727.      upstream or downstream.
  1728.  
  1729.    o A VC for a stream whose target and SAP are specified is initiated
  1730.      from upstream or downstream.
  1731.  
  1732.    o Any combination of the above.
  1733.  
  1734.  
  1735.  
  1736. Suzuki                    Expires April, 1998                  [Page 31]
  1737.  
  1738. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1739.  
  1740.  
  1741. 6.5 VC Management
  1742.  
  1743.    This subsection specifies VC management in the ST2+ over ATM
  1744.    protocol.
  1745.  
  1746. 6.5.1 Outgoing call processing of SVC
  1747.  
  1748.    When outgoing call processing of the first leaf of a point-to-
  1749.    multipoint SVC or a point-to-point SVC is required inside the ST2+
  1750.    SCMP layer entity, a setup.req primitive is sent to the UNI 3.1
  1751.    signaling layer entity.  If the UNI 3.1 signaling layer entity
  1752.    responds with a setup.conf primitive, the call processing is assumed
  1753.    to have succeeded.  If the UNI 3.1 signaling layer entity responds
  1754.    with anything other than this primitive, the processing rule is the
  1755.    same as the SVC disconnect processing that is shown in section 6.5.4
  1756.    and the outgoing call processing is assumed to have failed.
  1757.  
  1758.    When outgoing call processing of a later leaf of a point-to-
  1759.    multipoint SVC is required, an add-party.req primitive is sent to the
  1760.    UNI 3.1 signaling layer entity.  If the UNI 3.1 signaling layer
  1761.    entity responds with an add-party.conf primitive, the call processing
  1762.    is assumed to have succeeded.  If the UNI 3.1 signaling layer entity
  1763.    responds with anything other than this primitive, the processing rule
  1764.    is the same as the SVC disconnect processing that is shown in section
  1765.    6.5.4 and the outgoing call processing is assumed to have failed.
  1766.  
  1767. 6.5.2 Incoming call processing of SVC
  1768.  
  1769.    When an incoming call processing of SVC is required inside the ST2+
  1770.    SCMP layer entity, it sets a watchdog timer.  The time interval of
  1771.    the timer depends on the implementation.
  1772.  
  1773.    The ST2+ SCMP layer entity waits for a setup.ind primitive indication
  1774.    from the UNI 3.1 signaling layer entity.  When this primitive is
  1775.    indicated and the parameters in it are acceptable, the ST2+ SCMP
  1776.    layer entity responds with a setup.resp primitive.  If the parameters
  1777.    are not acceptable, the ST2+ SCMP layer entity stops the timer, and
  1778.    if the state of the UNI 3.1 signaling layer entity is U6, the entity
  1779.    responds with a release.resp primitive, and if the state is other
  1780.    than this, the entity responds with a release.req primitive, and then
  1781.    waits for a release.conf primitive response and the incoming call
  1782.    processing is assumed to have failed.
  1783.  
  1784.    If the ST2+ SCMP layer entity responds with a setup.resp primitive,
  1785.    then the entity waits for the next primitive indication, and when the
  1786.    next primitive is indicated, the ST2+ SCMP layer entity stops the
  1787.    timer.  If a setup-complete.ind primitive is indicated, the incoming
  1788.    call processing is assumed to have succeeded.  If the UNI 3.1
  1789.  
  1790.  
  1791.  
  1792. Suzuki                    Expires April, 1998                  [Page 32]
  1793.  
  1794. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1795.  
  1796.  
  1797.    signaling layer entity responds with anything other than this
  1798.    primitive or if the timer expires, the processing rule is the same as
  1799.    the SVC disconnect processing that is shown in section 6.5.4 and the
  1800.    incoming call processing is assumed to have failed.
  1801.  
  1802. 6.5.3 VC release processing inside ST2+ SCMP layer
  1803.  
  1804.    When a VC release is required inside an ST2+ SCMP layer entity, if
  1805.    the previous hop or next hop is connected with a PVC, the PVC state
  1806.    is set to vacant and the VC release processing is assumed to be
  1807.    completed.
  1808.  
  1809.    If the previous hop or next hop is connected with a point-to-point
  1810.    SVC whose reverse channel is occupied, the state of the channel in
  1811.    the VC is set to vacant, the SID information of the VC is updated,
  1812.    and the VC release processing is assumed to be completed.
  1813.  
  1814.    If the previous hop or next hop is connected with a point-to-point
  1815.    SVC whose reverse channel is vacant, if the previous hop is connected
  1816.    with a point-to-multipoint SVC, or if the next hop is connected with
  1817.    a point-to-multipoint SVC and the number of leaves is 1, then the
  1818.    ST2+ SCMP layer entity sends a release.req primitive to the UNI 3.1
  1819.    signaling layer entity, then waits for a release.conf primitive
  1820.    indication; when one is indicated, the VC release processing is
  1821.    assumed to be completed.
  1822.  
  1823.    If the next hop is connected with a point-to-multipoint SVC and the
  1824.    number of leaves is other than 1, the ST2+ SCMP layer entity sends a
  1825.    drop-party.req primitive to the UNI 3.1 signaling layer entity, then
  1826.    waits for a drop-party.conf primitive indication; when one is
  1827.    indicated, the VC release processing is assumed to be completed.
  1828.  
  1829. 6.5.4 VC disconnect processing from UNI 3.1 signaling layer
  1830.  
  1831.    If an ST2+ SCMP layer entity corresponds to a UNI 3.1 signaling layer
  1832.    entity, and if the ST2+ SCMP layer entity is sent a release.ind
  1833.    primitive from the UNI 3.1 signaling layer entity, whose cause is a
  1834.    delivery of a RELEASE message, the ST2+ SCMP layer entity responds
  1835.    with a release.resp primitive, and then the VC disconnect processing
  1836.    is assumed to be completed.  If the ST2+ SCMP layer entity is sent a
  1837.    release.ind primitive, whose cause is other than the previous case,
  1838.    the ST2+ SCMP layer entity waits for a release.conf primitive
  1839.    response.  When a release.conf primitive is indicated, the VC
  1840.    disconnect processing is assumed to be completed.
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848. Suzuki                    Expires April, 1998                  [Page 33]
  1849.  
  1850. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1851.  
  1852.  
  1853.    Note that if next hops from ST2+ SCMP layer entities are connected
  1854.    with a point-to-multipoint SVC, the ST2+ SCMP layer entities to next
  1855.    hops correspond to a UNI 3.1 signaling layer entity.  In this case,
  1856.    if the ST2+ SCMP layer entities are sent release.ind primitives from
  1857.    the UNI 3.1 signaling layer entity, whose cause is the delivery of a
  1858.    RELEASE message, one of the ST2+ SCMP layer entities responds with a
  1859.    release.resp primitive, and then the VC disconnect processing in the
  1860.    entities that are sent release.ind primitives are assumed to be
  1861.    completed.  If the ST2+ SCMP layer entities are sent release.ind
  1862.    primitives, whose cause is other than the previous case, the ST2+
  1863.    SCMP layer entities wait for release.conf primitives responses.  When
  1864.    release.conf primitives are indicated, the VC disconnect processing
  1865.    in the entities that are indicated release.ind primitives are assumed
  1866.    to be completed.
  1867.  
  1868.    If the ST2+ SCMP layer entity is sent a drop-party.ind primitive from
  1869.    the UNI 3.1 signaling layer entity, the ST2+ SCMP layer entity
  1870.    responds with a drop-party.resp primitive, and then the VC disconnect
  1871.    processing is assumed to be completed.  If the ST2+ SCMP layer entity
  1872.    is sent a drop-party.conf primitive, the VC disconnect processing is
  1873.    assumed to be completed.
  1874.  
  1875.  
  1876. 6.6 Additional SCMP Processing Rules
  1877.  
  1878.    This subsection specifies the additional SCMP processing rules that
  1879.    are defined in RFC 1819 ST2+ protocol specification.  The following
  1880.    additional rules are applied when the previous hop or next hop is
  1881.    connected with an ATM connection in the ST2+ SCMP layer entity.
  1882.  
  1883. 6.6.1 Additional connect.req processing rules
  1884.  
  1885.    When a connect.req primitive is sent to the ST2+ SCMP layer entity
  1886.    for the next hop, the entity confirms whether or not the VC for the
  1887.    next hop exists.
  1888.  
  1889.    If it does, the entity forwards a CONNECT message that does not
  1890.    include a VC-type common SCMP element to the next hop.
  1891.  
  1892.    If it does not, the entity selects a VC style.  If the result is a
  1893.    PVC or a reverse channel of a bi-directional point-to-point SVC used
  1894.    by an existing stream, the VC state is set to occupied.  The entity
  1895.    forwards a CONNECT message with a VC-type common SCMP element that
  1896.    reflects the result of the selection to the next hop.
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904. Suzuki                    Expires April, 1998                  [Page 34]
  1905.  
  1906. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1907.  
  1908.  
  1909. 6.6.2 Additional connect.ind processing rules
  1910.  
  1911.    The ST2+ SCMP layer entity for the previous hop confirms whether or
  1912.    not the CONNECT message includes a VC-type common SCMP element.
  1913.  
  1914.    If a VC-type common SCMP element is not included and the VC for the
  1915.    next hop exists, a connect.ind primitive is sent to the routing
  1916.    machine.  If the VC for the next hop does not exist, a REFUSE message
  1917.    is forwarded to the previous hop.
  1918.  
  1919.    If a VC-type common SCMP element is included and a point-to-point
  1920.    SVC, whose calling party is the upstream or downstream, or a point-
  1921.    to-multipoint SVC is specified, a connect.ind primitive is sent to
  1922.    the routing machine.  If a PVC or a reverse channel of a bi-
  1923.    directional point-to-point SVC used by an existing stream is
  1924.    specified and the specified VC exists, the VC state is set to
  1925.    occupied and a connect.ind primitive is sent to the routing machine.
  1926.    Otherwise, a REFUSE message is forwarded to the previous hop.
  1927.  
  1928. 6.6.3 Additional change.req processing rules
  1929.  
  1930.    When a change.req primitive is sent to the ST2+ SCMP layer entity for
  1931.    the next hop, the entity releases the VC whose process is shown in
  1932.    section 6.5.3.
  1933.  
  1934.    Then, the entity selects a VC style.  If the result is a PVC or a
  1935.    reverse channel of a bi-directional point-to-point SVC used by an
  1936.    existing stream, the VC state is set to occupied.  The entity
  1937.    forwards a CHANGE message with a VC-type common SCMP element that
  1938.    reflects the result of the selection to the next hop.
  1939.  
  1940. 6.6.4 Additional change.ind processing rules
  1941.  
  1942.    The ST2+ SCMP layer entity for the previous hop confirms whether the
  1943.    CHANGE message includes a VC-type common SCMP element.  If a VC-type
  1944.    common SCMP element is not included, a REFUSE message is forwarded to
  1945.    the previous hop.
  1946.  
  1947.    If a VC-type common SCMP element is included, the entity releases the
  1948.    VC whose process is shown in section 6.5.3.  If the element specifies
  1949.    a point-to-point SVC, whose calling party is the upstream or
  1950.    downstream, or a point-to-multipoint SVC, a change.ind primitive is
  1951.    sent to the routing machine.  If a PVC or a reverse channel of a bi-
  1952.    directional point-to-point SVC used by an existing stream is
  1953.    specified and the specified VC exists, the VC state is set to
  1954.    occupied and a change.ind primitive is sent to the routing machine.
  1955.    Otherwise, a REFUSE message is forwarded to the previous hop.
  1956.  
  1957.  
  1958.  
  1959.  
  1960. Suzuki                    Expires April, 1998                  [Page 35]
  1961.  
  1962. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  1963.  
  1964.  
  1965. 6.6.5 Additional accept.req processing rules
  1966.  
  1967.    When an accept.req primitive is sent to the ST2+ SCMP layer entity
  1968.    for the previous hop, the entity confirms the state of the UNI 3.1
  1969.    signaling layer entity.  If the state of the entity is other than U0
  1970.    or U10, the accept.req primitive is queued and is processed after the
  1971.    state changes to U0 or U10.
  1972.  
  1973.    If the state of the entity is U0 or U10, the ST2+ SCMP layer entity
  1974.    confirms whether or not the VC for the previous hop exists.  If it
  1975.    does, an ACCEPT message is forwarded to the previous hop.
  1976.  
  1977.    If it does not and the CONNECT or CHANGE message that corresponds to
  1978.    the accept.req primitive specified a point-to-point SVC whose calling
  1979.    party is the upstream or a point-to-multipoint SVC, then the entity
  1980.    processes an incoming call that is shown in section 6.5.2.  If the
  1981.    incoming call processing succeeds, an ACCEPT message is forwarded to
  1982.    the previous hop.  If the CONNECT or CHANGE message that corresponds
  1983.    to the accept.req primitive specified a point-to-point SVC whose
  1984.    calling party is downstream, the entity converts from the IP address
  1985.    of the previous hop to the ATM address, and then the entity processes
  1986.    an outgoing call that is shown in section 6.5.1.  If the outgoing
  1987.    call processing succeeds, an ACCEPT message is forwarded to the
  1988.    previous hop.  For cases other than those described above or if the
  1989.    incoming or outgoing call processing fails, a REFUSE message is
  1990.    forwarded to the previous hop and a disconnect.ind primitive is sent
  1991.    to the routing machine.
  1992.  
  1993. 6.6.6 Additional accept.ind processing rules
  1994.  
  1995.    When an ACCEPT message is processed in the ST2+ SCMP layer entity for
  1996.    the next hop, the entity confirms the state of the UNI 3.1 signaling
  1997.    layer entity.  If the state of the entity is other than U0 or U10,
  1998.    the ACCEPT message is queued and is processed after the state changes
  1999.    to U0 or U10.
  2000.  
  2001.    If the state of the entity is U0 or U10, the ST2+ SCMP layer entity
  2002.    confirms whether or not the VC for the next hop exists.  If it does,
  2003.    an accept.ind primitive is sent to the routing machine.
  2004.  
  2005.    If it does not and the CONNECT or CHANGE message that corresponds to
  2006.    the ACCEPT message specified a point-to-point SVC whose calling party
  2007.    is the upstream or a point-to-multipoint SVC, then the entity
  2008.    converts from the IP address of the next hop to the ATM address, and
  2009.    then the entity processes an outgoing call that is shown in section
  2010.    6.5.1.  If the outgoing call processing succeeds, an accept.ind
  2011.    primitive is sent to the routing machine.  If the CONNECT or CHANGE
  2012.    message that corresponds to the ACCEPT message specified a point-to-
  2013.  
  2014.  
  2015.  
  2016. Suzuki                    Expires April, 1998                  [Page 36]
  2017.  
  2018. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2019.  
  2020.  
  2021.    point SVC whose calling party is downstream, the entity processes an
  2022.    incoming call that is shown in section 6.5.2.  If the incoming call
  2023.    processing succeeds, an accept.ind primitive is sent to the routing
  2024.    machine.  For cases other than those described above or if the
  2025.    incoming or outgoing call processing fails, a refuse.ind primitive is
  2026.    sent to the routing machine and a DISCONNECT message is forwarded to
  2027.    the next hop.
  2028.  
  2029. 6.6.7 Additional disconnect.req processing rules
  2030.  
  2031.    At first, the ST2+ SCMP layer entity for the next hop forwards a
  2032.    DISCONNECT message to the next hop.
  2033.  
  2034.    And then, after the disconnect.req processing, if there are no more
  2035.    targets that are connected downstream of the entity and the entity is
  2036.    not waiting for an ACCEPT or REFUSE message response from targets,
  2037.    the entity releases the VC whose process is shown in section 6.5.3.
  2038.  
  2039. 6.6.8 Additional disconnect.ind processing rules
  2040.  
  2041.    AT first, after the disconnect.ind processing, if there are no more
  2042.    targets that are connected downstream of the ST2+ SCMP layer entity
  2043.    for the previous hop and the entity is not waiting for an ACCEPT or
  2044.    REFUSE message response from targets, the entity releases the VC
  2045.    whose process is shown in section 6.5.3.
  2046.  
  2047.    And then, the entity sends a disconnect.ind primitive to the routing
  2048.    machine.
  2049.  
  2050. 6.6.9 Additional refuse.req processing rules
  2051.  
  2052.    At first, the ST2+ SCMP layer entity for the previous hop forwards a
  2053.    REFUSE message to the previous hop.
  2054.  
  2055.    And then, after the refuse.req processing, if there are no more
  2056.    targets that are connected downstream of the entity and the entity is
  2057.    not waiting for an ACCEPT or REFUSE message response from targets,
  2058.    the entity releases the VC whose process is shown in section 6.5.3.
  2059.  
  2060. 6.6.10 Additional refuse.ind processing rules
  2061.  
  2062.    At first, after the refuse.ind processing, if there are no more
  2063.    targets that are connected downstream of the ST2+ SCMP layer entity
  2064.    for the next hop and the entity is not waiting for an ACCEPT or
  2065.    REFUSE message response from targets, the entity releases the VC
  2066.    whose process is shown in section 6.5.3.
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072. Suzuki                    Expires April, 1998                  [Page 37]
  2073.  
  2074. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2075.  
  2076.  
  2077.    And then, the entity sends a refuse.ind primitive to the routing
  2078.    machine.
  2079.  
  2080. 6.6.11 SVC disconnect processing
  2081.  
  2082.    When the ST2+ SCMP layer entity for the previous hop is sent a SVC
  2083.    disconnect processing from the UNI 3.1 signaling layer entity and
  2084.    then the SVC disconnect processing is completed, the entity forwards
  2085.    a REFUSE message to the previous hop and sends a disconnect.ind
  2086.    primitive to the routing machine.
  2087.  
  2088.    When the ST2+ SCMP layer entity for the next hop is sent a SVC
  2089.    disconnect processing from the UNI 3.1 signaling layer entity and
  2090.    then the SVC disconnect processing is completed, the entity sends a
  2091.    refuse.ind primitive to the routing machine and forwards a DISCONNECT
  2092.    message to the previous hop.
  2093.  
  2094.  
  2095. 6.7 UNI 3.1 Signaling Information Element Coding Rules
  2096.  
  2097.    The ST2+ over ATM protocol does not specify the coding rules needed
  2098.    for the following information elements in UNI 3.1 signaling.  The
  2099.    usages of these information elements are specified in [10].
  2100.  
  2101.    o Protocol discriminator
  2102.  
  2103.    o Call reference
  2104.  
  2105.    o Message type
  2106.  
  2107.    o Message length
  2108.  
  2109.    o Call state
  2110.  
  2111.    o Called party number
  2112.  
  2113.    o Called party subaddress
  2114.  
  2115.    o Calling party number
  2116.  
  2117.    o Calling party subaddress
  2118.  
  2119.    o Cause
  2120.  
  2121.    o Connection identifier
  2122.  
  2123.    o Broadband repeat indicator
  2124.  
  2125.  
  2126.  
  2127.  
  2128. Suzuki                    Expires April, 1998                  [Page 38]
  2129.  
  2130. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2131.  
  2132.  
  2133.    o Restart indicator
  2134.  
  2135.    o Broadband sending complete
  2136.  
  2137.    o Transit network selection
  2138.  
  2139.    o Endpoint reference
  2140.  
  2141.    o Endpoint state
  2142.  
  2143. 6.7.1 ATM adaptation layer parameters coding
  2144.  
  2145.    The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must
  2146.    include an ATM adaptation layer parameters information element.  The
  2147.    CONNECT message may or may not include this element.  The coding
  2148.    rules for the fields are as follows.
  2149.  
  2150.    o The AAL Type is set to AAL5.
  2151.  
  2152.    o The value of the Forward maximum CPCS size field is set to the same
  2153.      as that of the MaxMsgSize field in the CONNECT SCMP message
  2154.      corresponding to the SETUP or ADD PARTY message.
  2155.  
  2156.    o If the VC is established as a point-to-point call, the value of the
  2157.      Backward maximum CPCS size field is set the same as that of the
  2158.      Forward maximum CPCS size field.  If the VC is established as a
  2159.      point-to-multipoint call, the value of the Backward maximum CPCS
  2160.      size field is set to zero.
  2161.  
  2162.    o The SSCS type is set to null.
  2163.  
  2164. 6.7.2 ATM traffic descriptor coding
  2165.  
  2166.    If the Null FlowSpec is specified in the ST2+ over ATM protocol, the
  2167.    coding rules for the fields in the ATM traffic descriptor information
  2168.    element in the SETUP message are as follows.
  2169.  
  2170.    o The value of the Forward PCR (CLP=0+1) field depends on the
  2171.      specification of the ATM network.  The Forward PCR (CLP=0+1) field
  2172.      in each ATM interface in an implementation must be configurable to
  2173.      any value between zero and 16,777,215.
  2174.  
  2175.    o If the VC is established as a point-to-point call, the value of the
  2176.      Backward PCR (CLP=0+1) field is set the same as that of the Forward
  2177.      PCR (CLP=0+1) field.  If the VC is established as a point-to-
  2178.      multipoint call, the value of the Backward PCR (CLP=0+1) field is
  2179.      set to zero.
  2180.  
  2181.  
  2182.  
  2183.  
  2184. Suzuki                    Expires April, 1998                  [Page 39]
  2185.  
  2186. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2187.  
  2188.  
  2189.    o The Best effort indication must be present.
  2190.  
  2191.    If the Controlled-Load Service FlowSpec is specified, the coding
  2192.    rules for the fields are as follows.
  2193.  
  2194.    o The value of the Forward PCR (CLP=0+1) field depends on the
  2195.      specification of the ATM network.  The Forward PCR (CLP=0+1) field
  2196.      in each ATM interface in an implementation must be configurable to
  2197.      any value between zero and 16,777,215.
  2198.  
  2199.    o If the VC is established as a point-to-point call, the value of the
  2200.      Backward PCR (CLP=0+1) field is set the same as that of the Forward
  2201.      PCR (CLP=0+1) field.  If the VC is established as a point-to-
  2202.      multipoint call, the value of the Backward PCR (CLP=0+1) field is
  2203.      set to zero.
  2204.  
  2205.    o The method for calculating the Forward SCR (CLP=0+1) field is shown
  2206.      in section 5.
  2207.  
  2208.    o If the VC is established as a point-to-point call, the value of the
  2209.      Backward SCR (CLP=0+1) field is set the same as that of the Forward
  2210.      SCR (CLP=0+1) field.  If the VC is established as a point-to-
  2211.      multipoint call, this field must not be present.
  2212.  
  2213.    o The method for calculating the Forward MBS (CLP=0+1) field is shown
  2214.      in section 5.
  2215.  
  2216.    o If the VC is established as a point-to-point call, the value of the
  2217.      Backward MBS (CLP=0+1) field is set the same as that of the Forward
  2218.      MBS (CLP=0+1) field.  If the VC is established as a point-to-
  2219.      multipoint call, this field must not be present.
  2220.  
  2221.    o The Best effort indication, Tagging backward, and Tagging forward
  2222.      fields must not be present.
  2223.  
  2224. 6.7.3 Broadband bearer capability coding
  2225.  
  2226.    If the Null FlowSpec is specified in the ST2+ over ATM protocol, the
  2227.    coding rules for the fields in the Broadband bearer capability
  2228.    information element in the SETUP message are as follows.
  2229.  
  2230.    o The Bearer class depends on the specification of the ATM network.
  2231.      The Bearer class in each ATM interface in an implementation must be
  2232.      configurable as either BCOB-X or BCOB-C.  BCOB-X is recommended as
  2233.      the default configuration.
  2234.  
  2235.    o The Traffic type and Timing requirements fields must not be
  2236.      present.
  2237.  
  2238.  
  2239.  
  2240. Suzuki                    Expires April, 1998                  [Page 40]
  2241.  
  2242. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2243.  
  2244.  
  2245.    o The Susceptibility to clipping field is set to not susceptible to
  2246.      clipping.
  2247.  
  2248.    o If the VC is established as a point-to-point call, the User plane
  2249.      connection configuration field is set to point-to-point, and if the
  2250.      VC is established as a point-to-multipoint call, it is set to
  2251.      point-to-multipoint.
  2252.  
  2253.    If the Controlled-Load Service FlowSpec is specified, the coding
  2254.    rules for the fields are as follows.
  2255.  
  2256.    o The Bearer class depends on the specification of the ATM network.
  2257.      The Bearer class in each ATM interface in an implementation must be
  2258.      configurable as either BCOB-X or BCOB-C.  BCOB-X is recommended as
  2259.      the default configuration.
  2260.  
  2261.    o If the Bearer class is BCOB-X, the Traffic type and Timing
  2262.      requirements fields depend on the specification of the ATM network.
  2263.      The Traffic type and Timing requirements fields in each ATM
  2264.      interface in an implementation must be configurable as either no
  2265.      indication or VBR and Not required, respectively.  No indication is
  2266.      recommended as the default configuration.  If the Bearer class is
  2267.      BCOB-C, the Traffic type and Timing requirements fields must not be
  2268.      present.
  2269.  
  2270.    o The Susceptibility to clipping field depends on the specification
  2271.      of the ATM network.  The Susceptibility to clipping field in each
  2272.      ATM interface in an implementation must be configurable as either
  2273.      not susceptible to clipping or susceptible to clipping.  Not
  2274.      susceptible to clipping is recommended as the default
  2275.      configuration.
  2276.  
  2277.    o If the VC is established as a point-to-point call, the User plane
  2278.      connection configuration field is set to point-to-point, and if the
  2279.      VC is established as a point-to-multipoint call, it is set to
  2280.      point-to-multipoint.
  2281.  
  2282. 6.7.4 Broadband high layer information coding
  2283.  
  2284.    The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must
  2285.    include a Broadband high layer information information element. The
  2286.    coding rules for the fields are as follows.
  2287.  
  2288.    o The High layer information type is set to User specific.
  2289.  
  2290.    o The first 6 bytes in the High layer information field are set to
  2291.      the SID of the stream corresponding to the VC.
  2292.  
  2293.  
  2294.  
  2295.  
  2296. Suzuki                    Expires April, 1998                  [Page 41]
  2297.  
  2298. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2299.  
  2300.  
  2301. 6.7.5 Broadband low layer information coding
  2302.  
  2303.    The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must
  2304.    include a Broadband low layer information information element. The
  2305.    CONNECT message may or may not include this element.  The coding
  2306.    rules for the fields are as follows.
  2307.  
  2308.    o The User information layer 3 protocol field is set to ISO/IEC TR
  2309.      9577.
  2310.  
  2311.    o The IPI field is set to IEEE 802.1 SNAP (0x80).
  2312.  
  2313.    o The OUI field is set to IANA (0x00-00-5E).
  2314.  
  2315.    o The PID field is set to ST2+ (TBD).
  2316.  
  2317. 6.7.6 QoS parameter coding
  2318.  
  2319.    If the Null FlowSpec is specified in the ST2+ over ATM protocol, the
  2320.    coding rules for the fields in the QoS parameter in the SETUP message
  2321.    are as follows.
  2322.  
  2323.    o The QoS class forward and QoS class backward fields are set to QoS
  2324.      class 0.
  2325.  
  2326.    If the Controlled-Load Service FlowSpec is specified, the coding
  2327.    rules for the fields are as follows.
  2328.  
  2329.    o The QoS class forward and QoS class backward fields depend on the
  2330.      specification of the ATM network.  The QoS class forward and QoS
  2331.      class backward fields in each ATM interface in an implementation
  2332.      must be configurable as either QoS class 0 or QoS class 3.  QoS
  2333.      class 0 is recommended as the default configuration.
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352. Suzuki                    Expires April, 1998                  [Page 42]
  2353.  
  2354. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2355.  
  2356.  
  2357. 7. Security Considerations
  2358.  
  2359.    The ST2+ over ATM protocol modifies RFC 1819 ST2+ protocol, but
  2360.    basically these modifications are minimum extensions for ATM support
  2361.    and bug fixes, so they do not weaken the security of the ST2+
  2362.    protocol.
  2363.  
  2364.    The ST2+ over ATM protocol specifies protocol interaction between
  2365.    ST2+ and UNI 3.1, and this does not weaken the security of the UNI
  2366.    3.1 protocol.
  2367.  
  2368.    In an ST2+ agent that processes an incoming call of SVC, if the
  2369.    incoming SETUP message contains the calling party number and if it is
  2370.    verified and passed by the ATM network or it is provided by the
  2371.    network, then it is feasible to use the calling party number for part
  2372.    of the calling party authentication to strengthen security.
  2373.  
  2374.  
  2375.  
  2376. References
  2377.  
  2378.       [1] M. Borden, E. Crawley, B. Davie, and S. Batsell, "Integration
  2379.       of Real-time Services in an IP-ATM Network Architecture," RFC
  2380.       1821, August 1995.
  2381.  
  2382.       [2] S. Jackowski, "Native ATM Support for ST2+," RFC 1946, May
  2383.       1996.
  2384.  
  2385.       [3] S. Damaskos and A. Gavras, "Connection Oriented Protocols over
  2386.       ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, February
  2387.       1994.
  2388.  
  2389.       [4] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
  2390.       Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
  2391.       August 1995.
  2392.  
  2393.       [5] J. Wroclawski, "Specification of the Controlled-Load Network
  2394.       Element Service," RFC 2211, September 1997.
  2395.  
  2396.       [6] S. Shenker, C. Partridge, and R. Guerin, "Specification of
  2397.       Guaranteed Quality of Service," RFC 2212, September 1997.
  2398.  
  2399.       [7] J. Wroclawski, "The Use of RSVP with IETF Integrated
  2400.       Services," RFC 2210, September 1997.
  2401.  
  2402.       [8] M. Garrett and M. Borden, "Interoperation of Controlled-Load
  2403.       Service and Guaranteed Service with ATM," Internet Draft, July
  2404.       1997, <draft-ietf-issll-atm-mapping-03.txt>.
  2405.  
  2406.  
  2407.  
  2408. Suzuki                    Expires April, 1998                  [Page 43]
  2409.  
  2410. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2411.  
  2412.  
  2413.       [9] A. Ghanwani, J. W. Pace, and V. Srinivasan, "A Framework for
  2414.       Providing Integrated Services Over Shared and Switched LAN
  2415.       Technologies," Internet Draft, May 1997, <draft-ietf-issll-is802-
  2416.       framework-02.txt>.
  2417.  
  2418.       [10] The ATM Forum, "ATM User-Network Interface Specification
  2419.       Version 3.1," September 1994.
  2420.  
  2421.       [11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling
  2422.       Specification Version 4.0," af-sig-0061.000, July 1996.
  2423.  
  2424.       [12] ITU-T, "Broadband Integrated Services Digital Network (B-
  2425.       ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-
  2426.       Network Interface (UNI) Layer 3 Specification for Basic
  2427.       Call/Connection Control," ITU-T Recommendation Q.2931, September
  2428.       1995.
  2429.  
  2430.       [13] ITU-T, "Broadband Integrated Services Digital Network (B-
  2431.       ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-
  2432.       Network Interface Layer 3 Specification for Point-to-Multipoint
  2433.       Call/Connection Control," ITU-T Recommendation Q.2971, October
  2434.       1995.
  2435.  
  2436.       [14] ITU-T, "B-ISDN Protocol Reference Model and its Application,"
  2437.       CCITT Recommendation I.321, April 1991.
  2438.  
  2439.       [15] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5
  2440.       specification," Draft new ITU-T Recommendation I.363.5, September
  2441.       1995.
  2442.  
  2443.       [16] J.  Heinanen, "Multiprotocol Encapsulation over ATM
  2444.       Adaptation Layer 5," RFC 1483, July 1993.
  2445.  
  2446.       [17] M. Laubach, "Classical IP and ARP over ATM," RFC 1577,
  2447.       January 1994.
  2448.  
  2449.       [18] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, and A.
  2450.       Malis, "ATM Signaling Support for IP over ATM," RFC 1755, February
  2451.       1995.
  2452.  
  2453.       [19] J. Luciani, D. Katz, D. Piscitello, and B. Cole, "NBMA Next
  2454.       Hop Resolution Protocol (NHRP)," Internet Draft, March 1997,
  2455.       <draft-ietf-rolc-nhrp-11.txt>.
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464. Suzuki                    Expires April, 1998                  [Page 44]
  2465.  
  2466. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2467.  
  2468.  
  2469. Acknowledgments
  2470.  
  2471.       ATM is a huge technology and without the help of many colleagues
  2472.       at NTT who are involved in ATM research and development, it would
  2473.       have been impossible for me to complete this protocol
  2474.       specification.  I would like to thank Hideaki Arai of the NTT
  2475.       Network Strategy Planning Dept., Shin-ichi Kuribayashi of the NTT
  2476.       Business Communications Hqs., Naotaka Morita, Jun Aramomi, and
  2477.       Takumi Ohba of the NTT Network Service Systems Labs., and also
  2478.       Hisao Uose of the NTT Multimedia Networks Labs. for their valuable
  2479.       comments and discussions.
  2480.  
  2481.       And I would also like to especially thank Eric Crawley of
  2482.       Gigapacket Networks, John Wroclawski of MIT, Steven Jackowski of
  2483.       Net Manage, Louis Berger of FORE Systems, Steven Willis of Bay
  2484.       Networks, Greg Burch of Qosnetics, and Denis Gallant, James Watt,
  2485.       and Joel Halpern of Newbridge Networks for their valuable comments
  2486.       and suggestions.
  2487.  
  2488.       Also this specification is based on various discussions during NTT
  2489.       Multimedia Joint Project with NACSIS.  I would like to thank
  2490.       Professor Shoichiro Asano of the National Center for Science
  2491.       Information Systems for his invaluable advice in this area.
  2492.  
  2493.  
  2494.  
  2495. Author's Address
  2496.  
  2497.       Muneyoshi Suzuki
  2498.       NTT Multimedia Networks Laboratories
  2499.       3-9-11, Midori-cho
  2500.       Musashino-shi, Tokyo 180, Japan
  2501.  
  2502.       Phone: +81-422-59-2119
  2503.       Fax:   +81-422-59-3203
  2504.       EMail: suzuki@nal.ecl.net
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520. Suzuki                    Expires April, 1998                  [Page 45]
  2521.  
  2522. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2523.  
  2524.  
  2525. Appendix A. RFC 1819 ST2+ Errata
  2526.  
  2527. A.1  4.3 SCMP Reliability
  2528.  
  2529.    The following sentence in the second paragraph:
  2530.  
  2531.    < For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
  2532.  
  2533.    should be changed to
  2534.  
  2535.    > For some SCMP messages (CONNECT, CHANGE, and JOIN) the
  2536.  
  2537. A.2  4.4.4 User Data
  2538.  
  2539.    The following sentence:
  2540.  
  2541.    < option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and
  2542.    < REFUSE messages. The format of the UserData parameter is shown in
  2543.  
  2544.    should be changed to
  2545.  
  2546.    > option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, NOTIFY,
  2547.    > and REFUSE messages. The format of the UserData parameter is shown in
  2548.  
  2549. A.3  5.3.2  Other Cases
  2550.  
  2551.    The following sentence:
  2552.  
  2553.    < CONNECT with a REFUSE message with the affected targets specified in
  2554.    < the TargetList and an appropriate ReasonCode (StreamExists).
  2555.  
  2556.    should be changed to
  2557.  
  2558.    > CONNECT with a REFUSE message with the affected targets specified in
  2559.    > the TargetList and an appropriate ReasonCode (TargetExists).
  2560.  
  2561. A.4  5.5.1 Mismatched FlowSpecs
  2562.  
  2563.    The following sentence:
  2564.  
  2565.    < notifies the processing ST agent which should respond with ReasonCode
  2566.    < (FlowSpecMismatch).
  2567.  
  2568.    should be changed to
  2569.  
  2570.    > notifies the processing ST agent which should respond with a REFUSE
  2571.    > message with ReasonCode (FlowSpecMismatch).
  2572.  
  2573.  
  2574.  
  2575.  
  2576. Suzuki                    Expires April, 1998                  [Page 46]
  2577.  
  2578. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2579.  
  2580.  
  2581. A.5  6.2.1  Problems in Stream Recovery
  2582.  
  2583.    The following sentence:
  2584.  
  2585.    < some time after a failure. As a result, the ST agent attempting the
  2586.    < recovery may receive ERROR messages for the new CONNECTs that are
  2587.    < ...
  2588.    < failure, and will interpret the new CONNECT as resulting from a
  2589.    < routing failure. It will respond with an ERROR message with the
  2590.    < appropriate ReasonCode (StreamExists). Since the timeout that the ST
  2591.    < ...
  2592.    < remnants of the broken stream will soon be torn down by a DISCONNECT
  2593.    < message. Therefore, the ST agent that receives the ERROR message with
  2594.    < ReasonCode (StreamExists) should retransmit the CONNECT message after
  2595.  
  2596.    should be changed to
  2597.  
  2598.    > some time after a failure. As a result, the ST agent attempting the
  2599.    > recovery may receive REFUSE messages for the new CONNECTs that are
  2600.    > ...
  2601.    > failure, and will interpret the new CONNECT as resulting from a
  2602.    > routing failure. It will respond with a REFUSE message with the
  2603.    > appropriate ReasonCode (TargetExists). Since the timeout that the ST
  2604.    > ...
  2605.    > remnants of the broken stream will soon be torn down by a DISCONNECT
  2606.    > message. Therefore, the ST agent that receives the REFUSE message with
  2607.    > ReasonCode (TargetExists) should retransmit the CONNECT message after
  2608.  
  2609. A.6  6.3  Stream Preemption}
  2610.  
  2611.    The following sentence:
  2612.  
  2613.    <    (least important) to 256 (most important). This value is
  2614.  
  2615.    should be changed to
  2616.  
  2617.    >    (least important) to 255 (most important). This value is
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632. Suzuki                    Expires April, 1998                  [Page 47]
  2633.  
  2634. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2635.  
  2636.  
  2637. A.7  10.2 Control PDUs
  2638.  
  2639.    The following sentence:
  2640.  
  2641.    <o  Reference is a transaction number. Each sender of a request control
  2642.    <   message assigns a Reference number to the message that is unique
  2643.    <   with respect to the stream.
  2644.  
  2645.    should be changed to
  2646.  
  2647.    >o  Reference is a transaction number. Each sender of a request control
  2648.    >   message assigns a Reference number to the message that is unique
  2649.    >   with respect to the stream for messages generated by each agent.
  2650.  
  2651. A.8  10.3.4 Origin
  2652.  
  2653.    The following:
  2654.  
  2655.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2656.    <   |  PCode = 5    |   PBytes      | NextPcol      |OriginSAPBytes |
  2657.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2658.  
  2659.    should be changed to
  2660.  
  2661.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2662.    >   |  PCode = 4    |   PBytes      | NextPcol      |OriginSAPBytes |
  2663.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2664.  
  2665. A.9  10.4.1  ACCEPT
  2666.  
  2667.    The following sentence:
  2668.  
  2669.    <o   IPHops is the number of IP encapsulated hops traversed by the
  2670.    <    stream. This field is set to zero by the origin, and is incremented
  2671.    <    at each IP encapsulating agent.
  2672.  
  2673.    should be changed to
  2674.  
  2675.    >o   IPHops is the number of IP encapsulated hops traversed by the
  2676.    >    stream.
  2677.  
  2678.  
  2679.  
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688. Suzuki                    Expires April, 1998                  [Page 48]
  2689.  
  2690. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2691.  
  2692.  
  2693. A.10  10.4.2  ACK
  2694.  
  2695.    The following:
  2696.  
  2697.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2698.    <   |  OpCode = 2   |     0         |           TotalBytes          |
  2699.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2700.  
  2701.    should be changed to
  2702.  
  2703.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2704.    >   |  OpCode = 2   |     0         |         TotalBytes = 16       |
  2705.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2706.  
  2707. A.11  10.4.3  CHANGE
  2708.  
  2709.    The following sentence:
  2710.  
  2711.    <o   I (bit 7) is used to indicate that the LRM is permitted to interrupt
  2712.  
  2713.    should be changed to
  2714.  
  2715.    >o   I (bit 9) is used to indicate that the LRM is permitted to interrupt
  2716.  
  2717. A.12  10.4.7  HELLO
  2718.  
  2719.    The following:
  2720.  
  2721.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2722.    <   |  OpCode = 7   |R|    0        |           TotalBytes          |
  2723.    <   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2724.  
  2725.    should be changed to
  2726.  
  2727.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2728.    >   |  OpCode = 7   |R|    0        |         TotalBytes = 20       |
  2729.    >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2730.  
  2731.  
  2732.  
  2733.  
  2734.  
  2735.  
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744. Suzuki                    Expires April, 1998                  [Page 49]
  2745.  
  2746. INTERNET DRAFT      draft-suzuki-st2-over-atm-02.txt       October, 1997
  2747.  
  2748.  
  2749. A.13  10.4.9  JOIN-REJECT
  2750.  
  2751.    The following sentence:
  2752.  
  2753.    <o   Reference contains a number assigned by the ST agent sending the
  2754.    <    REFUSE for use in the acknowledging ACK.
  2755.  
  2756.    should be changed to
  2757.  
  2758.    >o   Reference contains a number assigned by the ST agent sending the
  2759.    >    JOIN-REJECT for use in the acknowledging ACK.
  2760.  
  2761. A.14  10.4.13  STATUS-RESPONSE
  2762.  
  2763.    The following sentence:
  2764.  
  2765.    <   possibly Groups of the stream. It the full target list can not fit in
  2766.  
  2767.    should be changed to
  2768.  
  2769.    >   possibly Groups of the stream. If the full target list can not fit in
  2770.  
  2771. A.15  10.5.3 ReasonCode
  2772.  
  2773.    The following:
  2774.  
  2775.    < 32      PCodeUnknown    Control PDU has a parameter with an invalid
  2776.    <                         PCode.
  2777.  
  2778.    should be removed because a common SCMP element with an unknown PCode
  2779.    is equivalent to the UserData (RFC 1819, Section 10.3.8).
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800. Suzuki                    Expires April, 1998                  [Page 50]
  2801.