Network Working Group K. Morneault
Request for Comments: 4233 Cisco Systems
Obsoletes: 3057 S. Rengasami
Category: Standards Track Tridea Works
M. Kalla
Telcordia Technologies
G. Sidebottom
Signatus Technologies
January 2006
Network Working Group K. Morneault
Request for Comments: 4233 Cisco Systems
Obsoletes: 3057 S. Rengasami
Category: Standards Track Tridea Works
M. Kalla
Telcordia Technologies
G. Sidebottom
Signatus Technologies
January 2006
Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
综合业务数字网（ISDN）Q.921-用户适配层
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
本文件定义了使用流控制传输协议（SCTP）通过IP回传综合业务数字网（ISDN）Q.921用户消息的协议。该协议将在信令网关（SG）和媒体网关控制器（MGC）之间使用。假定SG通过标准ISDN接口接收ISDN信令。
This document obsoletes RFC 3057.
本文件淘汰RFC 3057。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. IUA Overview ...............................................5
1.4. Services Provided by the IUA Layer .........................7
1.5. Functions Implemented by the IUA Layer ....................10
1.6. Definition of IUA Boundaries ..............................12
2. Conventions ....................................................15
3. Protocol Elements ..............................................15
3.1. Common Message Header .....................................15
3.2. IUA Message Header ........................................19
3.3. IUA Messages ..............................................21
4. Procedures .....................................................46
4.1. Procedures to Support Service in Section 1.4.1 ............46
4.2. Procedures to Support Service in Section 1.4.2 ............46
4.3. Procedures to Support Service in Section 1.4.3 ............48
5. Examples .......................................................58
5.1. Establishment of Association and Traffic between
SGs and ASPs ..............................................58
5.2. ASP Traffic Fail-over Examples ............................62
5.3. Q.921/Q.931 Primitives Backhaul Examples ..................63
5.4. Layer Management Communication Examples ...................64
6. Security .......................................................65
7. IANA Considerations ............................................65
7.1. SCTP Payload Protocol Identifier ..........................65
7.2. IUA Protocol Extensions ...................................65
8. Timer Values ...................................................67
9. Acknowledgements ...............................................67
10. References ....................................................67
10.1. Normative References .....................................67
10.2. Informative References ...................................67
11. Change Log ....................................................68
Appendix A ........................................................69
A.1. Signaling Network Architecture ............................69
A.2. Application Server Process Redundancy .....................70
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. IUA Overview ...............................................5
1.4. Services Provided by the IUA Layer .........................7
1.5. Functions Implemented by the IUA Layer ....................10
1.6. Definition of IUA Boundaries ..............................12
2. Conventions ....................................................15
3. Protocol Elements ..............................................15
3.1. Common Message Header .....................................15
3.2. IUA Message Header ........................................19
3.3. IUA Messages ..............................................21
4. Procedures .....................................................46
4.1. Procedures to Support Service in Section 1.4.1 ............46
4.2. Procedures to Support Service in Section 1.4.2 ............46
4.3. Procedures to Support Service in Section 1.4.3 ............48
5. Examples .......................................................58
5.1. Establishment of Association and Traffic between
SGs and ASPs ..............................................58
5.2. ASP Traffic Fail-over Examples ............................62
5.3. Q.921/Q.931 Primitives Backhaul Examples ..................63
5.4. Layer Management Communication Examples ...................64
6. Security .......................................................65
7. IANA Considerations ............................................65
7.1. SCTP Payload Protocol Identifier ..........................65
7.2. IUA Protocol Extensions ...................................65
8. Timer Values ...................................................67
9. Acknowledgements ...............................................67
10. References ....................................................67
10.1. Normative References .....................................67
10.2. Informative References ...................................67
11. Change Log ....................................................68
Appendix A ........................................................69
A.1. Signaling Network Architecture ............................69
A.2. Application Server Process Redundancy .....................70
In this document, the term Q.921-User refers to an upper layer that uses the services of Q.921, not the user side of ISDN interface [1]. Examples of the upper layer would be Q.931 and QSIG.
在本文件中，术语Q.921-用户是指使用Q.921服务的上层，而不是ISDN接口的用户端[1]。上层示例为Q.931和QSIG。
This section describes the need for ISDN Q.921-User Adaptation (IUA) layer protocol as well as how this protocol shall be implemented.
本节描述了ISDN Q.921-用户适配（IUA）层协议的需求以及该协议的实施方式。
There is a need for Switched Circuit Network (SCN) signaling protocol delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Controller (MGC) as described in the Framework Architecture for
需要从ISDN信令网关（SG）到媒体网关控制器（MGC）的交换电路网络（SCN）信令协议交付，如架构框架中所述
Signaling Transport [5]. The delivery mechanism SHOULD meet the following criteria:
信号传输[5]。交付机制应符合以下标准：
* Support for transport of the Q.921/Q.931 boundary primitives * Support for communication between Layer Management modules on SG and MGC * Support for management of SCTP active associations between SG and MGC
* 支持Q.921/Q.931边界原语的传输*支持SG和MGC上图层管理模块之间的通信*支持SG和MGC之间SCTP活动关联的管理
This document supports both ISDN Primary Rate Access (PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point and point-to-multipoint modes of communication. This support includes Facility Associated Signaling (FAS), Non-Facility Associated Signaling (NFAS), and NFAS with backup D channel. QSIG adaptation layer requirements do not differ from Q.931 adaptation layer; hence, the procedures described in this document are also applicable for a QSIG adaptation layer. For simplicity, only Q.931 will be mentioned in the rest of this document.
本文档支持ISDN主速率访问（PRA）和基本速率访问（BRA），包括对点对点和点对多点通信模式的支持。这种支持包括设施相关信令（FAS）、非设施相关信令（NFAS）和具有备用D信道的NFAS。QSIG适配层要求与Q.931适配层要求相同；因此，本文件中描述的程序也适用于QSIG适配层。为简单起见，本文档的其余部分将仅提及Q.931。
Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the Q.931 and call processing for D channels terminated by the Signaling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary).
应用程序服务器（AS）-为特定应用程序实例提供服务的逻辑实体。应用服务器的一个示例是MGC，它处理由信令网关终止的D个信道的Q.931和呼叫处理。实际上，AS在SG处被建模为一个或多个相关应用服务器进程（例如，主、次、三级）的有序列表。
Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances.
应用程序服务器进程（ASP）-应用程序服务器的进程实例。应用程序服务器进程的示例包括主MGC实例或备份MGC实例。
Association - An association refers to an SCTP association. The association will provide the transport for the delivery of Q.921-User protocol data units and IUA adaptation layer peer messages.
关联-关联是指SCTP关联。该协会将提供Q.921用户协议数据单元和IUA适配层对等消息的传输。
Backhaul - A SG terminates the lower layers of an SCN protocol and backhauls the upper layer(s) to MGC for call processing. For the purposes of this document, the SG terminates Q.921 and backhauls Q.931 to MGC.
回程-SG终止SCN协议的下层，并将上层回程到MGC进行呼叫处理。就本文件而言，SG终止Q.921，并将Q.931回传给MGC。
Fail-over - The capability to re-route signaling traffic as required between related ASPs in the event of failure or unavailability of the currently used ASP (e.g., from primary MGC to backup MGC). Fail-over also applies upon the return to service of a previously unavailable process.
故障转移-在当前使用的ASP出现故障或不可用时（例如，从主MGC到备用MGC），根据需要在相关ASP之间重新路由信令流量的能力。故障转移也适用于以前不可用的进程恢复服务时。
Host - The computing platform that the ASP process is running on.
主机—运行ASP进程的计算平台。
Interface - For the purposes of this document, an interface supports the relevant ISDN signaling channel. This signaling channel MAY be a 16-kbps D channel for an ISDN BRA as well as 64-kbps primary or backup D channel for an ISDN PRA. For QSIG, the signaling channel is a Qc channel.
接口-在本文件中，接口支持相关ISDN信令信道。该信令信道可以是ISDN BRA的16 kbps D信道，以及ISDN PRA的64 kbps主或备用D信道。对于QSIG，信令信道是Qc信道。
Interface Identifier - The Interface Identifier identifies the physical interface at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP. Significance is not implied across SGs served by an AS.
接口标识符-接口标识符标识SG上发送/接收信令消息的物理接口。接口标识符参数的格式可以是文本或整数，其值根据网络运营商策略分配。使用的值仅具有局部意义，在SG和ASP之间进行协调。在AS服务的SGs中不暗示重要性。
Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the IUA layer and a local management entity.
层管理-层管理是处理IUA层和本地管理实体之间的输入和输出的节点功能。
Network Byte Order - Most significant byte first, a.k.a big endian.
网络字节顺序-最高有效字节优先，也称为大端字节。
Stream - A stream refers to an SCTP stream: a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the un-ordered delivery service.
流-流指SCTP流：从一个SCTP端点到另一个关联SCTP端点建立的单向逻辑通道，在该通道中，除提交给未排序传递服务的用户消息外，所有用户消息都按顺序传递。
Q.921-User - Any protocol normally using the services of the ISDN Q.921 (e.g., Q.931, QSIG, etc.).
Q.921-用户-通常使用ISDN Q.921服务的任何协议（例如，Q.931、QSIG等）。
The architecture that has been defined [5] for SCN signaling transport over IP uses multiple components, including an IP transport protocol, a signaling common transport protocol, and an adaptation module to support the services expected by a particular SCN signaling protocol from its underlying protocol layer.
为通过IP的SCN信令传输定义的体系结构[5]使用多个组件，包括IP传输协议、信令公共传输协议和适配模块，以支持特定SCN信令协议从其底层协议层期望的服务。
This document defines an adaptation module that is suitable for the transport of ISDN Q.921-User (e.g., Q.931) messages.
本文件定义了适用于传输ISDN Q.921用户（如Q.931）消息的适配模块。
In a Signaling Gateway (SG), it is expected that the ISDN signaling is received over a standard ISDN network termination. The SG then provides interworking of transport functions with IP Signaling Transport, in order to transport the Q.931 signaling messages to the MGC where the peer Q.931 protocol layer exists, as shown below:
在信令网关（SG）中，预期ISDN信令通过标准ISDN网络终端接收。然后，SG提供传输功能与IP信令传输的互通，以便将Q.931信令消息传输到存在对等Q.931协议层的MGC，如下所示：
****** ISDN ****** IP *******
* EP *---------------* SG *--------------* MGC *
****** ****** *******
****** ISDN ****** IP *******
* EP *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+
|Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
NIF - Nodal Interworking Function EP - ISDN End Point SCTP - Stream Control Transmission Protocol (Refer to [4,8]) IUA - ISDN User Adaptation Layer Protocol
NIF-节点互通功能EP-ISDN端点SCTP-流控制传输协议（参考[4,8]）IUA-ISDN用户适配层协议
Figure 1. IUA in the SG to MGC Application
图1。SG到MGC应用中的IUA
It is recommended that the IUA use the services of the Stream Control Transmission Protocol (SCTP) as the underlying reliable common signaling transport protocol. The use of SCTP provides the following features:
建议IUA使用流控制传输协议（SCTP）的服务作为底层可靠的通用信令传输协议。SCTP的使用提供了以下功能：
- explicit packet-oriented delivery (not stream-oriented)
- 显式面向数据包的交付（非面向流）
- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, - optional multiplexing of user messages into SCTP datagrams, - network-level fault tolerance through support of multi-homing at either or both ends of an association, - resistance to flooding and masquerade attacks, and - data segmentation to conform to discovered path MTU size.
- 在多个流中按顺序传递用户消息，可选择单个用户消息的到达顺序传递，-可选择将用户消息多路复用到SCTP数据报，-通过在关联的任意一端或两端支持多宿主实现网络级容错，-抵抗洪水和伪装攻击，以及-数据分割以符合发现的路径MTU大小。
There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY be determined to not be required and TCP MAY be used as the underlying common transport protocol.
有些场景没有冗余要求，有些场景在传输层下支持冗余。在这些情况下，可以确定不需要上述SCTP功能，并且可以将TCP用作底层公共传输协议。
1.3.2. Support for the Management of SCTP Associations between the SG and ASPs
1.3.2. 支持管理SG和ASP之间的SCTP关联
The IUA layer at the SG maintains the availability state of all dynamically registered remote ASPs, in order to manage the SCTP associations and the traffic between the SG and ASPs. As well, the active/inactive states of remote ASP(s) are maintained. Active ASPs are those currently receiving traffic from the SG.
SG处的IUA层维护所有动态注册的远程ASP的可用性状态，以便管理SCTP关联以及SG和ASP之间的流量。此外，远程ASP的活动/非活动状态也会保持不变。活动ASP是当前从SG接收流量的ASP。
The IUA layer MAY be instructed by local management to establish an SCTP association to a peer IUA node. This can be achieved using the M-SCTP ESTABLISH primitive to request, indicate, and confirm the establishment of an SCTP association with a peer IUA node.
IUA层可由本地管理层指示建立与对等IUA节点的SCTP关联。这可以通过使用M-SCTP建立原语来请求、指示和确认与对等IUA节点建立SCTP关联来实现。
The IUA layer MAY also need to inform local management of the status of the underlying SCTP associations using the M-SCTP STATUS request and indication primitive. For example, the IUA MAY inform local management of the reason for the release of an SCTP association, determined either locally within the IUA layer or by a primitive from the SCTP.
IUA层可能还需要使用M-SCTP状态请求和指示原语通知本地管理层底层SCTP关联的状态。例如，IUA可以通知本地管理层释放SCTP关联的原因，该关联由IUA层内本地确定或由来自SCTP的原语确定。
The IUA layer supports ASP fail-over functions in order to support a high availability of call processing capability. All Q.921-User messages incoming to an SG are assigned to a unique Application Server, based on the Interface Identifier of the message.
IUA层支持ASP故障转移功能，以支持呼叫处理能力的高可用性。根据消息的接口标识符，传入SG的所有Q.921用户消息都分配给唯一的应用程序服务器。
The Application Server is, in practical terms, a list of all ASPs configured to process Q.921-User messages from certain Interface Identifiers. One or more ASPs in the list are normally active (i.e., handling traffic) while any others MAY be unavailable or inactive, to be possibly used in the event of failure or unavailability of the active ASP(s).
实际上，应用服务器是配置为处理来自特定接口标识符的Q.921用户消息的所有ASP的列表。列表中的一个或多个ASP通常处于活动状态（即处理流量），而任何其他ASP可能不可用或不活动，以便在活动ASP出现故障或不可用时使用。
The IUA layer supports an n+k redundancy model (active-standby, load sharing, broadcast) where n is the minimum number of redundant ASPs required to handle traffic and k ASPs are available to take over for a failed or unavailable ASP. Note that 1+1 active/standby redundancy is a subset of this model. A simplex 1+0 model is also supported as a subset, with no ASP redundancy.
IUA层支持n+k冗余模型（主动备用、负载共享、广播），其中n是处理流量所需的最小冗余ASP数量，k个ASP可用于接管发生故障或不可用的ASP。请注意，1+1主动/备用冗余是该模型的一个子集。simplex 1+0模型也支持作为子集，没有ASP冗余。
It is recommended that the SG and ASP be able to support both client and server operation. The peer endpoints using IUA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The default orientation would be for the SG to take on the role of server while the ASP is the client. In this case, ASPs SHOULD initiate the SCTP association to the SG.
建议SG和ASP能够同时支持客户端和服务器操作。应配置使用IUA的对等端点，以便其中一个始终扮演客户端角色，另一个始终扮演服务器角色，以启动SCTP关联。默认情况下，SG将承担服务器角色，而ASP是客户端。在这种情况下，ASP应启动与SG的SCTP关联。
The SCTP and TCP Registered User Port Number Assignment for IUA is 9900.
IUA的SCTP和TCP注册用户端口号分配为9900。
In the backhaul scenario, the Q.921/Q.931 boundary primitives are exposed. IUA layer needs to support all of the primitives of this boundary to successfully backhaul Q.931.
在回程场景中，将显示Q.921/Q.931边界原语。IUA层需要支持该边界的所有原语，才能成功回程Q.931。
This includes the following primitives [1]:
这包括以下原语[1]：
DL-ESTABLISH
DL-建立
The DL-ESTABLISH primitives are used to request, indicate, and confirm the outcome of the procedures for establishing multiple frame operation.
DL-SETUP原语用于请求、指示和确认建立多帧操作的过程的结果。
DL-RELEASE
DL-释放
DL-RELEASE primitives are used to request, indicate, and confirm the outcome of the procedures for terminating a previously established multiple frame operation, or for reporting an unsuccessful establishment attempt.
DL-RELEASE原语用于请求、指示和确认终止先前建立的多帧操作或报告不成功的建立尝试的过程的结果。
DL-DATA
DL-DATA
The DL-DATA primitives are used to request and indicate layer 3 (Q.931) messages that are to be transmitted, or have been received, by the Q.921 layer using the acknowledged information transfer service.
DL-DATA原语用于请求和指示将由Q.921层使用确认信息传输服务传输或接收的第3层（Q.931）消息。
DL-UNIT DATA
DL单元数据
The DL-UNIT DATA primitives are used to request and indicate layer 3 (Q.931) messages that are to be transmitted, by the Q.921 layer using the unacknowledged information transfer service.
DL-UNIT数据原语用于请求和指示将由Q.921层使用未确认信息传输服务传输的第3层（Q.931）消息。
1.4.2. Support for Communication between Layer Management Modules on SG and MGC
1.4.2. 支持SG和MGC上的层管理模块之间的通信
It is envisioned that the IUA layer needs to provide some services that will facilitate communication between Layer Management modules on the SG and MGC. These primitives are shown below:
预计IUA层需要提供一些服务，以促进SG和MGC上的层管理模块之间的通信。这些原语如下所示：
M-TEI STATUS
M-TEI状态
The M-TEI STATUS primitives are used to request, confirm, and indicate the status (assigned/unassigned) of an ISDN Terminal Endpoint Identifier (TEI).
M-TEI状态原语用于请求、确认和指示ISDN终端端点标识符（TEI）的状态（已分配/未分配）。
M-ERROR
M误差
The M-ERROR primitive is used to indicate an error with a received IUA message (e.g., interface identifier value is not known to the SG).
M-ERROR原语用于指示接收到的IUA消息的错误（例如，SG不知道接口标识符值）。
A set of primitives between the IUA layer and the Layer Management is defined below to help the Layer Management manage the SCTP association(s) between the SG and MGC. The IUA layer can be instructed by the Layer Management to establish an SCTP association to a peer IUA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive.
下面定义了IUA层和层管理之间的一组原语，以帮助层管理管理SG和MGC之间的SCTP关联。层管理可以指示IUA层建立与对等IUA节点的SCTP关联。此过程可使用M-SCTP建立原语实现。
M-SCTP ESTABLISH
M-SCTP建立
The M-SCTP ESTABLISH primitives are used to request, indicate, and confirm the establishment of an SCTP association to a peer IUA node.
M-SCTP建立原语用于请求、指示和确认建立到对等IUA节点的SCTP关联。
M-SCTP RELEASE
M-SCTP释放
The M-SCTP RELEASE primitives are used to request, indicate, and confirm the release of an SCTP association to a peer IUA node.
M-SCTP释放原语用于请求、指示和确认向对等IUA节点释放SCTP关联。
The IUA layer MAY also need to inform the status of the SCTP associations to the Layer Management. This can be achieved using the M-SCTP STATUS primitive.
IUA层可能还需要向管理层通知SCTP关联的状态。这可以通过使用M-SCTP状态原语来实现。
M-SCTP STATUS
M-SCTP状态
The M-SCTP STATUS primitives are used to request and indicate the status of the underlying SCTP association(s).
M-SCTP状态原语用于请求和指示底层SCTP关联的状态。
The Layer Management MAY need to inform the IUA layer of an AS/ASP status (i.e., failure, active, etc.), so that messages can be exchanged between IUA layer peers to stop traffic to the local IUA user. This can be achieved using the M-ASP STATUS primitive.
层管理可能需要通知IUA层AS/ASP状态（即，故障、活动等），以便可以在IUA层对等方之间交换消息以停止到本地IUA用户的通信。这可以使用M-ASP状态原语实现。
M-ASP STATUS
M-ASP状态
The ASP status is stored inside IUA layer on both the SG and MGC sides. The M-ASP STATUS primitive can be used by Layer Management to request the status of the Application Server Process from the IUA layer. This primitive can also be used to indicate the status of the Application Server Process.
ASP状态存储在SG和MGC两侧的IUA层内。层管理可以使用M-ASP状态原语从IUA层请求应用程序服务器进程的状态。此原语还可用于指示应用程序服务器进程的状态。
M-ASP-UP
M-ASP-UP
The M-ASP-UP primitive can be used by Layer Management to send a ASP Up message for the Application Server Process. It can also be used to generate an ASP Up Acknowledgement.
层管理可以使用M-ASP-UP原语为应用程序服务器进程发送ASP UP消息。它还可用于生成ASP Up确认。
M-ASP-DOWN
M-ASP-DOWN
The M-ASP-DOWN primitive can be used by Layer Management to send a ASP Down message for the Application Server Process. It can also be used to generate an ASP Down Acknowledgement.
层管理可以使用M-ASP-DOWN原语为应用程序服务器进程发送ASP DOWN消息。它还可用于生成ASP关闭确认。
M-ASP-ACTIVE
M-ASP-ACTIVE
The M-ASP-UP primitive can be used by Layer Management to send a ASP Active message for the Application Server Process. It can also be used to generate an ASP Active Acknowledgement.
层管理可以使用M-ASP-UP原语为应用程序服务器进程发送ASP活动消息。它还可用于生成ASP活动确认。
M-ASP-INACTIVE
M-ASP-1
The M-ASP-UP primitive can be used by Layer Management to send a ASP Inactive message for the Application Server Process. It can also be used to generate an ASP Inactive Acknowledgement.
层管理可以使用M-ASP-UP原语为应用程序服务器进程发送ASP非活动消息。它还可用于生成ASP非活动确认。
M-AS STATUS
并购地位
The M-AS STATUS primitive can be used by Layer Management to request the status of the Application Server. This primitive can also be used to indicate the status of the Application Server.
层管理可以使用M-AS STATUS原语请求应用程序服务器的状态。此原语还可用于指示应用程序服务器的状态。
The IUA layer MUST maintain a map of the Interface Identifier to a physical interface on the Signaling Gateway. A physical interface would be a T1 line, E1 line, etc., and could include the Time-Division Multiplexing (TDM) timeslot. In addition, for a given interface the SG MUST be able to identify the associated signaling channel. IUA layers on both SG and MGC MAY maintain the status of ISDN Terminal Endpoint Identifiers (TEIs) and Service Access Point Identifiers (SAPIs).
IUA层必须维护接口标识符到信令网关上物理接口的映射。物理接口可以是T1线、E1线等，并且可以包括时分复用（TDM）时隙。此外，对于给定接口，SG必须能够识别相关的信令信道。SG和MGC上的IUA层可以维护ISDN终端端点标识符（tei）和服务接入点标识符（sapi）的状态。
The SG maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular Interface Identifier. It MUST be noted, however, that this mapping is dynamic and could change at any time due to a change of ASP state. This mapping could even temporarily be invalid, for example, during fail-over of one ASP to another. Therefore, the SG MUST maintain the states of AS/ASP and reference them during the routing of an messages to an AS/ASP.
只有当ASP发送特定接口标识符的ASP活动消息时，SG才会将接口标识符映射到SCTP关联/流。但是，必须注意的是，此映射是动态的，并且可能由于ASP状态的更改而随时更改。这种映射甚至可能暂时无效，例如，在一个ASP到另一个ASP的故障转移期间。因此，SG必须维护AS/ASP的状态，并在将消息路由到AS/ASP期间引用这些状态。
One example of the logical view of relationship between D channel, Interface Identifier, AS, and ASP in the SG is shown below:
SG中D通道、接口标识符、AS和ASP之间关系的逻辑视图的一个示例如下所示：
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+-
D chan1-------->|IID |-+ +-->| ASP |--->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
D chan2-------->|IID |-+ | ASP |
+----+ +-----+
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+-
D chan1-------->|IID |-+ +-->| ASP |--->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
D chan2-------->|IID |-+ | ASP |
+----+ +-----+
where IID = Interface Identifier
其中IID=接口标识符
Note that an ASP can be in more than one AS.
请注意，ASP可以在多个AS中。
The IUA layer on the SG MUST maintain the state of the ASPs it is supporting. The state of an ASP changes because of reception of peer-to-peer messages (ASPM messages as described in Section 3.3.2) or reception of indications from the local SCTP association. ASP state transition procedures are described in Section 4.3.1.
SG上的IUA层必须保持其支持的ASP的状态。由于接收到对等消息（如第3.3.2节所述的ASPM消息）或接收到来自本地SCTP协会的指示，ASP的状态会发生变化。ASP状态转换程序见第4.3.1节。
At a SG, an Application Server list MAY contain active and inactive ASPs to support ASP load-sharing and fail-over procedures. When, for example, both a primary and a backup 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).
在SG，应用服务器列表可能包含活动和非活动ASP，以支持ASP负载共享和故障转移过程。例如，当主ASP和备份ASP都可用时，需要IUA对等协议来控制当前活动的ASP。逻辑应用程序服务器中的ASP有序列表在SG中保持更新，以反映活动的应用程序服务器进程。
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.
此外，IUA层可能需要通知本地管理层ASP或AS状态的变化。这可以使用M-ASP状态或M-AS状态原语实现。
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.
SCTP允许在初始化期间打开用户指定数量的流。IUA层负责确保这些流的正确管理。由于流的单向性，IUA层不知道其对等IUA层的流号到接口标识符的映射。相反，接口标识符位于IUA消息头中。
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.
建议在IUA中使用SCTP流，以最小化传输和缓冲延迟，从而提高信令元件的整体性能和可靠性。建议为每个D通道使用单独的SCTP流。
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.
如果当前活动的ASP从活动状态移动，则SG上的IUA层应将IUA用户不可用的指示（Q.931）传递给本地层管理。如果层管理层认为合适，可以指示Q.921采取一些措施。
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.
同样，如果SCTP关联失败，SG和ASP双方的IUA层可能会生成释放原语，以使数据链路停止服务。
If the IUA layer becomes congested (implementation dependent), it MAY stop reading from the SCTP association to flow control from the peer IUA.
如果IUA层变得拥挤（取决于实现），它可能会停止从SCTP关联读取来自对等IUA的流控制。
DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA
DL-建立DL-发布DL-数据DL-单元数据
DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA
DL-建立DL-发布DL-数据DL-单元数据
An example of the upper layer primitives provided by SCTP are available in Section 10 of RFC 2960 [4].
RFC 2960[4]第10节提供了SCTP提供的上层原语示例。
M-SCTP ESTABLISH request Direction: LM -> IUA Purpose: LM requests ASP to establish an SCTP association with an SG.
M-SCTP建立请求方向：LM->IUA目的：LM请求ASP与SG建立SCTP关联。
M-STCP ESTABLISH confirm Direction: IUA -> LM Purpose: ASP confirms to LM that it has established an SCTP association with an SG.
M-STCP建立确认方向：IUA->LM目的：ASP向LM确认其已与SG建立SCTP关联。
M-SCTP ESTABLISH indication Direction: IUA -> LM Purpose: SG informs LM that an ASP has established an SCTP association.
M-SCTP建立指示方向：IUA->LM目的：SG通知LM ASP已建立SCTP关联。
M-SCTP RELEASE request Direction: LM -> IUA Purpose: LM requests ASP to release an SCTP association with SG.
M-SCTP发布请求方向：LM->IUA目的：LM请求ASP发布与SG的SCTP关联。
M-SCTP RELEASE confirm Direction: IUA -> LM Purpose: ASP confirms to LM that it has released SCTP association with SG.
M-SCTP发布确认方向：IUA->LM目的：ASP向LM确认其已发布与SG的SCTP关联。
M-SCTP RELEASE indication Direction: IUA -> LM Purpose: SG informs LM that ASP has released an SCTP association.
M-SCTP发布指示方向：IUA->LM目的：SG通知LM ASP已发布SCTP关联。
M-SCTP STATUS request Direction: LM -> IUA Purpose: LM requests IUA to report status of SCTP association.
M-SCTP状态请求方向：LM->IUA目的：LM请求IUA报告SCTP关联状态。
M-SCTP STATUS indication Direction: IUA -> LM Purpose: IUA reports status of SCTP association.
M-SCTP状态指示方向：IUA->LM目的：IUA报告SCTP关联的状态。
M-ASP STATUS request Direction: LM -> IUA Purpose: LM requests SG to report status of remote ASP.
M-ASP状态请求方向：LM->IUA目的：LM请求SG报告远程ASP的状态。
M-ASP STATUS indication Direction: IUA -> LM Purpose: SG reports status of remote ASP.
M-ASP状态指示方向：IUA->LM目的：SG报告远程ASP的状态。
M-AS-STATUS request Direction: LM -> IUA Purpose: LM requests SG to report status of AS.
M-AS-STATUS请求方向：LM->IUA目的：LM请求SG报告AS的状态。
M-AS-STATUS indication Direction: IUA -> LM Purpose: SG reports status of AS.
M-AS状态指示方向：IUA->LM目的：SG报告AS状态。
M-NOTIFY indication Direction: IUA -> LM Purpose: ASP reports that it has received a NOTIFY message from its peer.
M-NOTIFY指示方向：IUA->LM目的：ASP报告它已收到来自其对等方的NOTIFY消息。
M-ERROR indication Direction: IUA -> LM Purpose: ASP or SG reports that it has received an ERROR message from its peer.
M-错误指示方向：IUA->LM目的：ASP或SG报告它已收到来自其对等方的错误消息。
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请求方向：LM->IUA目的：LM请求ASP启动其操作并向SG发送ASP UP消息。
M-ASP-UP confirm Direction: IUA -> LM Purpose: ASP reports that is has received an ASP UP Acknowledgement message from the SG.
M-ASP-UP确认方向：IUA->LM目的：收到来自SG的ASP UP确认消息的ASP报告。
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请求方向：LM->IUA目的：LM请求ASP停止其操作并向SG发送ASP DOWN消息。
M-ASP-DOWN confirm Direction: IUA -> LM Purpose: ASP reports that is has received an ASP DOWN Acknowledgement message from the SG.
M-ASP-DOWN确认方向：IUA->LM目的：已收到来自SG的ASP DOWN确认消息的ASP报告。
M-ASP-ACTIVE request Direction: LM -> IUA Purpose: LM requests ASP to send an ASP ACTIVE message to the SG.
M-ASP-ACTIVE请求方向：LM->IUA目的：LM请求ASP向SG发送ASP活动消息。
M-ASP-ACTIVE confirm Direction: IUA -> LM Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement message from the SG.
M-ASP-ACTIVE确认方向：IUA->LM目的：已收到来自SG的ASP ACTIVE确认消息的ASP报告。
M-ASP-INACTIVE request Direction: LM -> IUA Purpose: LM requests ASP to send an ASP INACTIVE message to the SG.
M-ASP-INACTIVE请求方向：LM->IUA目的：LM请求ASP向SG发送ASP INACTIVE消息。
M-ASP-INACTIVE confirm Direction: IUA -> LM Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement message from the SG.
M-ASP-INACTIVE确认方向：IUA->LM目的：接收到来自SG的ASP INACTIVE确认消息的ASP报告。
M-TEI STATUS request Direction: LM -> IUA Purpose: LM requests ASP to send a TEI status request to the SG.
M-TEI状态请求方向：LM->IUA目的：LM请求ASP向SG发送TEI状态请求。
M-TEI STATUS indication Direction: IUA -> LM Purpose: ASP reports that is has received a TEI status indication from the SG.
M-TEI状态指示方向：IUA->LM目的：ASP报告已从SG接收到TEI状态指示。
M-TEI STATUS confirm Direction: IUA -> LM Purpose: ASP reports that is has received a TEI status confirm from the SG.
M-TEI状态确认方向：IUA->LM目的：已从SG收到TEI状态确认的ASP报告。
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 [6].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照[6]中所述进行解释。
This section describes the format of various messages used in this protocol.
本节介绍本协议中使用的各种消息的格式。
The protocol messages for Q.921-User Adaptation require a message header that contains the adaptation layer version, the message type, and message length.
Q.921-用户自适应的协议消息需要包含自适应层版本、消息类型和消息长度的消息头。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 2. Common Header Format
图2。通用头格式
All fields in an IUA message MUST be transmitted in the network byte order, unless otherwise stated.
除非另有说明，IUA消息中的所有字段必须以网络字节顺序传输。
The version field contains the version of the IUA adaptation layer. The supported versions are the following:
版本字段包含IUA适配层的版本。支持的版本如下：
Value Version
----- -------
1 Release 1.0
Value Version
----- -------
1 Release 1.0
The following list contains the valid Message Classes:
以下列表包含有效的消息类：
Message Class: 8 bits (unsigned integer)
消息类：8位（无符号整数）
0 Management (MGMT) Message 1 Reserved for Other SIGTRAN Adaptation Layer 2 Reserved for Other SIGTRAN Adaptation Layers 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 6 Reserved for Other SIGTRAN Adaptation Layer 7 Reserved for Other SIGTRAN Adaptation Layer 8 Reserved for Other SIGTRAN Adaptation Layer 9 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions
0管理（MGMT）消息1为其他SIGTRAN适配层保留2为其他SIGTRAN适配层保留3 ASP状态维护（ASPSM）消息4 ASP流量维护（ASPTM）消息5 Q.921/Q.931边界原语传输（QPTM）消息6保留给其他SIGTRAN适配层7保留给其他SIGTRAN适配层8保留给其他SIGTRAN适配层9到127保留给IETF 128到255保留给IETF定义的消息类扩展
The following list contains the message names for the defined messages.
以下列表包含已定义消息的消息名称。
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
Q.921/Q.931边界原语传输（QPTM）消息
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
0保留1数据请求消息2数据指示消息3单元数据请求消息4单元数据指示消息5建立请求6建立确认7建立指示8发布请求9发布确认10发布指示11至127由IETF保留128至255为IETF定义的QPTM扩展保留
Application Server Process State Maintenance (ASPSM) messages
应用程序服务器进程状态维护（ASPSM）消息
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
0保留1 ASP向上（向上）2 ASP向下（向下）3心跳（节拍）4 ASP向上确认（向上确认）5 ASP向下确认（向下确认）6热拍确认（节拍确认）7到127由IETF保留128到255为IETF定义的ASPSM扩展保留
Application Server Process Traffic Maintenance (ASPTM) messages
应用程序服务器进程流量维护（ASPTM）消息
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
0保留1 ASP活动（活动）2 ASP非活动（非活动）3 ASP活动确认（活动确认）4 ASP非活动确认（非活动确认）5到127由IETF保留128到255为IETF定义的ASPTM扩展保留
Management (MGMT) Messages
管理（MGMT）消息
0 Error (ERR) 1 Notify (NTFY) 2 TEI Status Request 3 TEI Status Confirm 4 TEI Status Indication 5 TEI Query Request 6 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MGMT extensions
0错误（错误）1通知（NTFY）2 TEI状态请求3 TEI状态确认4 TEI状态指示5 TEI查询请求6到127由IETF保留128到255为IETF定义的管理扩展保留
The Reserved field is 8 bits. It SHOULD be set to all '0's and ignored by the receiver.
保留字段为8位。它应设置为所有“0”，并被接收器忽略。
The Message Length defines the length of the message in octets, including the Common Header. The Message Length MUST include parameter padding bytes, if any.
消息长度以八位字节定义消息的长度，包括公共头。消息长度必须包括参数填充字节（如果有）。
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.
注意：无论消息长度中是否包含最终参数填充，接收方都应接受消息。
IUA messages consist of a Common Header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a Type-Length-Value (TLV) format as shown below.
IUA消息由一个公共头和零个或多个可变长度参数组成，这些参数由消息类型定义。消息中包含的可变长度参数以类型长度值（TLV）格式定义，如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory parameters MUST be placed before optional parameters in a message.
在消息中，必须将强制参数置于可选参数之前。
Parameter Tag: 16 bits (unsigned integer)
参数标记：16位（无符号整数）
The Tag field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. Common parameters used by adaptation layers are in the range of 0x00 to 0x3f. The parameter Tags defined are as follows:
标记字段是参数类型的16位标识符。它的值为0到65534。适配层使用的通用参数范围为0x00到0x3f。定义的参数标记如下所示：
Common Parameters. These TLV parameters are common across the different adaptation layers:
公共参数。这些TLV参数在不同的适配层中是通用的：
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Interface Identifier (integer) 0x0001
Not Used in IUA 0x0002
Interface Identifier (text) 0x0003
INFO String 0x0004
DLCI 0x0005
Not Used in IUA 0x0006
Diagnostic Information 0x0007
Interface Identifier Range 0x0008
Heartbeat Data 0x0009
Not Used in IUA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Protocol Data 0x000e
Release Reason 0x000f
TEI Status 0x0010
ASP Identifier 0x0011
Not Used in IUA 0x0012 - 0x003f
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Interface Identifier (integer) 0x0001
Not Used in IUA 0x0002
Interface Identifier (text) 0x0003
INFO String 0x0004
DLCI 0x0005
Not Used in IUA 0x0006
Diagnostic Information 0x0007
Interface Identifier Range 0x0008
Heartbeat Data 0x0009
Not Used in IUA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Protocol Data 0x000e
Release Reason 0x000f
TEI Status 0x0010
ASP Identifier 0x0011
Not Used in IUA 0x0012 - 0x003f
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific parameter description are reserved for use by the IETF.
65535的值保留给IETF定义的扩展。特定参数描述中定义的值以外的值保留供IETF使用。
Parameter Length: 16 bits (unsigned integer)
参数长度：16位（无符号整数）
The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. The Parameter Length does not include any padding bytes.
参数长度字段包含以字节为单位的参数大小，包括参数标记、参数长度和参数值字段。参数长度不包括任何填充字节。
Parameter Value: variable-length
参数值：可变长度
The Parameter Value field contains the actual information to be transferred in the parameter.
参数值字段包含要在参数中传输的实际信息。
The total length of a parameter (including Tag, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the Parameter Length field. A sender SHOULD NEVER pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
参数的总长度（包括标记、参数长度和值字段）必须是4字节的倍数。如果参数的长度不是4字节的倍数，则发送方在参数末尾（即参数值字段之后）填充所有零字节。填充的长度不包括在参数长度字段中。发送方的填充长度不应超过3个字节。接收器必须忽略填充字节。
In addition to the common message header, there will be a specific message header for QPTM and the TEI Status MGMT messages. The IUA message header will immediately follow the Common header in these messages.
除了通用消息头之外，QPTM和TEI状态管理消息还有一个特定的消息头。IUA消息头将紧跟在这些消息中的公共头之后。
This message header will contain the Interface Identifier and Data Link Connection Identifier (DLCI). The Interface Identifier identifies the physical interface terminating the signaling channel at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer. The Interface Identifiers are assigned according to network operator policy. The integer values used are of local significance only, coordinated between the SG and ASP.
此消息头将包含接口标识符和数据链路连接标识符（DLCI）。接口标识符标识在SG处终止信令信道的物理接口，信令消息针对该物理接口被发送/接收。接口标识符参数的格式可以是文本或整数。根据网络运营商策略分配接口标识符。使用的整数值仅具有局部意义，在SG和ASP之间进行协调。
The integer-formatted Interface Identifier MUST be supported. The text-formatted Interface Identifier MAY optionally be supported.
必须支持整数格式的接口标识符。可以选择支持文本格式的接口标识符。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IUA Message Header (Integer-based Interface Identifier)
图3。IUA消息头（基于整数的接口标识符）
The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8.
基于整数的接口标识符的标记值为0x1。长度始终设置为8的值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Interface Identifier (text) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Interface Identifier (text) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IUA Message Header (Text-based Interface Identifier)
图4。IUA消息头（基于文本的接口标识符）
The Tag value for the Text-based [2] Interface Identifier is 0x3. The length is variable.
基于文本的[2]接口标识符的标记值为0x3。长度是可变的。
The DLCI format is shown below in Figure 5.
DLCI格式如下图5所示。
most least
significant significant
bit bit
+-----+-----+-----+-----+-----+-----+-----+-----+
| SAPI | SPR | 0 |
+-----------------------------------------------+
| TEI | 1 |
+-----------------------------------------------+
most least
significant significant
bit bit
+-----+-----+-----+-----+-----+-----+-----+-----+
| SAPI | SPR | 0 |
+-----------------------------------------------+
| TEI | 1 |
+-----------------------------------------------+
Figure 5. DLCI Format
图5。DLCI格式
SPR: Spare 2nd bit in octet 1 (1 bit)
SPR：八位组1中的备用第二位（1位）
SAPI: Service Access Point Identifier (6 bits)
SAPI：服务接入点标识符（6位）
TEI: Terminal Endpoint Identifier (7 bits)
TEI：终端端点标识符（7位）
As an example, SAPI = 0, TEI = 64, SPR = 0 would be encoded as follows:
例如，SAPI=0、TEI=64、SPR=0的编码如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x81 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x81 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DLCI field (including the SAPI and TEI) is coded in accordance with Q.921.
DLCI字段（包括SAPI和TEI）按照Q.921进行编码。
The following section defines the messages and parameter contents. The IUA messages will use the common message header (Figure 2) and the IUA message header (Figure 3 and Figure 4).
以下部分定义了消息和参数内容。IUA消息将使用公共消息头（图2）和IUA消息头（图3和图4）。
The Establish Messages are used to establish a data link on the signaling channel or to confirm that a data link on the signaling channel has been established. The MGC controls the state of the D channel. When the MGC desires the D channel to be in-service, it will send the Establish Request message.
建立消息用于在信令信道上建立数据链路或确认已在信令信道上建立数据链路。MGC控制D通道的状态。当MGC希望D通道处于服务状态时，它将发送建立请求消息。
When the MGC sends an IUA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an IUA Establish Confirm or Establish Indication. If the timer expires, the MGC would resend the IUA Establish Request message and restart the timer. In other words, the MGC MAY continue to request the establishment of the data link on a periodic basis until the desired state is achieved or take some other action (notify the Management Layer).
当MGC发送IUA建立请求消息时，MGC可以启动计时器。收到IUA建立确认或建立指示后，该计时器将停止。如果计时器过期，MGC将重新发送IUA建立请求消息并重新启动计时器。换言之，MGC可以继续定期请求建立数据链路，直到达到期望的状态，或者采取一些其他行动（通知管理层）。
When the SG receives an IUA Establish Request from the MGC, the SG shall send the Q.921 Establish Request primitive to the Q.921 entity. In addition, the SG shall map any response received from the Q.921 entity to the appropriate message to the MGC. For example, if the Q.921 entity responds with a Q.921 Establish Confirm primitive, the
当SG从MGC收到IUA建立请求时，SG应将Q.921建立请求原语发送给Q.921实体。此外，SG应将从Q.921实体收到的任何响应映射到MGC的适当消息。例如，如果Q.921实体响应Q.921建立确认原语，则
IUA layer shall map this to an IUA Establish Confirm message. As another example, if the IUA Layer receives a Q.921 Release Confirm or Release Indication as an apparent response to the Q.921 Establish Request primitive, the IUA Layer shall map these to the corresponding IUA Release Confirm or Release Indication messages.
IUA层应将其映射到IUA建立确认消息。作为另一个示例，如果IUA层接收到Q.921发布确认或发布指示，作为对Q.921建立请求原语的明显响应，则IUA层应将其映射到相应的IUA发布确认或发布指示消息。
The Establish messages contain the common message header followed by IUA message header. It does not contain any additional parameters.
建立消息包含公共消息头，后跟IUA消息头。它不包含任何附加参数。
The Release Request message is used to release the data link on the signaling channel. The Release Confirm and Indication messages are used to indicate that the data link on the signaling channel has been released.
释放请求消息用于释放信令信道上的数据链路。释放确认和指示消息用于指示信令信道上的数据链路已被释放。
If a response to the Release Request message is not received, the MGC MAY resend the Release Request message. If no response is received, the MGC can consider the data link as being released. In this case, signaling traffic on that D channel is not expected from the SG and signaling traffic will not be sent to the SG for that D channel.
如果未收到对释放请求消息的响应，则MGC可重新发送释放请求消息。如果没有接收到响应，MGC可以考虑数据链路被释放。在这种情况下，该D信道上的信令业务预计不会来自SG，并且该D信道的信令业务将不会被发送到SG。
The Release messages contain the common message header followed by IUA message header. The Release Confirm message is in response to a Release Request message and it does not contain any additional parameters. The Release Request and Indication messages contain the following parameter:
发布消息包含公共消息头，后跟IUA消息头。释放确认消息是对释放请求消息的响应，它不包含任何附加参数。释放请求和指示消息包含以下参数：
Reason
原因
The format for Release Message parameters is as follows:
发布消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Reason are shown in the following table.
下表显示了合理的有效值。
Define Value Description RELEASE_MGMT 0x0 Management layer generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_DM 0x2 Specific to a request. Indicates Layer 2 SHOULD release and deny all requests from far end to establish a data link on the signaling channel (i.e., if SABME is received, send a DM) RELEASE_OTHER 0x3 Other reasons
定义值描述发布管理0x0管理层生成的发布。释放\u PHYS 0x1物理层警报生成释放。释放特定于请求的DM 0x2。指示第2层应释放并拒绝来自远端的所有请求，以在信令信道上建立数据链路（即，如果接收到SABME，则发送DM）释放\u其他0x3其他原因
Note: Only RELEASE_MGMT, RELEASE_DM, and RELEASE_OTHER are valid reason codes for a Release Request message.
注意：只有RELEASE_MGMT、RELEASE_DM和RELEASE_OTHER是发布请求消息的有效原因码。
The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to acknowledged information transfer service.
数据报文包含一个ISDN Q.921用户协议数据单元（PDU），对应于已确认的信息传输服务。
The Data messages contain the common message header followed by IUA message header. The Data message contains the following parameter:
数据消息包含公共消息头，后跟IUA消息头。数据消息包含以下参数：
Protocol Data
协议数据
The format for Data Message parameters is as follows:
数据消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The protocol data contains upper layer signaling message, e.g., Q.931, QSIG.
协议数据包含上层信令消息，例如Q.931、QSIG。
The Unit Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to unacknowledged information transfer service.
单元数据消息包含对应于未确认信息传输服务的ISDN Q.921用户协议数据单元（PDU）。
The Unit Data messages contain the common message header followed by IUA message header. The Unit Data message contains the following parameter:
单元数据消息包含公共消息头，后跟IUA消息头。机组数据消息包含以下参数：
Protocol Data
协议数据
The format for Unit Data Message parameters is as follows:
机组数据报文参数格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ASPM messages will use only the common message header.
ASPM消息将仅使用公共消息头。
The ASP Up (ASPUP) message is sent by an ASP to indicate to an SG that it is ready to receive traffic or maintenance messages.
ASP Up（ASPUP）消息由ASP发送，以向SG指示其已准备好接收流量或维护消息。
The ASPUP message contains the following parameters:
ASPUP消息包含以下参数：
ASP Identifier (Optional) INFO String (Optional)
ASP标识符（可选）信息字符串（可选）
The format for ASPUP Message parameters is as follows:
ASPUP消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASP Identifier: 32-bit unsigned integer
ASP标识符：32位无符号整数
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SG should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.3.3.2).
可选的ASP标识符参数包含一个唯一值，该值在支持AS的ASP中具有本地意义。SG应保存ASP标识符，以便在必要时与Notify消息一起使用（见第3.3.3.2节）。
The optional INFO String parameter can carry any meaningful 8-bit ASCII [2] character string along with the message. Length of the INFO String parameter is from 0 to 255 characters. No procedures are presently identified for its use, but the INFO String MAY be used for debugging purposes.
可选信息字符串参数可以携带任何有意义的8位ASCII[2]字符串以及消息。信息字符串参数的长度为0到255个字符。目前还没有为其使用标识任何过程，但信息字符串可用于调试目的。
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote IUA peer.
ASP Up Ack消息用于确认从远程IUA对等方接收到的ASP Up消息。
The ASPUP Ack message contains the following parameters:
ASUP Ack消息包含以下参数：
INFO String (optional)
信息字符串（可选）
The format for ASPUP Ack Message parameters is as follows:
ASPUP Ack消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（参见第3.3.2.1节）。
The ASP Down (ASPDN) message is sent by an ASP to indicate to an SG that it is NOT ready to receive traffic or maintenance messages.
ASP Down（ASPDN）消息由ASP发送，以指示SG尚未准备好接收流量或维护消息。
The ASPDN message contains the following parameters:
ASPDN消息包含以下参数：
INFO String (Optional)
信息字符串（可选）
The format for the ASPDN message parameters is as follows:
ASPDN消息参数的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（参见第3.3.2.1节）。
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer.
ASP Down Ack消息用于确认从远程IUA对等方接收到的ASP Down消息。
The ASP Down Ack message contains the following parameters:
ASP Down Ack消息包含以下参数：
INFO String (Optional)
信息字符串（可选）
The format for the ASP Down Ack message parameters is as follows:
ASP Down Ack消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（参见第3.3.2.1节）。
The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used.
ASPAC消息由ASP发送，以向SG指示其处于活动状态并准备好使用。
The ASPAC message contains the following parameters:
ASPAC消息包含以下参数：
Traffic Mode Type (Mandatory) Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text-formatted) INFO String (Optional)
交通模式类型（必需）接口标识符（可选）-整数和整数范围的组合，或-字符串（文本格式）信息字符串（可选）
The format for the ASPAC message using integer-formatted Interface Identifiers is as follows:
使用整数格式接口标识符的ASPAC消息格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASPAC message using text-formatted (string) Interface Identifiers is as follows:
使用文本格式（字符串）接口标识符的ASPAC消息格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table:
Traffic Mode Type参数标识AS中ASP的运行流量模式。类型的有效值如下表所示：
Value Description 0x1 Over-ride 0x2 Load-share
值说明0x1超越0x2负载共享
Within a particular AS, only one Traffic Mode Type can be used. The Over-ride value indicates that the ASP is operating in Over-ride mode, where the ASP takes over all traffic in an Application Server (i.e., primary/backup operation), over-riding any currently active ASPs in the AS. In Load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs.
在特定AS中，只能使用一种交通模式类型。Over ride值表示ASP在Over ride模式下运行，在此模式下，ASP接管应用程序服务器中的所有流量（即主/备份操作），超过AS中任何当前活动的ASP。在负载共享模式下，ASP将与任何其他当前活动的ASP共享流量分布。
The optional Interface Identifiers parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer-formatted
可选的Interface Identifiers参数包含接口标识符整数（类型0x1或类型0x8）或文本字符串（类型0x3）列表，用于索引发送ASP配置/注册为接收的应用程序服务器流量。如果整数格式
Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8). Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text-formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
如果正在使用接口标识符，ASP还可以发送接口标识符的范围（类型0x8）。同一消息中允许使用Integer（0x1）和Integer Range（0x8）接口标识符类型。文本格式的接口标识符（0x3）不能与整数（0x1）或整数范围（0x8）类型一起使用。
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS or ASes in which the ASP is provisioned. If only a subset of Interface Identifiers is included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
如果未包含任何接口标识符，则该消息针对在其中配置ASP的AS或ASE中所有配置的接口标识符。如果仅包括接口标识符的子集，则ASP对于为其设置的所有接口标识符都被视为活动的。
Note: If the optional Interface Identifier parameter is present, the integer-formatted Interface Identifier MUST be supported, whereas the text-formatted Interface Identifier MAY be supported.
注意：如果存在可选接口标识符参数，则必须支持整数格式的接口标识符，而可能支持文本格式的接口标识符。
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1.).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（见第3.3.2.1节）。
An SG that receives an ASPAC with an incorrect Traffic Mode Type for a particular Interface Identifier will respond with an Error Message (Cause: Unsupported Traffic Handling Mode).
接收到特定接口标识符的ASPAC的流量模式类型不正确的SG将响应错误消息（原因：不支持的流量处理模式）。
The ASPAC Ack message is used to acknowledge an ASP Active message received from a remote IUA peer.
ASPAC Ack消息用于确认从远程IUA对等方接收到的ASP活动消息。
The ASPAC Ack message contains the following parameters:
ASPAC Ack消息包含以下参数：
Traffic Mode Type (Mandatory) Interface Identifier (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
交通模式类型（必需）接口标识符（可选）-整数和整数范围的组合，或-字符串（文本格式）信息字符串（可选）
The format for the ASPAC Ack message with integer-formatted Interface Identifiers is as follows:
带有整数格式接口标识符的ASPAC Ack消息格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Active Ack message using text-formatted (string) Interface Identifiers is as follows:
使用文本格式（字符串）接口标识符的ASP活动确认消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Mode Type and Interface Identifier parameters is the same as for the ASP Active message (see Section 3.3.2.5).
流量模式类型和接口标识符参数的格式与ASP活动消息的格式相同（见第3.3.2.5节）。
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（参见第3.3.2.1节）。
The ASPIA message is sent by an ASP to indicate to an SG that it is no longer an active ASP to be used from within a list of ASPs. The SG will respond with an ASPIA Ack message and either discard incoming messages or buffer for a timed period and then discard.
ASPIA消息由ASP发送，以指示SG它不再是要从ASP列表中使用的活动ASP。SG将使用ASPIA Ack消息进行响应，并在一段时间内丢弃传入消息或缓冲区，然后丢弃。
The ASPIA message contains the following parameters:
ASPIA消息包含以下参数：
Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted)
接口标识符（可选）-整数和整数范围的组合，或-字符串（文本格式）
INFO String (Optional)
信息字符串（可选）
The format for the ASP Inactive message parameters using integer-formatted Interface Identifiers is as follows:
使用整数格式接口标识符的ASP非活动消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive message using text-formatted (string) Interface Identifiers is as follows:
使用文本格式（字符串）接口标识符的ASP非活动消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional Interface Identifiers parameter contains a list of Interface Identifier integers or text strings indexing the Application Server traffic that the sending ASP is configured/registered to receive, but does not want to receive at this time.
可选接口标识符参数包含接口标识符整数或文本字符串列表，这些整数或文本字符串索引发送ASP配置/注册为接收但此时不希望接收的应用程序服务器流量。
The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
可选接口标识符和信息字符串参数的格式和说明与ASP活动消息相同（见第3.3.2.5节）。
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote IUA peer.
ASP Inactive（ASPIA）Ack消息用于确认从远程IUA对等方接收到的ASP Inactive消息。
The ASPIA Ack message contains the following parameters:
ASPIA Ack消息包含以下参数：
Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
接口标识符（可选）-整数和整数范围的组合，或-字符串（文本格式）信息字符串（可选）
The format for the ASP Inactive Ack message parameters using integer-formatted Interface Identifiers is as follows:
使用整数格式接口标识符的ASP非活动Ack消息参数的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive Ack message using text-formatted (string) Interface Identifiers is as follows:
使用文本格式（字符串）接口标识符的ASP非活动确认消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
可选接口标识符和信息字符串参数的格式和说明与ASP活动消息相同（见第3.3.2.5节）。
The Heartbeat message is optionally used to ensure that the IUA peers are still available to each other. It is recommended for use when the IUA runs over a transport layer other than the SCTP, which has its own heartbeat.
心跳消息可选择性地用于确保IUA对等点彼此仍然可用。当IUA运行在SCTP以外的传输层时，建议使用它，因为SCTP有自己的心跳信号。
The BEAT message contains the following parameters:
节拍消息包含以下参数：
Heartbeat Data (Optional)
心跳数据（可选）
The format for the BEAT message is as follows:
节拍信息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and/or Timestamp. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver MUST respond with a Heartbeat Ack message.
心跳数据参数内容由发送节点定义。心跳数据可以包括例如心跳序列号和/或时间戳。心跳消息的接收者不处理此字段，因为它仅对发送者重要。接收器必须以心跳确认消息进行响应。
The Heartbeat Ack message is sent in response to a received Heartbeat message. It includes all the parameters of the received Heartbeat message, without any change.
Heartbeat Ack消息是响应接收到的Heartbeat消息而发送的。它包括接收到的心跳消息的所有参数，没有任何更改。
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
错误消息用于通知对等方与传入消息关联的错误事件。例如，给定当前状态，消息类型可能是意外的，或者参数值可能无效。
The Error message will have only the common message header. The Error message contains the following parameters:
错误消息将只有公共消息头。错误消息包含以下参数：
Error Code Diagnostic Information (Optional)
错误代码诊断信息（可选）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Diagnostic Information \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Diagnostic Information \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error message. The Error parameter value can be one of the following values:
Error Code参数指示错误消息的原因。错误参数值可以是以下值之一：
Invalid Version 0x01 Invalid Interface Identifier 0x02 Unsupported Message Class 0x03 Unsupported Message Type 0x04 Unsupported Traffic Handling Mode 0x05 Unexpected Message 0x06 Protocol Error 0x07 Unsupported Interface Identifier Type 0x08 Invalid Stream Identifier 0x09 Unassigned TEI 0x0a Unrecognized SAPI 0x0b Invalid TEI, SAPI combination 0x0c Refused - Management Blocking 0x0d ASP Identifier Required 0x0e Invalid ASP Identifier 0x0f
无效版本0x01无效接口标识符0x02不支持的消息类0x03不支持的消息类型0x04不支持的流量处理模式0x05意外消息0x06协议错误0x07不支持的接口标识符类型0x08无效流标识符0x09未分配的TEI 0x0a未识别的SAPI 0x0b无效TEI，SAPI组合0x0c被拒绝-管理阻止0x0d需要ASP标识符0x0e无效ASP标识符0x0f
The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version. The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area.
如果收到的消息版本无效或不受支持，则会发送“无效版本”错误。错误消息将在公共标头中包含受支持的版本。错误消息可以在诊断信息区域提供支持的版本。
The "Invalid Interface Identifier" error would be sent by an SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value. For this error, the Diagnostic Information MUST contain enough of the offending message to identify the invalid Interface Identifier. For example, in the case of QPTM and TEI Status management messages, the Common and IUA message headers of the offending message would be placed in the Diagnostic Information at a minimum.
如果ASP发送带有无效（未配置）接口标识符值的消息，则SG将发送“无效接口标识符”错误。对于此错误，诊断信息必须包含足够多的违规消息，以识别无效的接口标识符。例如，在QPTM和TEI状态管理消息的情况下，违规消息的公共和IUA消息头将至少放在诊断信息中。
The "Unsupported Traffic Handling Mode" error would be sent by an SG if an ASP sends an ASP Active with an unsupported Traffic Handling Mode. An example would be a case in which the SG did not support load-sharing.
如果ASP以不支持的流量处理模式发送ASP活动，则SG将发送“不支持的流量处理模式”错误。例如，SG不支持负载共享。
The "Unexpected Message" error would be sent by an ASP if it received a QPTM message from an SG while it was in the Inactive state (the ASP could optionally drop the message and not send an error). It would also be sent by an ASP if it received a defined and recognized message that the SG is not expected to send (e.g., if the MGC receives an IUA Establish Request message).
如果ASP在非活动状态下收到来自SG的QPTM消息，则ASP将发送“意外消息”错误（ASP可以选择删除消息而不发送错误）。如果ASP接收到一条定义和识别的消息，而SG不希望发送该消息（例如，如果MGC接收到一条IUA建立请求消息），则ASP也会发送该消息。
The "Protocol Error" error would be sent for any protocol anomaly (i.e., a bogus message).
对于任何协议异常（即虚假消息），都会发送“协议错误”错误。
The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream (e.g., a MGMT message was received on a stream other than "0").
如果在意外的SCTP流上接收到消息（例如，在“0”以外的流上接收到MGMT消息），则将发送“无效流标识符”错误。
The "Unsupported Interface Identifier Type" error would be sent by an SG if an ASP sends a text-formatted Interface Identifier and the SG only supports integer-formatted Interface Identifiers. When the ASP receives this error, it will need to resend its message with an integer-formatted Interface Identifier.
如果ASP发送文本格式的接口标识符，且SG仅支持整数格式的接口标识符，则SG将发送“不支持的接口标识符类型”错误。当ASP收到此错误时，需要使用整数格式的接口标识符重新发送其消息。
The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received.
如果收到具有意外或不支持的消息类型的消息，则会发送“不支持的消息类型”错误。
The "Unsupported Message Class" error would be sent if a message with an unexpected or unsupported Message Class is received.
如果收到包含意外或不支持的消息类的消息，则会发送“不支持的消息类”错误。
The "Unassigned TEI" error may be used when the SG receives an IUA message that includes a TEI that has not been assigned or recognized for use on the indicated ISDN D-channel.
当SG接收到IUA消息时，可能会使用“未分配TEI”错误，该IUA消息包括尚未分配或识别用于指示ISDN D信道的TEI。
The "Unrecognized SAPI" error would handle the case of using an SAPI that is not recognized by the SG. The "Invalid TEI, SAPI combination" error identifies errors where the TEI is assigned and the SAPI is recognized, but the combination is not valid for the interface (e.g., on a Basic Rate Interface (BRI), the MGC tries to send Q.921 Management messages via IUA when Layer Management at the SG SHOULD be performing this function).
“Unrecognized SAPI”错误将处理使用SG无法识别的SAPI的情况。“无效TEI，SAPI组合”错误识别分配TEI且识别SAPI的错误，但组合对接口无效（例如，在基本速率接口（BRI）上，当SG的层管理应执行此功能时，MGC尝试通过IUA发送Q.921管理消息）。
The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout).
当收到ASP Up或ASP Active消息并且由于管理原因（例如，管理锁定）拒绝请求时，将发送“拒绝-管理阻止”错误。
The "ASP Identifier Required" is sent by an SG in response to an ASP Up message that does not contain an ASP Identifier parameter when the SG requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier.
当SG需要ASP标识符参数时，“需要ASP标识符”由SG发送，以响应不包含ASP标识符参数的ASP Up消息。ASP应使用ASP标识符重新发送ASP Up消息。
The "Invalid ASP Identifier" is sent by a SG in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
“无效ASP标识符”由SG发送，以响应带有无效（即非唯一）ASP标识符的ASP Up消息。
Diagnostic Information: variable length
诊断信息：可变长度
When included, the optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. The Diagnostic information SHOULD contain the offending message.
包括时，可选诊断信息可以是与错误条件相关的任何信息，以帮助识别错误条件。诊断信息应包含有问题的信息。
Error messages MUST NOT be generated in response to other Error messages.
不得为响应其他错误消息而生成错误消息。
The Notify message used to provide an autonomous indication of IUA events to an IUA peer.
用于向IUA对等方提供IUA事件的自主指示的通知消息。
The Notify message will use only the common message header. The Notify message contains the following parameters:
通知消息将仅使用公共消息头。通知消息包含以下参数：
Status (Mandatory) ASP Identifier (Optional) Interface Identifiers (Optional) INFO String (Optional)
状态（必需）ASP标识符（可选）接口标识符（可选）信息字符串（可选）
The format for the Notify message with integer-formatted Interface Identifiers is as follows:
带有整数格式接口标识符的Notify消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the Notify message with text-formatted Interface Identifiers is as follows:
带有文本格式接口标识符的Notify消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Type: 16 bits (unsigned integer)
状态类型：16位（无符号整数）
The Status Type parameter identifies the type of the Notify message. The following are the valid Status Type values:
Status Type参数标识通知消息的类型。以下是有效的状态类型值：
1 Application Server State Change (AS-State_Change) 2 Other
1应用程序服务器状态更改（AS-State_更改）2其他
Status Information: 16 bits (unsigned integer)
状态信息：16位（无符号整数）
The Status Information parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS-State_Change, the following Status Information values are used:
Status Information参数根据状态类型的值包含通知的更详细信息。如果状态类型为AS-State_Change，则使用以下状态信息值：
1 reserved 2 Application Server Inactive (AS-INACTIVE) 3 Application Server Active (AS-ACTIVE) 4 Application Server Pending (AS-PENDING)
1保留2应用程序服务器不活动（AS-Inactive）3应用程序服务器活动（AS-Active）4应用程序服务器挂起（AS-Pending）
These notifications are sent from an SG to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server.
当特定应用服务器的状态发生变化时，这些通知从SG发送到ASP。该值反映应用程序服务器的新状态。
If the Status Type is Other, then the following Status Information values are defined:
如果状态类型为“其他”，则定义以下状态信息值：
Value Description 1 Insufficient ASP resources active in AS 2 Alternate ASP Active 3 ASP Failure
值说明1活动的ASP资源不足，如2备用ASP活动3 ASP失败
These notifications are not based on the SG reporting the state change of an ASP or AS. In the Insufficient ASP Resources case, the SG is indicating to an ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode). For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Over-ride mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SG is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
这些通知并非基于报告ASP或AS状态更改的SG。在ASP资源不足的情况下，SG向AS中的ASP-非活动ASP指示需要另一个ASP来处理AS的负载（负载共享模式）。对于备用ASP激活情况，当备用ASP在超车模式下转换为ASP激活状态时，会通知ASP。备用ASP的ASP标识符（如果可用）必须放在消息中。对于ASP故障情况，SG向AS中的ASP指示其中一个ASP已转换为ASP-DOWN。失败ASP的ASP标识符（如果可用）必须放在消息中。
The format and description of the optional ASP Identifier are the same as for the ASP Up message (see Section 3.3.2.1). The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
可选ASP标识符的格式和说明与ASP Up消息的格式和说明相同（见第3.3.2.1节）。可选接口标识符和信息字符串参数的格式和说明与ASP活动消息相同（见第3.3.2.5节）。
The TEI Status messages are exchanged between IUA layer peers to request, confirm, and indicate the status of a particular TEI.
TEI状态消息在IUA层对等方之间交换，以请求、确认和指示特定TEI的状态。
The TEI Status messages contain the common message header followed by IUA message header. The TEI Status Request message does not contain any additional parameters.
TEI状态消息包含公共消息头，后跟IUA消息头。TEI状态请求消息不包含任何其他参数。
In the integrated ISDN Layer 2/3 model (e.g., in traditional ISDN switches), it is assumed that the Layer Management for the Q.921 Layer and the Q.931 layer are co-located. When backhauling ISDN, this assumption is not necessarily valid. The TEI Status messages
在综合ISDN第2/3层模型中（例如，在传统ISDN交换机中），假定Q.921层和Q.931层的层管理位于同一位置。当回传ISDN时，这种假设不一定有效。TEI状态消息
allow the two Layer Management entities to communicate the status of the TEI. In addition, knowing that a TEI is in service allows the ASP to request the SG to establish the datalink to the terminal (via the IUA Establish message) for signaling if the ASP wants to be in control of data link establishment. Another use of the TEI Status procedure is where the Layer Management at the ASP can prepare for send/receive signaling to/from a given TEI and confirm/verify the establishment of a datalink to that TEI. For example, if a datalink is established for a TEI that the ASP did not know was assigned, the ASP can check to see whether it was assigned or whether there was an error in the signaling message. Also, knowing that a TEI is out of service, the ASP need not request the SG to establish a datalink to that TEI.
允许两层管理实体通信TEI的状态。此外，知道TEI正在服务中允许ASP请求SG建立到终端的数据链路（通过IUA建立消息），以便在ASP想要控制数据链路建立时发信号。TEI状态过程的另一个用途是，ASP处的层管理可以准备向给定TEI发送/接收信令，并确认/验证到该TEI的数据链路的建立。例如，如果为ASP不知道已分配的TEI建立了数据链路，则ASP可以检查该TEI是否已分配或信令消息中是否存在错误。此外，知道TEI已停止服务，ASP无需请求SG建立到该TEI的数据链路。
The TEI Status Indication and Confirm messages contain the following parameter:
TEI状态指示和确认消息包含以下参数：
STATUS
地位
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0010 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0010 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Status are shown in the following table.
下表显示了状态的有效值。
Define Value Description ASSIGNED 0x0 TEI is considered assigned by Q.921 UNASSIGNED 0x1 TEI is considered unassigned by Q.921
定义值说明分配0x0 TEI被认为是由Q.921分配的未分配0x1 TEI被认为是由Q.921分配的
The TEI Query message is sent by the ASP to query the TEI(s). This message consists of the common header and IUA header. The DLCI in the IUA header MUST be ignored by the SG. The SG will respond to this message with TEI Status Indication(s).
TEI查询消息由ASP发送以查询TEI。此消息由公共标头和IUA标头组成。SG必须忽略IUA标头中的DLCI。SG将用TEI状态指示响应此消息。
The IUA layer needs to respond to various primitives it receives from other layers as well as messages it receives from the peer IUA layer. This section describes various procedures involved in response to these events.
IUA层需要响应从其他层接收的各种原语以及从对等IUA层接收的消息。本节描述了应对这些事件所涉及的各种程序。
These procedures achieve the IUA layer's "Transport of Q.921/Q.931 boundary primitives" service.
这些程序实现了IUA层的“传输Q.921/Q.931边界原语”服务。
On receiving these primitives from the local layer, the IUA layer will send the corresponding QPTM message (Data, Unit Data, Establish, Release) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly. In addition, the message needs to be sent on the SCTP stream that corresponds to the D channel (Interface Identifier).
从本地层接收到这些原语后，IUA层将向其对等方发送相应的QPTM消息（数据、单元数据、建立、释放）。在执行此操作时，IUA层需要正确填充公共和特定头的各个字段。此外，需要在对应于D通道（接口标识符）的SCTP流上发送消息。
On receiving QPTM messages from a peer IUA layer, the IUA layer on an SG or MGC needs to invoke the corresponding layer primitives (DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) to the local Q.921 or Q.931 layer.
在从对等IUA层接收QPTM消息时，SG或MGC上的IUA层需要调用本地Q.921或Q.931层的相应层原语（DL-SETUP、DL-DATA、DL-UNIT DATA、DL-RELEASE）。
These procedures achieve the IUA layer's "Support for Communication between Layer Managements" service.
这些程序实现了IUA层的“支持层管理之间的通信”服务。
On receiving these primitives from the local Layer Management, the IUA layer will provide the appropriate response primitive across the internal local Layer Management interface.
从本地层管理接收这些原语后，IUA层将通过内部本地层管理接口提供适当的响应原语。
An M-SCTP ESTABLISH request from Layer Management will initiate the establishment of an SCTP association. An M-SCTP ESTABLISH confirm will be sent to Layer Management when the initiated association setup is complete. An M-SCTP ESTABLISH indication is sent to Layer Management upon successful completion of an incoming SCTP association setup from a peer IUA node.
来自层管理的M-SCTP建立请求将启动SCTP关联的建立。启动的关联设置完成后，M-SCTP建立确认将发送给层管理。在从对等IUA节点成功完成传入SCTP关联设置后，M-SCTP建立指示被发送到层管理。
An M-SCTP RELEASE request from Layer Management will initiate the teardown of an SCTP association. An M-SCTP RELEASE confirm will be sent by Layer Management when the association teardown is complete. An M-SCTP RELEASE indication is sent to Layer Management upon successful teardown of an SCTP association initiated by a peer IUA.
来自层管理的M-SCTP释放请求将启动SCTP关联的拆除。关联拆卸完成后，层管理将发送M-SCTP发布确认。在对等IUA启动的SCTP关联成功断开后，M-SCTP释放指示被发送到层管理。
M-SCTP STATUS request and indication support a Layer Management query of the local status of a particular SCTP association.
M-SCTP状态请求和指示支持对特定SCTP关联的本地状态进行层管理查询。
M-NOTIFY indication and M-ERROR indication indicate to Layer Management the notification or error information contained in a received IUA Notify or Error message, respectively. These indications can also be generated based on local IUA events.
M-NOTIFY指示和M-ERROR指示分别向层管理层指示接收到的IUA NOTIFY或ERROR消息中包含的通知或错误信息。也可以根据本地IUA事件生成这些指示。
M-ASP STATUS request/indication and M-AS-STATUS request/indication support a Layer Management query of the local status of a particular ASP or AS. No IUA peer protocol is invoked.
M-ASP状态请求/指示和M-AS状态请求/指示支持对特定ASP或AS的本地状态进行层管理查询。未调用IUA对等协议。
M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request, and M-ASP-ACTIVE request allow Layer Management at an ASP to initiate state changes. These requests result in outgoing IUA ASP UP, ASP DOWN, ASP INACTIVE, and ASP ACTIVE messages.
M-ASP-UP请求、M-ASP-DOWN请求、M-ASP-INACTIVE请求和M-ASP-ACTIVE请求允许ASP上的层管理启动状态更改。这些请求导致传出IUA ASP UP、ASP DOWN、ASP INACTIVE和ASP ACTIVE消息。
M-ASP-UP confirmation, M-ASP-DOWN confirmation, M-ASP-INACTIVE confirmation, and M-ASP-ACTIVE confirmation indicate to Layer Management that the previous request has been confirmed.
M-ASP-UP确认、M-ASP-DOWN确认、M-ASP-INACTIVE确认和M-ASP-ACTIVE确认向层管理指示上一个请求已被确认。
Upon receipt of an M-TEI Status primitive from Layer Management, the IUA will send the corresponding MGMT message (TEI Status) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly.
在从层管理接收到M-TEI状态原语后，IUA将向其对等方发送相应的管理消息（TEI状态）。在执行此操作时，IUA层需要正确填充公共和特定头的各个字段。
All MGMT messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
所有管理消息都以顺序流发送，以确保有序。应使用SCTP流“0”。
Upon receipt of IUA Management messages, the IUA layer MUST invoke the corresponding Layer Management primitive indications (e.g., M-AS Status ind., M-ASP Status ind., M-ERROR ind., M-TEI STATUS) to the local layer management.
收到IUA管理消息后，IUA层必须向本地层管理调用相应的层管理原语指示（例如，M-AS状态指示、M-ASP状态指示、M-ERROR指示、M-TEI状态）。
M-NOTIFY indication and M-ERROR indication indicate to Layer Management the notification or error information contained in a received IUA Notify or Error message. These indications can also be generated based on local IUA events.
M-NOTIFY指示和M-ERROR指示向层管理层指示接收到的IUA NOTIFY或ERROR消息中包含的通知或错误信息。也可以根据本地IUA事件生成这些指示。
All MGMT messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
所有管理消息都以顺序流发送，以确保有序。应使用SCTP流“0”。
These procedures achieve the IUA layer's "Support for management of active associations between SG and MGC" service.
这些程序实现了IUA层的“支持管理SG和MGC之间的活动关联”服务。
The IUA layer on the SG needs to maintain the states of each ASP as well as the state of the AS.
SG上的IUA层需要维护每个ASP的状态以及as的状态。
The state of the each ASP, in each AS that it is configured, is maintained in the IUA layer on the SG. The state of an ASP changes due to the following type of events:
每个ASP在其配置的每个AS中的状态都保存在SG上的IUA层中。ASP的状态因以下类型的事件而更改：
* Reception of messages from peer IUA layer at that ASP * Reception of some messages from the peer IUA layer at other ASPs in the AS * Reception of indications from SCTP layer * Local Management intervention
* 接收来自该ASP的对等IUA层的消息*接收来自AS中其他ASP的对等IUA层的一些消息*接收来自SCTP层的指示*本地管理干预
The ASP state transition diagram is shown in Figure 6. The possible states of an ASP are the following:
ASP状态转换图如图6所示。ASP的可能状态如下所示：
ASP-DOWN: Application Server Process is unavailable and/or the related SCTP association is down. Initially, all ASPs will be in this state. An ASP in this state SHOULD NOT be sent any IUA messages.
ASP-DOWN:应用程序服务器进程不可用和/或相关SCTP关联已关闭。最初，所有ASP都将处于此状态。处于此状态的ASP不应发送任何IUA消息。
ASP-INACTIVE: The remote IUA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped. In this state, the ASP can be sent any non-QPTM IUA messages (except for TEI Status messages).
ASP-INACTIVE：ASP上的远程IUA对等机可用（并且相关的SCTP关联已启动），但应用程序通信已停止。在此状态下，ASP可以发送任何非QPTM IUA消息（TEI状态消息除外）。
ASP-ACTIVE: The remote IUA peer at the ASP is available and application traffic is active.
ASP-ACTIVE：ASP上的远程IUA对等方可用，且应用程序流量处于活动状态。
+--------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +--------------+
| Takeover | ^ |
| | ASP | | ASP Inactive /
| | Active | | ASP Up
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI /
SCTP RI | | v SCTP RI
| +--------------+
+--------------------->| |
| ASP-DOWN |
+--------------+
+--------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +--------------+
| Takeover | ^ |
| | ASP | | ASP Inactive /
| | Active | | ASP Up
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI /
SCTP RI | | v SCTP RI
| +--------------+
+--------------------->| |
| ASP-DOWN |
+--------------+
Figure 6. ASP State Transition Diagram
图6。ASP状态转换图
SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP.
SCTP CDI：本地SCTP层与SG上上层协议（IUA）的通信下行指示。当本地SCTP检测到与ASP对等SCTP层的连接丢失时，将发送此指示。SCTP CDI被理解为来自SCTP的停机完成通知和通信丢失通知。
SCTP RI: The local SCTP layer's Restart indication to the upper layer protocol (IUA) on an SG. The local SCTP will send this indication when it detects a restart from the ASP's peer SCTP layer.
SCTP RI：本地SCTP层对SG上上层协议（IUA）的重启指示。当本地SCTP检测到来自ASP对等SCTP层的重启时，将发送此指示。
The state of the AS is maintained in the IUA layer on the SG.
AS的状态保持在SG上的IUA层中。
The state of an AS changes due to events. These events include the following:
AS的状态因事件而更改。这些活动包括：
* ASP state transitions * Recovery timer triggers
* ASP状态转换*恢复计时器触发器
The possible states of an AS are the following:
AS的可能状态如下所示：
AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially, the AS will be in this state.
AS-DOWN：应用程序服务器不可用。此状态表示此AS的所有相关ASP都处于ASP-DOWN状态。最初，AS将处于这种状态。
AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP-INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired.
AS-INACTIVE：应用程序服务器可用，但没有活动的应用程序流量（即，一个或多个相关的ASP处于ASP-INACTIVE状态，但没有处于ASP-active状态）。恢复计时器T（r）未运行或已过期。
AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state.
AS-ACTIVE：应用程序服务器可用，且应用程序流量处于活动状态。此状态表示至少有一个ASP处于ASP-ACTIVE状态。
AS-PENDING: An active ASP has transitioned from active to inactive or down and it was the last remaining active ASP in the AS. A recovery timer T(r) will be started and all incoming SCN messages will be queued by the SG. If an ASP becomes active before T(r) expires, the AS will move to AS-ACTIVE state and all the queued messages will be sent to the active ASP.
挂起状态：活动ASP已从活动状态转换为非活动状态或关闭状态，并且它是AS中最后一个剩余的活动ASP。恢复计时器T（r）将启动，所有传入的SCN消息将由SG排队。如果ASP在T（r）到期之前变为活动状态，AS将移动到AS-active状态，所有排队的消息将发送到活动ASP。
If T(r) expires before an ASP becomes active, the SG stops queuing messages and discards all previously queued messages. The AS will move to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state.
如果在ASP激活之前T（r）过期，则SG将停止对消息进行排队，并丢弃所有先前排队的消息。如果至少有一个ASP处于ASP-INACTIVE状态，AS将移动到AS-INACTIVE状态，否则它将移动到AS-DOWN状态。
+----------+ one ASP trans to ASP-ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state
+----------+ one ASP trans to ASP-ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state
Tr = Recovery Timer
Tr = Recovery Timer
Figure 7: AS State Transition Diagram
图7:AS状态转换图
Before the establishment of an SCTP association, the ASP state at both the SG and ASP is assumed to be in the state ASP-DOWN.
在建立SCTP关联之前，假定SG和ASP的ASP状态都处于ASP-DOWN状态。
As the ASP is responsible for initiating the setup of an SCTP association to an SG, the IUA layer at an ASP receives an M-SCTP ESTABLISH request primitive from the Layer Management, the IUA layer will try to establish an SCTP association with the remote IUA peer at an SG. Upon reception of an eventual SCTP-Communication Up confirm primitive from the SCTP, the IUA layer will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management.
由于ASP负责启动与SG的SCTP关联的设置，ASP处的IUA层从层管理接收M-SCTP建立请求原语，IUA层将尝试与SG处的远程IUA对等方建立SCTP关联。在接收到来自SCTP的最终SCTP通信上行确认原语后，IUA层将调用原语M-SCTP建立确认以进行管理。
At the SG, the IUA layer will receive an SCTP Communication Up indication primitive from the SCTP. The IUA layer will then invoke the primitive M-SCTP ESTABLISH indication to the Layer Management.
在SG处，IUA层将从SCTP接收SCTP通信上行指示原语。然后，IUA层将向管理层调用基本M-SCTP建立指示。
Once the SCTP association is established and assuming that the local IUA-User is ready, the local ASP IUA Application Server Process Maintenance (ASPM) function will initiate the ASPM procedures, using the ASP Up/-Down/-Active/-Inactive messages to convey the ASP state to the SG (see Section 4.3.3).
一旦建立SCTP关联并假设本地IUA用户已准备就绪，本地ASP IUA应用程序服务器进程维护（ASPM）功能将启动ASPM过程，使用ASP Up/-Down/-Active/-Inactive消息将ASP状态传递给SG（见第4.3.3节）。
The Layer Management and the IUA layer on SG can communicate the status of the application server using the M-AS_STATUS primitives. The Layer Management and the IUA layer on both the SG and ASP can communicate the status of an SCTP association using the M-SCTP_STATUS primitives.
SG上的层管理和IUA层可以使用M-AS_状态原语通信应用服务器的状态。SG和ASP上的层管理和IUA层都可以使用M-SCTP_状态原语传达SCTP关联的状态。
If the Layer Management on SG or ASP wants to bring down an SCTP association for management reasons, it would send M-SCTP RELEASE request primitive to the local IUA layer. The IUA layer would release the SCTP association and upon receiving the SCTP-COMMUNICATION_DOWN indication from the underlying SCTP layer, it would inform the local Layer Management using M-SCTP_RELEASE confirm primitive.
如果出于管理原因，SG或ASP上的层管理希望关闭SCTP关联，它将向本地IUA层发送M-SCTP RELEASE request原语。IUA层将释放SCTP关联，并在从底层SCTP层接收到SCTP-COMMUNICATION_DOWN指示后，使用M-SCTP_release confirm原语通知本地层管理层。
If the IUA layer receives an SCTP-COMMUNICATION_DOWN indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP RELEASE indication primitive. The state of the ASP will be moved to "Down" at both the SG and ASP.
如果IUA层从底层SCTP层接收到SCTP-COMMUNICATION_DOWN指示，它将通过调用M-SCTP RELEASE indication原语通知层管理。在SG和ASP处，ASP的状态都将移至“向下”。
At an ASP, the Layer Management MAY try to reestablish the SCTP association using M-SCTP_ESTABLISH request primitive.
在ASP中，层管理可以尝试使用M-SCTP_建立请求原语重新建立SCTP关联。
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its IUA peer to be in the ASP-DOWN state. The ASP, if it is to recover, must begin any recovery with the ASP Up procedure.
在ASP处出现SCTP重启指示的情况下，其IUA对等方现在认为ASP处于ASP-DOWN状态。如果要恢复，ASP必须使用ASP Up过程开始任何恢复。
All ASPM messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
所有ASPM消息都以顺序流发送，以确保有序。应使用SCTP流“0”。
After an ASP has successfully established an SCTP association to an SG, the SG waits for the ASP to send an ASP Up message, indicating that the ASP IUA peer is available. The ASP is always the initiator of the ASP Up message. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an IUA management function.
ASP成功建立与SG的SCTP关联后，SG等待ASP发送ASP Up消息，指示ASP IUA对等机可用。ASP始终是ASP Up消息的发起方。此操作可以由层管理的M-ASP_UP request原语在ASP处启动，也可以由IUA管理功能自动启动。
When an ASP Up message is received at an SG and internally the remote ASP is in the ASP-DOWN state and not considered locked out for local management reasons, the SG marks the remote ASP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the SG is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SG updates the ASP state to ASP-INACTIVE in each AS that it is a member.
当SG收到ASP Up消息且远程ASP在内部处于ASP-DOWN状态且由于本地管理原因未被视为锁定时，SG将远程ASP标记为ASP-INACTIVE状态，并使用M-ASP_Up指示原语通知层管理。如果SG通过当前配置数据知道ASP配置在哪些应用服务器中运行，则SG会将每个应用服务器中的ASP状态更新为ASP-INACTIVE，因为它是一个成员。
Alternatively, the SG may move the ASP into a pool of Inactive ASPs available for future configuration within Application Server(s), determined in a subsequent ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SG should save the ASP Identifier for that ASP. The SG MUST send an ASP Up Ack message in response to a received ASP Up message even if the ASP is already marked as ASP-INACTIVE at the SG.
或者，SG可以将ASP移动到非活动ASP池中，该非活动ASP池可用于在后续ASP活动过程中确定的应用服务器内的未来配置。如果ASP Up消息包含ASP标识符，则SG应保存该ASP的ASP标识符。SG必须发送ASP Up Ack消息以响应接收到的ASP Up消息，即使该ASP已在SG处标记为ASP-INACTIVE。
If for any local reason (e.g., management lockout) the SG cannot respond with an ASP Up Ack message, the SG responds to an ASP Up message with an Error message with reason "Refused - Management Blocking".
如果出于任何本地原因（例如，管理锁定），SG无法响应ASP Up Ack消息，则SG会响应ASP Up消息，并返回错误消息，原因为“拒绝-管理阻塞”。
At the ASP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive.
在ASP上，接收到的ASP Up Ack消息未得到确认。层管理由M-ASP\U UP确认原语通知。
When the ASP sends an ASP Up message, it starts timer T(ack). If the ASP does not receive a response to an ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication.
当ASP发送ASP Up消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP Up消息的响应，则ASP可重新启动T（确认）并重新发送ASP Up消息，直到收到ASP Up ack消息。T（ack）是可设置的，默认值为2秒。或者，ASP Up消息的重新传输可以置于层管理的控制之下。在这种方法中，T（ack）的到期将导致带有否定指示的M-ASP_UP confirm原语。
The ASP must wait for the ASP Up Ack message before sending any other IUA messages (e.g., ASP Active). If the SG receives any other IUA messages before an ASP Up message is received (other than ASP Down; see Section 4.3.3.2), the SG MAY discard them.
ASP必须等待ASP Up Ack消息，然后才能发送任何其他IUA消息（例如，ASP Active）。如果SG在收到ASP Up消息（ASP Down除外；请参阅第4.3.3.2节）之前收到任何其他IUA消息，则SG可以丢弃这些消息。
If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message"), and the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers.
如果收到ASP Up消息且远程ASP在内部处于ASP-ACTIVE状态，将返回ASP Up Ack消息以及错误消息（“意外消息”），并且所有相关应用程序服务器中的远程ASP状态将更改为ASP-INACTIVE。
If an ASP Up message is received and internally the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and no further action is taken.
如果收到ASP Up消息，并且远程ASP在内部已处于ASP-INACTIVE状态，则返回ASP Up Ack消息，并且不采取进一步的操作。
The ASP will send an ASP Down message to an SG when the ASP wishes to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA QPTM or ASPTM messages. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an IUA management function.
当ASP希望从其作为成员的所有应用程序服务器中的ASP列表中删除并且不再接收任何IUA QPTM或ASPTM消息时，ASP将向SG发送ASP Down消息。此操作可以由层管理的M-ASP_DOWN request原语在ASP处启动，也可以由IUA管理功能自动启动。
Whether the ASP is permanently removed from an AS is a function of configuration management.
是否从AS中永久删除ASP是配置管理的一项功能。
The SG marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP.
SG将ASP标记为ASP-DOWN，用M-ASP\U DOWN指示原语通知图层管理，并向ASP返回ASP-DOWN确认消息。
The SG MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at the SG.
SG必须发送ASP Down Ack消息，以响应从ASP接收到的ASP Down消息，即使ASP已在SG处标记为ASP-Down。
At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself as in the ASP-DOWN state. If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
在ASP上，接收到的ASP Down Ack消息未得到确认。通过M-ASP_DOWN confirm原语通知层管理。如果ASP在没有发送ASP向下消息的情况下接收到ASP Unk ACK，那么ASP现在应该将其视为ASP-DOWN状态。如果ASP以前处于ASP-ACTIVE或ASP-INACTIVE状态，则ASP应启动过程以将自身恢复到以前的状态。
When the ASP sends an ASP Down message, it starts timer T(ack). If the ASP does not receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication.
当ASP发送ASP Down消息时，它启动定时器T（ack）。如果ASP在T（ack）内未收到对ASP Down消息的响应，则ASP可重新启动T（ack）并重新发送ASP Down消息，直到收到ASP Down ack消息。T（ack）是可设置的，默认值为2秒。或者，ASP Down消息的重传可以置于层管理的控制之下。在这种方法中，T（ack）的到期会导致M-ASP_DOWN confirm原语带有否定指示。
If a ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies Layer Management.
如果接收到版本不受支持的ASP Up消息，接收端将以错误消息响应，指示接收节点支持的版本，并通知层管理。
This is useful when protocol version upgrades are being performed in a network. A node upgraded to a newer version SHOULD support the older versions used on other nodes it is communicating with. Because ASPs initiate the ASP Up procedure it is assumed that the Error message would normally come from the SG.
这在网络中执行协议版本升级时非常有用。升级到较新版本的节点应支持与之通信的其他节点上使用的较旧版本。由于ASP启动ASP Up过程，因此假定错误消息通常来自SG。
Any time after the ASP has received an ASP Up Ack from the SG, the ASP sends an ASP Active message to the SG indicating that the ASP is ready to start processing traffic. This action MAY be initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer Management or MAY be initiated automatically by an IUA management function. In the case where an ASP is configured/registered to process the traffic for more than one Application Server across an SCTP association, the ASPAC contains one or more Interface Identifiers to indicate for which Application Servers the ASPAC applies.
在ASP从SG收到ASP Up Ack后的任何时候，ASP都会向SG发送一条ASP活动消息，指示ASP已准备好开始处理流量。此操作可以由层管理的M-ASP_活动请求原语在ASP处启动，也可以由IUA管理功能自动启动。在配置/注册ASP以处理SCTP关联中多个应用服务器的流量的情况下，ASPAC包含一个或多个接口标识符，以指示ASPAC应用于哪些应用服务器。
If the Application Server can be successfully activated, the SG responds to the ASP with an ASPAC Ack message acknowledging that the ASPAC message was received and starts sending traffic for the Application Server to that ASP.
如果可以成功激活应用程序服务器，则SG使用ASPAC Ack消息响应ASP，确认已收到ASPAC消息，并开始向该ASP发送应用程序服务器的通信量。
In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded.
在接收到“出乎意料的”ASP活动消息的情况下（即，ASP没有向SG注册，或者SG没有ASP的静态配置数据），该消息可以被静默地丢弃。
The SG MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SG.
如果SG上的ASP已标记为ASP-Active状态，则SG必须发送ASP-Active Ack消息以响应从ASP接收到的ASP-Active消息。
At the ASP, the ASP Active Ack message received is not acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. It is possible for the ASP to receive Data message(s) before the ASP Active Ack message as the ASP Active Ack and Data messages from an SG may be sent on different SCTP streams. Message loss is possible as the ASP does not consider itself in the ASP-ACTIVE state until reception of the ASP Active Ack message.
在ASP上，接收到的ASP活动确认消息未得到确认。层管理由M-ASP_活动确认原语通知。ASP可以在ASP活动Ack消息之前接收数据消息，因为ASP活动Ack和来自SG的数据消息可以在不同的SCTP流上发送。消息丢失是可能的，因为ASP在接收ASP活动ACK消息之前不考虑自身处于ASP-Active状态。
When the ASP sends an ASP Active message, it starts timer T(ack). If the ASP does not receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying a negative indication.
当ASP发送ASP活动消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP活动消息的响应，则ASP可重新启动T（确认）并重新发送ASP活动消息，直到收到ASP活动确认消息。T（ack）是可设置的，默认值为2秒。或者，ASP活动消息的重传可以置于层管理的控制之下。在这种方法中，T（ack）的到期会导致带有否定指示的M-ASP_活动确认原语。
The ASP MUST wait for the ASP Active Ack message from the SG before sending any Data messages or it will risk message loss. If the SG receives QPTM messages before an ASP Active is received, the SG SHOULD discard these messages.
在发送任何数据消息之前，ASP必须等待来自SG的ASP Active Ack消息，否则将有消息丢失的风险。如果SG在收到ASP Active之前收到QPTM消息，则SG应丢弃这些消息。
There are two modes of Application Server traffic handling in the SG IUA: Over-ride and Load-sharing. The Type parameter in the ASPAC message indicates the mode used in a particular Application Server. If the SG determines that the mode indicates in an ASPAC is incompatible with the traffic handling mode currently used in the AS, the SG responds with an Error message indicating Unsupported Traffic Handling Mode.
SG IUA中有两种应用程序服务器流量处理模式：超限和负载共享。ASPAC消息中的Type参数表示特定应用程序服务器中使用的模式。如果SG确定ASPAC中指示的模式与AS中当前使用的流量处理模式不兼容，则SG会发出错误消息，指示不支持的流量处理模式。
In the case of an Over-ride mode AS, reception of an ASPAC message at an SG causes the redirection of all traffic for the AS to the ASP that sent the ASPAC. The SG responds to the ASPAC with an ASP Active Ack message to the ASP. Any previously active ASP in the AS is now considered Inactive and will no longer receive traffic from the SG within the AS. The SG sends a Notify (Alternate ASP Active) to the previously active ASP in the AS, after stopping all traffic to that ASP.
在超车模式AS的情况下，SG接收到ASPAC消息会导致AS的所有流量重定向到发送ASPAC的ASP。SG向ASP发送ASP活动确认消息，以响应ASPAC。AS中任何以前处于活动状态的ASP现在都被视为非活动状态，不再接收来自AS内SG的流量。在停止到该ASP的所有通信后，SG向AS中先前活动的ASP发送通知（备用ASP活动）。
In the case of a load-share mode AS, reception of an ASPAC message at an SG causes the direction of traffic to the ASP sending the ASPAC, in addition to all the other ASPs that are currently active in the AS. The algorithm at the SG for load-sharing traffic within an AS to all the active ASPs is implementation dependent. The algorithm could, for example, be round-robin or based on information in the Data message, such as Interface Identifier, depending on the requirements of the application and the call state handling assumptions of the collection of ASPs in the AS. The SG responds to the ASPAC with an ASP Active Ack message to the ASP.
在负载共享模式AS的情况下，除了AS中当前处于活动状态的所有其他ASP外，在SG处接收ASPAC消息会导致发送ASPAC的ASP的流量方向。SG中用于AS内负载共享流量的算法与所有活动ASP的算法取决于实现。例如，该算法可以是循环的，或者基于数据消息中的信息，例如接口标识符，这取决于应用程序的需求和as中的ASPs集合的调用状态处理假设。SG向ASP发送ASP活动确认消息，以响应ASPAC。
When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive message to the SG. This action MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an IUA management function. In the case where an ASP is configured/ registered to process the traffic for more than one Application Server across an SCTP association, the ASPIA contains one or more Interface Identifiers to indicate for which Application Servers the ASP Inactive message applies.
当ASP希望退出AS内的接收流量时，ASP会向SG发送一条ASP非活动消息。此操作可以由层管理的M-ASP_非活动请求原语在ASP处启动，也可以由IUA管理功能自动启动。在配置/注册ASP以处理SCTP关联中多个应用服务器的流量的情况下，ASPIA包含一个或多个接口标识符，以指示ASP非活动消息适用于哪些应用服务器。
There are two modes of Application Server traffic handling in the SG IUA when withdrawing an ASP from service: Over-ride and Load-sharing. In the case of an Over-ride mode AS, where normally another ASP has already taken over the traffic within the AS with an Over-ride ASPAC message, the ASP that sends the ASPIA message is already considered by the SG to be ASP-INACTIVE. An ASPIA Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
从服务中退出ASP时，SG IUA中有两种应用程序服务器流量处理模式：超限和负载共享。在超车模式AS的情况下，通常另一个ASP已通过超车ASPAC消息接管AS内的交通，SG已将发送ASPIA消息的ASP视为ASP-INACTIVE。在确保所有到ASP的通信停止后，将向ASP发送ASPIA Ack消息。
In the case of a Load-share mode AS, the SG moves the ASP to the ASP-INACTIVE state and the AS traffic is re-allocated across the remaining ASP-ACTIVE ASPs per the load-sharing algorithm currently used within the AS. An ASPIA Ack message is sent to the ASP after all traffic is halted to the ASP. A Notify (Insufficient ASPs) message MAY be sent to all inactive ASPs, if required.
在负载共享模式AS的情况下，SG将ASP移动到ASP-INACTIVE状态，并根据AS中当前使用的负载共享算法在其余ASP-ACTIVE ASP之间重新分配AS流量。ASP的所有通信停止后，将向ASP发送ASPIA Ack消息。如果需要，可能会向所有非活动的ASP发送通知（ASP不足）消息。
When the ASP sends an ASP Inactive message it starts timer T(ack). If the ASP does not receive a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in a M-ASP_Inactive confirm primitive carrying a negative indication.
当ASP发送ASP非活动消息时，它启动计时器T（确认）。如果ASP在T（确认）内未收到对ASP非活动消息的响应，则ASP可重新启动T（确认）并重新发送ASP非活动消息，直到收到ASP非活动确认消息。T（ack）是可设置的，默认值为2秒。或者，ASP非活动消息的重新传输可以置于层管理的控制之下。在这种方法中，T（ack）的到期导致M-ASP_非活动确认原语携带负指示。
If no other ASPs in the Application Server are in the state ASP-ACTIVE, the SG MUST send a Notify ("AS-Pending") message to all of the ASPs in the AS that are in the state ASP-INACTIVE. The SG SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. If the SG receives an ASP Active message from an ASP in the AS before expiry of T(r), the buffered traffic is directed to that ASP and the timer is cancelled. If T(r) expires, the AS is moved to the AS-INACTIVE state.
如果应用服务器中没有其他ASP处于ASP-ACTIVE状态，则SG必须向AS中处于ASP-ACTIVE状态的所有ASP发送通知（“AS Pending”）消息。SG应开始将传入消息缓冲T（r）秒，之后可能会丢弃消息。T（r）可由网络运营商配置。如果SG在T（r）到期之前从AS中的ASP接收到ASP活动消息，则缓冲的通信量被定向到该ASP，并且定时器被取消。如果T（r）过期，AS将移至AS-INACTIVE状态。
At the ASP, the ASP Inactive Ack message received is not acknowledged. Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider itself as in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
在ASP上，接收到的ASP非活动确认消息未得到确认。使用M-ASP\U非活动确认原语通知图层管理。如果ASP接收到ASP非活动ACK而不发送ASP非激活消息，那么ASP现在应该认为自己处于ASP非活动状态。如果ASP以前处于ASP-ACTIVE状态，则ASP应启动过程以将自身恢复到以前的状态。
A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).
必须向AS中的所有ASP发送反映AS状态更改的Notify消息（ASP-DOWN状态的ASP除外），其中包含相应的状态信息和失败ASP的任何ASP标识符。在ASP中，层管理通过M-NOTIFY指示原语通知。无论AS状态更改是由于ASP故障还是由于接收到ASP状态管理（ASPSM）/ASP流量管理（ASPTM）消息而导致，都必须发送Notify消息。在第二种情况下，通知消息必须在任何相关确认消息（例如，ASP Up Ack、ASP Down Ack、ASP Active Ack或ASP Inactive Ack）之后发送。
In the case where a Notify ("AS-Pending") message is sent by an SG that now has no ASPs active to service the traffic, or a NTFY ("Insufficient ASPs") is sent in the Load-share mode, the Notify does not explicitly compel the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) action is taken.
如果一个SG发送了一条Notify（“AS Pending”）消息，而该SG现在没有活动的ASP来为流量提供服务，或者在负载共享模式下发送了一条NTFY（“ASPs不足”），则Notify不会显式强制接收该消息的ASP变为活动状态。ASP仍然控制采取什么（以及何时）行动。
The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than the SCTP).
可选的心跳程序可用于在传输层上操作，这些传输层没有自己的心跳机制来检测传输关联的丢失（即，除了SCTP）。
Either IUA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the IUA peer MUST respond with a Heartbeat Ack message.
任何一个IUA对等方都可以选择性地根据可设置的定时器T（节拍）周期性地发送心跳消息。收到心跳消息后，IUA对等方必须使用心跳确认消息进行响应。
If no Heartbeat Ack message (or any other IUA message) is received from the IUA peer within 2*T(beat), the remote IUA peer is considered unavailable. Transmission of Heartbeat messages is stopped and the signaling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected IUA peer.
如果在2*T（beat）内未从IUA对等方接收到心跳确认消息（或任何其他IUA消息），则认为远程IUA对等方不可用。心跳消息的传输停止，如果信令进程被配置为断开连接的IUA对等方的客户端，则应尝试重新建立通信。
The BEAT message MAY optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Beat Ack message. The ASP upon examining the contents of the returned BEAT Ack message MAY choose to consider the remote ASP as unavailable. The contents/format of the Heartbeat Data parameter is implementation dependent and only of local interest to the original sender. The contents MAY be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays).
节拍消息可以选择性地包含不透明的心跳数据参数，该参数必须在相关节拍确认消息中原封不动地回显。在检查返回的ACK ACK消息的内容时，ASP可以选择认为远程ASP不可用。Heartbeat数据参数的内容/格式取决于实现，仅与原始发送方的本地兴趣相关。例如，内容可用于支持心跳序列算法（检测丢失的心跳）和/或时间戳机制（评估延迟）。
Note: Heartbeat-related events are not shown in Figure 6, "ASP State Transition Diagram".
注意：图6“ASP状态转换图”中未显示心跳相关事件。
This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP, where only one ASP is configured within an AS (no backup). It is assumed that the SCTP association is already setup.
此场景显示了用于在SG和ASP之间建立流量的示例IUA消息流，其中AS中仅配置了一个ASP（无备份）。假设SCTP关联已设置。
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |
This scenario shows the example IUA message flows for the establishment of traffic between an SG and two ASPs in the same Application Server, where ASP1 is configured to be Active and ASP2 a standby in the event of communication failure or the withdrawal from service of ASP1. ASP2 MAY act as a hot, warm, or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP Active messages are Over-ride or Load-share mode although typically this example would use an Over-ride mode.
此场景显示了用于在同一应用服务器中的一个SG和两个ASP之间建立流量的示例IUA消息流，其中，在发生通信故障或ASP1退出服务时，ASP1配置为活动，ASP2配置为备用。根据ASP1和ASP2在故障/退出事件下共享呼叫状态或可通信呼叫状态的程度，ASP2可作为热备、热备或冷备。无论ASP活动消息是Over ride模式还是Load share模式，示例消息流都是相同的，尽管此示例通常使用Over ride模式。
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
5.1.3. Two ASPs in an Application Server (1+1 sparing, load-sharing case)
5.1.3. 应用服务器中的两个ASP（1+1备用，负载共享情况）
This scenario shows a similar case to Section 5.1.2 but where the two ASPs are brought to active and load-share the traffic load. In this case, one ASP is sufficient to handle the total traffic load.
该场景显示了与第5.1.2节类似的情况，但两个ASP被激活，负载共享流量负载。在这种情况下，一个ASP足以处理总流量负载。
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
5.1.4. Three ASPs in an Application Server (n+k sparing, load-sharing case)
5.1.4. 应用服务器中的三个ASP（n+k备用，负载共享情况）
This scenario shows the example IUA message flows for the establishment of traffic between an SG and three ASPs in the same Application Server, where two of the ASPs are brought to active and share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2+1 sparing).
此场景显示了用于在同一应用程序服务器中的一个SG和三个ASP之间建立流量的示例IUA消息流，其中两个ASP处于活动状态并共享负载。在这种情况下，至少需要两个ASP来处理总流量负载（2+1备用）。
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
| | | |
|<--------------------------ASP Up-------| |
|-----------------------ASP Up Ack------>| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
| | | |
|<--------------------------ASP Up-------| |
|-----------------------ASP Up Ack------>| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|
This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP in which some of the Interface Identifiers have been misconfigured on the ASP side. The SG in this case has Interface Identifiers 1-5 configured for ASP1.
此场景显示了用于在SG和ASP之间建立流量的示例IUA消息流，其中一些接口标识符在ASP端被错误配置。在这种情况下，SG具有为ASP1配置的接口标识符1-5。
SG ASP1
| |
| |
|<----ASP Active (IIDs 1-10)-----|
|---ASP Active Ack (IIDs 1-5)--->|
|-------Error (IIDs 6)---------->|
|-------Error (IIDs 7)---------->|
|-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->|
| |
SG ASP1
| |
| |
|<----ASP Active (IIDs 1-10)-----|
|---ASP Active Ack (IIDs 1-5)--->|
|-------Error (IIDs 6)---------->|
|-------Error (IIDs 7)---------->|
|-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->|
| |
The following example shows a case in which an ASP withdraws from service:
以下示例显示ASP从服务中退出的情况：
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
| | |
|----NTFY(AS-Pending)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| | |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
| | |
|----NTFY(AS-Pending)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| | |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|
In this case, the SG notifies ASP2 that the AS has moved to the Down state. The SG could have also (optionally) sent a Notify message when the AS moved to the Pending state.
在这种情况下，SG通知ASP2 AS已移至停机状态。当AS移动到挂起状态时，SG还可以（可选地）发送通知消息。
Note: If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange would not occur.
注意：如果SG检测到IUA对等丢失（IUA心跳丢失或检测到SCTP故障），则初始SG-ASP1 ASP非活动消息交换将不会发生。
The following example shows a case in which ASP2 wishes to override ASP1 and take over the traffic:
以下示例显示了ASP2希望覆盖ASP1并接管流量的情况：
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |
In this case, the SG notifies ASP1 that an alternative ASP has overridden it.
在这种情况下，SG通知ASP1替代ASP已覆盖它。
Following on from the example in Section 5.1.4, and ASP1 withdraws from service:
根据第5.1.4节中的示例，ASP1退出服务：
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
In this case, the SG has knowledge of the minimum ASP resources required (implementation dependent), for example, if the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1.
在这种情况下，SG知道所需的最小ASP资源（取决于实现），例如，如果SG知道负载共享AS的n+k=2+1，并且n当前等于1。
Note: If the SG detects loss of the ASP1 IUA peer (IUA heartbeat loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive message exchange would not occur.
注意：如果SG检测到ASP1 IUA对等丢失（IUA心跳丢失或检测到SCTP故障），则不会发生第一次SG-ASP1 ASP非活动消息交换。
When the IUA layer on the ASP has a QPTM message to send to the SG, it will do the following:
当ASP上的IUA层向SG发送QPTM消息时，它将执行以下操作：
- Determine the correct SG
- 确定正确的SG
- Find the SCTP association to the chosen SG
- 查找与所选SG的SCTP关联
- Determine the correct stream in the SCTP association based on the D channel
- 根据D通道确定SCTP关联中的正确流
- Fill in the QPTM message, fill in IUA Message Header, fill in Common Header
- 填写QPTM消息，填写IUA消息头，填写公共消息头
- Send the QPTM message to the remote IUA peer in the SG, over the SCTP association
- 通过SCTP关联向SG中的远程IUA对等方发送QPTM消息
When the IUA layer on the SG has a QPTM message to send to the ASP, it will do the following:
当SG上的IUA层向ASP发送QPTM消息时，它将执行以下操作：
- Determine the AS for the Interface Identifier
- 确定接口标识符的AS
- Determine the Active ASP (SCTP association) within the AS
- 确定AS中的活动ASP（SCTP关联）
- Determine the correct stream in the SCTP association based on the D channel
- 根据D通道确定SCTP关联中的正确流
- Fill in the QPTM message, fill in IUA Message Header, fill in Common Header
- 填写QPTM消息，填写IUA消息头，填写公共消息头
- Send the QPTM message to the remote IUA peer in the ASP, over the SCTP association
- 通过SCTP关联向ASP中的远程IUA对等方发送QPTM消息
An example of the message flows for establishing a data link on a signaling channel, passing PDUs and releasing a data link on a signaling channel is shown below. An active association between MGC and SG is established (Section 5.1) prior to the following message flows.
用于在信令信道上建立数据链路、通过pdu和释放信令信道上的数据链路的消息流的示例如下所示。在以下消息流之前，MGC和SG之间建立了主动关联（第5.1节）。
SG ASP
SG ASP
<----------- Establish Request
Establish Confirm ---------->
<----------- Establish Request
Establish Confirm ---------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
<----------- Data Request
Data Indication ----------->
<----------- Release Request (RELEASE_MGMT)
Release Confirm ---------->
<----------- Release Request (RELEASE_MGMT)
Release Confirm ---------->
An example of the message flows for a failed attempt to establish a data link on the signaling channel is shown below. In this case, the gateway has a problem with its physical connection (e.g., Red Alarm), so it cannot establish a data link on the signaling channel.
在信令信道上建立数据链路的失败尝试的消息流示例如下所示。在这种情况下，网关的物理连接有问题（例如红色警报），因此无法在信令信道上建立数据链路。
SG ASP
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)
An example of the message flows for communication between Layer Management modules between SG and ASP is shown below. An active association between ASP and SG is established (Section 5.1) prior to the following message flows.
SG和ASP之间的层管理模块之间通信的消息流示例如下所示。在以下消息流之前，ASP和SG之间建立了主动关联（第5.1节）。
SG ASP
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
The security considerations discussed in "Security Considerations for SIGTRAN Protocols", RFC 3788 [3], apply to this document.
“SIGTRAN协议的安全注意事项”RFC 3788[3]中讨论的安全注意事项适用于本文件。
The IANA has assigned an IUA value for the Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier has been registered:
IANA为SCTP有效负载数据块中的有效负载协议标识符分配了一个IUA值。已注册以下SCTP有效负载协议标识符：
IUA "1"
IUA“1”
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to indicate which protocol the SCTP is carrying. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a Data chunk.
SCTP有效负载协议标识符包含在每个SCTP数据块中，以指示SCTP承载的协议。此有效负载协议标识符不直接由SCTP使用，但可由某些网络实体用于标识数据块中承载的信息类型。
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP.
用户适配对等方可以使用有效负载协议标识符作为确定关于由SCTP呈现给它的数据的附加信息的方式。
This protocol may also be extended through IANA in three ways:
本协议也可通过IANA以三种方式扩展：
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types, and parameters are an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [7].
新消息类、类型和参数的定义和使用是SIGTRAN适配层不可分割的一部分。因此，IANA通过[7]中定义的IETF共识行动分配这些扩展。
The proposed extension must in no way adversely affect the general working of the protocol.
拟议的延期决不能对议定书的一般工作产生不利影响。
The documentation for a new message class MUST include the following information:
新消息类的文档必须包括以下信息：
(a) A long and short name for the message class. (b) A detailed description of the purpose of the message class.
(a) 消息类的长名称和短名称。（b） 消息类用途的详细说明。
Documentation of the message type MUST contain the following information:
消息类型的文档必须包含以下信息：
(a) A long and short name for the new message type. (b) A detailed description of the structure of the message. (c) A detailed definition and description of intended use of each field within the message. (d) A detailed procedural description of the use of the new message type within the operation of the protocol. (e) A detailed description of error conditions when receiving this message type.
(a) 新消息类型的长名称和短名称。（b） 对消息结构的详细描述。（c） 对消息中每个字段的预期用途的详细定义和说明。（d） 协议操作中使用新消息类型的详细过程描述。（e） 接收此消息类型时错误情况的详细说明。
When an implementation receives a message type that it does not support, it MUST respond with an Error (ERR) message with an Error Code of Unsupported Message Type.
当实现接收到不支持的消息类型时，它必须以错误（ERR）消息响应，错误代码为不支持的消息类型。
Documentation of the message parameter MUST contain the following information:
消息参数的文档必须包含以下信息：
(a) Name of the parameter type. (b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.1.5. (c) Detailed definition of each component of the parameter value. (d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same message type.
(a) 参数类型的名称。（b） 参数字段结构的详细说明。该结构必须符合第3.1.5节所述的通用类型长度值格式。（c） 参数值的每个组件的详细定义。（d） 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一消息类型中找到此参数类型的多个实例的指示。
The following are suggestions for default timer values.
以下是默认计时器值的建议。
T(r) 3-5 seconds T(ack) 2-5 seconds T(beat) Heartbeat Timer 30 seconds
T（r）3-5秒T（确认）2-5秒T（节拍）心跳计时器30秒
The authors would like to thank Alex Audu, Maria Sonia Vazquez Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain, Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez Ramirez, Ian Rytina, Michael Tuexen, and Hank Wang for their valuable comments and suggestions.
作者要感谢Alex Audu、Maria Sonia Vazquez Arevalillo、Ming te Chao、Keith Drage、Norm Glaude、Nikhil Jain、Bernard Kuc、Ming Lin、Stephen Lorusso、John Loughney、Barry Nagelberg、Neil Olson、Lyndon Ong、Heinz Prantner、Jose Luis Jimenez Ramirez、Ian Rytna、Michael Tuexen、，以及王汉克的宝贵意见和建议。
[1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects'
[1] ITU-T建议Q.920，“第1号数字用户信令系统（DSS1）——ISDN用户网络接口数据链路层——一般方面”
[2] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[2] 编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[3] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004.
[3] Loughney，J.，Tuexen，M.，和J.Pastor Balbas，“信号传输（SIGTRAN）协议的安全考虑”，RFC 3788，2004年6月。
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[4] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[5] Ong，L.，Rytina，I.，Garcia，M.，Schwarzbauer，H.，Coene，L.，Lin，H.，Juhasz，I.，Holdrege，M.，和C.Sharp，“信号传输的框架架构”，RFC 2719，1999年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[8] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[8] Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC3309，2002年9月。
Below is a list of the major changes between this document and RFC 3057.
以下是本文件与RFC 3057之间的主要变更列表。
1. The TEI Query message was added.
1. 已添加TEI查询消息。
2. An explanation of the DLCI format (shown in Figure 6) is provided.
2. 提供了DLCI格式的说明（如图6所示）。
3. Aligned the ASP and AS procedures in Section 4 with RFC3331 and RFC3332.
3. 将第4节中的ASP和AS程序与RFC3331和RFC3332对齐。
4. Alinged the format of the ASPSM and ASPTM messages with RFC3331 and RFC3332. These changes include removing the Reason field from the ASP Down and ASP Down Ack messages and the Traffic Mode Type field from the ASP Inactive and ASP Inactive Ack messages.
4. 将ASPSM和ASPTM消息的格式与RFC3331和RFC3332对齐。这些更改包括从ASP Down和ASP Down Ack消息中删除原因字段，以及从ASP Inactive和ASP Inactive Ack消息中删除流量模式类型字段。
5. Sections 1.3.3 and 1.3.4 were moved to Appendix A. A new section was added in place of Section 1.3.3.
5. 第1.3.3节和第1.3.4节移至附录A。增加了一个新的章节，以取代第1.3.3节。
6. The references have been split between Normative and Informative.
6. 参考文献分为规范性参考文献和信息性参考文献。
7. The new Sigtran security document is referenced and Section 6 has been updated appropriately.
7. 参考了新的Sigtran安全文件，并对第6节进行了适当更新。
A Signaling Gateway is used to support the transport of Q.921-User signaling traffic to one or more distributed ASPs (e.g., MGCs). Clearly, the IUA protocol is not designed to meet the performance and reliability requirements for such transport by itself. However, the conjunction of distributed architecture and redundant networks does allow for a sufficiently reliable transport of signaling traffic over IP. The IUA protocol is flexible enough to allow its operation and management in a variety of physical configurations, enabling Network Operators to meet their performance and reliability requirements.
信令网关用于支持将Q.921用户信令业务传输到一个或多个分布式ASP（例如，MGC）。显然，IUA协议本身并不是为了满足此类传输的性能和可靠性要求而设计的。然而，分布式体系结构和冗余网络的结合确实允许通过IP充分可靠地传输信令流量。IUA协议足够灵活，允许在各种物理配置中进行操作和管理，使网络运营商能够满足其性能和可靠性要求。
To meet the ISDN signaling reliability and performance requirements for carrier grade networks, Network Operators SHOULD ensure that there is no single point of failure provisioned in the end-to-end network architecture between an ISDN node and an IP ASP.
为了满足运营商级网络的ISDN信令可靠性和性能要求，网络运营商应确保在ISDN节点和IP ASP之间的端到端网络架构中不存在单点故障。
Depending of course on the reliability of the SG and ASP functional elements, this can typically be met by the provision of redundant Quality of Service (QoS)-bounded IP network paths for SCTP Associations between SCTP End Points, and redundant Hosts, and redundant SGs. The distribution of ASPs within the available Hosts is also important. For a particular Application Server, the related ASPs SHOULD be distributed over at least two Hosts.
当然，这取决于SG和ASP功能元件的可靠性，通常可以通过为SCTP端点、冗余主机和冗余SG之间的SCTP关联提供冗余服务质量（QoS）-有界IP网络路径来实现。ASP在可用主机中的分布也很重要。对于特定的应用程序服务器，相关的ASP应至少分布在两台主机上。
An example logical network architecture relevant to carrier-grade operation in the IP network domain is shown in Figure 8 below:
与IP网络域中的运营商级操作相关的示例逻辑网络架构如下图8所示：
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 8. Logical Model Example
图8。逻辑模型示例
For carrier-grade networks, the failure or isolation of a particular ASP SHOULD NOT cause stable calls to be dropped. This implies that ASPs need, in some cases, to share the call state or be able to pass the call state between each other. However, this sharing or communication of call state information is outside the scope of this document.
对于运营商级网络，特定ASP的故障或隔离不应导致稳定呼叫被丢弃。这意味着在某些情况下，ASP需要共享调用状态或能够在彼此之间传递调用状态。但是，呼叫状态信息的共享或通信不在本文档的范围之内。
To avoid a single point of failure, it is recommended that a minimum of two ASPs be in the list, resident in separate hosts and therefore available over different SCTP Associations. For example, in the network shown in Figure 8, all messages from a particular D Channel (Interface Identifier) could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1 might look like the following:
为避免单点故障，建议列表中至少有两个ASP，驻留在不同的主机上，因此可通过不同的SCTP关联使用。例如，在图8所示的网络中，来自特定D通道（接口标识符）的所有消息都可以发送到Host1中的ASP1或Host2中的ASP1。SG1上的AS列表可能如下所示：
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactive
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming message for the Interface Identifiers registered. ASP1 in Host2 would normally be brought to the active state upon failure of, or loss of connectivity to, ASP1/Host1. In this example, both ASPs are Up, meaning that the related SCTP association and far-end IUA peer are ready.
在这种1+1冗余的情况下，Host1中的ASP1将被发送注册的接口标识符的任何传入消息。当ASP1/Host1发生故障或失去与ASP1的连接时，Host2中的ASP1通常会进入活动状态。在本例中，两个ASP都已启动，这意味着相关的SCTP关联和远端IUA对等已准备就绪。
The AS List at SG1 might also be set up in load-share mode as shown below:
SG1上的AS列表也可以在负载共享模式下设置，如下所示：
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Active
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Active
In this case, both the ASPs would be sent a portion of the traffic.
在这种情况下，两个ASP都将被发送一部分流量。
In the process of fail-over, it is recommended that in the case of ASPs supporting call processing, stable calls do not get released. It is possible that calls in transition MAY fail, although measures of communication between the ASPs involved can be used to mitigate this problem. For example, the two ASPs MAY share call state via shared memory, or MAY use an ASP-to-ASP protocol to pass call state information. The ASP-to-ASP protocol is outside the scope of this document.
在故障转移过程中，建议在ASP支持呼叫处理的情况下，不要释放稳定的呼叫。转换中的调用可能会失败，尽管可以使用相关ASP之间的通信措施来缓解此问题。例如，两个ASP可以通过共享内存共享呼叫状态，或者可以使用ASP-to-ASP协议传递呼叫状态信息。ASP到ASP协议不在本文档的范围内。
Authors' Addresses
作者地址
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
Ken Morneault Cisco Systems Inc.美国弗吉尼亚州赫恩登市杜勒斯技术大道13615号，邮编：20171
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Malleswar Kalla Telcordia Technologies PYA 2J-341 3 Corporate Place Piscataway, NJ 08854 USA
Malleswar Kalla Telcordia Technologies PYA 2J-341美国新泽西州皮斯卡塔韦3号企业广场，邮编08854
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Selvam Rengasami Tridea Works
Selvam Rengasami Tridea工厂
Phone: +1-732-512-0969
EMail: selvam@trideaworks.com
Phone: +1-732-512-0969
EMail: selvam@trideaworks.com
Greg Sidebottom Signatus Technologies Kanata, Ontario, Canada
Greg Sidebottom Signatus Technologies加拿大安大略省卡纳塔市
EMail: greg@signatustechnologies.com
EMail: greg@signatustechnologies.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。