rfc3057.txt

RFC 的详细文档！

   example, both a primary and a back-up ASP are available, IUA peer
   protocol is required to control which ASP is currently active.  The
   ordered list of ASPs within a logical Application Server is kept
   updated in the SG to reflect the active Application Server
   Process(es).

   Also the IUA layer MAY need to inform the local management of the
   change in status of an ASP or AS.  This can be achieved using the M-
   ASP STATUS or M-AS STATUS primitives.

1.5.3 SCTP Stream Management

   SCTP allows a user specified number of streams to be opened during
   the initialization.  It is the responsibility of the IUA layer to
   ensure proper management of these streams.  Because of the
   unidirectional nature of streams, an IUA layer is not aware of the
   stream number to Interface Identifier mapping of its peer IUA layer.
   Instead, the Interface Identifier is in the IUA message header.

   The use of SCTP streams within IUA is recommended in order to
   minimize transmission and buffering delay, therefore improving the
   overall performance and reliability of the signaling elements.  It is
   recommended that a separate SCTP stream is used for each D channel.

1.5.4 Seamless Network Management Interworking

   The IUA layer on the SG SHOULD pass an indication of unavailability
   of the IUA-User (Q.931) to the local Layer Management, if the
   currently active ASP moves from the ACTIVE state.  The Layer
   Management could instruct Q.921 to take some action, if it deems
   appropriate.

   Likewise, if an SCTP association fails, the IUA layer on both the SG
   and ASP sides MAY generate Release primitives to take the data links
   out-of-service.

1.5.5 Congestion Management

   If the IUA layer becomes congested (implementation dependent), it MAY
   stop reading from the SCTP association to flow control from the peer
   IUA.








Morneault, et al.           Standards Track                    [Page 13]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


1.6 Definition of IUA Boundaries

1.6.1 Definition of IUA/Q.921 boundary

   DL-ESTABLISH
   DL-RELEASE
   DL-DATA
   DL-UNIT DATA

1.6.2 Definition of IUA/Q.931 boundary

   DL-ESTABLISH
   DL-RELEASE
   DL-DATA
   DL-UNIT DATA

1.6.3 Definition of SCTP/IUA Boundary

   An example of the upper layer primitives provided by SCTP are
   available in Reference [3] section 10.

1.6.4 Definition of IUA/Layer-Management Boundary

   M-SCTP ESTABLISH request
   Direction: LM -> IUA
   Purpose: LM requests ASP to establish an SCTP association with an SG.

   M-STCP ESTABLISH confirm
   Direction: IUA -> LM
   Purpose: ASP confirms to LM that it has established an SCTP
            association with an SG.

   M-SCTP ESTABLISH indication
   Direction: IUA -> LM
   Purpose: SG informs LM that an ASP has established an SCTP
            association.

   M-SCTP RELEASE request
   Direction: LM -> IUA
   Purpose: LM requests ASP to release an SCTP association with SG.

   M-SCTP RELEASE confirm
   Direction: IUA -> LM
   Purpose: ASP confirms to LM that it has released SCTP association
            with SG.






Morneault, et al.           Standards Track                    [Page 14]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   M-SCTP RELEASE indication
   Direction: IUA -> LM
   Purpose: SG informs LM that ASP has released an SCTP association.

   M-SCTP STATUS request
   Direction: LM -> IUA
   Purpose: LM requests IUA to report status of SCTP association.

   M-SCTP STATUS indication
   Direction: IUA -> LM
   Purpose: IUA reports status of SCTP association.

   M-ASP STATUS request
   Direction: LM -> IUA
   Purpose: LM requests SG to report status of remote ASP.

   M-ASP STATUS indication
   Direction: IUA -> LM
   Purpose: SG reports status of remote ASP.

   M-AS-STATUS request
   Direction: LM -> IUA
   Purpose: LM requests SG to report status of AS.

   M-AS-STATUS indication
   Direction: IUA -> LM
   Purpose: SG reports status of AS.

   M-NOTIFY indication
   Direction: IUA -> LM
   Purpose: ASP reports that it has received a NOTIFY message
            from its peer.

   M-ERROR indication
   Direction: IUA -> LM
   Purpose: ASP or SG reports that it has received an ERROR
            message from its peer.

   M-ASP-UP request
   Direction: LM -> IUA
   Purpose: LM requests ASP to start its operation and send an ASP UP
            message to the SG.

   M-ASP-UP confirm
   Direction: IUA -> LM
   Purpose: ASP reports that is has received an ASP UP Acknowledgement
            message from the SG.




Morneault, et al.           Standards Track                    [Page 15]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   M-ASP-DOWN request
   Direction: LM -> IUA
   Purpose: LM requests ASP to stop its operation and send an ASP DOWN
            message to the SG.

   M-ASP-DOWN confirm
   Direction: IUA -> LM
   Purpose: ASP reports that is has received an ASP DOWN
            Acknowledgement message from the SG.

   M-ASP-ACTIVE request
   Direction: LM -> IUA
   Purpose: LM requests ASP to send an ASP ACTIVE message to the SG.

   M-ASP-ACTIVE confirm
   Direction: IUA -> LM
   Purpose: ASP reports that is has received an ASP ACTIVE
            Acknowledgement message from the SG.

   M-ASP-INACTIVE request
   Direction: LM -> IUA
   Purpose: LM requests ASP to send an ASP INACTIVE message to the SG.

   M-ASP-INACTIVE confirm
   Direction: IUA -> LM
   Purpose: ASP reports that is has received an ASP INACTIVE
            Acknowledgement message from the SG.

   M-TEI STATUS request
   Direction: LM -> IUA
   Purpose: LM requests ASP to send a TEI status request to the SG.

   M-TEI STATUS indication
   Direction: IUA -> LM
   Purpose: ASP reports that is has received a TEI status indication
            from the SG.

   M-TEI STATUS confirm
   Direction: IUA -> LM
   Purpose: ASP reports that is has received a TEI status confirm from the
            SG.

2.0 Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].



Morneault, et al.           Standards Track                    [Page 16]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


3.0 Protocol Elements

   This section describes the format of various messages used in this
   protocol.

3.1 Common Message Header

   The protocol messages for Q.921-User Adaptation require a message
   header which contains the adaptation layer version, the message type,
   and message length.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    | Message Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3 Common Header Format

   All fields in an IUA message MUST be transmitted in the network byte
   order, unless otherwise stated.

3.1.1 Version

   The version field contains the version of the IUA adaptation layer.
   The supported versions are the following:

      Value    Version
      -----    -------
        1      Release 1.0

3.1.2  Message Classes and Types

   The following List contains the valid Message Classes:

   Message Class: 8 bits (unsigned integer)

     0      Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
     1      Transfer Messages [M3UA]
     2      SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
     3      ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
     4      ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
     5      Q.921/Q.931 Boundary Primitives Transport (QPTM)
            Messages [IUA]
     6      MTP2 User Adaptation (MAUP) Messages [M2UA]
     7      Connectionless Messages [SUA]



Morneault, et al.           Standards Track                    [Page 17]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


     8      Connection-Oriented Messages [SUA]
  9 to 127  Reserved by the IETF
128 to 255  Reserved for IETF-Defined Message Class extensions

   The following list contains the message names for the defined
   messages.

    Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages

       0        Reserved
       1        Data Request Message
       2        Data Indication Message
       3        Unit Data Request Message
       4        Unit Data Indication Message
       5        Establish Request
       6        Establish Confirm
       7        Establish Indication
       8        Release Request
       9        Release Confirm
      10        Release Indication
    11 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined QPTM extensions

    Application Server Process State Maintenance (ASPSM) messages

       0        Reserved
       1        ASP Up (UP)
       2        ASP Down (DOWN)
       3        Heartbeat (BEAT)
       4        ASP Up Ack (UP ACK)
       5        ASP Down Ack (DOWN ACK)
       6        Heatbeat Ack (BEAT ACK)
     7 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined ASPSM extensions

    Application Server Process Traffic Maintenance (ASPTM) messages

       0        Reserved
       1        ASP Active (ACTIVE)
       2        ASP Inactive (INACTIVE)
       3        ASP Active Ack (ACTIVE ACK)
       4        ASP Inactive Ack (INACTIVE ACK)
     5 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined ASPTM extensions







Morneault, et al.           Standards Track                    [Page 18]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


    Management (MGMT) Messages

       0        Error (ERR)
       1        Notify (NTFY)
       2        TEI Status Request
       3        TEI Status Confirm