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