📄 rfc3057.txt
字号:
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 + -