rfc2383.txt

RFC 的详细文档！

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

3.1.3 VC-type common SCMP element

   The ST2+ over ATM protocol specifies an additional common SCMP
   element that designates the VC type used to support the diverse VC
   styles.  The CONNECT and CHANGE messages that establish a hop with a
   VC must contain a VC-type common SCMP element.  This element is valid
   between neighboring ST2+ agents, but must not propagate beyond the
   previous-hop or next-hop ST2+ agent.


















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


   The format of the VC-type common SCMP element is shown in Fig. 3.2.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 8   |  PBytes = 20  |            VCType             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          PVCIdentifer                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          0(unused)            |           UniqueID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        OriginIPAddress                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LIJCallIdentifer                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Fig. 3.2: Format of VC-type common SCMP element.

     The PCode field identifies the common SCMP elements. The PCode
     value for the VC type is 8.

     The PBytes field for the VC type is 20 bytes.

     The VCType field identifies the VC type.  The correspondence
     between the value in this field and the meaning is as follows:

       0: ST2+ data stream uses a PVC.

       1: ST2+ data stream uses the reverse channel of the bi-
          directional point-to-point SVC used by the existing stream.

       2: ST2+ data stream is established by a point-to-point SVC
          initiated from the upstream side.

       3: ST2+ data stream is established by a point-to-multipoint SVC
          initiated from the upstream side.

       4: ST2+ data stream is established by a point-to-point SVC
          initiated from the downstream side.

       5: ST2+ data stream is established by a point-to-multipoint SVC
          initiated from the downstream side.

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





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


     The PVCIdentifer field identifies the PVC identifier uniquely
     assigned between neighboring ST2+ agents. This field is valid only
     when the VCType field is zero.

     The UniqueID and OriginIPAddress fields identify the reverse
     channel of the bi-directional point-to-point SVC that is used by
     this SID.  These fields are valid only when the VCType field is 1.

     The LIJCallIdentifer field identifies the LIJ Call Identifier for
     point-to-multipoint SVC. This field is valid only when the VCType
     field is 5.

3.1.4 Reason Code

   The extension of the Reason Code (RFC 1819, Section 10.5.3) to the
   ST2+ over ATM protocol is shown below.

     57 CantChange   Partial changes not supported.
     58 NoRecover    Stream recovery not supported.

3.2 Restricted Functions of RFC 1819 ST2+

3.2.1 FlowSpec changes

   In the following case, the ST2+ over ATM protocol supports stream
   FlowSpec changes by using the CHANGE message.

   o The I-bit is set to 1 and the G-bit is set to 1.

   In the following case, the CHANGE fails and a REFUSE message, with
   the E and N-bits set to 1 and the ReasonCode set to CantChange, is
   propagated upstream.

   o The I and/or G-bits are set to zero.

3.3 Unsupported Functions of RFC 1819 ST2+

3.3.1 ST2+ FlowSpec

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







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


3.3.2 Stream preemption

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

3.3.3 HELLO message

   Implementations may not support the HELLO message (RFC 1819, Section
   10.4.7) and thus ST2+ agent failure detection using the HELLO message
   (RFC 1819, Section 6.1.2). This is because ATM has an adequate
   failure detection mechanism, and the HELLO message is not sufficient
   for detecting link failure in the ST2+ over ATM protocol, because the
   ST2+ data and the ST2+ SCMP are forwarded through another VC.

3.3.4 Stream recovery

   Implementors must select the NoRecover option of the CONNECT message
   (RFC 1819, Section 4.4.1) with the S-bit set to 1.  This is because
   the descriptions of the stream recovery process in RFC 1819 (Sections
   5.3.2, 6.2, and 6.2.1) are unclear and incomplete. It is thus
   possible that if a link failure occurs and several ST2+ agents detect
   it simultaneously, the recovery process may encounter problems.

   The ST2+ over ATM protocol does not support stream recovery. If
   recovery is needed, the application should support it. A CONNECT
   message in which the NoRecover option is not selected will fail; a
   REFUSE message in which the N-bit is set to 1 and the ReaseonCode is
   set to NoRecover is then propagated upstream.

3.3.5 Subnet Resources Sharing

   The ST2+ over ATM protocol does not support subnet resources sharing
   (RFC 1819, Section 7.1.4).  This is because ATM does not support the
   concept of the MAC layer.

3.3.6 IP encapsulation of ST

   The ST2+ over ATM protocol does not support IP encapsulation of ST
   (RFC 1819, Section 8.7), because there is no need to implement IP
   encapsulation in this protocol.

3.3.7 IP Multicasting

   The ST2+ over ATM protocol does not support IP multicasting (RFC
   1819, Section 8.8), because this protocol does not support IP
   encapsulation of ST.




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


3.4 Modified Functions of RFC 1819 ST2+

   The ST2+ receiver-oriented stream creation procedure has some fatal
   problems: the value of the LnkReferecnce field in the CONNECT message
   that is a response to a JOIN message is not valid, ST2+ agent cannot
   update the LnkReference field in the JOIN-REJECT message, and ST2+
   agent cannot deliver the JOIN-REJECT message to the target because
   the JOIN-REJECT message does not contain a TargetList field.  To
   solve these problems, the ST2+ over ATM protocol modifies the ST2+
   protocol processing rules.

3.4.1 Modifications of Message Processing Rules

   Modifications of the CONNECT, JOIN, and JOIN-REJECT message
   processing rules in the ST2+ over ATM protocol are described in the
   following.

   o The target that creates a JOIN message assigns the same value as in
     the Reference field to the LnkReference field.

   o The agent that creates a CONNECT message as a response to a JOIN
     message assigns the same value as in the LnkReference field in the
     JOIN message to the LnkReference field.  In other cases, the value
     of the LnkReference field in a CONNECT message is zero.

   o The agent that creates a JOIN-REJECT message assigns the same value
     as in the LnkReference field in the JOIN message to the
     LnkReference field.

   o An intermediate agent must not modify the value of the LnkReference
     field in the CONNECT, JOIN, or JOIN-REJECT message.  Note that this
     rule differs from the LnkReference field processing rule in the
     ACCEPT and REFUSE messages.


















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


3.4.2 Modified JOIN-REJECT Control Message

   The modified JOIN-REJECT control message in the ST2+ over ATM
   protocol is shown in Fig. 3.3

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OpCode = 9   |       0       |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |          LnkReference         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |           ReasonCode          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       GeneratorIPAddress                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          TargetList                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Fig. 3.3: JOIN-REJECT Control Message.

   The TargetList is assigned the same TargetList in the JOIN message as
   the one that corresponds to the JOIN-REJECT message.

4. Protocol Specification of the User Plane

   This section specifies the AAL5 PDU encapusulation for the ST2+ Data
   PDU.

4.1 Service Primitives Provided by User Plane

4.1.1 Overview of interactions

   The ST2+ data layer entity on the user plane of the ST2+ over ATM
   protocol provides the following services to the upper layer.

   o st2p_unitdata.req

   o st2p_unitdata.ind

4.1.1.1 St2p_unitdata.req

   The st2p_unitdata.req primitive sends a request for an ST2+ Data PDU
   transfer to the ST2+ data layer entity.  The semantics of the
   primitive are as follows:




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


   st2p_unitdata.req (
           pri,
           sid,
           data
           )

   The pri parameter specifies priority of ST2+ Data PDU.  The sid
   parameter specifies SID of ST2+ Data PDU.  The data parameter
   specifies ST2+ data to be transferred.

4.1.1.2 St2p_unitdata.ind

   The st2p_unitdata.ind primitive indicates an ST2+ Data PDU delivery
   from the ST2+ data layer entity.  The semantics of the primitive are
   as follows:

   st2p_unitdata.ind (
           pri [optional],
           sid,
           data,
           status [optional]
           )

   The pri parameter indicates priority of ST2+ Data PDU, if AAL5 is
   used for encapsulating the ST2+ Data PDU.  The sid parameter
   indicates SID of ST2+ Data PDU.  The data parameter indicates
   delivered ST2+ data.  The status is an optional parameter that
   indicates whether the delivered ST2+ data is corrupt or not.

4.2 Service Primitives Provided by AAL5

4.2.1 Requirements for AAL5