⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc3057.txt

📁 最新的RFC
💻 TXT
📖 第 1 页 / 共 5 页
字号:
   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 20011.6 Definition of IUA Boundaries1.6.1 Definition of IUA/Q.921 boundary   DL-ESTABLISH   DL-RELEASE   DL-DATA   DL-UNIT DATA1.6.2 Definition of IUA/Q.931 boundary   DL-ESTABLISH   DL-RELEASE   DL-DATA   DL-UNIT DATA1.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 20013.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.03.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 IETF128 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 extensionsMorneault, 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       4        TEI Status Indication     5 to 127   Reserved by the IETF   128 to 255   Reserved for IETF-Defined MGMT extensions3.1.3  Reserved   The Reserved field is 8-bits.  It SHOULD be set to all '0's and   ignored by the receiver.3.1.4  Message Length   The Message length defines the length of the message in octets,   including the Common header.3.1.5  Variable-Length Parameter Format   IUA messages consist of a Common Header followed by zero or more   variable-length parameters, as defined by the message type.  The

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -