Network Working Group K. Morneault
Request for Comments: 3057 Cisco Systems
Category: Standards Track S. Rengasami
M. Kalla
Telcordia Technologies
G. Sidebottom
Nortel Networks
February 2001
Network Working Group K. Morneault
Request for Comments: 3057 Cisco Systems
Category: Standards Track S. Rengasami
M. Kalla
Telcordia Technologies
G. Sidebottom
Nortel Networks
February 2001
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines a protocol for backhauling of 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信令。
Table of Contents
目录
1. Introduction................................................. 2
1.1 Scope..................................................... 2
1.2 Terminology............................................... 3
1.3 IUA Overview.............................................. 4
1.4 Services Provided by the IUA Layer........................ 9
1.5 Functions Implemented by the IUA Layer.................... 12
1.6 Definition of IUA Boundaries.............................. 14
2. Conventions.................................................. 16
3. Protocol Elements............................................ 17
3.1 Common Message Header..................................... 17
3.2 IUA Message Header........................................ 20
3.3 Description of Messages................................... 22
4. Procedures................................................... 45
4.1 Procedures to Support Service in Section 1.4.1............ 45
4.2 Procedures to Support Service in Section 1.4.2............ 46
4.3 Procedures to Support Service in Section 1.4.3............ 47
5. Examples...................................................... 56
5.1 Establishment of associations between SG and MGC examples.. 56
5.2 ASP Traffic Fail-over Examples............................. 58
5.3 Q.921/Q.931 primitives backhaul Examples................... 59
5.4 Layer Management Communication Examples.................... 61
6. Security..................................................... 61
6.1 Threats.................................................... 61
6.2 Protecting Confidentiality ................................ 62
7. IANA Considerations.......................................... 62
7.1 SCTP Payload Protocol Identifier........................... 62
7.2 IUA Protocol Extensions.................................... 62
8. Acknowledgements............................................. 64
9. References................................................... 64
10. Authors' Addresses........................................... 65
11. Full Copyright Statement..................................... 66
1. Introduction................................................. 2
1.1 Scope..................................................... 2
1.2 Terminology............................................... 3
1.3 IUA Overview.............................................. 4
1.4 Services Provided by the IUA Layer........................ 9
1.5 Functions Implemented by the IUA Layer.................... 12
1.6 Definition of IUA Boundaries.............................. 14
2. Conventions.................................................. 16
3. Protocol Elements............................................ 17
3.1 Common Message Header..................................... 17
3.2 IUA Message Header........................................ 20
3.3 Description of Messages................................... 22
4. Procedures................................................... 45
4.1 Procedures to Support Service in Section 1.4.1............ 45
4.2 Procedures to Support Service in Section 1.4.2............ 46
4.3 Procedures to Support Service in Section 1.4.3............ 47
5. Examples...................................................... 56
5.1 Establishment of associations between SG and MGC examples.. 56
5.2 ASP Traffic Fail-over Examples............................. 58
5.3 Q.921/Q.931 primitives backhaul Examples................... 59
5.4 Layer Management Communication Examples.................... 61
6. Security..................................................... 61
6.1 Threats.................................................... 61
6.2 Protecting Confidentiality ................................ 62
7. IANA Considerations.......................................... 62
7.1 SCTP Payload Protocol Identifier........................... 62
7.2 IUA Protocol Extensions.................................... 62
8. Acknowledgements............................................. 64
9. References................................................... 64
10. Authors' Addresses........................................... 65
11. Full Copyright Statement..................................... 66
In this document, the term Q.921-User refers to an upper layer which 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 [4]. The delivery mechanism SHOULD meet the following criteria:
信号传输[4]。交付机制应符合以下标准：
* 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 active associations between SG and MGC
* 支持Q.921/Q.931边界原语的传输*支持SG和MGC上图层管理模块之间的通信*支持SG和MGC之间活动关联的管理
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。
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信道。
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等）。
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。
Association - An association refers to a 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适配层对等消息的传输。
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端点建立的单向逻辑通道，在该通道内，除提交给未排序传递服务的用户消息外，所有用户消息都按顺序传递。
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
接口标识符-接口标识符标识SG上发送/接收信令消息的物理接口。接口标识符参数的格式可以是文本或整数，其值根据
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和ASP之间进行协调。在AS服务的SGs中不暗示重要性。
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实例。
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 back-up MGC). Fail-over also applies upon the return to service of a previously unavailable process.
故障转移-在当前使用的ASP出现故障或不可用时（例如，从主MGC到备用MGC），根据需要在相关ASP之间重新路由信令流量的能力。故障转移也适用于以前不可用的进程恢复服务时。
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.
网络字节顺序-最高有效字节优先，也称为大端字节。
Host - The computing platform that the ASP process is running on.
主机—运行ASP进程的计算平台。
The architecture that has been defined [4] 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信令传输定义的架构[4]使用多个组件，包括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, 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:
在信令网关中，期望通过标准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 [3]) IUA - ISDN User Adaptation Layer Protocol
NIF-节点互通功能EP-ISDN端点SCTP-流控制传输协议（参考[3]）IUA-ISDN用户适配层协议
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 NOT be a requirement and TCP can 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 state of remote ASP(s) are also 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的原语确定。
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 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 1 below:
与IP网络域中的运营商级操作相关的示例逻辑网络架构如下图1所示：
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 2 - Logical Model Example
图2-逻辑模型示例
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需要共享调用状态或能够在彼此之间传递调用状态。但是，呼叫状态信息的共享或通信不在本文档的范围之内。
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 fail-over model supports an n+k redundancy model, where n ASP(s) are 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.
故障转移模型支持n+k冗余模型，其中n ASP（s）是处理流量所需的最小冗余ASP数量，k ASP可用于接管故障或不可用的ASP。请注意，1+1主动/备用冗余是该模型的一个子集。simplex 1+0模型也支持作为子集，没有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 2, 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关联使用。例如，在图2所示的网络中，来自特定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 is 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协议不在本文档的范围内。
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
建议SG和ASP能够同时支持客户端和服务器操作。应配置使用IUA的对等端点，以便始终扮演客户机和服务器的角色
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.
其他服务器角色用于启动SCTP关联。默认情况下，SG将承担服务器角色，而ASP是客户端。在这种情况下，ASP应启动与SG的SCTP关联。
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA is 9900.
IUA的SCTP（和UDP/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 which 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 which 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 pointed out in [2], which are shown below:
预计IUA层需要提供一些服务，以促进SG和MGC上的层管理模块之间的通信。[2]中指出了这些原语，如下所示：
M-TEI STATUS
M-TEI状态
The M-TEI STATUS primitives are used to request, confirm and indicate the status (assigned/unassigned) of a TEI.
M-TEI状态原语用于请求、确认和指示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 are 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 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 TEIs and SAPIs.
IUA层必须维护接口标识符到信令网关上物理接口的映射。物理接口可以是T1线、E1线等，并且可以包括TDM时隙。此外，对于给定接口，SG必须能够识别相关的信令信道。SG和MGC上的IUA层可保持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 failover 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 back-up ASP are available, IUA peer protocol is required to control which ASP is currently active. The ordered list of ASPs within a logical Application Server is kept updated in the SG to reflect the active Application Server Process(es).
在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 Reference [3] section 10.
参考文献[3]第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 [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照[RFC2119]中的说明进行解释。
This section describes the format of various messages used in this protocol.
本节介绍本协议中使用的各种消息的格式。
The protocol messages for Q.921-User Adaptation require a message header which 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 3 Common Header Format
图3通用标题格式
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 [IUA/M2UA/M3UA/SUA]
1 Transfer Messages [M3UA]
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
Messages [IUA]
6 MTP2 User Adaptation (MAUP) Messages [M2UA]
7 Connectionless Messages [SUA]
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
1 Transfer Messages [M3UA]
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
Messages [IUA]
6 MTP2 User Adaptation (MAUP) Messages [M2UA]
7 Connectionless Messages [SUA]
8 Connection-Oriented Messages [SUA] 9 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions
8 IETF保留的面向连接的消息[SUA]9至127 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 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到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.
消息长度以八位字节定义消息的长度，包括公共头。
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 Tag-Length-Value format as shown below.
IUA消息由一个公共头和零个或多个可变长度参数组成，这些参数由消息类型定义。消息中包含的可变长度参数以标记长度值格式定义，如下所示。
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.
标记字段是参数类型的16位标识符。它的值为0到65534。
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 4 IUA Message Header (Integer-based Interface Identifier)
图4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IUA Message Header (Text-based Interface Identifier)
图5 IUA消息头（基于文本的接口标识符）
The Tag value for the Text-based Interface Identifier is 0x3. The length is variable.
基于文本的接口标识符的标记值为0x3。长度是可变的。
The DLCI format is shown below in Figure 6.
DLCI格式如下图6所示。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | SPR | SAPI |
+-----------------------------------------------+
| 1 | TEI |
+-----------------------------------------------+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | SPR | SAPI |
+-----------------------------------------------+
| 1 | TEI |
+-----------------------------------------------+
Figure 6 DLCI Format
图6 DLCI格式
SPR: Spare 2nd bit in octet 1, (1 bit)
SPR：八位组1中的备用第二位（1位）
SAPI: Service Access Point Identifier, 3rd through 8th bits in octet 1 (6 bits)
SAPI：服务接入点标识符，八位组1中的第3位到第8位（6位）
TEI: Terminal Endpoint Identifier, 2nd through 8th bits in octet 2 (7 bits)
TEI：终端端点标识符，八位字节2中的第2位到第8位（7位）
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 3) and the IUA message header (Figure 4 and Figure 5).
以下部分定义了消息和参数内容。IUA消息将使用公共消息头（图3）和IUA消息头（图4和图5）。
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 re-send 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 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 its 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 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.
当SG收到来自MGC的IUA建立请求时，SG应将Q.921建立请求原语发送给its Q.921实体。此外，SG应将从Q.921实体收到的任何响应映射到MGC的适当消息。例如，如果Q.921实体响应Q.921建立确认原语，则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
原因
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 parameters:
数据消息包含公共消息头，后跟IUA消息头。数据消息包含以下参数：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 parameters
单元数据消息包含公共消息头，后跟IUA消息头。机组数据信息包含以下参数
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 only use 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消息包含以下参数：
Info String (optional)
信息字符串（可选）
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 (0x4) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional INFO String parameter can carry any meaningful 8-bit ASCII 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字符串以及消息。信息字符串参数的长度为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 (0x4) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（参见第3.3.3.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消息包含以下参数：
Reason 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 (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1.).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（见第3.3.3.1节）。
The Reason parameter indicates the reason that the remote IUA adaptation layer is unavailable. The valid values for Reason are shown in the following table.
Reason参数表示远程IUA适配层不可用的原因。下表显示了合理的有效值。
Value Description 0x1 Management Inhibit
值说明0x1管理禁止
If a ASP is removed from Management Inhibit, the ASP will send an ASP Up message.
如果从管理禁止中删除ASP，则ASP将发送ASP Up消息。
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消息包含以下参数：
Reason 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 (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.).
可选信息字符串参数的格式和说明与ASP Up消息相同（见第3.3.2.1节）。
The format of the Reason parameter is the same as for the ASP Down message (See Section 3.3.2.3).
原因参数的格式与ASP Down消息的格式相同（见第3.3.2.3节）。
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 Identifier (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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifiers | | of Tag Type 0x1 or 0x8 |
|标签类型为0x1或0x8的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
|接口标识符*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
|标签类型0x3的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Interface Identifier, 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/back-up 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.
在特定接口标识符中，只能使用一种通信模式类型。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(s) in which the ASP is provisioned. If only a subset of Interface Identifiers are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
如果未包括任何接口标识符，则该消息适用于配置ASP的AS中的所有已配置接口标识符。如果仅包括接口标识符的子集，则ASP对于为其设置的所有接口标识符都被视为活动的。
Note: If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier MUST be supported, while the text formatted Interface Identifier MAY be supported.
注意：如果存在可选接口标识符参数，则必须支持整数格式的接口标识符，而可能支持文本格式的接口标识符。
The format and description of the optional Info String parameter is 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifiers | | of Tag Type 0x1 or 0x8 |
|标签类型为0x1或0x8的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
|接口标识符*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
|标签类型0x3的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is 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消息包含以下参数
Traffic Mode Type (Mandatory) 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifiers | | of Tag Type 0x1 or 0x8 |
|标签类型为0x1或0x8的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
|接口标识符*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
|标签类型0x3的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Traffic Mode Type are shown in the following table:
Traffic Mode Type参数标识AS中ASP的运行流量模式。交通模式类型的有效值如下表所示：
Value Description 0x1 Over-ride 0x2 Load-share
值说明0x1超越0x2负载共享
The format and description of the optional Interface Identifiers and Info String parameters is the same as for the ASP Active message (See Section 3.3.2.3.).
可选接口标识符和信息字符串参数的格式和说明与ASP活动消息的格式和说明相同（见第3.3.2.3节）。
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 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消息包含以下参数：
Traffic Mode Type (Mandatory) Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifiers | | of Tag Type 0x1 or 0x8 |
|标签类型为0x1或0x8的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
|接口标识符*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
|标签类型0x3的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Mode Type and Interface Identifier parameters is the same as for the ASP Inactive message (See Section 3.3.2.7).
流量模式类型和接口标识符参数的格式与ASP非活动消息的格式相同（见第3.3.2.7节）。
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
可选信息字符串参数的格式和说明与ASP Up消息的格式和说明相同（见第3.3.2.1节）。
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 = 9 | 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 = 9 | 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 only have 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 (0xc) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xc) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | 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
无效版本0x01无效接口标识符0x02不支持的消息类0x03不支持的消息类型0x04不支持的流量处理模式0x05意外消息0x06协议错误0x07不支持的接口标识符类型0x08无效流标识符0x09未分配的TEI 0x0a未识别的SAPI 0x0b无效TEI，SAPI组合0x0c
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 a SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value.
如果ASP发送带有无效（未配置）接口标识符值的消息，则SG将发送“无效接口标识符”错误。
The "Unsupported Traffic Handling Mode" error would be sent by a 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
如果ASP在非活动状态下收到来自SG的QPTM消息，则ASP将发送“意外消息”错误（ASP可以选择删除消息而不发送错误）。会的
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不希望发送的已定义和已识别的消息（例如，如果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 (i.e., a MGMT message was received on a stream other than "0").
如果在意外的SCTP流上接收到消息（即，在“0”以外的流上接收到管理消息），则将发送“无效流标识符”错误。
The "Unsupported Interface Identifier Type" error would be sent by a 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 which 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 a SAPI that is not recognized by the SG. The "Invalid TEI, SAPI combination" error identify errors where the TEI is assigned and the the SAPI is recognized, but the combination is not valid for the interface (e.g., on a 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 optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. To enhance debugging, the Diagnostic information could contain the first 40 bytes of the offending message.
可选诊断信息可以是与错误状况相关的任何信息，以帮助识别错误状况。为了增强调试，诊断信息可以包含出错消息的前40个字节。
The Notify message used to provide an autonomous indication of IUA events to an IUA peer.
用于向IUA对等方提供IUA事件的自主指示的通知消息。
The Notify message will only use the common message header. The Notify message contains the following parameters:
通知消息将仅使用公共消息头。通知消息包含以下参数：
Status Type Status Identification Interface Identifiers (Optional) INFO String (Optional)
状态类型状态标识接口标识符（可选）信息字符串（可选）
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 (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifiers | | of Tag Type 0x1 or 0x8 |
|标签类型为0x1或0x8的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | 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 (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
|接口标识符*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
|标签类型0x3的附加接口标识符| ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
|信息字符串*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status Type parameter identifies the type of the Notify message. The following are the valid Status Type values:
Status Type参数标识通知消息的类型。以下是有效的状态类型值：
Value Description 0x1 Application Server state change (AS_State_Change) 0x2 Other
值说明0x1应用程序服务器状态更改（作为状态更改）0x2其他
The Status Identification 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 Identification values are used:
Status Identification参数根据状态类型的值包含通知的更详细信息。如果状态类型为AS_State_Change，则使用以下状态标识值：
Value Description 1 Application Server Down (AS_Down) 2 Application Server Inactive (AS_Inactive) 3 Application Server Active (AS_Active) 4 Application Server Pending (AS_Pending)
值说明1应用程序服务器关闭（AS_关闭）2应用程序服务器不活动（AS_不活动）3应用程序服务器活动（AS_活动）4应用程序服务器挂起（AS_挂起）
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
值说明1中活动的ASP资源不足，2备用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 "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.
这些通知并非基于报告ASP或AS状态更改的SG。在ASP资源不足的情况下，SG向AS中的“非活动”ASP指示需要另一个ASP来处理AS的负载（负载共享模式）。对于备用ASP激活情况，当备用ASP在超车模式下转换为ASP激活状态时，会通知ASP。
The format and description of the optional Interface Identifiers and Info String parameters is the same as for the ASP Active message (See Section 3.3.2.3.).
可选接口标识符和信息字符串参数的格式和说明与ASP活动消息的格式和说明相同（见第3.3.2.3节）。
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 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.
在综合ISDN第2/3层模型中（例如，在传统ISDN交换机中），假定Q.921层和Q.931层的层管理位于同一位置。当回传ISDN时，这种假设不一定有效。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 (0x10) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (0x10) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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" 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 set-up is complete. An M-SCTP ESTABLISH indication is sent to Layer Management upon successful completion of an incoming SCTP association set-up 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 tear-down 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 tear-down 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 a 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
* 接收来自该ASP的对等IUA层的消息*接收来自AS中其他ASP的对等IUA层的一些消息*接收来自SCTP层的指示
The ASP state transition diagram is shown in Figure 7. The possible states of an ASP are the following:
ASP状态转换图如图7所示。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对等方可用，且应用程序流量处于活动状态。
Figure 7 ASP State Transition Diagram
图7 ASP状态转换图
+-------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +-------------+
| Takeover | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +-------------+
| | | |
| +------>| ASP-INACT |
| +-------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI
| | v
| +-------------+
+--------------------->| |
| ASP-DOWN |
+-------------+
+-------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +-------------+
| Takeover | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +-------------+
| | | |
| +------>| ASP-INACT |
| +-------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI
| | v
| +-------------+
+--------------------->| |
| ASP-DOWN |
+-------------+
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的停机完成通知和通信丢失通知。
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状态。
Figure 8 AS State Transition Diagram
图8为状态转换图
+----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| |
| AS-INACT | | AS-ACTIVE |
| | | |
| |< | |
+----------+ \ +-------------+
^ | \ Tr Trigger ^ |
| | \ at least one | |
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | \ one ASP | | Last ACTIVE ASP
trans | | all ASP \------\ trans to | | trans to INACT
to | | trans to \ ACTIVE | | or DOWN
INACT | | DOWN \ | | (start Tr timer)
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | -| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<------------------------| |
+----------+ Tr Expiry and no +-------------+
ASP in INACTIVE state
+----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| |
| AS-INACT | | AS-ACTIVE |
| | | |
| |< | |
+----------+ \ +-------------+
^ | \ Tr Trigger ^ |
| | \ at least one | |
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | \ one ASP | | Last ACTIVE ASP
trans | | all ASP \------\ trans to | | trans to INACT
to | | trans to \ ACTIVE | | or DOWN
INACT | | DOWN \ | | (start Tr timer)
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | -| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<------------------------| |
+----------+ Tr Expiry and no +-------------+
ASP in INACTIVE state
Tr = Recovery Timer
Tr = Recovery Timer
Before the establishment of an SCTP association the ASP state at both the SG and ASP is assumed to be "Down".
在建立SCTP关联之前，假定SG和ASP的ASP状态均为“关闭”。
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, they 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通信中断指示后，使用M-SCTP释放确认原语通知本地层管理层。
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通信中断指示，它将通过调用M-SCTP释放指示原语通知层管理。在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关联。
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 exchange.
ASP成功建立与SG的SCTP关联后，SG等待ASP发送ASP Up消息，指示ASP IUA对等机可用。ASP始终是ASP Up exchange的发起方。
When an ASP Up message is received at an SG and internally the remote ASP is not considered locked-out for local management reasons, the SG marks the remote ASP as "Inactive". The SG responds with an ASP Up Ack message in acknowledgement. The SG sends an ASP-Up Ack message in response to a received ASP Up message even if the ASP is already marked as "Inactive" at the SG.
当SG接收到ASP Up消息且出于本地管理原因远程ASP在内部未被视为锁定时，SG将远程ASP标记为“非活动”。SG以ASP Up Ack消息作为应答。SG发送ASP Up Ack消息以响应接收到的ASP Up消息，即使该ASP已在SG处标记为“非活动”。
If for any local reason the SG cannot respond with an ASP Up, the SG responds to a ASP Up with a with an ASP-Down Ack message with Reason "Management Blocking".
如果出于任何本地原因，SG无法以ASP Up响应，则SG会以ASP Down Ack消息响应ASP Up，原因为“管理阻塞”。
At the ASP, the ASP Up Ack message received from the SG is not acknowledged by the ASP. If the ASP does not receive a response from the SG, or an ASP Down Ack is received, the ASP MAY resend ASP Up messages every 2 seconds until it receives a ASP Up Ack message from the SG. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Up Ack is not received after a few tries.
在ASP处，ASP不确认从SG接收的ASP Up Ack消息。如果ASP未收到来自SG的响应，或收到ASP Down Ack，则ASP可每隔2秒重新发送ASP Up消息，直到收到来自SG的ASP Up Ack消息。如果在几次尝试后未收到ASP Up Ack，ASP可能会决定降低频率（例如每5秒一次）。
The ASP MUST wait for the ASP Up Ack message from the SG before sending any ASP traffic control messages (ASPAC or ASPIA) or Data messages or it will risk message loss. If the SG receives QPTM, ASP Active or ASP Inactive messages before an ASP Up is received, the SG SHOULD discard these messages.
在发送任何ASP流量控制消息（ASPAC或ASPIA）或数据消息之前，ASP必须等待来自SG的ASP Up Ack消息，否则将有消息丢失的风险。如果SG在收到ASP Up之前收到QPTM、ASP Active或ASP Inactive消息，则SG应丢弃这些消息。
The ASP will send an ASP Down to an SG when the ASP is to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA traffic or management messages.
当ASP从其作为成员的所有应用程序服务器中的ASP列表中删除并且不再接收任何IUA流量或管理消息时，ASP将向SG发送ASP。
Whether the ASP is permanently removed from an AS is a function of configuration management.
是否从AS中永久删除ASP是配置管理的一项功能。
The SG marks the ASP as "Down" and returns an ASP Down Ack message to the ASP if one of the following events occur:
如果发生以下事件之一，SG将ASP标记为“停机”，并向ASP返回ASP停机确认消息：
- to acknowledge an ASP Down message from an ASP, - to reply to ASPM messages from an ASP which is locked out for management reasons.
- 若要确认来自ASP的ASP关闭消息，请，-答复来自因管理原因被锁定的ASP的ASPM消息。
The SG sends an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as "Down" at the SG.
SG发送ASP Down Ack消息以响应从ASP接收到的ASP Down消息，即使ASP已在SG处标记为“Down”。
If the ASP does not receive a response from the SG, the ASP MAY send ASP Down messages every 2 seconds until it receives an ASP Down Ack message from the SG or the SCTP association goes down. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Down Ack is not received after a few tries.
如果ASP没有收到来自SG的响应，ASP可能每2秒发送一次ASP Down消息，直到收到来自SG的ASP Down Ack消息或SCTP关联停止。如果在几次尝试后未收到ASP Down Ack，ASP可能会决定降低频率（例如每5秒一次）。
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 a ASP Up Ack from the SG, the ASP sends an ASP-Active (ASPAC) to the SG indicating that the ASP is ready to start processing traffic. 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 Active（ASPAC），指示ASP已准备好开始处理流量。在配置/注册ASP以处理SCTP关联中多个应用服务器的流量的情况下，ASPAC包含一个或多个接口标识符，以指示ASPAC应用于哪些应用服务器。
When an ASP Active (ASPAC) message is received, the SG responds to the ASP with a ASPAC Ack message acknowledging that the ASPAC was received and starts sending traffic for the associated Application Server(s) to that ASP.
当收到ASP Active（ASPAC）消息时，SG用ASPAC Ack消息响应ASP，确认已收到ASPAC，并开始向该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
在负载共享模式AS的情况下，除了AS中当前处于活动状态的所有其他ASP外，在SG处接收ASPAC消息会导致发送ASPAC的ASP的流量方向。SG中用于AS内负载共享流量的算法与所有活动ASP的算法取决于实现。算法
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 a ASP-Active Ack message to the 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 (ASPIA) to the SG. 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 ASPIA applies.
当ASP希望退出AS内的接收流量时，ASP向SG发送一个ASP非活动（ASPIA）。在配置/注册ASP以处理SCTP关联中多个应用服务器的流量的情况下，ASPIA包含一个或多个接口标识符，以指示ASPIA应用于哪些应用服务器。
There are two modes of Application Server traffic handling in the SG IUA when withdrawing an ASP from service - Over-ride and Load-sharing. The Type parameter in the ASPIA 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.
从服务转移和负载共享中退出ASP时，SG IUA中有两种应用程序服务器流量处理模式。ASPIA消息中的Type参数表示特定应用程序服务器中使用的模式。如果SG确定ASPAC中指示的模式与AS中当前使用的流量处理模式不兼容，则SG会发出错误消息，指示不支持的流量处理模式。
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, the ASP which sends the ASPIA is already considered by the SG to be "Inactive". An ASPIA Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
在超车模式AS的情况下，通常另一个ASP已经用超车ASPAC接管AS内的交通，发送ASPIA的ASP已经被SG视为“非活动”。在确保所有到ASP的通信停止后，将向ASP发送ASPIA Ack消息。
In the case of a Load-share mode AS, the SG moves the ASP to the "Inactive" state and the AS traffic is re-allocated across the remaining "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 NTFY (Insufficient ASPs) MAY be sent to all inactive ASPs, if required.
在负载共享模式AS的情况下，SG将ASP移动到“非活动”状态，并且根据AS中当前使用的负载共享算法在剩余的“活动”ASP之间重新分配AS流量。ASP的所有通信停止后，将向ASP发送ASPIA Ack消息。如果需要，可以向所有非活动的ASP发送NTFY（不足的ASP）。
If no other ASPs are Active in the Application Server, the SG sends a NTFY (AS-Pending) to all inactive ASPs of the AS and either discards all incoming messages for the AS or starts buffering the incoming messages for T(r)seconds, after which messages will be discarded. T(r) is configurable by the network operator. If the SG receives an ASPAC from an ASP in the AS before expiry of T(r), the buffered traffic is directed to the ASP and the timer is cancelled. If T(r) expires, the AS is moved to the "Inactive" state.
如果应用服务器中没有其他ASP处于活动状态，则SG向AS的所有非活动ASP发送NTFY（AS挂起），并丢弃AS的所有传入消息或开始将传入消息缓冲T（r）秒，然后丢弃消息。T（r）可由网络运营商配置。如果SG在T（r）到期之前从AS中的ASP接收到ASPAC，则缓冲的通信量被定向到ASP，并且定时器被取消。如果T（r）过期，AS将移至“非活动”状态。
A Notify message reflecting a change in the AS state is sent to all ASPs in the AS, except those in the "Down" state, with appropriate Status Identification.
反映AS状态变化的Notify消息被发送到AS中的所有ASP，处于“关闭”状态的ASP除外，并带有适当的状态标识。
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 force 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）。
After receiving an ASP Up Ack message from the SG in response to an ASP Up message, the ASP MAY optionally send Beat messages periodically, subject to a provisionable timer T(beat). The SG IUA, upon receiving a BEAT message from the ASP, responds with a BEAT ACK message. If no BEAT message (or any other IUA message) is received from the SG within the timer 2*T(beat), the SG will consider the remote IUA as "Down". The SG will also send an ASP Down Ack message to the ASP.
在响应于ASP-Up消息从SG接收到ASP-Up Ack消息之后，ASP可以选择性地根据可设置的定时器T（Beat）周期性地发送Beat消息。SG IUA在接收到来自ASP的节拍消息后，用节拍确认消息进行响应。如果在计时器2 *T（节拍）内没有从SG接收节拍消息（或任何其他IUA消息），则SG将远程IUA视为“向下”。SG还将向ASP发送ASP Down Ack消息。
At the ASP, if no BEAT ACK message (or any other IUA message) is received from the SG within 2*T(beat), the SG is considered unavailable. Transmission of BEAT messages is stopped and ASP Up procedures are used to re-establish communication with the SG IUA peer.
在ASP，如果在2*T（BEAT）内没有从SG接收到BEAT ACK消息（或任何其他IUA消息），则认为SG不可用。停止BEAT消息的传输，并使用ASP Up过程重新建立与SG 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 4 "ASP state transition diagram".
注意：图4“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 set-up.
此场景显示了用于在SG和ASP之间建立流量的示例IUA消息流，其中AS中仅配置了一个ASP（无备份）。假设SCTP关联已经建立。
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
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------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
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------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|<----------------------------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---->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
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) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-------------------NTFY(AS-Pending) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
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 over-ride 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)
IUA is designed to carry signaling messages for telephony services. As such, IUA MUST involve the security needs of several parties the end users of the services; the network providers and the applications involved. Additional requirements MAY come from local regulation. While having some overlapping security needs, any security solution SHOULD fulfill all of the different parties' needs.
IUA被设计用于承载电话服务的信令消息。因此，IUA必须涉及服务最终用户的多方安全需求；网络提供商和涉及的应用程序。其他要求可能来自当地法规。尽管存在一些重叠的安全需求，但任何安全解决方案都应该满足不同各方的所有需求。
There is no quick fix, one-size-fits-all solution for security. As a transport protocol, IUA has the following security objectives:
没有快速修复、一刀切的安全解决方案。作为一种传输协议，IUA具有以下安全目标：
* Availability of reliable and timely user data transport. * Integrity of user data transport. * Confidentiality of user data.
* 提供可靠、及时的用户数据传输。*用户数据传输的完整性。*用户数据的保密性。
IUA runs on top of SCTP. SCTP [3] provides certain transport related security features, such as
IUA运行在SCTP之上。SCTP[3]提供了某些与传输相关的安全功能，例如
* Blind Denial of Service Attacks * Flooding * Masquerade * Improper Monopolization of Services
* 盲目拒绝服务攻击*泛滥*伪装*不正当的服务垄断
When IUA is running in professionally managed corporate or service provider network, it is reasonable to expect that this network includes an appropriate security policy framework. The "Site Security Handbook" [5] SHOULD be consulted for guidance.
当IUA在专业管理的公司或服务提供商网络中运行时，可以合理地期望该网络包含适当的安全策略框架。应参考“现场安全手册”[5]以获取指导。
When the network in which IUA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [6] for more information on configuring IPSEC services.
当IUA运行的网络涉及多个参与方时，期望所有参与方都以充分的方式实施了安全性可能是不合理的。在这种情况下，建议使用IPSEC来确保用户负载的机密性。有关配置IPSEC服务的更多信息，请参阅[6]。
Particularly for mobile users, the requirement for confidentiality MAY include the masking of IP addresses and ports. In this case application level encryption is not sufficient; IPSEC ESP SHOULD be used instead. Regardless of which level performs the encryption, the IPSEC ISAKMP service SHOULD be used for key management.
特别是对于移动用户，保密性要求可能包括屏蔽IP地址和端口。在这种情况下，应用程序级加密是不够的；应改用IPSEC ESP。无论哪个级别执行加密，都应使用IPSEC ISAKMP服务进行密钥管理。
A request will be made to IANA to assign an IUA value for the Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier will be 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 is an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [RFC2434].
新消息类、类型和参数的定义和使用是SIGTRAN适配层不可分割的一部分。因此，IANA通过[RFC2434]中定义的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. ti3 (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） 对消息中每个字段的预期用途的详细定义和说明。ti3（d）在协议操作中使用新消息类型的详细程序说明。（e） 接收此消息类型时错误情况的详细说明。
When an implementation receives a message type which 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 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 Rytina、，Michael Tuexen和Hank Wang感谢他们的宝贵意见和建议。
[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] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a Voice over Packet Network'
[2] T1S1.7/99-220贡献，“分组语音网络中DSS1协议的回传”
[3] 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.
[3] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural Framework for Signaling Transport", RFC 2719, October 1999.
[4] Ong，L.，Rytina，I.，Garcia，M.，Schwarzbauer，H.，Coene，L.，Lin，H.，Juhasz，I.，Holdrege，M.，和C.Sharp，“信号传输的架构框架”，RFC 2719，1999年10月。
[5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[5] Fraser，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[7] Bradner, s., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，s.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
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 Telcordia Technologies NVC-2Z439 331 Newman Springs Road Red Bank, NJ 07701 USA
Selvam Rengasami Telcordia Technologies NVC-2Z439 331美国新泽西州纽曼斯普林斯路红银行07701
Phone: +1-732-758-5260
EMail: srengasa@telcordia.com
Phone: +1-732-758-5260
EMail: srengasa@telcordia.com
Greg Sidebottom Nortel Networks 3685 Richmond Road Nepean, Ontario Canada K2H5B7
Greg Sidebottom北电网络加拿大安大略省内皮恩里士满路3685号K2H5B7
Phone: +1-613-763-7305
EMail: gregside@nortelnetworks.com
Phone: +1-613-763-7305
EMail: gregside@nortelnetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。