Network Working Group D. Sprague
Request for Comments: 3094 R. Benedyk
Category: Informational D. Brendes
J. Keller
Tekelec
April 2001
Network Working Group D. Sprague
Request for Comments: 3094 R. Benedyk
Category: Informational D. Brendes
J. Keller
Tekelec
April 2001
Tekelec's Transport Adapter Layer Interface
Tekelec的传输适配器层接口
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
IESG Note:
IESG注：
Readers should note that this memo presents a vendor's alternative to standards track technology being developed by the IETF SIGTRAN Working Group. The technology presented in this memo has not been reviewed by the IETF for its technical soundness or completeness. Potential users of this type of technology are urged to examine the SIGTRAN work before deciding to use the technology described here.
读者应注意，本备忘录介绍了IETF SIGTRAN工作组正在开发的标准跟踪技术的供应商替代方案。本备忘录中介绍的技术未经IETF审查其技术可靠性或完整性。这类技术的潜在用户在决定使用本文描述的技术之前，应检查SIGTRAN的工作。
Abstract
摘要
This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
本文件提出了信令网关的接口，它提供了交换电路网络（SCN）和IP网络之间的互通。由于网关是信令信息的中心点，它不仅提供从一个网络到另一个网络的信令传输，还可以提供附加功能，如协议转换、安全屏蔽、路由信息以及对两个网络上的智能网（IN）服务的无缝访问。
The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability Application Part), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (Signalling Connection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.
传输适配器层接口（TALI）是提议的接口，它通过TCP/IP提供TCAP（事务能力应用程序部分）、ISUP（ISDN用户部分）和MTP（邮件传输协议）消息传递。此外，TALI还提供SCCP（信令连接控制部分）管理（SCMG）、MTP原语、电路动态注册以及基于电路位置的呼叫控制消息路由。
Table of Contents
目录
1. Introduction 4 2. Overview of the TALI Protocol 6 2.1 Traditional PSTN SS7 Networks 6 2.2 Converged SS7 Networks 8 2.3 TALI Protocol Stack Overview 10 2.3.1 An Alternate TALI Protocol Stack using the SAAL Layer 13 2.3.2 An Alternate TALI Protocol Stack using SCTP 15 2.4 Inputs to the TALI Version 1.0 State Machine 15 3. TALI Version 1.0 17 3.1 Overview of the TALI Message Structure 17 3.1.1 Types of TALI Fields 19 3.2 Detailed TALI Message Structure 20 3.2.1 TALI Peer to Peer Messages 20 3.2.1.1 Test Message (test) 20 3.2.1.2 Allow Message (allo) 21 3.2.1.3 Prohibit Message (proh) 21 3.2.1.4 Prohibit Acknowledgement Message (proa) 21 3.2.1.5 Monitor Message (moni) 22 3.2.1.6 Monitor Acknowledge Message (mona) 22 3.2.2 Service Messages 23 3.2.2.1 SCCP Service Message (sccp) 23 3.2.2.1.1 SCCP Encapsulation using TALI 25 3.2.2.2 ISUP Service Message (isot) 27 3.2.2.2.1 ISUP Encapsulation using TALI 27 3.2.2.3 MTP3 Service Message (mtp3) 28 3.2.2.3.1 MTP3 Encapsulation using TALI 29 3.2.2.4 SAAL Service Message (saal) 30 3.2.2.4.1 MTP3 and SAAL Peer to Peer Encapsulation using TALI 31 3.3 TALI Timers 34 3.3.1 T1 Timer 34 3.3.2 T2 Timer 34 3.3.3 T3 Timer 34 3.3.4 T4 Timer 34 3.3.5 Recommended Defaults and Ranges for the TALI Timers 35 3.4 TALI User Events 35 3.4.1 Management Open Socket Event 35 3.4.2 Management Close Socket Event 36 3.4.3 Management Allow Traffic Event 36 3.4.4 Management Prohibit Traffic Event 36 3.5 Other Implementation Dependent TALI Events 37 3.6 TALI States 37 3.7 TALI Version 1.0 State Machine 38 3.7.1 State Machine Concepts 38 3.7.1.1 General Protocol Rules 38 3.7.1.2 Graceful Shutdown of a Socket 39 3.7.1.3 TALI Protocol Violations 39
1. 导言4 2。TALI协议概述6 2.1传统PSTN SS7网络6 2.2聚合SS7网络8 2.3 TALI协议栈概述10 2.3.1使用SAAL层的备用TALI协议栈13 2.3.2使用SCTP 15 2.4输入到TALI版本1.0状态机15 3的备用TALI协议栈。TALI版本1.0 17 3.1 TALI消息结构概述17 3.1.1 TALI字段类型19 3.2详细TALI消息结构20 3.2.1 TALI对等消息20 3.2.1.1测试消息（测试）20 3.2.1.2允许消息（allo）21 3.2.1.3禁止消息（proh）21 3.2.1.4禁止确认消息（proa）21 3.2.1.5监视消息（moni）22 3.2.1.6监视器确认消息（mona）22 3.2.2服务消息23 3.2.2.1 SCCP服务消息（SCCP）23 3.2.2.1.1使用TALI 25 3.2.2.2 ISUP服务消息（isot）27 3.2.2.1使用TALI 27 3.2.2.3 MTP3服务消息（MTP3）的ISUP封装28 3.2.2.3.1使用TALI 29 3.2.2.4 SAAL服务消息（SAAL）封装MTP330 3.2.2.4.1使用TALI 31 3.3 TALI定时器34 3.3.1 T1定时器34 3.3.2 T2定时器34 3.3.3 T3定时器34 3.3.4 T4定时器34 3.3.5 TALI定时器35 3.4 TALI用户事件35 3.4.1管理打开套接字事件35 3.4.2管理关闭套接字事件36 3.4.3管理允许流量事件36 3.4.4管理禁止流量事件36 3.5其他依赖于实现的TALI事件37 3.6 TALI状态37 3.7 TALI版本1.0状态机38 3.7.1状态机概念38 3.7.1.1一般协议规则38 3.7.1.2套接字的正常关闭39 3.7.1.3 TALI协议冲突39
3.7.2 The State Machine 40 3.8 TALI 1.0 Implementation Notes 42 3.8.1 Failure on a TCP/IP Socket 42 3.8.2 Congestion on a TCP/IP Socket 43 3.9 TALI 1.0 Limitations 43 4. TALI Version 2.0 43 4.1 Overview of TALI Version 2.0 Features 45 4.2 TALI Version Identification 47 4.3 Backwards Compatibility 50 4.3.1 Generating Protocol Violations based on Received Messages 53 4.4 Overview of the TALI Message Structure 55 4.4.1 Types of TALI Fields 55 4.5 Detailed TALI Message Structures for New 2.0 Opcodes 58 4.5.1 Management Message (mgmt) 60 4.5.1.1 Routing Key Registration Primitive (rkrp) 61 4.5.1.1.1 RKRP Data Structures 65 4.5.1.1.1.1 Common Fields in all RKRP Messages 65 4.5.1.1.1.2 CIC Based Routing Key Operations 67 4.5.1.1.1.3 SCCP Routing Key Operations 71 4.5.1.1.1.4 DPC-SI, DPC and SI based Routing Key Operations 74 4.5.1.1.1.5 Default Routing Key Operations 76 4.5.1.1.1.6 Support for Multiple RKRP Registration Operations 78 4.5.1.1.1.6.1 Multiple Registrations Support 78 4.5.1.1.1.6.2 Multiple RKRP Operations in a Single Message 80 4.5.1.2 MTP3 Primitive (mtpp) 82 4.5.1.3 Socket Option Registration Primitive (sorp) 87 4.5.2 Extended Service Message (xsrv) 91 4.5.3 Special Message (spcl) 92 4.5.3.1 Special Messages Not Supported (smns) 93 4.5.3.2 Query Message (qury) 93 4.5.3.3 Reply Message (rply) 94 4.5.3.4 Unsolicited Information Message (USIM) 95 4.6 TALI Timers 95 4.7 TALI User Events 95 4.8 TALI States 96 4.9 TALI Version 2.0 State Machine 96 4.9.1 State Machine Concepts 96 4.9.1.1 General Protocol Rules 96 4.9.1.2 Graceful Shutdown of a Socket 97 4.9.1.3 TALI Protocol Violations 97 4.9.2 The State Machine 97 4.10 TALI 2.0 Specification Limitations 101 5. Success/Failure Codes 101 6. Security Considerations 102 7. References 102 8. Acknowledgments 103 9. Authors' Addresses 104 10. Full Copyright Statement 105
3.7.2 状态机40 3.8 TALI 1.0实现注意到TCP/IP套接字上的42 3.8.1故障42 3.8.2 TCP/IP套接字上的拥塞43 3.9 TALI 1.0限制43 4。TALI版本2.0 43 4.1 TALI版本2.0概述45 4.2 TALI版本标识47 4.3向后兼容性50 4.3.1基于接收到的消息生成协议冲突53 4.4 TALI消息结构概述55 4.4.1 TALI字段类型55 4.5新2.0操作码的详细TALI消息结构58 4.5.1管理消息（mgmt）60 4.5.1.1路由密钥注册原语（rkrp）61 4.5.1.1.1 rkrp数据结构65 4.5.1.1.1.1所有rkrp消息中的公共字段65 4.5.1.1.2基于CIC的路由密钥操作67 4.5.1.1.3 SCCP路由密钥操作71 4.5.1.1.1.4 DPC-SI，基于DPC和SI的路由密钥操作74 4.5.1.1.1.5默认路由密钥操作76 4.5.1.1.1.6支持多个RKRP注册操作78 4.5.1.1.1.6.1多个注册支持78 4.5.1.1.6.2单个消息中的多个RKRP操作80 4.5.1.2 MTP3原语（mtpp）82 4.5.1.3套接字选项注册原语（sorp）87 4.5.2扩展服务消息（xsrv）91 4.5.3特殊消息（spcl）92 4.5.3.1不支持特殊消息（smns）93 4.5.3.2查询消息（qury）93 4.5.3.3回复消息（rply）94 4.5.3.4未经请求的信息消息（USIM）95 4.6 TALI定时器95 4.7 TALI用户事件95 4.8 TALI状态96 4.9 TALI版本2.0状态机96 4.9.1状态机概念96 4.9.1.1一般协议规则96 4.9.1.2套接字正常关机97 4.9.1.3 TALI协议冲突97 4.9.2状态机97 4.10 TALI 2.0规范限制101 5。成功/失败代码101 6。安全考虑102 7。参考文献102 8。致谢103 9。作者地址104 10。完整版权声明105
This document is organized into the following 6 sections:
本文件分为以下6个部分：
- Introduction to the document - Overview of the TALI Protocol - TALI Version 1.0 - TALI Version 2.0 - Success/Failure Codes - Security Considerations
- 文件简介-TALI协议概述-TALI版本1.0-TALI版本2.0-成功/失败代码-安全注意事项
The following terms are used throughout this document.
本文件中使用了以下术语。
Circuit Identification Code (CIC): A field identifying the circuit being setup or released. Depending on SI and MSU Type, this field can be 12, 14 or 32 bits.
电路识别码（CIC）：识别正在设置或释放的电路的字段。根据SI和MSU类型，该字段可以是12、14或32位。
Changeover/Changeback (co/cb): SS7 MTP3 procedure related to link failure and re-establishment.
转换/恢复（co/cb）：与链路故障和重建相关的SS7 MTP3程序。
Far End (FE): The remote endpoint of a socket connection.
远端（FE）：套接字连接的远程端点。
Far End Allowed (FEA): The FE is ready to use the socket for service PDUs.
允许远端（FEA）：FE已准备好将插座用于维修PDU。
Far End Prohibited (FEP): The FE is not ready to use the socket for service PDUs.
远端禁止（FEP）：FE未准备好将插座用于服务PDU。
Intelligent Network (IN): A network that allows functionality to be distributed flexibly at a variety of nodes on and off the network and allows the architecture to be modified to control the services.
智能网络（IN）：一种允许在网络上和网络外的各种节点上灵活分布功能并允许修改体系结构以控制服务的网络。
Management ATM Adaptation Layer (MAAL): This layer is a component of SAAL. This layer maps requests and indications between the System Management for the SG and the other SAAL layers. MAAL includes interfaces to/from SSCOP, SSCF, and system management. More information can be found in T1.652.
管理ATM适配层（MAAL）：该层是SAAL的一个组件。该层映射SG系统管理层和其他SAAL层之间的请求和指示。MAAL包括与SSCOP、SSCF和系统管理的接口。更多信息可在T1.652中找到。
Media Gateway (MG): A MG terminates SCN media streams, packetizes the media data, if it is not already packetized, and delivers packetized traffic to the packet network. It performs these functions in reverse order for media streams flowing from the packet network to the SCN.
媒体网关（MG）：MG终止SCN媒体流，对尚未打包的媒体数据进行打包，并将打包的流量传送到分组网络。对于从分组网络流向SCN的媒体流，它以相反的顺序执行这些功能。
Media Gateway Controller (MGC): An MGC handles the registration and management of resources at the MG. The MGC may have the ability to authorize resource usage based on local policy. For signaling transport purposes, the MGC serves as a possible termination and origination point for SCN application protocols, such as SS7 ISDN User Part and Q.931/DSS1.
媒体网关控制器（MGC）：MGC处理MG上资源的注册和管理。MGC可以基于本地策略授权资源使用。出于信令传输目的，MGC充当SCN应用协议（如SS7 ISDN用户部分和Q.931/DSS1）的可能终止点和发起点。
MTP3 Framing (MTP3F): TALI does not require full MTP3 procedures support but rather uses the MTP3 framing structure (ie: SIO, Routing Label, etc)
MTP3框架（MTP3F）：TALI不需要完整的MTP3程序支持，而是使用MTP3框架结构（即SIO、路由标签等）
Near End (NE): The local endpoint of a socket connection.
近端（NE）：套接字连接的本地端点。
Near End Allowed (NEA): The NE is ready to use the socket for service PDUs.
允许近端（NEA）：网元已准备好将套接字用于服务PDU。
Near End Prohibited (NEP): The NE is not ready to use the socket for service PDUs.
禁止近端（NEP）：网元未准备好将套接字用于服务PDU。
Q.BICC ISUP: An ISUP+ variant that uses 32 bit CIC codes instead of 14/12 bit CIC codes. ISUP+, or Q.BICC ISUP, is based on the Q.765.BICC specification currently being developed in ITU Study Group 11.
Q.BICC ISUP：一种ISUP+变体，使用32位CIC代码而不是14/12位CIC代码。ISUP+，或Q.BICC ISUP，基于ITU第11研究组目前正在开发的Q.765.BICC规范。
Signaling ATM Adaptation Layer (SAAL): This layer is the equivalent of MTP-2 for ATM High Speed Links carrying SS7 Traffic as described in GR-2878-CORE [8]. SAAL includes SSCF, SSCOP and MAAL.
信令ATM适配层（SAAL）：该层相当于承载SS7业务的ATM高速链路的MTP-2，如GR-2878-CORE[8]所述。SAAL包括SSCF、SSCOP和MAAL。
Signaling Gateway (SG): An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. The SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MGC/MG functions to process SCN signaling associated with line or trunk terminations controlled by the MG (e.g., signaling backhaul).
信令网关（SG）：SG是在IP网络边缘接收/发送SCN本机信令的信令代理。SG功能可以中继、转换或终止SS7互联网网关中的SS7信令。SG功能还可以与MGC/MG功能共存，以处理与MG控制的线路或中继终端相关联的SCN信令（例如，信令回程）。
Service Specific Coordination Function (SSCF): This layer is a component of SAAL. This layer maps the services provided by the lower layers of the SAAL to the needs of a specific higher layer user. In the case of the STP, the higher layer user is the MTP-3 protocol, and the SSCF required is that as defined by T1.645: SSCF for Support of Signaling at the Network Node Interface (SSCF at the NNI). More information can be found in T1.645. SSCF provides the interface between SSCOP and MTP3 and includes the following functions:
特定于服务的协调功能（SSCF）：该层是SAAL的一个组件。该层将SAAL的较低层提供的服务映射到特定的较高层用户的需求。在STP的情况下，上层用户是MTP-3协议，所需的SSCF是T1.645中定义的支持网络节点接口信令的SSCF（NNI的SSCF）。更多信息可在T1.645中找到。SSCF提供SSCOP和MTP3之间的接口，包括以下功能：
- Local Retrieve of messages to support link changeover procedures - Flow control with four levels of congestion
- 本地检索消息以支持链路切换程序-具有四级拥塞的流量控制
Switched Circuit Network (SCN): The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.
交换电路网络（SCN）：术语SCN用于指在预定义大小的信道化承载内承载业务的网络。示例包括公共交换电话网络（PSTN）和公共陆地移动网络（PLMN）。SCN中使用的信令协议示例包括Q.931、SS7 MTP级别3和SS7应用程序/用户部分。
Service Specific Connection Oriented Protocol (SSCOP): This layer is a component of SAAL. This layer provides reliable point to point data transfer with sequence integrity and error recovery by selective retransmission. Protocol layer interfaces are described in T1.637. Aspects of the protocol include flow control, connection control, error reporting to layer management, connection maintenance in the prolonged absence of data transfer, local data retrieval by the user of the SSCOP, error detection of protocol control information and status reporting. SSCOP provides the link layer functions that are:
特定于服务的面向连接协议（SSCOP）：该层是SAAL的一个组件。该层提供可靠的点对点数据传输，具有序列完整性，并通过选择性重传进行错误恢复。T1.637中描述了协议层接口。协议的各个方面包括流量控制、连接控制、向层管理报告错误、在长时间不进行数据传输时的连接维护、SSCOP用户的本地数据检索、协议控制信息的错误检测和状态报告。SSCOP提供以下链路层功能：
- In-Sequence Delivery - Flow Control - Error Detection/Correction - Keep Alive - Local Data Retrieval - Connection Control - Protocol Error Detection and Recovery
- 顺序交付-流量控制-错误检测/纠正-保持活动状态-本地数据检索-连接控制-协议错误检测和恢复
Signaling Transfer Point (STP): Packet switches that provide CCS message routing and transport. They are stored programmed switches that use information contained in the message in conjunction with information stored in memory to route the message to the appropriate destination signaling point.
信令传输点（STP）：提供CCS消息路由和传输的分组交换机。它们是存储的编程交换机，使用消息中包含的信息以及存储在内存中的信息将消息路由到适当的目标信令点。
The traditional PSTN SS7 network consists of 3 types of devices connected via dedicated SS7 signaling links.
传统的PSTN SS7网络由3种通过专用SS7信令链路连接的设备组成。
The 3 primary device types for PSTN networks are:
PSTN网络的3种主要设备类型为：
* SSP: Signaling Service Point. These nodes act as endpoints in the SS7 network, originating SS7 messages as users attempt to place phone calls. These nodes contain interfaces into the SS7 data network and the SS7 voice network.
* SSP：信令服务点。这些节点充当SS7网络中的端点，在用户尝试拨打电话时发出SS7消息。这些节点包含到SS7数据网络和SS7语音网络的接口。
* STP: Signaling Transfer Point. These nodes act primarily as switches, switching SS7 traffic from node to node throughout the network until it reaches another endpoint. An important feature of each STP is to provide SS7 network management functionality that allows messages to be delivered even when links and devices fail. STPs also sometimes provide database type services, such as Global Title Translations and Local Number Portability.
* STP：信令传输点。这些节点主要充当交换机，在整个网络中从一个节点切换到另一个节点，直到到达另一个端点。每个STP的一个重要功能是提供SS7网络管理功能，允许在链路和设备出现故障时发送消息。STP有时还提供数据库类型的服务，如全局标题翻译和本地号码可移植性。
* SCP: Signaling Control Point. These nodes act as databases. These nodes contain stored data that is used to turn SS7 Queries into SS7 Replies.
* 信号控制点。这些节点充当数据库。这些节点包含用于将SS7查询转换为SS7应答的存储数据。
There are 3 primary types of dedicated SS7 signaling links:
有3种主要类型的专用SS7信令链路：
* 56Kbps SS7 (DS0, V35, OCU) links. These links implement the MTP-1 and MTP-2 protocols as defined in [1].
* 56Kbps SS7（DS0、V35、OCU）链路。这些链路实现[1]中定义的MTP-1和MTP-2协议。
* DS1 High Speed Links. These links use the SAAL protocol to provide an alternative to 56Kbps SS7 links that is based on newer, faster technology. These links implement the SS7 protocol as defined in [8].
* DS1高速链路。这些链路使用SAAL协议提供基于更新、更快技术的56Kbps SS7链路的替代方案。这些链路实现[8]中定义的SS7协议。
* E1 Links.
* E1链路。
Figure 1 provides an overview of the traditional PSTN network. In this network, any of the links can be implemented via either 56 Kbps, DS1, or E1 links.
图1提供了传统PSTN网络的概览。在该网络中，任何链路都可以通过56 Kbps、DS1或E1链路实现。
^
/ \
/SCP\
/-----\
/ \
/ \
/ \
/ \
/---\ +---+ +---+ /---\
| SSP |-----|STP|----|STP|-----| SSP |
\---/ \ /+-+-+\ /+-+-+ \ / \---/
\/ | \/ | \/
/\ | /\ | /\
/---\ / \+-+-+/ \+-+-+ / \ /---\
| SSP |/----|STP|----|STP|/----| SSP |
\---/ +---+ +---+ \---/
\ /
\ /
\ /
\ ^ /
\/ \/
/SCP\
/-----\
^
/ \
/SCP\
/-----\
/ \
/ \
/ \
/ \
/---\ +---+ +---+ /---\
| SSP |-----|STP|----|STP|-----| SSP |
\---/ \ /+-+-+\ /+-+-+ \ / \---/
\/ | \/ | \/
/\ | /\ | /\
/---\ / \+-+-+/ \+-+-+ / \ /---\
| SSP |/----|STP|----|STP|/----| SSP |
\---/ +---+ +---+ \---/
\ /
\ /
\ /
\ ^ /
\/ \/
/SCP\
/-----\
Figure 1: The Traditional PSTN Network
图1：传统的PSTN网络
In the converged SS7 network, SS7 devices will reside on both the traditional PSTN network (with dedicated 56 Kbps and DS1 links) and on the IP network (with Ethernet links based on IP protocol). The services of SSPs, STPs, and SCPs can be provided by new types of devices that reside on IP networks. The IP network is not intended to completely replace the PSTN, rather devices on the 2 types of networks must be able to communicate with one another and convert from 1 lower layer protocol to the other.
在聚合SS7网络中，SS7设备将驻留在传统PSTN网络（具有专用56 Kbps和DS1链路）和IP网络（具有基于IP协议的以太网链路）上。驻留在IP网络上的新型设备可以提供SSP、STP和SCP服务。IP网络并不打算完全取代PSTN，而是两种网络上的设备必须能够相互通信，并从一种较低层协议转换为另一种协议。
Signaling Gateways are new devices that may also function as an STP in the converged network. SGs provide interfaces to:
信令网关是一种新设备，在融合网络中也可以用作STP。SGs提供以下接口：
* devices on the SCN (traditional SSPs, STPs, and SCPs)
* SCN上的设备（传统SSP、STP和SCP）
* other SGs
* 其他SGs
* new devices on the IP network
* IP网络上的新设备
SGs also continue to perform STP functions such as SS7 network management and some database services (such as GTT and LNP).
SGs还继续执行STP功能，如SS7网络管理和一些数据库服务（如GTT和LNP）。
New devices on the IP network include:
IP网络上的新设备包括：
* Media Gateway Controllers. In addition to other functions, these devices control Media Gateways and perform call processing.
* 媒体网关控制器。除了其他功能外，这些设备还控制媒体网关并执行呼叫处理。
* Media Gateways. In addition to other functions, these devices control voice circuits that are used to carry telephone calls. MGs + MGCs combine to provide the functionality of traditional SSPs.
* 媒体网关。除了其他功能外，这些设备还控制用于承载电话呼叫的语音电路。MGs+MGC结合起来提供传统SSP的功能。
* IP based SCPs. The database services that are related to SS7 can be moved onto devices on the IP network.
* 基于IP的SCP。与SS7相关的数据库服务可以移动到IP网络上的设备上。
Figure 2 provides an overview of the converged SS7 network.
图2提供了聚合SS7网络的概述。
----- +----+
/\ / \-------------| SG |
/ \----| SCN | +----+ +----+
/SCP \ \ /------| SG | |
------ ----- +----+ |
| | | |
| | | |
| | -----
| | / \ /\
| | | IP |----/ \
| /---\ \ / /SCP \
| | SSP | ----- ------
| \---/ / \
| | / \
/---\ | / \
| SSP | | +---+ +---+
\---/ +----+ |MGC| |MGC|
| | MG | +---+ +---+
| +----+\ \ /
| \ \ /
| \ -----
| \ / \
+----+ | IP |
| MG |-----------\ /
+----+ -----
----- +----+
/\ / \-------------| SG |
/ \----| SCN | +----+ +----+
/SCP \ \ /------| SG | |
------ ----- +----+ |
| | | |
| | | |
| | -----
| | / \ /\
| | | IP |----/ \
| /---\ \ / /SCP \
| | SSP | ----- ------
| \---/ / \
| | / \
/---\ | / \
| SSP | | +---+ +---+
\---/ +----+ |MGC| |MGC|
| | MG | +---+ +---+
| +----+\ \ /
| \ \ /
| \ -----
| \ / \
+----+ | IP |
| MG |-----------\ /
+----+ -----
Figure 2: The Converged SS7 Network
图2：聚合SS7网络
In theory, the TALI protocol can be used between 2 nodes to carry SS7 traffic across TCP/IP. Some of the areas that TALI could be used include:
理论上，可以在两个节点之间使用TALI协议来跨TCP/IP承载SS7流量。TALI可以使用的一些领域包括：
- For SG to SG communication across IP - For SG to MGC communication across IP - For SG to IP based SCP communication across IP - For communication between multiple IP based SCPs - For communication between multiple MGCs - For communication between MGCs and MGs - For other IP devices such as DNS, Policy Servers, etc.
- 对于通过IP的SG到SG通信-对于通过IP的SG到MGC通信-对于通过IP的SG到IP的SCP通信-对于多个基于IP的SCP之间的通信-对于多个MGC之间的通信-对于MGC和MGs之间的通信-对于其他IP设备，如DNS、策略服务器等。
In reality, the communication between MGCs, or between MGC and MG is probably better suited to using other protocols. With respect to the Signaling Gateway implementation, the TALI protocol is used to carry SS7 traffic:
实际上，MGC之间或MGC与MG之间的通信可能更适合使用其他协议。关于信令网关实现，TALI协议用于承载SS7流量：
- For SG to SG communication - For SG to MGC communication - For SG to IP based SCP communication
- 对于SG-to-SG通信-对于SG-to-MGC通信-对于SG-to-IP-based SCP通信
The Transport Adapter Layer Interface is the proposed interface that provides SCCP, ISUP, and MTP messaging encapsulation within a TCP/IP packet between two switching elements. In addition, TALI provides SCCP Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.
传输适配器层接口是提议的接口，它在两个交换元件之间的TCP/IP数据包内提供SCCP、ISUP和MTP消息封装。此外，TALI还提供SCCP管理（SCMG）、MTP原语、电路动态注册以及基于电路位置的呼叫控制消息路由。
The major purpose of the TALI protocol is to provide a bridge between the SS7 Signaling Network and applications that reside within an IP network. Figure 3 provides a simple illustration that highlights the protocol stacks used for transport of SS7 MSUs on both the SS7 side and the IP side of the SG.
TALI协议的主要目的是在SS7信令网络和驻留在IP网络内的应用程序之间提供桥梁。图3提供了一个简单的示例，突出显示了用于在SG的SS7侧和IP侧传输SS7 MSU的协议栈。
SS7 traffic SS7 traffic
via 56Kbps links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 traffic SS7 traffic
via 56Kbps links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 SS7, TALI, TCP/IP
protocol stack protocol stack
+---------------+ +---------------+
|SS7 application| |SS7 application|
|layer | |layer |
+-------+-------+ +-------+-------+
| TCAP | ISUP | | TCAP | ISUP |
+-------+ | +-------+ |
| SCCP | | | SCCP | |
+-------+-------+ +-------+-------+
| MTP3 | | MTP3 |
+---------------+ +---------------+
| MTP2 | | TALI |
+---------------+ +---------------+
| MTP1 | | TCP |
| (& phy. | +---------------+
| layer) | | IP |
+---------------+ +---------------+
| MAC |
| (& phy. |
| layer) |
+---------------+
SS7 SS7, TALI, TCP/IP
protocol stack protocol stack
+---------------+ +---------------+
|SS7 application| |SS7 application|
|layer | |layer |
+-------+-------+ +-------+-------+
| TCAP | ISUP | | TCAP | ISUP |
+-------+ | +-------+ |
| SCCP | | | SCCP | |
+-------+-------+ +-------+-------+
| MTP3 | | MTP3 |
+---------------+ +---------------+
| MTP2 | | TALI |
+---------------+ +---------------+
| MTP1 | | TCP |
| (& phy. | +---------------+
| layer) | | IP |
+---------------+ +---------------+
| MAC |
| (& phy. |
| layer) |
+---------------+
Figure 3: TALI Protocol to carry SS7 over TCP/IP
图3：通过TCP/IP承载SS7的TALI协议
From Figure 3, several observations can be made:
从图3中可以观察到以下几点：
* The TALI layer is used when transferring SS7 over IP.
* 通过IP传输SS7时使用TALI层。
* When SS7 traffic is carried over a IP network, the MTP2 and MTP1 layers of a traditional 56 Kbps link are replaced by the TALI, TCP, IP, and MAC layers
* 当SS7流量通过IP网络传输时，传统56 Kbps链路的MTP2和MTP1层被TALI、TCP、IP和MAC层所取代
* The TALI layer sits on top of the TCP layer.
* TALI层位于TCP层的顶部。
* The TALI layer sits below the various SS7 layers (MTP3, SCCP/TCAP, ISUP, and applications). The data from these SS7 layers is carried as the data portion of TALI service data packets.
* TALI层位于各种SS7层（MTP3、SCCP/TCAP、ISUP和应用程序）的下方。来自这些SS7层的数据作为TALI服务数据包的数据部分携带。
Some of the facts concerning the TALI protocol which are important to understanding how TALI works that are not evident from Figure 3 include the following:
关于TALI协议的一些事实，对于理解TALI如何工作很重要，但从图3中看不清楚，包括：
* Each TALI connection is provided over a single TCP socket.
* 每个TALI连接通过单个TCP套接字提供。
* The standard Berkeley sockets interface to the TCP is used by the TALI layer to provide connection oriented service from endpoint to peer endpoint.
* TALI层使用TCP的标准Berkeley套接字接口提供从端点到对等端点的面向连接的服务。
* TCP sockets are based on a Client/Server architecture; one end of the TALI connection must be defined as the 'server side', the other end is a 'client'.
* TCP套接字基于客户机/服务器体系结构；TALI连接的一端必须定义为“服务器端”，另一端是“客户端”。
* The client/server roles are important only in bringing up the TCP connection between the 2 endpoint, once the connection is established both ends use the same Berkeley sockets calls (send, recv) to transfer data.
* 客户机/服务器角色仅在建立两个端点之间的TCP连接时才重要，一旦连接建立，两端使用相同的Berkeley套接字调用（send、recv）传输数据。
* The TCP socket must be connected before the 2 TALI endpoints can begin communicating.
* 必须先连接TCP套接字，然后2个TALI端点才能开始通信。
* TALI provides user control over each TALI connection that is defined. This control:
* TALI为用户提供对定义的每个TALI连接的控制。此控件：
* Allows the user to control when each TALI connection will be made
* 允许用户控制何时进行每个TALI连接
* Allows the user to control when each TALI connection is allowed to carry SS7 traffic
* 允许用户控制何时允许每个TALI连接承载SS7流量
* Allows the user to control the graceful shutdown of each socket
* 允许用户控制每个套接字的正常关闭
* TALI provides Peer to Peer messages. These messages originate from the TALI layer of one endpoint of the connection and are terminated at the TALI layer of the other endpoint. Peer to Peer messages are used:
* TALI提供对等消息。这些消息来自连接的一个端点的TALI层，并在另一个端点的TALI层终止。使用对等消息：
* To provide test and watchdog maintenance messages
* 提供测试和看门狗维护信息
* To control the ability of each socket to carry SS7 service messages
* 控制每个套接字承载SS7服务消息的能力
* TALI provides Service messages. These messages originate from the layer above the TALI layer of one endpoint of the connection and are transferred to and terminated at the layer above the TALI layer of the other endpoint.
* TALI提供服务消息。这些消息来自连接的一个端点的TALI层之上的层，并传输到另一个端点的TALI层之上的层并在该层终止。
* The service messages provide several different ways to encapsulate the SS7 messages (SCCP/TCAP, ISUP, and other MTP3 layer data) across the TCP/IP connection.
* 服务消息提供了几种不同的方式来封装跨TCP/IP连接的SS7消息（SCCP/TCAP、ISUP和其他MTP3层数据）。
* As we will see later, different Service opcodes are used to communicate across the TALI socket exactly how each SS7 message has been encapsulated.
* 正如我们稍后将看到的，不同的服务操作码用于通过TALI套接字进行通信，确切地说是如何封装每个SS7消息的。
* A set of TALI timers is defined. These timers are used to correctly implement the TALI state machine.
* 定义了一组TALI定时器。这些定时器用于正确实现TALI状态机。
This section presents a different, slightly more complex, TALI protocol stack that can be used in place of the protocol stack in the previous section.
本节介绍了一个不同的、稍微复杂一点的TALI协议栈，它可以代替上一节中的协议栈。
Figure 3 in the previous section provided a simple illustration that highlighted the basic TALI protocol stack that can be used to transport SS7 MSUs between 56 Kbps links on the SS7 side of an SG and the IP devices.
上一节中的图3提供了一个简单的示例，突出显示了基本的TALI协议栈，该协议栈可用于在SG的SS7侧和IP设备上的56 Kbps链路之间传输SS7 MSU。
Figure 4 below illustrates an alternate TALI protocol stack that includes the SAAL layer as part of the data transferred across the TCP/IP connection.
下面的图4说明了另一个TALI协议栈，该协议栈将SAAL层作为通过TCP/IP连接传输的数据的一部分。
SS7 traffic SS7 traffic
via DS1 links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 traffic SS7 traffic
via DS1 links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 DS1 SS7, TALI, TCP/IP
protocol stack protocol stack
+-----------------+ +-----------------+
| SS7 application | | SS7 application |
| layer | | layer |
+--------+--------+ +--------+--------+
| TCAP | ISUP | | TCAP | ISUP |
+--------+ | +--------+ |
| SCCP | | | SCCP | |
+--------+--------+ +--------+--------+
| MTP3 | | MTP3 |
+-----------------+ +-----------------+
| SAAL | | SAAL |
|(SSCF,MAAL,SSCOP)| |(SSCF,MAAL,SSCOP)|
+-----------------+ +-----------------+
| AAL5 | | TALI |
+-----------------+ +-----------------+
| ATM | | TCP |
| (& phy. | +-----------------+
| layer) | | IP |
+-----------------+ +-----------------+
| MAC |
| (& phy. |
| layer) |
+-----------------+
SS7 DS1 SS7, TALI, TCP/IP
protocol stack protocol stack
+-----------------+ +-----------------+
| SS7 application | | SS7 application |
| layer | | layer |
+--------+--------+ +--------+--------+
| TCAP | ISUP | | TCAP | ISUP |
+--------+ | +--------+ |
| SCCP | | | SCCP | |
+--------+--------+ +--------+--------+
| MTP3 | | MTP3 |
+-----------------+ +-----------------+
| SAAL | | SAAL |
|(SSCF,MAAL,SSCOP)| |(SSCF,MAAL,SSCOP)|
+-----------------+ +-----------------+
| AAL5 | | TALI |
+-----------------+ +-----------------+
| ATM | | TCP |
| (& phy. | +-----------------+
| layer) | | IP |
+-----------------+ +-----------------+
| MAC |
| (& phy. |
| layer) |
+-----------------+
Figure 4: An Alternate TALI Protocol Stack with SAAL
图4：使用SAAL的替代TALI协议栈
The following bullets provide a discussion regarding the differences between these 2 protocol stacks, the reasons for having 2 protocol stacks, and the advantages of each:
以下项目介绍了这两个协议栈之间的差异、拥有两个协议栈的原因以及每个协议栈的优点：
* When the TALI protocol stack is implemented without the SAAL layer, as in Figure 3, the SEQUENCE NUMBER of the SS7 MSU is NOT part of the data transferred across the TCP/IP connection. In 56 Kbps SS7 links, the MTP2 header contains an 8 bit sequence number for each MSU. The sequence number is used to preserve message sequencing and to support complex SS7 procedures involving MSU retrieval during link changeover and changeback. As indicated in Figure 3, the MTP2 header is NOT part of the data transferred
* 当TALI协议栈在没有SAAL层的情况下实现时，如图3所示，SS7 MSU的序列号不是通过TCP/IP连接传输的数据的一部分。在56 Kbps SS7链路中，MTP2报头包含每个MSU的8位序列号。序列号用于保留消息序列，并支持复杂的SS7过程，包括链路切换和回切期间的MSU检索。如图3所示，MTP2头不是传输的数据的一部分
across the TCP/IP connection. The TALI protocol stack without SAAL still guarantees correct sequencing of SS7 data (this sequencing is provided by sequence numbers in the TCP layer), however that protocol stack can not support SS7 changeover and changeback procedures.
通过TCP/IP连接。没有SAAL的TALI协议栈仍然保证SS7数据的正确排序（该排序由TCP层中的序列号提供），但是该协议栈不能支持SS7转换和回切过程。
* When the TALI protocol stack is implemented with the SAAL layer, as in Figure 4, the SEQUENCE NUMBER of the SS7 MSU IS part of the data transferred across TCP/IP. In SS7 DS1 links, the SSCOP trailer contains a 24 bit sequence number for each MSU. This 24 bit sequence number serves the same purposes as the 8 bit SS7 sequence number. As indicated in Figure 4, the SSCOP trailer IS part of the data transferred across the TCP/IP connection. The protocol stack in Figure 4 can support SS7 changeover and changeback procedures.
* 当使用SAAL层实现TALI协议栈时，如图4所示，SS7 MSU的序列号是通过TCP/IP传输的数据的一部分。在SS7 DS1链路中，SSCOP拖车包含每个MSU的24位序列号。该24位序列号的用途与8位SS7序列号相同。如图4所示，SSCOP拖车是通过TCP/IP连接传输的数据的一部分。图4中的协议栈可以支持SS7转换和回切过程。
* Implementing the TALI protocol with SAAL therefore provides support for SS7 co/cb and data retrieval and can help to minimize MSU loss as SS7 links are deactivated. However, implementing SAAL is not a trivial matter. The SAAL layer consists of 3 sublayers (SSCF, SSCOP, and MAAL), one of which (SSCOP) is quite involved. It is envisioned that most SS7 to TCP/IP applications will NOT choose to implement SAAL.
* 因此，通过SAAL实现TALI协议可为SS7 co/cb和数据检索提供支持，并有助于在SS7链路停用时将MSU损失降至最低。然而，实现SAAL并不是一件小事。SAAL层由3个子层（SSCF、SSCOP和MAAL）组成，其中一个子层（SSCOP）相当复杂。可以预见，大多数SS7到TCP/IP应用程序不会选择实现SAAL。
The TALI protocol is dependent on a reliable transport layer below it. At the initial design of TALI, TCP was the only reliable, proven transport layer. Simple Control Transport Protocol (SCTP) is currently being designed as a transport later specifically for signalling. Once SCTP is a proven and accepted transport protocol, SCTP can then be used in place of TCP as shown in Figures 3 and 4.
TALI协议依赖于它下面的可靠传输层。在TALI的初始设计中，TCP是唯一可靠、经验证的传输层。简单控制传输协议（SCTP）目前被设计为一种传输协议，以后专门用于信令。一旦SCTP是一种经过验证和认可的传输协议，就可以使用SCTP代替TCP，如图3和图4所示。
Figure 5 illustrates the inputs that affect the TALI State Machine. Inputs to the state machine include:
图5说明了影响TALI状态机的输入。状态机的输入包括：
* Management events (ie: requests from the human user of the TALI connection) to control the operation of a particular TALI session.
* 管理事件（即：TAI连接的人工用户的请求），以控制特定TAI会话的操作。
* TALI messages received from the Peer. These messages include peer to peer messages as well as service data messages.
* 从对等方接收的TALI消息。这些消息包括对等消息以及服务数据消息。
* Events from the User of the TALI layer. The user is the layer above TALI in the protocol stack, either the SS7 or SAAL layer.
* 来自TALI层用户的事件。用户是协议栈中TALI上面的层，SS7或SAAL层。
* Implementation Dependent Events. Each implementation must provide inputs into the TALI state machine such as:
* 依赖于实现的事件。每个实现必须向TALI状态机提供输入，例如：
* Socket Events
* 套接字事件
* TALI protocol violations. The TALI state machine must detect protocol violations and act accordingly.
* 违反TALI协议。TALI状态机必须检测协议冲突并相应地采取行动。
* Timer events.
* 计时器事件。
+====+ +============+
| | +---------+ +-------------+ | |
|User| | Service | | Mgmt. Open | | MANAGEMENT |
|Part|<-->| Message | | Mgmt. Close |<-->| |
| | | | | Mgmt. Proh. | | |
| | +---------+ | Mgmt. Allow | +============+
+====+ ^ +-------------+
| ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
| | | |
v | | |
+---------+ +-----------------+ +-----------+ +------------+
| Received| | Connection est. | | Protocol | | T1 Expired |
| 'test' | | Connection lost | | Violation | | T2 Expired |
| 'allo' | | | | | | T3 Expired |
| 'proh' | +-----------------+ +-----------+ | T4 Expired |
| 'proa' | ^ ^ +------------+
| 'moni' | | | ^
| 'mona' | | | |
| or | | | |
| Service | | | |
| Message | +========================================+
+---------+ | IMPLEMENTATION |
^ | DEPENDENT |
| +========================================+
|
v
+============+
| PEER |
| |
+============+
+====+ +============+
| | +---------+ +-------------+ | |
|User| | Service | | Mgmt. Open | | MANAGEMENT |
|Part|<-->| Message | | Mgmt. Close |<-->| |
| | | | | Mgmt. Proh. | | |
| | +---------+ | Mgmt. Allow | +============+
+====+ ^ +-------------+
| ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
| | | |
v | | |
+---------+ +-----------------+ +-----------+ +------------+
| Received| | Connection est. | | Protocol | | T1 Expired |
| 'test' | | Connection lost | | Violation | | T2 Expired |
| 'allo' | | | | | | T3 Expired |
| 'proh' | +-----------------+ +-----------+ | T4 Expired |
| 'proa' | ^ ^ +------------+
| 'moni' | | | ^
| 'mona' | | | |
| or | | | |
| Service | | | |
| Message | +========================================+
+---------+ | IMPLEMENTATION |
^ | DEPENDENT |
| +========================================+
|
v
+============+
| PEER |
| |
+============+
Figure 5: Overview of Inputs to the TALI 1.0 State Machine
图5:TALI 1.0状态机输入概览
This chapter provides the states, messages, message exchange rules and state machine that must be implemented to provide a TALI version 1.0 protocol layer.
本章提供必须实现的状态、消息、消息交换规则和状态机，以提供TALI版本1.0协议层。
Table 2 provides a summary of the messages and message structure used in TALI version 1.0.
表2总结了TALI版本1.0中使用的消息和消息结构。
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack | | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service over TALI | | 'isot' | |
| | MTP3 Service over TALI | | 'mtp3' | |
| | Service over SAAL | | 'saal' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor message| | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack | | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service over TALI | | 'isot' | |
| | MTP3 Service over TALI | | 'mtp3' | |
| | Service over SAAL | | 'saal' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor message| | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
Table 2: Message Structure for TALI 1.0
表2:TALI 1.0的消息结构
Table 3 indicates the valid values of the LENGTH field for each version 1.0 opcode. The LENGTH field is always an indication of the # of bytes contained in the DATA PAYLOAD portion of a general TALI message.
表3显示了每个版本1.0操作码的长度字段的有效值。长度字段始终表示通用TALI消息的数据有效负载部分中包含的字节数。
+------------------------------------------------------------------+
| OPCODE | VALID LENGTH VALUES | COMMENTS |
+------------------------------------------------------------------+
| test | 0 bytes | |
+------------------------------------------------------------------+
| allo | 0 bytes | |
+------------------------------------------------------------------+
| proh | 0 bytes | |
+------------------------------------------------------------------+
| proa | 0 bytes | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | A maximum length is provided so |
| | | that the maximum ethernet frame |
| | | size is not exceeded. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | Mona reply length and content must|
| | | match the original moni (with the |
| | | exception of the opcode) |
+------------------------------------------------------------------+
| sccp | 12-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT |
| | | MSUs |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte, the MTP3 routing |
| | | label, the CIC code, and the |
| | | ISUP Message Type field, and any |
| | | other bytes that may exist as part|
| | | of the SIF (Service Information |
| | | Field) |
+------------------------------------------------------------------+
| mtp3 | 5-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and the MTP3 routing |
| | | labeld, and any other bytes that |
| | | may exist as part of the SIF |
| | | (Service Information Field) |
+------------------------------------------------------------------+
| saal | 11-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and all bytes in the |
| | | SIF (Service Information Field) |
| | | field. The MTP3 routing label is |
| | | part of the SIF field. Seven (7) |
+------------------------------------------------------------------+
| OPCODE | VALID LENGTH VALUES | COMMENTS |
+------------------------------------------------------------------+
| test | 0 bytes | |
+------------------------------------------------------------------+
| allo | 0 bytes | |
+------------------------------------------------------------------+
| proh | 0 bytes | |
+------------------------------------------------------------------+
| proa | 0 bytes | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | A maximum length is provided so |
| | | that the maximum ethernet frame |
| | | size is not exceeded. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | Mona reply length and content must|
| | | match the original moni (with the |
| | | exception of the opcode) |
+------------------------------------------------------------------+
| sccp | 12-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT |
| | | MSUs |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte, the MTP3 routing |
| | | label, the CIC code, and the |
| | | ISUP Message Type field, and any |
| | | other bytes that may exist as part|
| | | of the SIF (Service Information |
| | | Field) |
+------------------------------------------------------------------+
| mtp3 | 5-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and the MTP3 routing |
| | | labeld, and any other bytes that |
| | | may exist as part of the SIF |
| | | (Service Information Field) |
+------------------------------------------------------------------+
| saal | 11-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and all bytes in the |
| | | SIF (Service Information Field) |
| | | field. The MTP3 routing label is |
| | | part of the SIF field. Seven (7) |
| | | octets of SSCOP trailer is added |
| | | to the message. The SSCOP trailer|
| | | bytes are also included in the |
| | | length. |
+------------------------------------------------------------------+
| | | octets of SSCOP trailer is added |
| | | to the message. The SSCOP trailer|
| | | bytes are also included in the |
| | | length. |
+------------------------------------------------------------------+
Table 3: Valid Length Fields for Each Opcode in TALI 1.0
表3:TALI 1.0中每个操作码的有效长度字段
Several field types are used in the general TALI message structure.
通用TALI消息结构中使用了几种字段类型。
+------------------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|4 byte | * 4 byte ASCII text strings are used to define the |
|ASCII text | sync code and the opcode of the basic TALI message.|
| | * These fields are case sensitive, the coding for |
| | each sync and opcode literal needs to match the |
| | case specified in Table 2. |
| | * The standard ASCII conversion table is used to |
| | transform each character into a byte. |
| | * The order of the ASCII characters is important. |
| | The first character in the string must be the |
| | first character transmitted across the wire. |
| | * For example, if the string being encoded is 'abCD',|
| | the order of the bytes as they are transferred |
| | over the wire must be: |
| | 1st byte: 0x61 ('a') 3rd byte: 0x43 ('C') |
| | 2nd byte: 0x62 ('b') 4th byte: 0x44 ('D') |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Integer | * A 1, 2 or 4 byte field to be treated as an integer |
| | value. Integer fields should be transmitted Least |
| | Significant Byte first across the wire. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Variable | * The definition of the message structure for this |
| | field is governed by other specifications. |
| | * For example, when transferring MTP3 service data |
+------------------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|4 byte | * 4 byte ASCII text strings are used to define the |
|ASCII text | sync code and the opcode of the basic TALI message.|
| | * These fields are case sensitive, the coding for |
| | each sync and opcode literal needs to match the |
| | case specified in Table 2. |
| | * The standard ASCII conversion table is used to |
| | transform each character into a byte. |
| | * The order of the ASCII characters is important. |
| | The first character in the string must be the |
| | first character transmitted across the wire. |
| | * For example, if the string being encoded is 'abCD',|
| | the order of the bytes as they are transferred |
| | over the wire must be: |
| | 1st byte: 0x61 ('a') 3rd byte: 0x43 ('C') |
| | 2nd byte: 0x62 ('b') 4th byte: 0x44 ('D') |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Integer | * A 1, 2 or 4 byte field to be treated as an integer |
| | value. Integer fields should be transmitted Least |
| | Significant Byte first across the wire. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Variable | * The definition of the message structure for this |
| | field is governed by other specifications. |
| | * For example, when transferring MTP3 service data |
| | via a 'mtp3' opcode, the DATA PAYLOAD begins with |
| | the SIO byte of the MTP3 routing label. The |
| | structure for the entire DATA PAYLOAD is governed |
| | by the MTP3 message structure defined in [1]. |
+------------------------------------------------------------------+
|X byte | * ASCII text fields of sizes other than 4 bytes |
|ASCII text | should be supported according to the same rules |
| | presented for the 4 byte ASCII text fields. For |
| | instance, an 8 byte string such as 'ab01cd23' could|
| | be used, where the 'a' would be the first byte of |
| | the field transmitted out the wire. |
+------------------------------------------------------------------+
| | via a 'mtp3' opcode, the DATA PAYLOAD begins with |
| | the SIO byte of the MTP3 routing label. The |
| | structure for the entire DATA PAYLOAD is governed |
| | by the MTP3 message structure defined in [1]. |
+------------------------------------------------------------------+
|X byte | * ASCII text fields of sizes other than 4 bytes |
|ASCII text | should be supported according to the same rules |
| | presented for the 4 byte ASCII text fields. For |
| | instance, an 8 byte string such as 'ab01cd23' could|
| | be used, where the 'a' would be the first byte of |
| | the field transmitted out the wire. |
+------------------------------------------------------------------+
Table 4: Implementation Notes for each Type of TALI field
表4：每种类型TALI字段的实施说明
The following subsections provide more information regarding the TALI Peer to Peer messages that are implemented in version 1.0. The TALI peer to peer messages originate at the TALI layer of 1 end of the socket connection (the near end) and are terminated at the TALI layer of the far end of the connection.
以下小节提供了有关1.0版中实现的TALI对等消息的更多信息。TALI对等消息起源于套接字连接1端（近端）的TALI层，并在连接远端的TALI层终止。
The 'test' message is used by a TALI implementation to query the remote end of the TALI connection with respect to the willingness of the remote end to carry SS7 service data. This message asks the other end: are you ready to carry service data? This message is sent periodically by each TALI implementation based on a T1 timer interval. Upon receiving 'test', a TALI implementation must reply with either 'proh' or 'allo' to indicate the nodes willingness to carry SS7 service data over that TALI connection.
TALI实现使用“测试”消息查询TALI连接的远程端是否愿意承载SS7服务数据。此消息询问另一端：您准备好携带服务数据了吗？该消息由每个TALI实现基于T1定时器间隔定期发送。收到“测试”后，TALI实现必须回复“proh”或“allo”，以表明节点愿意通过该TALI连接承载SS7服务数据。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'test' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'test' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'allo' message is sent in reply to a 'test' query, or in response to some internal implementation event, to indicate that a TALI implementation IS willing to carry SS7 service data over the TALI session. This message informs the far end that SS7 traffic can be transmitted on the socket. 'allo' is one of the 2 possible replies to a 'test' message. Before SS7 traffic can be carried over a socket, both ends of the connection need to send 'allo' messages.
发送“allo”消息是为了响应“test”查询，或者是为了响应某些内部实现事件，以表明TALI实现愿意在TALI会话上承载SS7服务数据。此消息通知远端SS7通信可以在套接字上传输。”allo是对“测试”消息的两种可能回复之一。在SS7通信可以通过套接字传输之前，连接的两端都需要发送“allo”消息。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'allo' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'allo' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'proh' message is sent in reply to a 'test' query, or in response to some internal implementation event, to indicate that a TALI implementation is NOT willing to carry SS7 service data over the TALI session. This message informs the far end that SS7 traffic can not be transmitted on the socket. 'proh' is one of the 2 possible replies to a 'test' message. As long as 1 end of the connection remains in the 'prohibited' state, SS7 traffic can not be carried over the socket.
发送“proh”消息是为了响应“测试”查询，或响应某些内部实施事件，以表明TALI实施不愿意在TALI会话上携带SS7服务数据。此消息通知远端SS7通信无法在套接字上传输。”“proh”是对“测试”消息的两种可能回复之一。只要连接的一端保持“禁止”状态，SS7通信就不能通过插座传输。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proh' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proh' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'proa' message is sent by a TALI implementation each time a 'proh' is received from the far end. This message is sent to indicate to the far end that his 'prohibit' message was received correctly and will be acted on accordingly.
每次从远端接收到“proh”时，TALI实现都会发送“proa”消息。发送此消息是为了向远端表明其“禁止”消息已正确接收，并将相应地采取行动。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proa' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proa' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'moni' message provides a generic ECHO capability that can be used by each TALI implementation as that implementation sees fit. A TALI version 1.0 implementation does not have to originate a 'moni' message to be compliant with the 1.0 specification. The primary intent of this message is to provide a way for the TALI layer to test the round-trip message transfer time on a socket. A 'mona' message must be sent in reply to each received 'moni' message. The DATA portion of a 'moni' message is vendor implementation dependent. The DATA portion of each 'mona' reply must exactly match the DATA portion of the 'moni' that is replied to. Regardless of whether an implementation chooses to send 'moni' or not, 'mona' must be sent in response to each 'moni' in order to remain compliant with the TALI protocol.
“moni”消息提供了通用的回显功能，每个TALI实现都可以在认为合适时使用该功能。TALI 1.0版的实现不必发出“moni”消息，就可以符合1.0规范。此消息的主要目的是为TALI层提供一种在套接字上测试往返消息传输时间的方法。必须发送“mona”消息以回复收到的每条“moni”消息。“moni”消息的数据部分取决于供应商的实现。每个“mona”回复的数据部分必须与被回复的“moni”的数据部分完全匹配。无论实现是否选择发送“moni”，都必须发送“mona”以响应每个“moni”，以保持符合TALI协议。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
As mentioned above, the 'mona' must be sent in reply to each received 'moni'. The contents of the 'mona' DATA area must match the DATA area of the received 'moni' message.
如上所述，“mona”必须发送给每个收到的“moni”。“mona”数据区的内容必须与收到的“moni”消息的数据区匹配。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mona' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mona' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
The following subsections provide more information regarding the TALI Service messages that are implemented in version 1.0. TALI Service messages are used to carry SS7 MSUs across the IP network. The information in this section includes details with respect to how to encapsulate SS7 MSUs into TCP/IP frames using each of the TALI service opcodes. The TALI service messages originate at the layer above TALI, are transported across the IP network via a TALI service message, and are delivered to the layer above TALI at the far end of the TALI connection.
以下小节提供了有关1.0版中实现的TALI服务消息的更多信息。TALI服务消息用于通过IP网络承载SS7 MSU。本节中的信息包括有关如何使用每个TALI服务操作码将SS7 MSU封装到TCP/IP帧的详细信息。TALI服务消息起源于TALI之上的层，通过TALI服务消息通过IP网络传输，并在TALI连接的远端传递到TALI之上的层。
The 'sccp' opcode is used to deliver SS7 MSUs with a Service Indicator of 3 (SCCP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU is NOT part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'sccp' message begins with the first byte of the SCCP data area in the SS7 MSU (after the MTP3 routing label). The first byte in the SCCP data area is an SCCP message type field.
“sccp”操作码用于通过TALI连接交付服务指示器为3（sccp）的SS7 MSU。此操作码仅用于在没有SAAL的情况下实现的TALI协议栈。SS7 MSU的MTP3层不是此操作码通过TCP/IP传输的数据的一部分；TALI“sccp”消息的数据部分以SS7 MSU中sccp数据区的第一个字节开始（MTP3路由标签之后）。SCCP数据区域中的第一个字节是SCCP消息类型字段。
Several restrictions on the SCCP messages that this TALI opcode can carry exist. These restrictions are as follows:
此TALI操作码可携带的SCCP消息存在若干限制。这些限制如下：
* SCCP messages contain an SCCP message type field. The SCCP messages that are supported by TALI 1.0 implementations are limited to Class 0 and Class 1 SCCP messages with a message type field of either:
* SCCP消息包含SCCP消息类型字段。TALI 1.0实施支持的SCCP消息仅限于0类和1类SCCP消息，消息类型字段为：
* UDT * UDTS * XUDT * XUDTS
* UDT*UDTS*XUDT*XUDT
* SCCP messages must contain a Point Code in the 'calling party' area in order to be transferred across the TCP/IP connection as a 'sccp' message. An implementation may choose to modify the original SCCP MSU to add an appropriate calling party point code before transmission across TALI if desired.
* SCCP消息必须在“主叫方”区域包含点代码，以便作为“SCCP”消息通过TCP/IP连接传输。如果需要，实现可以选择在跨TALI传输之前修改原始SCCP MSU以添加适当的呼叫方点码。
* SCCP messages must contain a Point Code in the 'called party' area in order to be transferred across the TCP/IP connection as a 'sccp' message. An implementation may choose to modify the original SCCP MSU to add an appropriate called party point code before transmission across TALI if desired.
* SCCP消息必须在“被叫方”区域包含点代码，以便作为“SCCP”消息通过TCP/IP连接传输。如果需要，实现可以选择在跨TALI传输之前修改原始SCCP MSU以添加适当的被叫方点代码。
* The encoding of the SS7 SCCP MSUs, as they are transmitted across TALI via 'sccp', should remain compliant with the ANSI specifications (T1.112 and T1.114) that apply to the SCCP and TCAP portions of the message respectively.
* 当SS7 SCCP MSU通过“SCCP”通过TALI传输时，其编码应符合分别适用于消息SCCP和TCAP部分的ANSI规范（T1.112和T1.114）。
NOTE 1: SCCP Subsystem Management for the IP based SCP's is supported via this 'sccp' opcode. SS7 SCCP Management messages are controlled by an SCMG SS7 process. SCMG sends the management messages via SCCP UNITDATA (UDT) messages. Therefore, the SCMG messages can be sent across the TALI connection.
注1：此“SCCP”操作码支持基于IP的SCP的SCCP子系统管理。SS7 SCCP管理消息由SCMG SS7进程控制。SCMG通过SCCP UNITDATA（UDT）消息发送管理消息。因此，可以通过TALI连接发送SCMG消息。
NOTE 2: 'sccp' TALI messages will not include the MTP3 header and therefore will not retain the original DPC/OPC of the SS7 MSU. Each TALI implementation needs to consider if/how to provide this DPC/OPC information in the SCCP portion of the message. For example the DPC can be replicated to the point code in the SCCP Called Party Address area and the OPC can be replicated to the point code in the SCCP Calling Party Address area.
注2：“sccp”TALI消息将不包括MTP3标头，因此不会保留SS7 MSU的原始DPC/OPC。每个TALI实现需要考虑是否/如何在消息的SCCP部分中提供此DPC/OPC信息。例如，DPC可以复制到SCCP呼叫方地址区域中的点代码，OPC可以复制到SCCP呼叫方地址区域中的点代码。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'sccp' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SCCP Data | SCCP data starting at the first byte after|
| | | the Layer 3 Routing Label (data does not |
| | | include the SIO or Routing Label) |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'sccp' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SCCP Data | SCCP data starting at the first byte after|
| | | the Layer 3 Routing Label (data does not |
| | | include the SIO or Routing Label) |
+------------------------------------------------------------------+
When an SCCP MSU arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG for transmission to an IP device, the SG performs the following processing on the SS7 MSU:
当SCCP MSU从56 Kbps或DS1链路到达SG并在SG内路由以传输到IP设备时，SG在SS7 MSU上执行以下处理：
* discards the MTP Layer 2 information, CRC and flags
* 丢弃MTP第2层信息、CRC和标志
* places the DPC from MTP Layer 3 into the Called Party Address field of the SCCP layer; the Calling Party Address field is created if it does not exist and then filled
* 将来自MTP层3的DPC放入SCCP层的被叫方地址字段；如果呼叫方地址字段不存在，则创建该字段，然后填充该字段
* places the OPC from MTP Layer 3 into the Calling Party Address field of the SCCP layer if there is no Calling Party Point Code
* 如果没有主叫方点代码，则将来自MTP第3层的OPC放入SCCP层的主叫方地址字段
* places the modified SCCP and unchanged TCAP data in the service payload area of the TALI packet
* 将修改后的SCCP和未更改的TCAP数据放入TALI数据包的服务有效负载区域
* The SYNC field is set
* 同步字段已设置
* The OPCODE is set to 'sccp'
* 操作码设置为“sccp”
* The LENGTH is set to the number of octets in the SERVICE field
* 长度设置为服务字段中的八位字节数
Once the fully formed 'sccp' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
一旦创建了完整格式的“sccp”TALI数据包，它将被传递到TCP套接字层并传输。传输过程将添加TCP、IP和MAC报头信息。
Since the routing information from MTP Layer 3 is placed in the SCCP part of the outgoing message, no routing information needs to be saved by the SG.
由于来自MTP层3的路由信息被放置在传出消息的SCCP部分，因此SG不需要保存路由信息。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
|Flag|FCS|TCAP |SCCP |Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Layer|Layer| Label | | | | | | | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
| |
| |
| |
TALI +-----------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------+---+------+----+
| |
| |
| |
+---------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+---------------------------+------+------+------+
| Layer 3 | Layer 2 |
| | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
|Flag|FCS|TCAP |SCCP |Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Layer|Layer| Label | | | | | | | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
| |
| |
| |
TALI +-----------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------+---+------+----+
| |
| |
| |
+---------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+---------------------------+------+------+------+
Figure 6: Encapsulation of SCCP MSUs using the TALI 'sccp' opcode
图6：使用TALI“SCCP”操作码封装SCCP MSU
When an 'sccp' TALI packet is received on by an SG from an IP device, the SG performs the following processing on the 'sccp' packet:
当SG从IP设备接收到“sccp”TALI数据包时，SG对“sccp”数据包执行以下处理：
* validates the TALI header
* 验证TALI标头
* Allocates space for a new SS7 message
* 为新的SS7消息分配空间
* Regenerates the SIO with the Sub-Service Field set to National Network, priority of zero (0), Service Indicator set to SCCP
* 重新生成SIO，子服务字段设置为国家网络，优先级为零（0），服务指示器设置为SCCP
* extracts the SCCP/TCAP data from the SERVICE area and places it in the new SS7 message
* 从服务区提取SCCP/TCAP数据，并将其放入新的SS7消息中
* sets the DPC to the SCCP Called Party Point Code
* 将DPC设置为SCCP呼叫方点代码
* sets the OPC to the SCCP Calling Party Point Code
* 将OPC设置为SCCP呼叫方点代码
* randomly generates the SLS
* 随机生成SLS
Once the 'sccp' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
一旦“sccp”数据包转换回正常的SS7 MSU，MSU将根据正常的SS7路由程序在SG内路由。
The 'isot' opcode is used to deliver SS7 MSUs with a Service Indicator of 5 (ISUP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'isot' message begins with the SIO byte of the MTP3 header in the SS7 MSU.
“isot”操作码用于通过TALI连接交付服务指示器为5（ISUP）的SS7 MSU。此操作码仅用于在没有SAAL的情况下实现的TALI协议栈。SS7 MSU的MTP3层是此操作码通过TCP/IP传输的数据的一部分；TALI“isot”消息的数据部分以SS7 MSU中MTP3头的SIO字节开始。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'isot' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | ISUP Data | Raw ISUP data starting at the Layer 3 SIO |
| | | field. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'isot' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | ISUP Data | Raw ISUP data starting at the Layer 3 SIO |
| | | field. |
+------------------------------------------------------------------+
When an ISUP MSU arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG to a IP device, the SG performs the following processing on the SS7 MSU:
当ISUP MSU从56 Kbps或DS1链路到达SG并在SG内路由到IP设备时，SG在SS7 MSU上执行以下处理：
* discards the MTP Layer 2 information, CRC and flags
* 丢弃MTP第2层信息、CRC和标志
* places MTP Layer 3 into the SERVICE payload area of the TALI packet
* 将MTP层3放入TALI数据包的服务有效负载区域
* The SYNC field is set
* 同步字段已设置
* The OPCODE is set to 'isot'
* 操作码设置为“isot”
* The LENGTH is set to the number of octets in the SERVICE field
* 长度设置为服务字段中的八位字节数
Once the fully formed 'isot' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
一旦完全形成的“isot”TALI数据包被创建，它就被交给TCP套接字层并传输。传输过程将添加TCP、IP和MAC报头信息。
Since the routing information is placed in the TALI Packet, no routing information needs to be saved by the SG.
由于路由信息放置在TALI数据包中，因此SG不需要保存路由信息。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
|Flag|FCS|ISUP|Msg.|CIC|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Part|Type| |Label | | | | | | | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
| /
| /
| |
TALI +-----------------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------------------+---+------+----+
| /
| ---------
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
| Layer 3 | Layer 2 |
| | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
|Flag|FCS|ISUP|Msg.|CIC|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Part|Type| |Label | | | | | | | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
| /
| /
| |
TALI +-----------------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------------------+---+------+----+
| /
| ---------
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
Figure 7: Encapsulation of ISUP MSUs using the TALI 'isot' opcode
图7：使用TALI“isot”操作码封装ISUP MSU
When an 'isot' TALI packet is received on an SG from an IP device, the SG performs the following processing on the 'isot' packet:
当SG上从IP设备接收到“isot”TALI数据包时，SG对“isot”数据包执行以下处理：
* validates the TALI header
* 验证TALI标头
* Allocates space for a new SS7 message
* 为新的SS7消息分配空间
* extracts the MTP Layer 3 data from the SERVICE area and places it in the new SS7 message
* 从服务区提取MTP第3层数据，并将其放入新的SS7消息中
Once the 'isot' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
一旦“isot”数据包转换回正常的SS7 MSU，MSU将根据正常的SS7路由程序在SG内路由。
The 'mtp3' opcode is used to deliver SS7 MSUs with a Service Indicator of 0-2, 4, 6-15 (non-SCCP, non-ISUP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'mtp3' message begins with the SIO byte of the MTP3 header in the SS7 MSU.
“mtp3”操作码用于通过TALI连接提供服务指示器为0-2、4、6-15（非SCCP、非ISUP）的SS7 MSU。此操作码仅用于在没有SAAL的情况下实现的TALI协议栈。SS7 MSU的MTP3层是此操作码通过TCP/IP传输的数据的一部分；TALI“mtp3”消息的数据部分以SS7 MSU中mtp3报头的SIO字节开始。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mtp3' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 MSU | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mtp3' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 MSU | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
When an SS7 MSU with SI=0-2,4,6-15 arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG to an IP device, the SG performs the following processing on the SS7 MSU:
当SI=0-2,4,6-15的SS7 MSU从56 Kbps或DS1链路到达SG，并在SG内路由到IP设备时，SG在SS7 MSU上执行以下处理：
* discards the MTP Layer 2 information, CRC and flags
* 丢弃MTP第2层信息、CRC和标志
* places MTP Layer 3 into the SERVICE payload area of TALI packet
* 将MTP层3放入TALI数据包的服务有效负载区域
* The SYNC field is set
* 同步字段已设置
* The OPCODE is set to 'mtp3'
* 操作码设置为“mtp3”
* The LENGTH is set to the number of octets in the SERVICE field
* 长度设置为服务字段中的八位字节数
Once the fully formed 'mtp3' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
创建完整格式的“mtp3”TALI数据包后，它将被传递到TCP套接字层并传输。传输过程将添加TCP、IP和MAC报头信息。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| /
| ------
| /
TALI +----------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+----------------+---+------+----+
| /
| --
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| /
| ------
| /
TALI +----------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+----------------+---+------+----+
| /
| --
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
Figure 8: Encapsulation of SS7 MSUs with SI!=3,5,13 using 'mtp3'
Figure 8: Encapsulation of SS7 MSUs with SI!=3,5,13 using 'mtp3'
When an 'mtp3' TALI packet is received by an SG from an IP device, the SG performs the following processing on the 'mtp3' packet:
当SG从IP设备接收到“mtp3”TALI数据包时，SG对“mtp3”数据包执行以下处理：
* validates the TALI header
* 验证TALI标头
* Allocates space for a new SS7 message
* 为新的SS7消息分配空间
* extracts the MTP Layer 3 data from the SERVICE area and places it in the new SS7 message
* 从服务区提取MTP第3层数据，并将其放入新的SS7消息中
Once the 'mtp3' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
一旦“mtp3”数据包转换回正常的SS7 MSU，MSU将根据正常的SS7路由程序在SG内路由。
The 'saal' opcode is used to deliver SS7 MSUs with any Service Indicator over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented with SAAL. The 'saal' opcode is also used to transmit SAAL peer to peer packets (SSCF peer to peer packets and SSCOP peer to peer packets other than SS7 service data) over a TALI connection.
“saal”操作码用于通过TALI连接交付带有任何服务指示器的SS7 MSU。此操作码仅用于使用SAAL实现的TALI协议栈。“saal”操作码还用于通过TALI连接传输saal对等数据包（SSCF对等数据包和SS7服务数据以外的SSCOP对等数据包）。
When used to transfer SS7 MSUs, the MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'saal' message begins with the SIO byte of the MTP3 header in the SS7 MSU and ends with the last byte of the SSCOP trailer.
当用于传输SS7 MSU时，SS7 MSU的MTP3层是该操作码通过TCP/IP传输的数据的一部分；TALI“saal”消息的数据部分以SS7 MSU中MTP3报头的SIO字节开始，以SSCOP尾部的最后一个字节结束。
When used to transfer SSCF/SSCOP peer to peer messages the data portion of the TALI 'saal' message includes the entire SSCOP PDU.
当用于传输SSCF/SSCOP对等消息时，TALI“saal”消息的数据部分包括整个SSCOP PDU。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
| (X+1) | SSCOP | Zero (0) to three (3) octets of padding |
| ..Y | Trailer | plus 4 octets for the trailer data. The |
| | | total length of the Layer 3 Data and the |
| | | SSCOP trailer must be a multiple of 4. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
| (X+1) | SSCOP | Zero (0) to three (3) octets of padding |
| ..Y | Trailer | plus 4 octets for the trailer data. The |
| | | total length of the Layer 3 Data and the |
| | | SSCOP trailer must be a multiple of 4. |
+------------------------------------------------------------------+
or
或
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SAAL Peer | Raw SSCF/SSCOP peer to peer packets are |
| | to Peer | also transferred over the TALI connection |
| | message | using this 'saal' opcode. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SAAL Peer | Raw SSCF/SSCOP peer to peer packets are |
| | to Peer | also transferred over the TALI connection |
| | message | using this 'saal' opcode. |
+------------------------------------------------------------------+
When an SS7 MSU (with any SI) arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG for transmission to an IP device, the SG performs the following processing on the SS7 MSU:
当SS7 MSU（具有任何SI）从56 Kbps或DS1链路到达SG并在SG内路由以传输到IP设备时，SG在SS7 MSU上执行以下处理：
* discards the MTP Layer 2 information, CRC and flags
* 丢弃MTP第2层信息、CRC和标志
* the MSU is passed from an MTP3 processing software layer to the SSCF and SSCOP layers (the SAAL layers). These layers convert the SS7 MSU into an SSCOP PDU. Part of this conversion includes adding an SSCOP trailer.
* MSU从MTP3处理软件层传递到SSCF和SSCOP层（SAAL层）。这些层将SS7 MSU转换为SSCOP PDU。此转换的一部分包括添加SSCOP拖车。
* the SSCOP PDU (whether it is a peer to peer SAAL message or SS7 MSU in an SSCOP PDU) is copied into the SERVICE payload area of the TALI packet
* SSCOP PDU（无论是对等SAAL消息还是SSCOP PDU中的SS7 MSU）复制到TALI数据包的服务有效负载区域
* The SYNC field is set
* 同步字段已设置
* The OPCODE is set to 'saal'
* 操作码设置为“saal”
* The LENGTH is set to the number of octets in the SERVICE field
* 长度设置为服务字段中的八位字节数
Once the fully formed 'saal' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
一旦完全形成的“saal”TALI数据包被创建，它就被传递到TCP套接字层并传输。传输过程将添加TCP、IP和MAC报头信息。
Since the routing information is placed in the TALI Packet, no routing information needs to be saved by the SG.
由于路由信息放置在TALI数据包中，因此SG不需要保存路由信息。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| |
| |
| |
+-------+-----------------------+
|SSCOP | Service |
|Trailer| |
+-------+-----------------------+
| |
+-------+-----------------------+---+------+----+
|Service with SSCOP Trailer |LEN|Opcode|SYNC|
+-------+-----------------------+---+------+----+
| /
| -----------------
| /
+----------------------------+------+------+------+
| TALI Packet |TCP | IP | MAC |
| |Header|Header|Header|
+----------------------------+------+------+------+
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| |
| |
| |
+-------+-----------------------+
|SSCOP | Service |
|Trailer| |
+-------+-----------------------+
| |
+-------+-----------------------+---+------+----+
|Service with SSCOP Trailer |LEN|Opcode|SYNC|
+-------+-----------------------+---+------+----+
| /
| -----------------
| /
+----------------------------+------+------+------+
| TALI Packet |TCP | IP | MAC |
| |Header|Header|Header|
+----------------------------+------+------+------+
Figure 9: Encapsulation of SAAL PDUs using the TALI 'saal' opcode
图9：使用TALI“SAAL”操作码封装SAAL PDU
When an 'saal' TALI packet is received at the SG from an IP device, the SG performs the following processing on the 'saal' packet:
当SG从IP设备接收到“saal”TALI数据包时，SG对“saal”数据包执行以下处理：
* validates the TALI header
* 验证TALI标头
* Allocates space for a new SSCOP PDU message
* 为新SSCOP PDU消息分配空间
* extracts the SSCOP PDU data from the SERVICE area and places it in the new SSCOP PDU message
* 从服务区提取SSCOP PDU数据，并将其放入新的SSCOP PDU消息中
Once the 'saal' packet is transformed back into a normal DS1 SSCOP PDU, the SSCOP PDU is passed to the SAAL layer for receive processing. If the SSCOP PDU is a peer to peer pdu, it is processed completely in the appropriate SAAL layer. If the SSCOP PDU is an SS7 MSU, the MSU is transformed back to a normal SS7 MSU and is routed within the SG according to the normal SS7 routing procedures.
一旦“saal”数据包转换回正常DS1 SSCOP PDU，SSCOP PDU将传递到saal层进行接收处理。如果SSCOP PDU是对等PDU，则在适当的SAAL层中对其进行完全处理。如果SSCOP PDU是SS7 MSU，MSU将转换回正常的SS7 MSU，并根据正常的SS7路由程序在SG内路由。
Version 1.0 of the TALI specification defined 4 TALI timers that are used as part of the TALI state machine. These timers are generically named 'T1' through 'T4'. Brief descriptions of each timer are provided in the following subsections. Timer expiration events for each of the T1-T4 timers appear as inputs to the TALI state machine. For exact processing of each timer (when to start/stop, how to process timer expirations), refer to the TALI state machine.
TALI规范1.0版定义了4个TALI定时器，用作TALI状态机的一部分。这些计时器一般命名为“T1”到“T4”。以下小节提供了每个计时器的简要说明。每个T1-T4定时器的定时器到期事件显示为TALI状态机的输入。有关每个计时器的精确处理（何时启动/停止，如何处理计时器过期），请参阅TALI状态机。
Both ends of the TALI connection have there own T1-T4 timers. The T1-T4 timer values can be set on each end of the connection independent of the settings on the far end. For each timer, a default value and range is recommended in the following sections.
TALI连接的两端都有自己的T1-T4定时器。T1-T4定时器值可以在连接的每一端进行设置，与远端的设置无关。对于每个计时器，以下部分建议使用默认值和范围。
The T1 timer represents the time interval between the origination of a 'test' message at each TALI implementation. Each time T1 expires, the TALI implementation should send a 'test'.
T1计时器表示在每个TALI实施时发出“测试”消息之间的时间间隔。每次T1过期时，TALI实现都应该发送一个“测试”。
The T2 timer represents the amount of time that the Peer has to return an 'allo' or a 'proh' in response to a 'test'. If the far end fails to reply with 'allo' or 'proh' before T2 expires, the sender of the 'test' treats the T2 expiration as a protocol violation. Note that T2 must be < T1 in order for these timers to work as designed.
T2计时器表示对等方响应“测试”必须返回“allo”或“proh”的时间量。如果远端在T2到期之前未能使用“allo”或“proh”进行应答，“test”的发送方将T2到期视为违反协议。请注意，T2必须小于T1才能使这些计时器按设计工作。
The T3 timer controls how long the near end should continue to process Service Data that is received from the far end after a Management Prohibit Traffic Event has occurred (at the near end). This timer is used when a transition from NEA-FEA (both ends allowed to send service data) to NEP-FEA (only far end willing to send service data) occurs. On that transition, it is reasonable to expect that the far end needs some amount of time to adjust its TALI state machine and divert service data traffic away from this socket. The T3 timer controls the amount of time the far end has to divert traffic.
T3定时器控制在发生管理禁止交通事件（在近端）后，近端应继续处理从远端接收的服务数据的时间。当NEA-FEA（两端允许发送服务数据）转换为NEP-FEA（只有远端愿意发送服务数据）时，使用该定时器。在该转换中，可以合理地预期远端需要一些时间来调整其TALI状态机并将服务数据流量从该套接字转移出去。T3定时器控制远端转移交通的时间量。
The T4 timer represents the time interval between the origination of a 'moni' message at each TALI implementation. Each time T4 expires, the TALI implementation should send a 'moni'.
T4计时器表示每次TAI实施时发出“moni”消息之间的时间间隔。每次T4到期时，TALI实施应发送“moni”。
The following table provides the recommended default and configurable range for each TALI timer.
下表提供了每个TALI定时器的推荐默认和可配置范围。
+------------------------------------------------------------------+
|Name| Min | Max |Default| Description |
+------------------------------------------------------------------+
| T1 | 100ms | 60sec | 4 sec | Send test PDU timer |
+------------------------------------------------------------------+
| T2 | 100ms | 60sec | 3 sec | Response timer for an allo or proh |
| | | | | response to test message. |
+------------------------------------------------------------------+
| T3 | 100ms | 60sec | 5 sec | Timer controls how long to process |
| | | | | rcvd serv data after an NE |
| | | | | transition from NEA to NEP. System |
| | | | | is waiting for a proa response to |
| | | | | the first proh send when NE |
| | | | | transitions from NEA to NEP. |
+------------------------------------------------------------------+
| T4 | 100ms | 60sec |10 sec | Send moni PDU timer |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Name| Min | Max |Default| Description |
+------------------------------------------------------------------+
| T1 | 100ms | 60sec | 4 sec | Send test PDU timer |
+------------------------------------------------------------------+
| T2 | 100ms | 60sec | 3 sec | Response timer for an allo or proh |
| | | | | response to test message. |
+------------------------------------------------------------------+
| T3 | 100ms | 60sec | 5 sec | Timer controls how long to process |
| | | | | rcvd serv data after an NE |
| | | | | transition from NEA to NEP. System |
| | | | | is waiting for a proa response to |
| | | | | the first proh send when NE |
| | | | | transitions from NEA to NEP. |
+------------------------------------------------------------------+
| T4 | 100ms | 60sec |10 sec | Send moni PDU timer |
+------------------------------------------------------------------+
Table 5: Timers
表5：计时器
NOTE: The value of T1 must be at least one (1) millisecond greater than T2. This is to prevent the system from a lockup in the T1 expired condition. If T1 is equal or less than T2, it will expire and restart T2 and not enforce responses to the test message.
注：T1的值必须至少比T2大一（1）毫秒。这是为了防止系统在T1过期状态下锁定。如果T1等于或小于T2，它将过期并重新启动T2，并且不会强制执行对测试消息的响应。
Enforcement of minimum and maximum timer values is implementation dependent.
最小和最大计时器值的实施取决于实现。
Each TALI implementation must provide several user event controls over the behavior of the TALI state machine for each TALI connection. The user interface to provide these capabilities is implementation specific.
每个TALI实现必须为每个TALI连接的TALI状态机行为提供多个用户事件控件。提供这些功能的用户界面是特定于实现的。
The 'mgmt open socket' event, together with the 'mgmt close socket' event, allows the user to control when each defined TALI connection will form a TCP socket connection. When 'open socket' for a particular TALI connection occurs, the TALI connection should begin trying to form a TCP socket connection to the peer.
“mgmt open socket”事件和“mgmt close socket”事件允许用户控制每个定义的TALI连接何时形成TCP套接字连接。当特定TALI连接出现“开放套接字”时，TALI连接应开始尝试与对等方形成TCP套接字连接。
The steps that are taken to connect are dependent on the client/server role of that end of the TALI connection. The exact steps to perform these tasks are implementation dependent and may differ based on the TCP stack being used.
连接所采取的步骤取决于TALI连接端的客户端/服务器角色。执行这些任务的确切步骤取决于实现，并且可能因使用的TCP堆栈而异。
In general, TALI clients form socket connections by using the BSD sockets calls:
通常，TALI客户端通过使用BSD套接字调用形成套接字连接：
Socket() Bind() Connect()
套接字（）绑定（）连接（）
In general, TALI servers form socket connections by using the BSD sockets calls:
通常，TALI服务器通过使用BSD套接字调用形成套接字连接：
Socket() Bind() Listen() Accept()
套接字（）绑定（）侦听（）接受（）
The 'mgmt close socket' event can be issued by the user when it is desired that the TCP socket for a TALI socket, be closed immediately, or discontinue its attempts to connect to the peer. After acting on 'close socket', the TALI connection will not be established until 'mgmt open socket' is issued.
当需要立即关闭TALI套接字的TCP套接字或停止其连接对等方的尝试时，用户可以发出“mgmt close socket”事件。在“闭合插座”上操作后，直到发出“管理开放插座”后，才能建立TALI连接。
The 'mgmt allow traffic' event, together with the 'mgmt prohibit traffic' event, allows the user to control when each defined TALI connection will be willing to carry SS7 service data over that particular TALI connection. When 'mgmt allow traffic' is issued, the TALI implementation becomes willing to carry service data. The TALI state for the near end should transition to NEA (near end allowed) if the connection is already established.
“管理允许流量”事件以及“管理禁止流量”事件允许用户控制每个定义的TALI连接何时愿意通过该特定TALI连接承载SS7服务数据。当发出“管理允许流量”时，TALI实现将愿意承载服务数据。如果已建立连接，近端的TALI状态应转换为NEA（允许近端）。
The 'mgmt prohibit traffic' event is the opposite of 'allow traffic'. When 'mgmt prohibit traffic' is issued, the TALI implementation becomes un-willing to carry SS7 service data over that particular TALI connection. The TALI state for the near end should transition to NEP (near end prohibited) if the connection is already established.
“管理禁止交通”事件与“允许交通”相反。当发出“管理禁止流量”时，TALI实现将不愿意通过该特定TALI连接承载SS7服务数据。如果已建立连接，近端的TALI状态应转换为NEP（禁止近端）。
In addition to timers, each TALI implementation needs to be able to detect, and react accordingly, for the following events:
除计时器外，每个TALI实现还需要能够检测以下事件并作出相应反应：
* Connection Established. When the TCP socket connection is initially established the TALI state machine must be notified.
* 已建立连接。当TCP套接字连接最初建立时，必须通知TALI状态机。
* Connection Lost. When the TCP socket connection is lost, due to socket errors during reads/writes, the TALI state machine must be notified.
* 连接丢失。当TCP套接字连接由于读/写期间的套接字错误而丢失时，必须通知TALI状态机。
* Protocol Violations. Any violation of the TALI protocol as discussed in 3.7.1.3.
* 违反协议。如3.7.1.3所述，任何违反TALI协议的行为。
The TALI version 1.0 specification is based on a state machine that considers 6 TALI states. Each end of the TALI connection maintains its own TALI state.
TALI版本1.0规范基于考虑6种TALI状态的状态机。TALI连接的每一端都保持其自身的TALI状态。
+------------------------------------------------------------------+
| Name | Description |
+------------------------------------------------------------------+
| OOS | The TALI connection is out of service. This usually|
| | corresponds to a user event to 'close' the socket, |
| | or a user event to 'deactivate the SS7 link'. |
+------------------------------------------------------------------+
| Connecting | The TALI layer is attempting to establish a TCP |
| | socket connection to the peer. Servers are |
| | 'accepting', clients are 'connecting'. |
+------------------------------------------------------------------+
| NEP-FEP | The TCP socket connection is established. Neither |
| | side of the connection is ready to use the socket |
| | for service PDUs. |
+------------------------------------------------------------------+
| NEP-FEA | The TCP socket connection is established. The NE is|
| | not ready to use the socket for service PDUs. The |
| | FE is ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEP | The TCP socket connection is established. The NE is|
| | ready to use the socket for service PDUs. The FE is|
| | not ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEA | The TCP socket connection is established. Both |
| | sides are ready to use the socket for service PDUs. |
| | This is the only state where normal bi-directional |
| | SS7 data transfer occurs. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Name | Description |
+------------------------------------------------------------------+
| OOS | The TALI connection is out of service. This usually|
| | corresponds to a user event to 'close' the socket, |
| | or a user event to 'deactivate the SS7 link'. |
+------------------------------------------------------------------+
| Connecting | The TALI layer is attempting to establish a TCP |
| | socket connection to the peer. Servers are |
| | 'accepting', clients are 'connecting'. |
+------------------------------------------------------------------+
| NEP-FEP | The TCP socket connection is established. Neither |
| | side of the connection is ready to use the socket |
| | for service PDUs. |
+------------------------------------------------------------------+
| NEP-FEA | The TCP socket connection is established. The NE is|
| | not ready to use the socket for service PDUs. The |
| | FE is ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEP | The TCP socket connection is established. The NE is|
| | ready to use the socket for service PDUs. The FE is|
| | not ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEA | The TCP socket connection is established. Both |
| | sides are ready to use the socket for service PDUs. |
| | This is the only state where normal bi-directional |
| | SS7 data transfer occurs. |
+------------------------------------------------------------------+
Table 6: TALI States
表6：塔利州
This section provides the state machine that must be followed by each TALI implementation in order to be compliant with this specification.
本节提供了每个TAI实现必须遵循的状态机，以符合本规范。
Before presenting the actual state machine, several concepts are discussed.
在介绍实际的状态机之前，讨论了几个概念。
1. Neither side can send service data unless both sides are allowed.
1. 除非双方都允许，否则任何一方都不能发送服务数据。
2. Each side initializes to the prohibited state for both near end and far end.
2. 对于近端和远端，每一方都初始化为禁止状态。
3. State changes between the NEx-FEx states are signaled with either an 'allo' or 'proh'.
3. NEx FEx状态之间的状态变化通过“allo”或“proh”发出信号。
4. Each side can poll the far end's state with a 'test'. Upon sending 'test', T1 and T2 should always be restarted.
4. 每一方都可以通过“测试”轮询远端的状态。发送“测试”后，T1和T2应始终重新启动。
5. Each side polls the far end with a 'test' every T1 expiration.
5. 每一方都会在T1到期时对远端进行“测试”。
6. The reply to a 'test' is based on the state of the near end only.
6. 对“测试”的回复仅基于近端的状态。
7. The reply to a 'test' is either 'allo' or 'proh'.
7. 对“测试”的回答是“allo”或“proh”。
8. A far end signals the last service PDU has been transmitted with either a 'proh' or a 'proa'.
8. 远端用“proh”或“proa”发送最后一个服务PDU的信号。
9. Upon receiving a 'proh', the receiver must always reply with 'proa'.
9. 收到“proh”后，接收者必须始终以“proa”回复。
10. The NE cannot gracefully close a socket unless a 'proh' is sent and 'proa' is received.
10. 除非发送“proh”并接收到“proa”，否则网元无法正常关闭套接字。
11. On the transition from NEA to NEP, after sending a 'proh', the near end must continue to process received service data until a 'proa' is received or until a T3 timer expires.
11. 在从NEA过渡到NEP时，在发送“proh”后，近端必须继续处理接收到的服务数据，直到接收到“proa”或T3计时器过期。
The state table treats a management request to close the socket as a 'hard' shutdown. That is, it will close the socket immediately regardless of the current state. Therefore, the correct steps to ensure a graceful shutdown of a socket (from the NEA_FEP or NEA_FEA states) is:
状态表将关闭套接字的管理请求视为“硬”关闭。也就是说，无论当前状态如何，它都会立即关闭套接字。因此，确保插座正常关闭（从NEA_FEP或NEA_FEA状态）的正确步骤是：
1. Management issues a Management Prohibit Traffic Event on the socket.
1. 管理在套接字上发出管理禁止通信事件。
2. Management will wait for T3 to expire.
2. 管理层将等待T3到期。
3. Management can then issue a Close Socket Event on the socket.
3. 然后，管理层可以在套接字上发出关闭套接字事件。
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include:
每个TALI实施必须检测何时发生违反TALI协议的情况，并作出相应反应。违反协议的行为包括：
* Invalid sync code in a received message
* 接收到的消息中的同步代码无效
* Invalid opcode in a received message
* 接收到的消息中的操作码无效
* Invalid length field in a received message
* 接收到的消息中的长度字段无效
* Not receiving an 'allo' or 'proh', in response to the origination of a 'test' , before the T2 timer expires
* 在T2定时器到期之前，未收到响应“测试”发起的“allo”或“proh”
* Receiving Service Messages on a prohibited socket.
* 在禁止的套接字上接收服务消息。
* TCP Socket errors - Connection Lost
* TCP套接字错误-连接丢失
In the state machine that follows, State/Event combinations that should be treated as protocol violations are indicated via a 'PV' in the state/event cell. All of the 'PV' events are then processed as per the 'Protocol Violation' row in the table.
在随后的状态机中，应视为违反协议的状态/事件组合通过状态/事件单元中的“PV”指示。然后根据表中的“协议冲突”行处理所有“PV”事件。
Internal Data required for State Machine:
状态机所需的内部数据：
boolean sock_allowed. This flag indicates whether the NE is allowed to carry Service Messages.
允许布尔sock_。此标志指示是否允许网元承载服务消息。
Initial Conditions: sock_allowed = FALSE state = OOS no timers running
初始条件：sock_allowed=错误状态=OOS无计时器运行
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
Table 7: TALI 1.0 State Machine
表7:TALI 1.0状态机
Several aspects of the expected TALI 1.0 implementation have not been specifically addressed in the state machine or previous text (or else they were presented but will be reiterated here). These implementation notes in some cases have to do with the expected behavior of the software layer above the TALI layer.
预期的TALI 1.0实现的几个方面在状态机或之前的文本中没有特别提到（或者已经介绍过，但将在这里重申）。在某些情况下，这些实现说明与TALI层之上的软件层的预期行为有关。
* The failure to read or write from a TCP socket shall be detected and generate a connection lost event.
* 应检测TCP套接字的读写失败，并生成连接丢失事件。
* Message streams can be monitored for congestion via implementation dependent methods.
* 可以通过依赖于实现的方法监控消息流的拥塞情况。
* One possible definition of congestion for the previous requirement might be when a TCP socket is blocked.
* 对于前面的需求，拥塞的一个可能定义可能是当TCP套接字被阻塞时。
Several limitations with the TALI 1.0 specification and implementation are identified:
确定了TALI 1.0规范和实施的几个限制：
* For SCCP traffic, only UDT and XUDT Class 0 and Class 1 traffic should be managed by this protocol.
* 对于SCCP流量，只有UDT和XUDT 0类和1类流量应由该协议管理。
* When the MTP3 Routing Label is not part of the data transmitted across the wire, priority zero (0) traffic is used for all traffic when the SIO is regenerated.
* 当MTP3路由标签不是通过导线传输的数据的一部分时，当SIO重新生成时，优先级为零（0）的流量将用于所有流量。
Version 2.0 of the TALI specification provides several additions to the Version 1.0 specification. The 2.0 additions are provided by introducing three new TALI opcodes. The basic functionality and most of the details of the TALI 1.0 implementation are NOT changed by the 2.0 additions.
TALI规范的2.0版为1.0版规范提供了一些补充。通过引入三个新的TALI操作码，提供了2.0新增功能。TALI 1.0实现的基本功能和大部分细节不会因2.0的添加而改变。
The table below provides a summary of the messages and message structure used in TALI version 2.0.
下表总结了TALI 2.0版中使用的消息和消息结构。
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack| | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service o/TALI | | 'isot' | |
| | MTP3 Service o/TALI | | 'mtp3' | |
| | Service o/SAAL | | 'saal' | |
| | Management Message | | 'mgmt' | |
| | Extended Service Msg| | 'xsrv' | |
| | Special Message | | 'spcl' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor msg | | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack| | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service o/TALI | | 'isot' | |
| | MTP3 Service o/TALI | | 'mtp3' | |
| | Service o/SAAL | | 'saal' | |
| | Management Message | | 'mgmt' | |
| | Extended Service Msg| | 'xsrv' | |
| | Special Message | | 'spcl' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor msg | | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
Due to the minimal amount of change from 1.0, this chapter will only provide:
由于1.0的更改量最小，本章仅提供：
* Detailed information regarding how a TALI implementation can identify itself as a 2.0 vs. a 1.0 implementation
* 关于TALI实现如何将自己识别为2.0与1.0实现的详细信息
* Detailed information regarding how to provide backward compatibility for a connection to a far end that is only TALI 1.0 capable
* 有关如何为仅支持TALI 1.0的远端连接提供向后兼容性的详细信息
* Detailed information regarding the new 2.0 opcodes
* 有关新2.0操作码的详细信息
* Detailed information regarding any other changes to the information presented in previous sections that need to be implemented in order to be 2.0 compatible.
* 有关前几节中所述信息的任何其他变更的详细信息，这些变更需要实施，以便与2.0兼容。
Therefore, readers of this chapter should read this from the point of view of modifying an existing TALI 1.0 implementation to support the new 2.0 features.
因此，本章的读者应该从修改现有TALI 1.0实现以支持新的2.0功能的角度来阅读本文。
A small number of changes to a 1.0 TALI implementation are required to support 2.0. Figure 10 illustrates the inputs that affect the 2.0 TALI State Machine. The reader may notice that the only differences from the inputs for 1.0 are as follows:
支持2.0需要对1.0 TALI实现进行少量更改。图10说明了影响2.0 TALI状态机的输入。读者可能会注意到，与1.0输入的唯一区别如下：
Three new TALI opcodes can be sent/received between a TALI node and its peer. The new opcodes are:
TALI节点与其对等节点之间可以发送/接收三个新的TALI操作码。新的操作码是：
* 'mgmt' * 'xsrv' * 'spcl'
* “管理”*“xsrv”*“spcl”
Three new User Part capabilities need to be supported by the layer of code above the TALI layer in each implementation. The user part needs to provide support for 'mgmt', 'xsrv', and 'spcl' data.
在每个实现中，TALI层之上的代码层需要支持三个新的用户部件功能。用户部件需要为“管理”、“xsrv”和“spcl”数据提供支持。
More information about the 3 new opcodes is provided in individual sections in this chapter. However, a brief description of the purpose of each of these opcodes is as follows:
有关3种新操作码的更多信息，请参见本章的各个章节。但是，对这些操作码的用途的简要说明如下：
* 'mgmt' - This opcode is intended to allow MANAGEMENT data, or data that will manage the operation of the device, to pass between the TALI endpoints. Examples of this management data include:
* “管理”-此操作码旨在允许管理数据或将管理设备操作的数据在TALI端点之间传递。该管理数据的示例包括：
* configuration data, such as which SS7 traffic streams a peer would like to receive over a specific socket
* 配置数据，例如对等方希望通过特定套接字接收的SS7通信流
* SS7 Network Management data, such as information regarding point code (un)availability and congestion.
* SS7网络管理数据，如有关点代码（un）可用性和拥塞的信息。
* Enabling/disabling various socket options, such as options regarding which messages are supported, or how to format data.
* 启用/禁用各种套接字选项，例如关于支持哪些消息或如何格式化数据的选项。
* 'xsrv' - Extended Service Opcodes. It is envisioned that the TALI protocol could be extended to carry other types of traffic that are not covered by the 1.0 service data opcodes ('sccp', 'isot', 'mtp3', or 'saal'). By defining a new 'xsrv' service opcode, the TALI protocol is opened up to the possibility of being used for other types of data transport.
* “xsrv”-扩展服务操作码。可以设想，TALI协议可以扩展到承载1.0服务数据操作码（“sccp”、“isot”、“mtp3”或“saal”）未涵盖的其他类型的流量。通过定义新的“xsrv”服务操作码，TALI协议可以用于其他类型的数据传输。
* 'spcl' - Special services. It is envisioned that vendors may want to build special services into their TALI implementations that are only activated when the implementation is connected to other equipment implementing the same special services. This opcode is intended to provide a general means to discover more information regarding who the TALI session is connected to, and a means to enable special features based on the vendor/implementation on the far end.
* “spcl”-特殊服务。可以预见，供应商可能希望在其TALI实现中构建特殊服务，只有当实现连接到实现相同特殊服务的其他设备时，才会激活这些服务。此操作码旨在提供一种通用方法，以发现有关TALI会话连接到谁的更多信息，并提供一种基于远端供应商/实现启用特殊功能的方法。
+====+ +---------+ +============+
| | | Service | +-------------+ | |
|User| | Message,| | Mgmt. Open | | MANAGEMENT |
|Part|<-->| MGMT, | | Mgmt. Close |<-->| |
| | | XSRV, | | Mgmt. Proh. | | |
| | | SPCL | | Mgmt. Allow | +============+
+====+ +---------+ +-------------+
^ ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
v | | |
+---------+ | | |
| Received| +-----------------+ +-----------+ +------------+
| 'test', | | Connection est. | | Protocol | | T1 Expired |
| 'allo', | | Connection lost | | Violation | | T2 Expired |
| 'proh', | | | | | | T3 Expired |
| 'proa', | +-----------------+ +-----------+ | T4 Expired |
| 'moni', | ^ ^ +------------+
| 'mona', | | | ^
| 'mgmt', | | | |
| 'xsrv', | | | |
| 'spcl', | | | |
| or | +========================================+
| Service | | IMPLEMENTATION |
| Message | | DEPENDENT |
+---------+ +========================================+
^
|
v
+============+
| PEER |
| |
+============+
+====+ +---------+ +============+
| | | Service | +-------------+ | |
|User| | Message,| | Mgmt. Open | | MANAGEMENT |
|Part|<-->| MGMT, | | Mgmt. Close |<-->| |
| | | XSRV, | | Mgmt. Proh. | | |
| | | SPCL | | Mgmt. Allow | +============+
+====+ +---------+ +-------------+
^ ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
v | | |
+---------+ | | |
| Received| +-----------------+ +-----------+ +------------+
| 'test', | | Connection est. | | Protocol | | T1 Expired |
| 'allo', | | Connection lost | | Violation | | T2 Expired |
| 'proh', | | | | | | T3 Expired |
| 'proa', | +-----------------+ +-----------+ | T4 Expired |
| 'moni', | ^ ^ +------------+
| 'mona', | | | ^
| 'mgmt', | | | |
| 'xsrv', | | | |
| 'spcl', | | | |
| or | +========================================+
| Service | | IMPLEMENTATION |
| Message | | DEPENDENT |
+---------+ +========================================+
^
|
v
+============+
| PEER |
| |
+============+
Figure 10: Overview of Inputs to the TALI 2.0 State Machine
图10:TALI 2.0状态机输入概览
The TALI 1.0 specification did not provide a simple means to perform TALI version identification. However, the general purpose 'moni' message from 1.0 can be used to solve this problem in 2.0.
TALI 1.0规范没有提供执行TALI版本识别的简单方法。但是，1.0中的通用“moni”消息可用于解决2.0中的此问题。
Recall from 1.0 that the 'moni' message was very loosely defined in the 1.0 spec:
回想一下1.0中的“moni”消息在1.0规范中的定义非常松散：
* The primary purpose of the 'moni' message was to provide a general purpose ECHO capability. It was envisioned that an important task that the ECHO capability could provide would be to measure Round Trip TALI/TALI processing time.
* “moni”消息的主要目的是提供通用回显功能。据设想，回波能力可以提供的一项重要任务是测量往返TAI/TAI处理时间。
* The data portion of the 'moni' message could be from 0-200 bytes long. The use of the data area was completely implementation specific.
* “moni”消息的数据部分的长度可能为0-200字节。数据区的使用完全是特定于实现的。
* There were no requirements that an implementation ever send a 'moni'.
* 没有要求实现发送“moni”。
* If an implementation did send 'moni', it should use the T4 timer to control the frequency of the outgoing 'moni'.
* 如果实现确实发送了“moni”，则应使用T4计时器控制传出“moni”的频率。
* The receiver of the 'moni' should not make any assumptions as to the data portion of the 'moni'. The receiver should simply convert the 'moni' into a 'mona' and return the message with the same data portion.
* “moni”的接收者不应对“moni”的数据部分做出任何假设。接收方只需将“moni”转换为“mona”，并返回具有相同数据部分的消息。
TALI 2.0 implementations should use the 'moni' message to provide version identification as per the following bullets:
TALI 2.0实施应使用“moni”消息，根据以下项目符号提供版本标识：
* The primary purpose of the 'moni' message is now twofold:
* “moni”信息的主要目的现在有两个：
* To provide version identification
* 提供版本标识
* To continue to provide a general purpose ECHO capability that can be used to measure Round Trip time or perform other implementation specific tasks.
* 继续提供可用于测量往返时间或执行其他实施特定任务的通用回显功能。
* The data portion of the 'moni' message is now divided into 2 portions
* “moni”消息的数据部分现在分为两部分
* A portion dedicated to version identification, 12 bytes long, with a specific format that must be followed
* 专用于版本标识的部分，12字节长，必须遵循特定格式
* Followed by a free format section that can be used in a completely implementation specific manner.
* 然后是一个自由格式部分，可以以完全特定于实现的方式使用。
* The overall length of the data portion for a 'moni' should still not exceed 200 bytes. This is required to maintain backward compatibility with 1.0 implementations that may check for a maximum length of 200 bytes on the 'moni' opcode.
* “MOI”数据部分的总长度仍不应超过200字节。这是与1.0实现保持向后兼容性所必需的，1.0实现可以检查“moni”操作码上的最大长度为200字节。
* If a TALI implementation wants to identify itself as a version 2.0 node, it must send a 'moni' encoded as per Table 8. Every 'moni' it sends should conform to the encoding in Table 8. The version label should not change from 'moni' to 'moni'. The data following the version label can change from 'moni' to 'moni' and can continue to be used for RTT calculations, or other purposes.
* 如果TALI实现希望将自己标识为2.0版节点，则必须发送按照表8编码的“moni”。它发送的每个“moni”都应该符合表8中的编码。版本标签不应从“moni”更改为“moni”。版本标签后面的数据可以从“moni”更改为“moni”，并且可以继续用于RTT计算或其他目的。
* If a TALI implementation is trying to determine if the far end of the TALI connection has implemented version 2.0, the implementation must examine any received 'moni' messages that arrive from the far end and see if they conform to the new stricter 'moni' encoding in Table 8. On receiving 'moni', a TALI 2.0 node will compare the 12 bytes of data in the VER LABEL field with a list of predetermined strings to determine the functionality of the TALI node it is connected to. If the data doesn't match any of the predetermined strings, the Far End is assumed to be a TALI 1.0 node.
* 如果TALI实现试图确定TALI连接的远端是否已实现版本2.0，则该实现必须检查从远端收到的任何“moni”消息，并查看它们是否符合表8中新的更严格的“moni”编码。在接收到“moni”时，TALI 2.0节点将比较版本标签字段中的12字节数据与预定字符串列表，以确定其连接的TALI节点的功能。如果数据与任何预定字符串都不匹配，则假定远端为TALI 1.0节点。
* Each TALI implementation must assume that the far end of the connection is a 1.0 implementation until an arriving 'moni' announces that the far end supports TALI version 2.0. If a 'moni' never arrives, the implementation knows the far end has implemented version 1.0 of the specification.
* 每个TALI实现必须假定连接的远端是1.0实现，直到到达的“moni”宣布远端支持TALI版本2.0。如果“moni”从未到达，则实现知道远端已实现规范的1.0版。
* TALI 1.0 implementations can receive newly encoded 'moni' messages and simply ignore the data. The 1.0 implementations will continue to operate as if the far end is always a 1.0 node (ignore the data portion of the 'moni', convert 'moni' to 'mona', and return the 'mona').
* TALI 1.0实现可以接收新编码的“moni”消息，只需忽略数据即可。1.0实现将继续运行，就像远端始终是1.0节点一样（忽略“moni”的数据部分，将“moni”转换为“mona”，并返回“mona”）。
* The next section provides more information regarding backwards compatibility (2.0 implementations connected to devices that implemented version 1.0 of the specification).
* 下一节将提供有关向后兼容性的更多信息（2.0实现连接到实现本规范1.0版的设备）。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (includes the version | Integer |
| | | label and data fields) | |
+------------------------------------------------------------------+
| 10..21 | Ver. Label | 'vers xxx.yyy' | 12 byte |
| | See note | | ASCII |
+------------------------------------------------------------------+
| 22..X | DATA | Vendor Dependent | Variable |
| | | Maximum length of this | |
| | | message (as coded in octets 8| |
| | | -9, and stored in bytes 10-X)| |
| | | should not exceed 200 bytes. | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (includes the version | Integer |
| | | label and data fields) | |
+------------------------------------------------------------------+
| 10..21 | Ver. Label | 'vers xxx.yyy' | 12 byte |
| | See note | | ASCII |
+------------------------------------------------------------------+
| 22..X | DATA | Vendor Dependent | Variable |
| | | Maximum length of this | |
| | | message (as coded in octets 8| |
| | | -9, and stored in bytes 10-X)| |
| | | should not exceed 200 bytes. | |
+------------------------------------------------------------------+
Table 8: Version Control 'moni' Message
表8：版本控制“moni”消息
NOTE: xxx.yyy = provides the Major and Minor release number of the TALI specification being implemented. 001.000 = Tali version 1.0 002.000 = Tali version 2.0 // this specification. 002.001 = Tali version 2.1 // a minor change to 2.0 003.000 = Tali version 3.0 and so on.
注：xxx.yyy=提供正在实施的TALI规范的主要和次要版本号。001.000=塔利1.0版002.000=塔利2.0版//本规范。002.001=Tali版本2.1//2.0 003.000=Tali版本3.0的微小更改，依此类推。
The 'vers 002.000' field is an 12 byte field of field type 'ascii text'. As such, 'v' should be the first byte of the field that is transmitted out the wire.
“vers 002.000”字段是字段类型为“ascii文本”的12字节字段。因此，“v”应该是从导线传输的字段的第一个字节。
As part of adding new functionality to the TALI specification, backwards compatibility from TALI version 2.0 to version 1.0 is required. Backwards compatibility is important since TALI 2.0 nodes may be connected to far ends that only support version 1.0; it is important that these 2 implementations continue to inter-operate, and that the 2.0 node falls back to supporting only 1.0 opcodes in this situation.
作为向TALI规范添加新功能的一部分，需要从TALI版本2.0向后兼容到版本1.0。向后兼容性很重要，因为TALI 2.0节点可能连接到仅支持版本1.0的远端；重要的是，这两种实现继续相互操作，2.0节点在这种情况下只能支持1.0操作码。
The previous section described how a TALI 2.0 implementation can use the 'moni' it sends to identify itself as a 2.0 node and how it can use the 'moni' it receives to determine if the far end is also a 2.0
上一节描述了TALI 2.0实现如何使用其发送的“moni”将自己标识为2.0节点，以及如何使用其接收的“moni”确定远端是否也是2.0节点
node. In addition to the discussion in the previous section, the following bullets provide details regarding how backwards compatibility must be achieved:
节点。除上一节中的讨论外，以下项目符号提供了有关如何实现向后兼容性的详细信息：
* As documented in the version 1.0 specification, TALI 1.0 implementations that receive TALI messages with 'mgmt', 'xsrv', and 'spcl' opcodes will treat the message as a Protocol Violation (invalid opcode received). The Protocol Violation will cause the socket to be dropped immediately.
* 如1.0版规范所述，接收带有“mgmt”、“xsrv”和“spcl”操作码的TALI消息的TALI 1.0实现将把该消息视为协议冲突（接收到无效操作码）。违反协议将导致套接字立即丢弃。
* It is therefore required that a 2.0 implementation only send 'mgmt', 'xsrv', and 'spcl' opcodes, after it has used a received 'moni' message to determine that the far end is a 2.0 (or later) implementation and has identified itself as a 2.0 (or later) implementation.
* 因此，要求2.0实现仅在使用接收到的“moni”消息确定远端是2.0（或更高版本）实现并将自身标识为2.0（或更高版本）实现后发送“mgmt”、“xsrv”和“spcl”操作码。
* Each TALI 2.0 implementations must use the 'moni' as described in the previous section to identify themselves as 2.0, and to learn if the far end is 2.0.
* 每个TALI 2.0实现都必须使用上一节所述的“moni”来标识自己为2.0，并了解远端是否为2.0。
* Each TALI 2.0 implementation should maintain a variable as part of its state machine, 'far_end_version'. The 'far_end_version' should be initialized to 1.0 when the socket is established. Each time a 2.0 implementation receives 'moni', it should update the 'far_end_version' variable. If the 'moni' did not contain a version label, the 'far_end_version' should be reset to 1.0. If the 'moni' did contain a version label for 2.0 (or a later version), the 'far_end_version' should be set accordingly.
* 每个TALI 2.0实现都应该维护一个变量作为其状态机“far\u end\u version”的一部分。建立套接字时，“远端版本”应初始化为1.0。每次2.0实现接收到“moni”时，它都应该更新“far\u end\u version”变量。如果“moni”不包含版本标签，“far\u end\u版本”应重置为1.0。如果“moni”确实包含2.0（或更高版本）的版本标签，则应相应地设置“far\u end\u版本”。
* Each time a 2.0 implementation receives a new 2.0 opcode ('mgmt', 'xsrv', and 'spcl') from the far end, it should examine the ' far_end_version'. If the 'far_end_version' indicates the far end is a 1.0 implementation, the received TALI message should be treated as a Protocol Violation (invalid opcode). If the 'far_end_version' is 2.0 (or later), the 2.0 implementation should process the received 'mgmt/xsrv/spcl' according to that nodes capabilities for that opcode.
* 每次2.0实现从远端接收到新的2.0操作码（“mgmt”、“xsrv”和“spcl”），它都应该检查“远端版本”。如果“far_end_version”表示远端是1.0实现，则收到的TALI消息应视为协议冲突（操作码无效）。如果“far_end_version”为2.0（或更高版本），则2.0实现应根据该操作码的节点功能处理收到的“mgmt/xsrv/spcl”。
* Each time a 2.0 implementation receives a request to send a TALI message with a 2.0 opcode ('mgmt/xsrv/spcl') from a higher layer of software, it should examine the 'far_end_version'. If the 'far_end_version' indicates the far end is a 1.0 implementation, the request to send the 2.0 opcode should be denied or ignored (an implementation decision) and the 2.0 opcode must NOT be sent to the far end. If the 'far_end_version' indicates the far end is 2.0 (or later), the request can be satisfied and the TALI message with the 2.0 opcode can be sent to the far end.
* 每当2.0实现从更高层的软件接收到发送带有2.0操作码（“mgmt/xsrv/spcl”）的TALI消息的请求时，它应该检查“远端版本”。如果“远端版本”表示远端是1.0实现，则发送2.0操作码的请求应被拒绝或忽略（实现决定），且2.0操作码不得发送到远端。如果“far_end_version”表示远端为2.0（或更高版本），则可以满足请求，并且可以向远端发送带有2.0操作码的TALI消息。
* Each TALI 2.0 implementation can provide a varying level of support for each of the three new 2.0 opcodes ('mgmt/xsrv/spcl'). In other words, an implementation may wish to only support SOME OF the primitives within the new opcodes. The level of support for each 2.0 opcode ('mgmt/xsrv/spcl') is independent of the other two 2.0 opcodes.
* 每个TALI 2.0实现都可以为三个新的2.0操作码（“mgmt/xsrv/spcl”）中的每一个提供不同级别的支持。换句话说，实现可能希望只支持新操作码中的一些原语。每个2.0操作码（“mgmt/xsrv/spcl”）的支持级别独立于其他两个2.0操作码。
* The basic message structure for TALI messages using the new 2.0 opcodes is presented in Table 9.
* 使用新2.0操作码的TALI消息的基本消息结构如表9所示。
* The minimal level of support that is required for each of the 2.0 opcodes (mgmt/xsrv/spcl) is to be able to receive TALI messages with these opcodes, recognize the new opcode, and ignore the message without affecting the state machine. The TALI state should not change. The socket connection should stay up. In other words, a 2.0 implementation can elect to ignore any received 'mgmt/xsrv/spcl' messages, if that implementation does not care to support the capability intended by that particular opcode.
* 每个2.0操作码（mgmt/xsrv/spcl）所需的最低支持级别是能够使用这些操作码接收TALI消息，识别新操作码，并在不影响状态机的情况下忽略消息。TALI状态不应改变。插座连接应保持正常。换句话说，2.0实现可以选择忽略任何接收到的“mgmt/xsrv/spcl”消息，如果该实现不关心支持该特定操作码预期的功能。
* A partial level of support for a 2.0 opcode could be implemented. Partial support may consist of understanding the data structure for the 2.0 opcode, but only supporting some of the variants of the opcode. The message structure for each of the new 2.0 opcodes consists of an extra 'Primitive' field that follows the TALI opcode and message length fields. Each 'Primitive' is used to differentiate a variant of the opcode. It is envisioned that each new 2.0 opcode can be extended by adding new 'Primitives', as more capabilities are defined for the opcode, without having to add new TALI opcodes. A 2.0 implementation may understand and be willing to act on some of the 'Primitives' for an opcode, but not others. Receiving variants of a 2.0 opcode that an implementation does not understand need to be ignored and not affect the 2.0 state machine.
* 可以实现对2.0操作码的部分支持。部分支持可能包括理解2.0操作码的数据结构，但仅支持部分操作码变体。每个新2.0操作码的消息结构都包含一个额外的“基元”字段，该字段位于TALI操作码和消息长度字段之后。每个“原语”用于区分操作码的变体。可以预见，每个新的2.0操作码都可以通过添加新的“原语”来扩展，因为操作码定义了更多的功能，而无需添加新的TALI操作码。2.0实现可能理解并愿意对操作码的某些“原语”采取行动，但不理解其他“原语”。需要忽略接收实现不理解的2.0操作码变体，并且不影响2.0状态机。
* The full level of support for a 2.0 opcode could be implemented. This support would consist of understanding and fully supporting every 'Primitive' within the 2.0 opcode.
* 可以实现对2.0操作码的全面支持。这种支持包括理解并完全支持2.0操作码中的每个“原语”。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt', 'xsrv' or 'spcl' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (length of the rest | Integer |
| | | of this packet) | |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'wxyz', or a 4 byte text | 4 byte |
| | See note | that is appropriate for the | ASCII |
| | | given opcode | |
+------------------------------------------------------------------+
| 14..X | DATA | The content of the data area | Variable |
| | | is dependent on the opcode/ | |
| | | primitive combination | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt', 'xsrv' or 'spcl' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (length of the rest | Integer |
| | | of this packet) | |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'wxyz', or a 4 byte text | 4 byte |
| | See note | that is appropriate for the | ASCII |
| | | given opcode | |
+------------------------------------------------------------------+
| 14..X | DATA | The content of the data area | Variable |
| | | is dependent on the opcode/ | |
| | | primitive combination | |
+------------------------------------------------------------------+
Table 9: Basic Message Structure for New 2.0 TALI Opcodes
表9：新2.0 TALI操作码的基本消息结构
NOTE: The Primitive field acts as a modifier for each opcode. Within an opcode, different operations or groups of operations can be defined and supported. The Primitive identifies each different operation or set of operations.
注意：基元字段充当每个操作码的修饰符。在操作码中，可以定义和支持不同的操作或操作组。原语标识每个不同的操作或操作集。
As implied by some of the bullets before Table 9, it is a goal of the 2.0 TALI specification to relax some of the error checking associated with the processing of received TALI messages.
正如表9之前的一些项目符号所暗示的，2.0 TALI规范的目标是放松与处理接收到的TALI消息相关的一些错误检查。
Version 1.0 of this specification was very strict in detailing the fields that were checked for each received message. As each received message was processed, the SYNC code, opcode and length field of the message was checked; if any of these fields were invalid an internal protocol violation was generated. The processing of the protocol violation caused the socket to go down. In addition to the 3 specific checks (sync, opcode, length), the overall philosophy of version 1.0 was to treat any received data that the receiver did not understand, or which the receiver deemed to contain incorrectly coded fields as protocol violations.
本规范的1.0版在详细说明为每个收到的消息检查的字段方面非常严格。在处理每个接收到的消息时，检查消息的同步码、操作码和长度字段；如果其中任何字段无效，则会生成内部协议冲突。协议冲突的处理导致套接字关闭。除了3种特定检查（同步、操作码、长度）外，版本1.0的总体理念是将接收器不理解的任何接收数据或接收器认为包含错误编码字段的任何接收数据视为违反协议。
Version 2.0 introduces the possibility of partial support for opcodes, partial support for primitives, and partial support for various fields (such as support for ANSI Pt Codes, but not ITU Pt Codes). Thus, the overall philosophy of how to treat received data that the receiver does not support needs to be relaxed from the
版本2.0引入了部分支持操作码、部分支持原语和部分支持各种字段的可能性（例如支持ANSI Pt代码，但不支持ITU Pt代码）。因此，如何处理接收器不支持的接收数据的总体原理需要从
strict treatment in version 1.0. Version 2.0 implementations should be more tolerant when they receive messages they do not support (or which they believe contain incorrectly coded fields). This tolerance should include NOT treating these receives as protocol violations.
版本1.0中的严格处理。当版本2.0实现接收到不支持的消息（或者认为包含错误编码的字段）时，应该更加宽容。该容差应包括不将这些接收视为违反协议。
Version 2.0 implementations should perform the following level of strict/loose checks on the received messages:
版本2.0的实施应对收到的消息执行以下严格/松散检查：
* Checks against the sync codes, opcodes and lengths for version 1.0 and version 2.0 opcodes should be performed (against Table 3 and Table 11). Invalid data in these fields should be treated as cause for protocol violations.
* 应对1.0版和2.0版操作码的同步码、操作码和长度进行检查（对照表3和表11）。这些字段中的无效数据应被视为违反协议的原因。
* Checks against the opcode field for messages with new 2.0 opcodes (mgmt/xsrv/spcl) should be performed to determine whether the message can be processed by the implementation. If an implementation chooses to NOT support a particular 2.0 opcode, the received message should be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 应针对带有新2.0操作码（mgmt/xsrv/spcl）的消息的操作码字段进行检查，以确定实现是否可以处理该消息。如果实现选择不支持特定的2.0操作码，则应丢弃接收到的消息，内部数据（如测量、消息日志、用户通知）可记录事件，且TALI状态不应受到影响。
* Checks against the primitive field for messages with new 2.0 opcodes (mgmt/xsrv/spcl) should be performed to determine whether the message can be processed by the implementation. If an implementation does not understand a particular primitive, or has chosen NOT to implement the features for a particular primitive, the received message should be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 应针对带有新2.0操作码（mgmt/xsrv/spcl）的消息的原始字段进行检查，以确定实现是否可以处理该消息。如果实现不理解特定原语，或选择不实现特定原语的功能，则应丢弃接收到的消息，内部数据（如测量、消息日志、用户通知）可记录事件，且TALI状态不应受到影响。
* Checks against other field types in messages with new 2.0 opcodes (such as checking the encoding of a Point Code field for a valid Pt Code type) should also be performed in a 'soft' manner. Errors found in individual fields should cause the received message to be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 使用新的2.0操作码检查消息中的其他字段类型（例如检查点代码字段的编码是否为有效的Pt代码类型），也应以“软”方式执行。在单个字段中发现的错误应导致丢弃接收到的消息，内部数据（如测量、消息日志、用户通知）可能会记录事件，并且TALI状态不应受到影响。
The goals behind introducing this gentler treatment of errors in received data are as follows:
采用这种更温和的方法处理接收数据中的错误的目的如下：
* To keep the socket up in order to perform the primary purpose of the connection (ie: to continue to transport SS7 data) in spite of improperly formatted/unsupported TALI messages related to other features/extensions/etc.
* 尽管与其他功能/扩展等相关的TALI消息格式不正确/不受支持，但仍保持套接字正常运行，以实现连接的主要目的（即：继续传输SS7数据）。
* To allow applications to support and use some of the features for a particular TALI revision without requiring the application to implement all of the functionality for the TALI revision.
* 允许应用程序支持和使用特定TALI版本的某些功能，而无需应用程序实现TALI版本的所有功能。
* To increase the extensibility of the protocol. Looser receive checks are preferred in order to be able to add new primitives and new primitive operations as they are defined.
* 以增加协议的可扩展性。为了能够根据定义添加新的原语和新的原语操作，最好使用更宽松的接收检查。
The basic message structure for all TALI messages is unchanged with the addition of new 2.0 opcodes. The base TALI header still consists of SYNC + OPCODE + LENGTH, as described in Table 2.
所有TALI消息的基本消息结构不变，添加了新的2.0操作码。基本TALI头仍然由SYNC+操作码+长度组成，如表2所述。
The message structure for the new 2.0 opcodes was shown in Table 9. These messages define an extra required field, PRIMITIVE, that follows the LENGTH field of Table 2.
新2.0操作码的消息结构如表9所示。这些消息定义了一个额外的必填字段PRIMITIVE，它位于表2的LENGTH字段之后。
Table 4 in the version 1.0 specification provided implementation notes for all the 'types of fields' found in the 1.0 specification. Version 2.0 of TALI continues to use all of the types provided in Table 4, and also defines some new fields that are used in TALI messages that use the new 2.0 opcodes. The following table introduces the new field types that are introduced with version 2.0. The types in Table 10 are used in addition to the types in Table 4 to implement the 2.0 TALI protocol.
1.0版规范中的表4提供了1.0版规范中所有“字段类型”的实现说明。TALI 2.0版继续使用表4中提供的所有类型，并定义了一些新字段，这些字段在使用新2.0操作码的TALI消息中使用。下表介绍了2.0版引入的新字段类型。除了表4中的类型外，还使用表10中的类型来实现2.0 TALI协议。
+-----------+------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|SS7 Point | Used to transmit point code information for ANSI or |
|Code | ITU variants of point codes across the TALI interface|
| | * The point code structure is 4 bytes. Byte 3 is used|
| | to identify the TYPE of point code. The actual |
| | point code is then encoded in bytes 0-2 (w/byte 0 |
| | being the least significant byte and the first byte|
| | transmitted across the wire) |
| | * Byte 3: encoding of the type of point code (PC) |
| | 0 = an ANSI Full PC |
| | 1 = an ITU International Full PC w/ a 3/8/3 coding |
| | scheme for zone/area/identifier |
| | 2 = an ITU National Full PC w/ a raw 14 bit PC |
| | 3 = unused |
| | 4 = an ANSI Cluster PC |
| | * For ANSI Full PC w/byte 3=0. These point codes are|
| | 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = Member |
| | * For ITU International Full PC (3/8/3) w/byte 3=1. |
| | These point codes use 14 bits (stored in the 14 |
| | least significant bits in bytes 0&1). Byte 2 is |
| | unused. The 14 bits should be interpreted as 3 |
| | bits of zone, 8 bits of area and 3 bits of |
| | signaling point identifier. The 3 bits of |
| | signaling point identifier are the 3 least |
| | significant bits. |
| | * For ITU National Full PC w/byte 3=2. These point |
| | codes use 14 bits (stored in the 14 least |
| | significant bits in bytes 0&1). Byte 2 is unused. |
| | The 14 bits represent a single 14-bit quantity that|
| | constitutes the point code. |
| | * For unused w/byte 3=3. Bytes 0 through 2 are |
| | undefined. |
| | * For ANSI Cluster PC, w/byte 3=4. These point codes|
| | are 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = 0. This field is ignored and should be |
| | coded as 0...all members of the cluster are implied|
| | * Byte 0 is the first byte that is transmitted across|
| | the wire, followed by byte 1, byte 2, then byte 3. |
+-----------+------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|SS7 Point | Used to transmit point code information for ANSI or |
|Code | ITU variants of point codes across the TALI interface|
| | * The point code structure is 4 bytes. Byte 3 is used|
| | to identify the TYPE of point code. The actual |
| | point code is then encoded in bytes 0-2 (w/byte 0 |
| | being the least significant byte and the first byte|
| | transmitted across the wire) |
| | * Byte 3: encoding of the type of point code (PC) |
| | 0 = an ANSI Full PC |
| | 1 = an ITU International Full PC w/ a 3/8/3 coding |
| | scheme for zone/area/identifier |
| | 2 = an ITU National Full PC w/ a raw 14 bit PC |
| | 3 = unused |
| | 4 = an ANSI Cluster PC |
| | * For ANSI Full PC w/byte 3=0. These point codes are|
| | 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = Member |
| | * For ITU International Full PC (3/8/3) w/byte 3=1. |
| | These point codes use 14 bits (stored in the 14 |
| | least significant bits in bytes 0&1). Byte 2 is |
| | unused. The 14 bits should be interpreted as 3 |
| | bits of zone, 8 bits of area and 3 bits of |
| | signaling point identifier. The 3 bits of |
| | signaling point identifier are the 3 least |
| | significant bits. |
| | * For ITU National Full PC w/byte 3=2. These point |
| | codes use 14 bits (stored in the 14 least |
| | significant bits in bytes 0&1). Byte 2 is unused. |
| | The 14 bits represent a single 14-bit quantity that|
| | constitutes the point code. |
| | * For unused w/byte 3=3. Bytes 0 through 2 are |
| | undefined. |
| | * For ANSI Cluster PC, w/byte 3=4. These point codes|
| | are 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = 0. This field is ignored and should be |
| | coded as 0...all members of the cluster are implied|
| | * Byte 0 is the first byte that is transmitted across|
| | the wire, followed by byte 1, byte 2, then byte 3. |
+------------------------------------------------------------------+
|Bit-Field | * Field containing an array of N bits, where N is a |
| | multiple of 8. Bit-Field types should be |
| | transmitted such that the byte containing bits 0 |
| | through 7 is transmitted across the wire first, |
| | followed by the byte containing bits 8 through 15, |
| | etc. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor need|
| | to be dealt with in the software). |
+------------------------------------------------------------------+
|Version |A TALI version label is a 12 byte ASCII text field. |
|Label |The label is of a format 'vers xxx.yyy', where xxx.yyy|
| |are used to identify the version such as 002.000. As |
| |with other ASCII text fields, the first byte of the |
| |text field (the 'v') should be the first byte |
| |transmitted out the wire. |
+------------------------------------------------------------------+
|Primitive |Messages that use the new TALI 2.0 opcodes all have a |
| |4 byte text ASCII field referred to as a Primitive. |
| |The Primitive acts as a modifier for the opcode. This |
| |allows a single opcode to be used to perform multiple |
| |actions. |
+------------------------------------------------------------------+
|Primitive |A Primitive can be used to specify either a specific |
|Operation |action or a set of actions. When the Primitive field |
| |is used to specify a set of actions, an operation |
| |field is used to pick a specific operation within that|
| |group of actions. Operation fields are 4 byte integers|
+------------------------------------------------------------------+
|Private |Various RFC documents have detailed a set of assigned |
|Enterprise |numbers (RFC 1700, Assigned Numbers) and defined data |
|Code |structures (RFC 1155, Structure and Identification of |
|(PEC) |Management Information for IP-based Internets) |
| |that are used on IP networks to provide network |
| |management information. |
| |Network Management Object Identifiers (OID) are used |
| |to recognize specific organizations, companies, |
| |protocols, and so on, in a manner that all vendors can|
| |agree on. |
| |An Object Identifier exists which uniquely describes |
| |each company that does business in the data/telecomm |
| |industry. That OID is referred to as an 'SMI Network |
| |Management Private Enterprise Code', which we are |
| |shortening to Private Enterprise Code of PEC in this |
| |document for simplicity. Each PEC is assumed to have |
+------------------------------------------------------------------+
|Bit-Field | * Field containing an array of N bits, where N is a |
| | multiple of 8. Bit-Field types should be |
| | transmitted such that the byte containing bits 0 |
| | through 7 is transmitted across the wire first, |
| | followed by the byte containing bits 8 through 15, |
| | etc. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor need|
| | to be dealt with in the software). |
+------------------------------------------------------------------+
|Version |A TALI version label is a 12 byte ASCII text field. |
|Label |The label is of a format 'vers xxx.yyy', where xxx.yyy|
| |are used to identify the version such as 002.000. As |
| |with other ASCII text fields, the first byte of the |
| |text field (the 'v') should be the first byte |
| |transmitted out the wire. |
+------------------------------------------------------------------+
|Primitive |Messages that use the new TALI 2.0 opcodes all have a |
| |4 byte text ASCII field referred to as a Primitive. |
| |The Primitive acts as a modifier for the opcode. This |
| |allows a single opcode to be used to perform multiple |
| |actions. |
+------------------------------------------------------------------+
|Primitive |A Primitive can be used to specify either a specific |
|Operation |action or a set of actions. When the Primitive field |
| |is used to specify a set of actions, an operation |
| |field is used to pick a specific operation within that|
| |group of actions. Operation fields are 4 byte integers|
+------------------------------------------------------------------+
|Private |Various RFC documents have detailed a set of assigned |
|Enterprise |numbers (RFC 1700, Assigned Numbers) and defined data |
|Code |structures (RFC 1155, Structure and Identification of |
|(PEC) |Management Information for IP-based Internets) |
| |that are used on IP networks to provide network |
| |management information. |
| |Network Management Object Identifiers (OID) are used |
| |to recognize specific organizations, companies, |
| |protocols, and so on, in a manner that all vendors can|
| |agree on. |
| |An Object Identifier exists which uniquely describes |
| |each company that does business in the data/telecomm |
| |industry. That OID is referred to as an 'SMI Network |
| |Management Private Enterprise Code', which we are |
| |shortening to Private Enterprise Code of PEC in this |
| |document for simplicity. Each PEC is assumed to have |
| |a defined prefix of |
| |'iso.org.dod.internet.private.enterprise' or |
| |(1.3.6.1.4.1). |
| | |
| |The PEC for each company can be found via a file at: |
| |ftp://ftp.isi.edu/in-notes/iana/assignments/ |
| | enterprise-numbers |
| | |
| |To encode the PEC for a vendor in each implementation |
| |of TALI, a 2 byte integer field is used. The contents|
| |of the integer field should match the PEC code for |
| |that company in the file mentioned above. |
| | |
| |For example, Tekelec, which has a PEC of 323, will |
| |code this 2 byte field as '0x0143'. |
| | |
| |Like other integer fields, the PEC value is |
| |transmitted Least Significant Byte first across the |
| |ethernet wire. |
+------------------------------------------------------------------+
| |a defined prefix of |
| |'iso.org.dod.internet.private.enterprise' or |
| |(1.3.6.1.4.1). |
| | |
| |The PEC for each company can be found via a file at: |
| |ftp://ftp.isi.edu/in-notes/iana/assignments/ |
| | enterprise-numbers |
| | |
| |To encode the PEC for a vendor in each implementation |
| |of TALI, a 2 byte integer field is used. The contents|
| |of the integer field should match the PEC code for |
| |that company in the file mentioned above. |
| | |
| |For example, Tekelec, which has a PEC of 323, will |
| |code this 2 byte field as '0x0143'. |
| | |
| |Like other integer fields, the PEC value is |
| |transmitted Least Significant Byte first across the |
| |ethernet wire. |
+------------------------------------------------------------------+
Table 10: Implementation for new field types introduced in TALI 2.0
表10:TALI 2.0中引入的新字段类型的实现
The message structures for opcodes defined in version 1.0 of TALI are unchanged from the information presented earlier, with the exception of the 'moni' message. The 2.0 format for the 'moni' message was described earlier.
TALI版本1.0中定义的操作码的消息结构与前面提供的信息相同，但“moni”消息除外。“moni”消息的2.0格式在前面已经描述过。
Detailed message structures, and discussion of the capabilities, for each of the new 2.0 opcodes is provided in the following sections. Before discussing each opcode individually, Table 11 provides the minimum and maximum value of the LENGTH field that should be supported for each new opcode (as well as 'moni/mona'). Table 11 additionally shows the impact of ITU support that was added in 2.0. The routing label for ITU point codes only uses 4 octets instead of 7 octets as ANSI requires.
以下各节提供了每个新2.0操作码的详细消息结构和功能讨论。在单独讨论每个操作码之前，表11提供了每个新操作码（以及“moni/mona”）应支持的长度字段的最小值和最大值。表11还显示了2.0中添加的ITU支持的影响。ITU点代码的路由标签仅使用4个八位字节，而不是ANSI要求的7个八位字节。
+------------------------------------------------------------------+
| Opcode | Valid Length | Comments |
| | Field Values | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | The overall length of the data portion |
| | | for 'moni' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | The overall length of the data portion |
| | | for 'mona' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mgmt | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| xsrv | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| spcl | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| sccp | 9-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT MSUs. |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| mtp3 | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Opcode | Valid Length | Comments |
| | Field Values | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | The overall length of the data portion |
| | | for 'moni' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | The overall length of the data portion |
| | | for 'mona' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mgmt | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| xsrv | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| spcl | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| sccp | 9-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT MSUs. |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| mtp3 | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| saal | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
| | | Seven (7) octets of SSCOP trailer is |
| | | added to the message. The SSCOP trailer |
| | | bytes are also included in the length. |
+------------------------------------------------------------------+
| saal | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
| | | Seven (7) octets of SSCOP trailer is |
| | | added to the message. The SSCOP trailer |
| | | bytes are also included in the length. |
+------------------------------------------------------------------+
Table 11: Valid Length Fields for Opcodes Affected by TALI 2.0
表11：受TALI 2.0影响的操作码的有效长度字段
The 'mgmt' opcode is intended to allow Management data, or data that will manage the operation of the device, to pass between the TALI endpoints over the socket connection. 'mgmt' messages can be received and processed in any of the TALI NEx-FEx states. Three PRIMITIVES are defined for use with this opcode:
“mgmt”操作码旨在允许管理数据或将管理设备操作的数据通过套接字连接在TALI端点之间传递。”管理信息可以在任何TALI NEx FEx状态下接收和处理。定义了三个原语用于此操作码：
* 'rkrp' - Routing Key Registration Primitive. This primitive allows the nodes to configure the SS7 traffic streams that they wish to receive over each socket. This 'routing key registration' is performed in-band, via TALI messages.
* “rkrp”-路由密钥注册原语。此原语允许节点配置希望通过每个套接字接收的SS7通信流。此“路由密钥注册”通过TALI消息在频带内执行。
* 'mtpp' - MTP3 Primitives. This primitive allows SS7 MTP3 network management messages regarding the (un)availability and congestion states of SS7 devices to be passed to the IP devices SG.
* “mtpp”-MTP3原语。此原语允许将有关SS7设备的（un）可用性和拥塞状态的SS7 MTP3网络管理消息传递给IP设备SG。
* 'sorp' - Socket Options Registration Primitive. This primitive allows various socket options to be enabled/disabled by each TALI device.
* “sorp”-套接字选项注册原语。此原语允许每个TALI设备启用/禁用各种套接字选项。
As of version 2.0, the only defined primitives for the 'mgmt' opcode are 'rkrp', 'mtpp', and 'sorp'. In the future, more primitives can be added to this opcode to extend the Management capabilities of the SG or IP devices. The basic message structure for the 2.0 'mgmt' messages for all 3 of these primitives is as follows:
从版本2.0开始，“mgmt”操作码的唯一定义原语是“rkrp”、“mtpp”和“sorp”。将来，可以向该操作码添加更多原语，以扩展SG或IP设备的管理功能。所有3个原语的2.0“管理”消息的基本消息结构如下所示：
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp', 'mtpp' or 'sorp' Each of these |
| | | primitives specify a group of applicable |
| | | management operations. |
+------------------------------------------------------------------+
| 14..17 | Primitive | The operation field specifies the one |
| | Operation | operation within the group of operations |
| | | identified by the primitive. |
+------------------------------------------------------------------+
| 18.. | Message | The content of the message data area is |
| | Data | dependent on the combination of opcode/ |
| | | primitive/operation fields. Each of those|
| | | combinations could use a different message|
| | | data structure. |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp', 'mtpp' or 'sorp' Each of these |
| | | primitives specify a group of applicable |
| | | management operations. |
+------------------------------------------------------------------+
| 14..17 | Primitive | The operation field specifies the one |
| | Operation | operation within the group of operations |
| | | identified by the primitive. |
+------------------------------------------------------------------+
| 18.. | Message | The content of the message data area is |
| | Data | dependent on the combination of opcode/ |
| | | primitive/operation fields. Each of those|
| | | combinations could use a different message|
| | | data structure. |
+------------------------------------------------------------------+
Table 12: Message Structure for 'mgmt' opcode
表12：“管理”操作码的消息结构
The 'rkrp' primitive allows IP nodes to modify the application routing key table in the SG by sending TALI messages to configure the SS7 traffic streams that they wish to receive over each socket. This 'routing key registration' is performed in-band, via TALI messages, as an alternative to using the SG user interface to configure the routing keys.
“rkrp”原语允许IP节点通过发送TALI消息来配置他们希望通过每个套接字接收的SS7流量流，从而修改SG中的应用程序路由密钥表。该“路由密钥注册”通过TALI消息在频带内执行，作为使用SG用户界面配置路由密钥的替代方案。
Recall from earlier discussion in this document that the specification supports five (5) types of fully specified routing keys:
回顾本文件前面的讨论，本规范支持五（5）种完全指定的路由密钥：
* A key for SCCP traffic, where key = DPC-SI-SSN, where SI=3.
* SCCP通信量的密钥，其中key=DPC-SI-SSN，其中SI=3。
* A key for ISUP traffic, where key = DPC-SI-OPC-CIC Range, where SI=5. The CIC values for traditional ISUP are 14 bit quantities in ANSI networks and 12 bit quantities in ITU networks.
* ISUP通信量的密钥，其中密钥=DPC-SI-OPC-CIC范围，其中SI=5。传统ISUP的CIC值在ANSI网络中为14位，在ITU网络中为12位。
* A key for TUP traffic, where key = DPC-SI-OPC-CIC Range, where SI=4. This key is only supported for ITU networks. The CIC values for TUP keys are 12 bit quantities in ITU networks.
* 用于TUP流量的密钥，其中密钥=DPC-SI-OPC-CIC范围，其中SI=4。此密钥仅适用于ITU网络。在ITU网络中，TUP密钥的CIC值为12位量。
* A key for QBICC traffic (an extension of ISUP which uses 32 bit CIC codes), where key = DPC-SI-OPC-CIC, where SI=13. The CIC values for QBICC keys are 32 bit quantities for ANSI and ITU networks.
* QBICC通信量的密钥（ISUP的扩展，使用32位CIC代码），其中密钥=DPC-SI-OPC-CIC，其中SI=13。对于ANSI和ITU网络，QBICC密钥的CIC值为32位量。
* A key for OTHER-MTP3-SI (non-SCCP, non-ISUP, non-QBICC for ANSI and non-SCCP, non-ISUP, non-QBICC, non-TUP for ITU) traffic, where key = DPC-SI
* OTHER-MTP3-SI（ANSI为非SCCP、非ISUP、非QBICC，ITU为非SCCP、非ISUP、非QBICC、非TUP）流量的密钥，其中密钥=DPC-SI
Each of these keys is fully specified key where the exact content of the MSU to be routed must match the data in the routing key.
每个密钥都是完全指定的密钥，其中要路由的MSU的确切内容必须与路由密钥中的数据匹配。
Extensions to the routing keys have been added that will support 'partial match' or 'default' routing keys. The purpose of these extensions is to improve the handling of MSU traffic when no fully specified routing key exists that matches the MSU. Partial match and default routing keys are used when the SG can not find a fully specified routing key that can be used to route an MSU. Partial match keys can be used to provide closest-match routing such as 'ignore the CIC' for ISUP/QBICC/TUP traffic, or 'ignore the SSN' for SCCP traffic. Default keys are used when no full or partial routing key has been found as a last resort destination to route the MSU to.
已添加支持“部分匹配”或“默认”路由密钥的路由密钥扩展。这些扩展的目的是在不存在与MSU匹配的完全指定的路由密钥时，改进MSU流量的处理。当SG无法找到可用于路由MSU的完全指定的路由密钥时，将使用部分匹配和默认路由密钥。部分匹配密钥可用于提供最接近的匹配路由，如ISUP/QBICC/TUP流量的“忽略CIC”，或SCCP流量的“忽略SSN”。当没有找到完整或部分路由密钥作为MSU路由到的最后目的地时，将使用默认密钥。
The types of partial and default keys defined by the protocol are discussed in the following table. The 4th column in the table indicates the data structure that is used in the TALI rkrp message to perform operations on each partial/default key type. Note: The order of the keys in the table (from top to bottom) matches the hierarchical search order that an SG will use to attempt to find a routing key to use for an MSU. The partial and default keys are only used after attempting to find a fully specified key that matches the MSU.
下表讨论了协议定义的部分密钥和默认密钥的类型。表中第4列表示TALI rkrp消息中用于对每个部分/默认键类型执行操作的数据结构。注意：表中键的顺序（从上到下）与SG尝试查找用于MSU的路由键时使用的分层搜索顺序相匹配。只有在尝试查找与MSU匹配的完全指定密钥后，才会使用部分密钥和默认密钥。
+--------+------------+--------------------------------+-----------+
|Key | Key | Comments | Cross |
|Type | Attributes | | Reference |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI-OPC |Used as backup routes for CIC | 4.5.1.1.2 |
| | |based traffic (but ignoring the | |
| | |CIC field). | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI |Used as backup routes for CIC | 4.5.1.1.4 |
| | |based or SCCP traffic (but | |
| | |ignoring the OPC-CIC or SSN). | |
| | |Routes traffic based solely on | |
| | |DPC and SI of the MSU. | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the DPC field. | |
+--------+------------+--------------------------------+-----------+
|Partial | SI |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the SI field. | |
+--------+------------+--------------------------------+-----------+
|Default | - |If no other type of routing key | 4.5.1.1.5 |
| | |for an MSU can be found, use | |
| | |this one. | |
+--------+------------+--------------------------------+-----------+
+--------+------------+--------------------------------+-----------+
|Key | Key | Comments | Cross |
|Type | Attributes | | Reference |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI-OPC |Used as backup routes for CIC | 4.5.1.1.2 |
| | |based traffic (but ignoring the | |
| | |CIC field). | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI |Used as backup routes for CIC | 4.5.1.1.4 |
| | |based or SCCP traffic (but | |
| | |ignoring the OPC-CIC or SSN). | |
| | |Routes traffic based solely on | |
| | |DPC and SI of the MSU. | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the DPC field. | |
+--------+------------+--------------------------------+-----------+
|Partial | SI |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the SI field. | |
+--------+------------+--------------------------------+-----------+
|Default | - |If no other type of routing key | 4.5.1.1.5 |
| | |for an MSU can be found, use | |
| | |this one. | |
+--------+------------+--------------------------------+-----------+
Table 13: Partial and Default Routing Keys (in hierarchical order)
表13：部分和默认路由键（按层次顺序）
The specific capability requested in each 'rkrp' message is indicated via an 'RKRP Operation' field. These capabilities include:
每个“rkrp”消息中请求的特定能力通过“rkrp操作”字段表示。这些能力包括：
* ENTER: The ENTER operation creates an association between a specific socket and a specific application routing key. The socket of the association is always the socket that the 'rkrp' was received on. The application routing key identifies an SS7 traffic stream that should be carried over that socket. Multiple sockets can be associated with the same application routing key, if so, they all receive traffic in a 'load sharing' mode. An override field can be used to remove any other socket associations for a particular routing key and add a single socket association. The ENTER operation is applicable for fully specified SCCP keys, CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and all types of partial keys and to the default routing key.
* 输入：输入操作在特定套接字和特定应用程序路由密钥之间创建关联。关联的套接字始终是接收“rkrp”的套接字。应用程序路由密钥标识应通过该套接字承载的SS7通信流。多个套接字可以与同一个应用程序路由密钥相关联，如果是，则它们都以“负载共享”模式接收流量。覆盖字段可用于删除特定路由密钥的任何其他套接字关联，并添加单个套接字关联。ENTER操作适用于完全指定的SCCP密钥、基于CIC的密钥（ISUP、Q.BICC和TUP）、OTHER-MTP3-SI密钥以及所有类型的部分密钥和默认路由密钥。
* DELETE: The DELETE operation deletes an association between a specific socket and a specific application routing key. The socket of the association is always the socket that the 'rkrp' was
* 删除：删除操作删除特定套接字和特定应用程序路由密钥之间的关联。关联的套接字始终是“rkrp”所在的套接字
received on. Other socket associations for the same application routing key are NOT affected by the deletion. When the last socket association for a routing key is deleted, the entire routing key entry is removed from the database. The DELETE operation operation is applicable for fully specified SCCP keys, CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and all types of partial keys and to the default routing key.
于收到。相同应用程序路由密钥的其他套接字关联不受删除的影响。删除路由密钥的最后一个套接字关联时，将从数据库中删除整个路由密钥条目。删除操作适用于完全指定的SCCP密钥、基于CIC的密钥（ISUP、Q.BICC和TUP）、OTHER-MTP3-SI密钥以及所有类型的部分密钥和默认路由密钥。
* SPLIT: The SPLIT operation is used to convert a single application routing key into 2 application routing keys that together cover the same SS7 traffic stream as the original key. Immediately after a split is performed, both of the resulting entries retain the same socket associations as the original routing key. When the split is completed, the socket associations can be modified for each of the 2 resulting ranges independent of the other range. The split operation is only applicable to fully specified CIC based keys (ISUP, QBICC, and TUP). Each fully specified CIC based key is uniquely identified by the combination of DPC/SI/OPC/CIC range. The CIC range is a continuous set of numbers from CICS(start) to CICE(end); the CIC range in the application routing key corresponds to the CIC value in a CIC based MSU.
* 拆分：拆分操作用于将单个应用程序路由密钥转换为两个应用程序路由密钥，它们共同覆盖与原始密钥相同的SS7通信流。执行拆分后，两个结果项立即保留与原始路由密钥相同的套接字关联。分割完成后，可以为两个结果范围中的每一个修改套接字关联，这两个范围独立于其他范围。拆分操作仅适用于完全指定的基于CIC的密钥（ISUP、QBICC和TUP）。每个完全指定的基于CIC的密钥通过DPC/SI/OPC/CIC范围的组合进行唯一标识。CIC范围是从CICS（开始）到CICE（结束）的一组连续数字；应用程序路由密钥中的CIC范围对应于基于CIC的MSU中的CIC值。
* RESIZE: The RESIZE operation is used to modify the CIC range in for a single application routing key. The resize operation is only applicable to fully specified CIC based routing keys. The resize operation replaces the CICS/CICE values for a routing key with a new CIC range (NCICS/NCICE). A wide variety of NCICS/NCICE ranges can be supported based on the existing CICS/CICE; just about the only restriction is that the new range can not already exist in the database and can not overlap any other entry in the database. The socket associations for the routing key are NOT affected by the change in CICS/CICE. The SPLIT operation is applicable only to fully specified CIC based keys (ISUP, Q.BICC, and TUP).
* 调整大小：调整大小操作用于修改中单个应用程序路由密钥的CIC范围。调整大小操作仅适用于完全指定的基于CIC的路由密钥。调整大小操作将路由密钥的CICS/CICE值替换为新的CIC范围（NCICS/NCICE）。基于现有CICS/CICE，可以支持多种NCICS/NCICE范围；唯一的限制是新范围不能已经存在于数据库中，并且不能与数据库中的任何其他条目重叠。路由密钥的套接字关联不受CICS/CICE中更改的影响。拆分操作仅适用于完全指定的基于CIC的密钥（ISUP、Q.BICC和TUP）。
The list of RKRP Operations (and their encodings) that are supported for TALI version 2.0 is as follows:
TALI 2.0版支持的RKRP操作（及其编码）列表如下：
0x0001 - ENTER ISUP KEY 0x0002 - DELETE ISUP KEY 0x0003 - SPLIT ISUP KEY 0x0004 - RESIZE ISUP KEY 0x0005 - ENTER Q.BICC ISUP KEY 0x0006 - DELETE Q.BICC ISUP KEY 0x0007 - SPLIT Q.BICC ISUP KEY 0x0008 - RESIZE Q.BICC ISUP KEY 0x0009 - ENTER SCCP KEY 0x000A - DELETE SCCP KEY
0x0001-输入ISUP键0x0002-删除ISUP键0x0003-拆分ISUP键0x0004-调整ISUP键0x0005-输入Q.BICC ISUP键0x0006-删除Q.BICC ISUP键0x0007-拆分Q.BICC ISUP键0x0008-调整Q.BICC ISUP键0x0009-输入SCCP键0x000A-删除SCCP键
0x000B - ENTER OTHER-MTP3-SI KEY 0x000C - DELETE OTHER-MTP3-SI KEY 0x000D - ENTER TUP KEY (ITU only) 0x000E - DELETE TUP KEY (ITU only) 0x000F - SPLIT TUP KEY (ITU only) 0x0010 - RESIZE TUP KEY (ITU only) 0x0011 - ENTER DPC-SI-OPC PARTIAL KEY 0x0012 - DELETE DPC-SI-OPC PARTIAL KEY 0x0013 - ENTER DPC-SI PARTIAL KEY 0x0014 - DELETE DPC-SI PARTIAL KEY 0x0015 - ENTER DPC PARTIAL KEY 0x0016 - DELETE DPC PARTIAL KEY 0x0017 - ENTER SI PARTIAL KEY 0x0018 - DELETE SI PARTIAL KEY 0x0019 - ENTER DEFAULT 0x001A - DELETE DEFAULT KEY 0x001B - MULTIPLE REGISTRATION SUPPORT
0x000B-输入OTHER-MTP3-SI键0x000C-删除OTHER-MTP3-SI键0x000D-输入TUP键（仅限ITU）0x000E-删除TUP键（仅限ITU）0x000F-拆分TUP键（仅限ITU）0x0010-调整TUP键大小（仅限ITU）0x0011-输入DPC-SI-OPC部分密钥0x0012-删除DPC-SI-OPC部分密钥0x0013-输入DPC-SI部分密钥0x0014-删除DPC-SI部分密钥0x0015-输入DPC部分密钥0x0016-删除DPC部分密钥0x0017-输入SI部分密钥0x0018-删除SI部分密钥0x0019-输入默认0x001A-删除默认密钥0x001B-多个注册支持
The message data area of the 'rkrp' messages will differ based on which RKRP Operation is specified. Several different structures are used, the correct structure can be identified by the RKRP Operation field.
“rkrp”消息的消息数据区域将根据指定的rkrp操作而有所不同。使用几种不同的结构，可通过RKRP操作字段识别正确的结构。
In order to simplify the implementation, each of these structures will define a structure that will support all of the operations required for the key type. This means that based on the rkrp operation, some of the fields will be required, and some of the fields will not be applicable for each RKRP message. Unused fields should be initialized to 0 by the sender and ignored by the receiver.
为了简化实现，这些结构中的每一个都将定义一个支持密钥类型所需的所有操作的结构。这意味着基于rkrp操作，某些字段将是必需的，而某些字段将不适用于每个rkrp消息。未使用的字段应由发送方初始化为0，并由接收方忽略。
In the following subsections several different data structures to be used for various RKRP operations are presented. It should be noted that each of these data structures has the following fields in common. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
以下小节介绍了用于各种RKRP操作的几种不同数据结构。应该注意的是，这些数据结构中的每一个都有以下共同的字段。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from in section 5. | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from in section 5. | |
+------------------------------------------------------------------+
Table 14: Common Fields in ALL 'rkrp' Data Structures
表14：所有“rkrp”数据结构中的公共字段
The primary purpose of requiring the data structures for all RKRP operations to begin with these same fields, is to provide a means for a receiver to reply to unknown RKRP messages in a consistent manner. When an implementation receives an RKRP request message it does not understand, it should turn the request into a reply and use the success/failure code to indicate that the operation is not supported (with an RKRP Reply Code of Unsupported rkrp Operation).
要求所有RKRP操作的数据结构从这些相同字段开始的主要目的是为接收方提供一种方法，以一致的方式回复未知RKRP消息。当一个实现接收到它不理解的RKRP请求消息时，它应该将该请求转换为应答，并使用成功/失败代码指示该操作不受支持（RKRP应答代码为不受支持的RKRP操作）。
It is a requirement that these common fields continue to be used as new RKRP operations are added to this specification. This will ensure that the capability described in the previous paragraph will always exist.
在本规范中添加新的RKRP操作时，要求继续使用这些公共字段。这将确保上一段中描述的能力始终存在。
The data structure used for 'rkrp' messages related to MSUs which are CIC based (ISUP, Q.BICC ISUP, and TUP (ITU only)) is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
下表给出了与基于CIC的MSU相关的“rkrp”消息（ISUP、Q.BICC ISUP和TUP（仅限ITU））所用的数据结构。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
Note 1: The number of bits used in each CIC field will vary based on the SI and network type.
注1：每个CIC字段中使用的位数将根据SI和网络类型而有所不同。
* ISUP operations (0x0001 - 0x0004) are assumed to use 14 bit CIC values from the corresponding fields in the structure when DPC/OPC indicate an ANSI network (12 bits used in ITU networks). Only the 14(12) least significant bits of the 32 bit CIC field will be used.
* 当DPC/OPC指示ANSI网络（12位用于ITU网络）时，假定ISUP操作（0x0001-0x0004）使用结构中相应字段的14位CIC值。仅使用32位CIC字段的14（12）最低有效位。
* Q.BICC ISUP operations (0x0005 - 0x0008) are assumed to use 32 bit CIC values from the corresponding fields in the structure.
* Q.BICC ISUP操作（0x0005-0x0008）假定使用结构中相应字段的32位CIC值。
* TUP operations (0x000d - 0x0010) are assumed to use 12 bit CIC values from the corresponding fields in the structure when DPC/OPC indicate an ITU network. Only the 12 least significant bits of the 32 bit CIC field will be used. TUP operations are not supported for ANSI networks.
* 当DPC/OPC指示ITU网络时，假定TUP操作（0x000d-0x0010）使用结构中相应字段的12位CIC值。仅使用32位CIC字段的12个最低有效位。ANSI网络不支持TUP操作。
Note 2: This same structure should be used to specify the partial key = DPC-SI-OPC(ignoreCIC). When specifying a DPC-SI-OPC partial key, the CIC fields in this structure should be set to 0 by the sender.
注2：应使用相同的结构指定部分密钥=DPC-SI-OPC（ignoreCIC）。指定DPC-SI-OPC部分密钥时，发送方应将此结构中的CIC字段设置为0。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 5 for ISUP keys.| |
| | | SI should be 13 for Q.BICC | |
| | | ISUP keys. | |
| | | SI should be 4 for TUP keys. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 5 for ISUP keys.| |
| | | SI should be 13 for Q.BICC | |
| | | ISUP keys. | |
| | | SI should be 4 for TUP keys. | |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 4 | OPC | Origination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a OPC that | Code |
| | | identifies the source of the | |
| | | MSU. ISUP routing keys must | |
| | | each specify a single OPC | |
| | | that the application routing | |
| | | key relates to. | |
+------------------------------------------------------------------+
| 4 | CICS | Circuit Identification Code | Integer |
| | | Start. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICS value is the low end of | |
| | | the CIC range. | |
+------------------------------------------------------------------+
| 4 | CICE | Circuit Identification Code | Integer |
| | | End. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICE value is the high end | |
| | | of the CIC range. | |
+------------------------------------------------------------------+
| 4 | SPLIT CIC | The SPLIT field is used on | Integer |
| | | the SPLIT operation to | |
| | | specify where in the existing| |
| | | CIC range (given by CICS/ | |
| | | CICE) an existing routing key| |
| | | should be split into 2 | |
| | | routing keys. To be valid, | |
| | | the following relationship | |
| | | must be true before the SPLIT| |
| | | is performed: | |
| | | CICS < SPLIT <= CICE. | |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 4 | OPC | Origination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a OPC that | Code |
| | | identifies the source of the | |
| | | MSU. ISUP routing keys must | |
| | | each specify a single OPC | |
| | | that the application routing | |
| | | key relates to. | |
+------------------------------------------------------------------+
| 4 | CICS | Circuit Identification Code | Integer |
| | | Start. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICS value is the low end of | |
| | | the CIC range. | |
+------------------------------------------------------------------+
| 4 | CICE | Circuit Identification Code | Integer |
| | | End. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICE value is the high end | |
| | | of the CIC range. | |
+------------------------------------------------------------------+
| 4 | SPLIT CIC | The SPLIT field is used on | Integer |
| | | the SPLIT operation to | |
| | | specify where in the existing| |
| | | CIC range (given by CICS/ | |
| | | CICE) an existing routing key| |
| | | should be split into 2 | |
| | | routing keys. To be valid, | |
| | | the following relationship | |
| | | must be true before the SPLIT| |
| | | is performed: | |
| | | CICS < SPLIT <= CICE. | |
| | | After the SPLIT is performed,| |
| | | the 2 routing keys are as | |
| | | follows: | |
| | | CICS to SPLIT-1 | |
| | | SPLIT to CICE | |
+------------------------------------------------------------------+
| 4 | NCICS | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICS specifies | |
| | | the new value that should | |
| | | replace the existing CICS | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
| 4 | NCICE | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICE specifies | |
| | | the new value that should | |
| | | replace the existing CICE | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
| | | After the SPLIT is performed,| |
| | | the 2 routing keys are as | |
| | | follows: | |
| | | CICS to SPLIT-1 | |
| | | SPLIT to CICE | |
+------------------------------------------------------------------+
| 4 | NCICS | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICS specifies | |
| | | the new value that should | |
| | | replace the existing CICS | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
| 4 | NCICE | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICE specifies | |
| | | the new value that should | |
| | | replace the existing CICE | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
Table 15: Message Data Structure CIC based Routing Key Operations
表15：基于消息数据结构CIC的路由密钥操作
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 15 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了表15中基于RKRP操作字段的消息数据结构每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+------------------------------------------------------------------+
| Operation | ENTER | DELETE | SPLIT | RESIZE | ENTER/DELETE |
| | (ISUP,| (ISUP, | (ISUP,| (ISUP, | PARTIAL DPC |
| | QBICC,| QBICC, | QBICC,| QBICC, | SI OPC KEY |
| Field | TUP) | TUP) | TUP) | TUP) | |
+------------------------------------------------------------------+
| Request/Reply | R | R | R | R | R |
+------------------------------------------------------------------+
| Success/Failure | R | R | R | R | R |
+------------------------------------------------------------------+
| RKRP Flags | R | R | R | R | R |
+------------------------------------------------------------------+
| SI | R | R | R | R | R |
+------------------------------------------------------------------+
| DPC | R | R | R | R | R |
+------------------------------------------------------------------+
| OPC | R | R | R | R | R |
+------------------------------------------------------------------+
| CICS | R | R | R | R | NA |
+------------------------------------------------------------------+
| CICE | R | R | R | R | NA |
+------------------------------------------------------------------+
| SPLIT CIC | NA | NA | R | NA | NA |
+------------------------------------------------------------------+
| NCICS | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
| NCICE | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Operation | ENTER | DELETE | SPLIT | RESIZE | ENTER/DELETE |
| | (ISUP,| (ISUP, | (ISUP,| (ISUP, | PARTIAL DPC |
| | QBICC,| QBICC, | QBICC,| QBICC, | SI OPC KEY |
| Field | TUP) | TUP) | TUP) | TUP) | |
+------------------------------------------------------------------+
| Request/Reply | R | R | R | R | R |
+------------------------------------------------------------------+
| Success/Failure | R | R | R | R | R |
+------------------------------------------------------------------+
| RKRP Flags | R | R | R | R | R |
+------------------------------------------------------------------+
| SI | R | R | R | R | R |
+------------------------------------------------------------------+
| DPC | R | R | R | R | R |
+------------------------------------------------------------------+
| OPC | R | R | R | R | R |
+------------------------------------------------------------------+
| CICS | R | R | R | R | NA |
+------------------------------------------------------------------+
| CICE | R | R | R | R | NA |
+------------------------------------------------------------------+
| SPLIT CIC | NA | NA | R | NA | NA |
+------------------------------------------------------------------+
| NCICS | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
| NCICE | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
Table 16: Required/Not Applicable Fields for CIC based Routing Keys
表16：基于CIC的路由密钥的必填/不适用字段
The data structure used for 'rkrp' messages related to SCCP routing keys is presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
下表显示了与SCCP路由键相关的“rkrp”消息所用的数据结构。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 3 for SCCP keys.| |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 1 | SSN | SubSystem Number. Each SCCP | Integer |
| | | MSU contains a subsystem | |
| | | number that identifies the | |
| | | SCCP subsystem that should | |
| | | process the MSU. SCCP | |
| | | routing keys must each | |
| | | specify a single SSN that | |
| | | the application routing key | |
| | | relates to. | |
+------------------------------------------------------------------+
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 3 for SCCP keys.| |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 1 | SSN | SubSystem Number. Each SCCP | Integer |
| | | MSU contains a subsystem | |
| | | number that identifies the | |
| | | SCCP subsystem that should | |
| | | process the MSU. SCCP | |
| | | routing keys must each | |
| | | specify a single SSN that | |
| | | the application routing key | |
| | | relates to. | |
+------------------------------------------------------------------+
Table 17: Message Data Structure SCCP Routing Key Operations
表17：消息数据结构SCCP路由密钥操作
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 17 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了表17中基于RKRP操作字段的消息数据结构每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+--------------------------------------------+
| Operation | ENTER SCCP | DELETE SCCP |
| Field | | |
+--------------------------------------------+
| Request/Reply | R | R |
+--------------------------------------------+
| Success/Failure | R | R |
+--------------------------------------------+
| RKRP Flags | R | R |
+--------------------------------------------+
| SI | R | R |
+--------------------------------------------+
| DPC | R | R |
+--------------------------------------------+
| SSN | R | R |
+--------------------------------------------+
+--------------------------------------------+
| Operation | ENTER SCCP | DELETE SCCP |
| Field | | |
+--------------------------------------------+
| Request/Reply | R | R |
+--------------------------------------------+
| Success/Failure | R | R |
+--------------------------------------------+
| RKRP Flags | R | R |
+--------------------------------------------+
| SI | R | R |
+--------------------------------------------+
| DPC | R | R |
+--------------------------------------------+
| SSN | R | R |
+--------------------------------------------+
Table 18: Required/Not Applicable Fields for SCCP Routing Keys
表18:SCCP路由密钥的必填/不适用字段
The data structure used for 'rkrp' messages related to DPC-SI based (either full keys for non-sccp, non-cic based traffic, or partial keys for CIC based or SCCP), DPC based (partial key), and SI based (partial key) operations is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
下表显示了与基于DPC-SI（非sccp、非cic流量的完整密钥或基于cic或sccp的部分密钥）、基于DPC（部分密钥）和基于SI（部分密钥）操作相关的“rkrp”消息所用的数据结构。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from section 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from section 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
Table 19: Message Data Structure DPC/SI, DPC and SI based Routing
Key Operations
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
Table 19: Message Data Structure DPC/SI, DPC and SI based Routing
Key Operations
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 19 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了表19中基于RKRP操作字段的消息数据结构每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+-------------------------------------------------------+
| Operation | ENTER/ | ENTER/ | ENTER/ | ENTER/ |
| | DELETE | DELETE | DELETE | DELETE |
| | OTHER | DPC-SI | DPC | SI |
| Field | MTP3 SI | PARTIAL | ONLY | ONLY |
+-------------------------------------------------------+
| Request/Reply | R | R | R | R |
+-------------------------------------------------------+
| Success/Failure | R | R | R | R |
+-------------------------------------------------------+
| RKRP Flags | R | R | R | R |
+-------------------------------------------------------+
| SI | R | R | NA | R |
+-------------------------------------------------------+
| DPC | R | R | R | NA |
+-------------------------------------------------------+
+-------------------------------------------------------+
| Operation | ENTER/ | ENTER/ | ENTER/ | ENTER/ |
| | DELETE | DELETE | DELETE | DELETE |
| | OTHER | DPC-SI | DPC | SI |
| Field | MTP3 SI | PARTIAL | ONLY | ONLY |
+-------------------------------------------------------+
| Request/Reply | R | R | R | R |
+-------------------------------------------------------+
| Success/Failure | R | R | R | R |
+-------------------------------------------------------+
| RKRP Flags | R | R | R | R |
+-------------------------------------------------------+
| SI | R | R | NA | R |
+-------------------------------------------------------+
| DPC | R | R | R | NA |
+-------------------------------------------------------+
Table 20: Required/Not Applicable Fields for DPC/SI, DPC and SI based Routing Keys
表20:DPC/SI、DPC和基于SI的路由密钥的必填/不适用字段
The data structure used for 'rkrp' messages related to entering and deleting a default routing key is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
与输入和删除默认路由密钥相关的“rkrp”消息所用的数据结构如下表所示。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
Table 21: Message Data Structure for Default Routing Keys
表21：默认路由键的消息数据结构
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 21 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了表21中基于RKRP操作字段的消息数据结构每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+-------------------------------------+
| Operation | ENTER | DELETE |
| Field | DEFAULT | DEFAULT |
+-------------------------------------+
| Request/Reply | R | R |
+-------------------------------------+
| Success/Failure | R | R |
+-------------------------------------+
| RKRP Flags | R | R |
+-------------------------------------+
+-------------------------------------+
| Operation | ENTER | DELETE |
| Field | DEFAULT | DEFAULT |
+-------------------------------------+
| Request/Reply | R | R |
+-------------------------------------+
| Success/Failure | R | R |
+-------------------------------------+
| RKRP Flags | R | R |
+-------------------------------------+
Table 22: Required/Not Applicable Fields for Default Routing Keys
表22：默认路由密钥的必填/不适用字段
The intent of support for multiple RKRP operations within a single TALI message (opcode = 'mgmt', primitive = 'rkrp') is to decrease the message count and byte overhead on network transmission when performing massive registration sequences.
支持单个TALI消息中的多个RKRP操作（操作码='mgmt'，原语='RKRP'）的目的是在执行大规模注册序列时减少网络传输上的消息计数和字节开销。
This functionality is added by 2 mechanisms:
此功能由两种机制添加：
* a new RKRP operation (0X001B, MULTIPLE REGISTRATIONS SUPPORT) is defined. This operation is meant to be used in a query/reply manner to determine if the far end supports multiple RKRP registrations per TALI message before using such capability.
* 定义了一个新的RKRP操作（0X001B，多个注册支持）。此操作旨在以查询/应答方式使用，以确定在使用此功能之前，远端是否支持每个TALI消息的多个RKRP注册。
* The basic 'rkrp' message structure is extended to allow multiple rkrp operations to follow one another in a tali message.
* 扩展了基本的“rkrp”消息结构，以允许多个rkrp操作在tali消息中相互跟踪。
A new RKRP operation and accompanying data structure are defined to determine if a far end device supports multiple RKRP registration operations per TALI message.
定义了新的RKRP操作和伴随的数据结构，以确定远端设备是否支持每个TALI消息的多个RKRP注册操作。
The data structure used for the 'multiple registrations support' operation is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
“多重注册支持”操作使用的数据结构如下表所示。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 4 | Operations | This field is used by the | Integer |
| | Per Message | reply to tell the requester | |
| | | the maximum # of RKRP | |
| | | registration operations per | |
| | | TALI message that are | |
| | | supported by the | |
| | | implementation. | |
| | | * This field should be set | |
| | | to 0 when the request/ | |
| | | reply field is set to | |
| | | Request. | |
| | | * This field should be set to| |
| | | the Maximum # of operations| |
| | | per TALI message that a | |
| | | TALI implementation is | |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 4 | Operations | This field is used by the | Integer |
| | Per Message | reply to tell the requester | |
| | | the maximum # of RKRP | |
| | | registration operations per | |
| | | TALI message that are | |
| | | supported by the | |
| | | implementation. | |
| | | * This field should be set | |
| | | to 0 when the request/ | |
| | | reply field is set to | |
| | | Request. | |
| | | * This field should be set to| |
| | | the Maximum # of operations| |
| | | per TALI message that a | |
| | | TALI implementation is | |
| | | willing to support when the| |
| | | request/reply field is set | |
| | | to Reply. | |
+------------------------------------------------------------------+
Table 23: Message Data Structure for Multiple Registrations Support
Operation
| | | willing to support when the| |
| | | request/reply field is set | |
| | | to Reply. | |
+------------------------------------------------------------------+
Table 23: Message Data Structure for Multiple Registrations Support
Operation
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure above. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了上述消息数据结构每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+-------------------------------------------------+
| Operation | MULTIPLE | MULTIPLE |
| | REGISTRATIONS | REGISTRATIONS |
| | SUPPORT | SUPPORT |
| Field | REQUEST | REPLY |
+-------------------------------------------------+
| Request/Reply | R | R |
+-------------------------------------------------+
| Success/Failure | R | R |
+-------------------------------------------------+
| Operations Per | R | R |
| Message | | |
+-------------------------------------------------+
+-------------------------------------------------+
| Operation | MULTIPLE | MULTIPLE |
| | REGISTRATIONS | REGISTRATIONS |
| | SUPPORT | SUPPORT |
| Field | REQUEST | REPLY |
+-------------------------------------------------+
| Request/Reply | R | R |
+-------------------------------------------------+
| Success/Failure | R | R |
+-------------------------------------------------+
| Operations Per | R | R |
| Message | | |
+-------------------------------------------------+
Table 24: Required/Not Applicable Fields for Multiple Registrations Support Operation
表24：多个注册支持操作的必填/不适用字段
After using the MULTIPLE REGISTRATIONS SUPPORT operation to determine that the far end supports multiple RKRP operations per TALI message, a device wishing to use this functionality can begin sending more than 1 registration request/reply per message. To do so, the basic message structure for an 'mgmt' opcode (presented in Table 12) can be extended so that each operation directly follows the previous operation in the TALI message. An example showing a TALI message with 3 RKRP operations in it would look as follows:
在使用多个注册支持操作确定远端支持每个TALI消息的多个RKRP操作后，希望使用此功能的设备可以开始发送每个消息超过1个注册请求/回复。为此，可以扩展“管理”操作码（如表12所示）的基本消息结构，以便每个操作直接遵循TALI消息中的前一个操作。显示包含3个RKRP操作的TALI消息的示例如下所示：
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length. The length should be set such that|
| | | all (3 in this example) operations are |
| | | accounted for. |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp' |
+------------------------------------------------------------------+
| 14..17 | Primitive | The fisrt operation field identifies a |
| | Operation | specific rkrp operation to be performed. |
| | #1 | |
+------------------------------------------------------------------+
| 18..x | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #1 depends on the message data |
| | #1 | required for rkrp operation #1 |
+------------------------------------------------------------------+
| x+1.. | Primitive | The fisrt operation field identifies a |
| x+4 | Operation | specific rkrp operation to be performed. |
| | #2 | |
+------------------------------------------------------------------+
| x+5..y | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #2 depends on the message data |
| | #2 | required for rkrp operation #2 |
+------------------------------------------------------------------+
| y+1.. | Primitive | The fisrt operation field identifies a |
| y+4 | Operation | specific rkrp operation to be performed. |
| | #3 | |
+------------------------------------------------------------------+
| y+5..z | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #3 depends on the message data |
| | #3 | required for rkrp operation #3 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length. The length should be set such that|
| | | all (3 in this example) operations are |
| | | accounted for. |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp' |
+------------------------------------------------------------------+
| 14..17 | Primitive | The fisrt operation field identifies a |
| | Operation | specific rkrp operation to be performed. |
| | #1 | |
+------------------------------------------------------------------+
| 18..x | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #1 depends on the message data |
| | #1 | required for rkrp operation #1 |
+------------------------------------------------------------------+
| x+1.. | Primitive | The fisrt operation field identifies a |
| x+4 | Operation | specific rkrp operation to be performed. |
| | #2 | |
+------------------------------------------------------------------+
| x+5..y | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #2 depends on the message data |
| | #2 | required for rkrp operation #2 |
+------------------------------------------------------------------+
| y+1.. | Primitive | The fisrt operation field identifies a |
| y+4 | Operation | specific rkrp operation to be performed. |
| | #3 | |
+------------------------------------------------------------------+
| y+5..z | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #3 depends on the message data |
| | #3 | required for rkrp operation #3 |
+------------------------------------------------------------------+
Table 25: Message Structure for 'mgmt' opcode with multiple 'rkrp' operations in 1 TALI Message
表25:1 TALI消息中具有多个“rkrp”操作的“mgmt”操作码的消息结构
It should be reiterated that in order to avoid unpredictable behavior, a node using the 'multiple registrations per TALI msg' capability must be sure the far end device supports the capability. The only way to be sure of this is to successfully send a MULTIPLE REGISTRATION SUPPORT request and receive a MULTIPLE REGISTRATION SUPPORT reply.
应该重申的是，为了避免不可预测的行为，使用“每个TALI msg多个注册”功能的节点必须确保远端设备支持该功能。确保这一点的唯一方法是成功发送多重注册支持请求并接收多重注册支持回复。
The 'mtpp' primitive allows IP nodes to receive status regarding point code (un)availability and congestion levels. These messages provide information similar to the TFP/TFA (TransFer Prohibited and TransFer Allowed), TFC (TransFer Congested) and RCT (Route Congestion Test) messages that are encoded as SS7 SNM (Signaling Network Management) MSUs in traditional SS7 networks. The 'mtp3 primitives' allow this status information to be transferred in-band, via TALI messages, to the IP nodes.
“mtpp”原语允许IP节点接收有关点代码（un）可用性和拥塞级别的状态。这些消息提供的信息类似于传统SS7网络中编码为SS7 SNM（信令网络管理）MSU的TFP/TFA（禁止传输和允许传输）、TFC（传输拥塞）和RCT（路由拥塞测试）消息。“mtp3原语”允许该状态信息通过TALI消息在频带内传输到IP节点。
The specific information provided in each 'mtpp' message is indicated via an 'MTPP Operation' field. These capabilities provided by the various MTPP Operation fields include:
每个“mtpp”消息中提供的特定信息通过“mtpp操作”字段指示。各种MTPP操作字段提供的这些功能包括：
* POINT CODE UNAVAILABLE: This primitive operation announces that an SS7 Point Code is Unavailable (ie: the SG has NO route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with.
* 点代码不可用：此基本操作宣布SS7点代码不可用（即：SG没有可用于向目的地发送流量的路由）。PT代码字段指示此操作涉及的SS7 PT代码。
* POINT CODE AVAILABLE: This primitive operation announces that an SS7 Point Code is Available (ie: the SG has SOME route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with.
* 可用点代码：此基本操作宣布SS7点代码可用（即：SG有一些路由可用于向目的地发送流量）。PT代码字段指示此操作涉及的SS7 PT代码。
* REQUEST FOR POINT CODE STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the available/unavailable status of a specific SS7 pt code. For instance, the IP node can poll the SG - Can you send traffic successfully for the destination indicated? The receiver of the request will reply to the request with either a point code available or pt code unavailable primitive respectively.
* 请求点代码状态：此原语操作为连接的一端轮询另一端特定SS7 pt代码的可用/不可用状态提供了一种方法。例如，IP节点可以轮询SG-您能否成功地为指定的目的地发送流量？请求的接收者将分别使用可用的点代码或不可用的pt代码原语回复请求。
* CLUSTER UNAVAILABLE: This primitive operation announces that an entire Cluster of SS7 Point Codes (ex: 10-10-*) are Unavailable (ie: the SG has NO route available to send traffic for any of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with.
* CLUSTER UNAVAILABLE（群集不可用）：此基本操作宣布整个SS7点代码群集（例如：10-10-*）不可用（即：SG没有可用于向该群集中的任何目的地发送流量的路由）。PT代码字段指示此操作涉及的SS7群集PT代码。
* CLUSTER AVAILABLE: This primitive operation announces that at least 1 SS7 Point Code within a cluster is Available (ie: the SG
* 集群可用：此基本操作宣布集群内至少有1个SS7点代码可用（即：SG
has SOME route available to send traffic for at least 1 of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with.
有一些路由可用于发送该群集中至少1个目的地的流量）。PT代码字段指示此操作涉及的SS7群集PT代码。
* REQUEST FOR CLUSTER STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the available/unavailable status of a cluster of SS7 pt codes. For instance, the IP node can poll the SG - Can you send traffic successfully for any of the destinations in the cluster? The receiver of the request will reply to the request with either a cluster available or cluster unavailable primitive respectively.
* 请求群集状态：此原语操作为连接的一端轮询另一端SS7 pt代码群集的可用/不可用状态提供了一种方法。例如，IP节点可以轮询SG-您能否成功地为集群中的任何目的地发送通信量？请求的接收者将分别使用集群可用或集群不可用原语回复请求。
* CONGESTED DESTINATION: This primitive operation announces that the path towards an SS7 Point Code is Congested. The PT CODE field indicates which SS7 Pt Code this operation is concerned with. The CONGESTION LEVEL field indicates the severity of the congestion.
* 拥塞目的地：此基本操作宣布指向SS7点代码的路径拥塞。PT代码字段指示此操作涉及的SS7 PT代码。拥塞级别字段指示拥塞的严重程度。
* REQUEST FOR CONGESTION STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the congestion status of an SS7 pt code. For instance, the IP node can poll the SG - Is the path to the specified destination still congested? This request is used to abate congestion towards an SS7 destination.
* 拥塞状态请求：此基本操作为连接的一端轮询另一端SS7 pt代码的拥塞状态提供了一种方法。例如，IP节点可以轮询SG-到指定目的地的路径是否仍然拥挤？此请求用于缓解SS7目的地的拥塞。
* As an implementation note: Upon receiving this request, the SG will generate and send a Route Congestion Test (RCT), SS7 Network Management Message with a priority set to match the congestion level in the request. The RCT is sent towards the SS7 destination. If the SS7 destination is still congested, the RCT will result an SS7 Transfer Controlled (TFC) arriving back at the SG, which will be converted into a CONGESTED DESTINATION primitive and sent on to the IP node.
* 作为实施说明：收到此请求后，SG将生成并发送路由拥塞测试（RCT），SS7网络管理消息，其优先级设置与请求中的拥塞级别相匹配。RCT被发送到SS7目的地。如果SS7目的地仍然拥挤，RCT将导致SS7传输控制（TFC）返回SG，并将其转换为拥挤的目的地原语并发送到IP节点。
* USER PART UNAVAILABLE: SS7 nodes send User Part Unavailable messages when a user part that is mounted on a node is no longer available for service. This primitive operation provides a way for an IP Node to receive the same information as the SS7 UPU message.
* 用户部件不可用：当安装在节点上的用户部件不再可用于服务时，SS7节点发送用户部件不可用消息。此基本操作为IP节点提供了接收与SS7 UPU消息相同的信息的方法。
In order to simplify the implementation, a single data structure is defined to be used for all of the 'mtpp' operations. Depending on the 'mtpp operation', some of the fields will be required, and some of the fields will not be applicable for each MTPP message. Unused fields should be initialized to 0 by the sender and ignored by the receiver. The data structure used for 'mtpp' messages is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
为了简化实现，定义了用于所有“mtpp”操作的单一数据结构。根据“mtpp操作”，有些字段是必需的，有些字段不适用于每个mtpp消息。未使用的字段应由发送方初始化为0，并由接收方忽略。用于“mtpp”消息的数据结构如下表所示。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | MTPP | Identifies which 'mtpp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = PC Unavailable | |
| | | 0x0002 = PC Available | |
| | | 0x0003 = Request for PC | |
| | | Status | |
| | | 0x0004 = Cluster Unavailable | |
| | | 0x0005 = Cluster Available | |
| | | 0x0006 = Request for Cluster | |
| | | Status | |
| | | 0x0007 = Congested | |
| | | Destination, w/Cong | |
| | | Level | |
| | | 0x0008 = Request for | |
| | | Congestion Status | |
| | | 0x0009 = User Part | |
| | | Unavailable | |
+------------------------------------------------------------------+
| 4 | Concerned | Identifies the SS7 Point Code| SS7 Point |
| | Point | that is relevant to the mtpp | Code |
| | Code | operation. The mtpp | |
| | | operation is concerning this | |
| | | point code (or cluster). | |
+------------------------------------------------------------------+
| 4 | Source | This field is only used on | SS7 Point |
| | Point | the 'Congested Destination' | Code |
| | Code | and 'Request for Congestion | |
| | | Status' operations. | |
| | | * When used in an 'Congestion| |
| | | Destination' operation, | |
| | | this field contains the Pt | |
| | | Code of the Source of the | |
| | | traffic that was | |
| | | experiencing congestion as | |
| | | it made its way to the | |
| | | Concerned Pt Code. In | |
| | | terms of the original SS7 | |
| | | MSUs (the TransFer | |
| | | Controlled MSU) that | |
| | | provided congestion | |
| | | information, the CPC of the| |
| | | TFC is the 'Concerned Point| |
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | MTPP | Identifies which 'mtpp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = PC Unavailable | |
| | | 0x0002 = PC Available | |
| | | 0x0003 = Request for PC | |
| | | Status | |
| | | 0x0004 = Cluster Unavailable | |
| | | 0x0005 = Cluster Available | |
| | | 0x0006 = Request for Cluster | |
| | | Status | |
| | | 0x0007 = Congested | |
| | | Destination, w/Cong | |
| | | Level | |
| | | 0x0008 = Request for | |
| | | Congestion Status | |
| | | 0x0009 = User Part | |
| | | Unavailable | |
+------------------------------------------------------------------+
| 4 | Concerned | Identifies the SS7 Point Code| SS7 Point |
| | Point | that is relevant to the mtpp | Code |
| | Code | operation. The mtpp | |
| | | operation is concerning this | |
| | | point code (or cluster). | |
+------------------------------------------------------------------+
| 4 | Source | This field is only used on | SS7 Point |
| | Point | the 'Congested Destination' | Code |
| | Code | and 'Request for Congestion | |
| | | Status' operations. | |
| | | * When used in an 'Congestion| |
| | | Destination' operation, | |
| | | this field contains the Pt | |
| | | Code of the Source of the | |
| | | traffic that was | |
| | | experiencing congestion as | |
| | | it made its way to the | |
| | | Concerned Pt Code. In | |
| | | terms of the original SS7 | |
| | | MSUs (the TransFer | |
| | | Controlled MSU) that | |
| | | provided congestion | |
| | | information, the CPC of the| |
| | | TFC is the 'Concerned Point| |
| | | Code' of the resulting MTPP| |
| | | primitive and the DPC of | |
| | | the TFC is the 'Source | |
| | | Point Code' of the | |
| | | resulting MTPP primitive. | |
| | | * When used in an 'Request | |
| | | for Congestion Status' | |
| | | operation, this field | |
| | | indicates which Source Pt | |
| | | Code is trying to abate the| |
| | | congestion of the concerned| |
| | | Pt Code. In terms of the | |
| | | original SS7 MSUs (the | |
| | | Route Congestion Test MSU) | |
| | | that is used to poll for | |
| | | congestion, the DPC of the | |
| | | RCT is the 'Concerned Point| |
| | | Code' of the MTPP primitive| |
| | | and the OPC of the RCT is | |
| | | the 'Source Point Code' of | |
| | | the MTPP primitive. | |
+------------------------------------------------------------------+
| 2 | Congestion | This field is used on the | Integer |
| | Level | 'Congested Destination' and | |
| | | 'Request for Congestion | |
| | | Status' operations to | |
| | | indicate the congestion level| |
| | | of the destination. This | |
| | | integer field uses the | |
| | | following encodings: | |
| | | 0x0000 = Congestion Level 0 | |
| | | 0x0001 = Congestion Level 1 | |
| | | 0x0002 = Congestion Level 2 | |
| | | 0x0003 = Congestion Level 3 | |
+------------------------------------------------------------------+
| 2 | Cause Code | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate the | |
| | | Cause Code for why the UPU is| |
| | | being sent. This integer | |
| | | field uses the following | |
| | | encodings: | |
| | | 0x0000 = Cause Unknown | |
| | | 0x0001 = User Part Unequipped| |
| | | 0x0002 = User Part | |
| | | Inaccessible | |
+------------------------------------------------------------------+
| | | Code' of the resulting MTPP| |
| | | primitive and the DPC of | |
| | | the TFC is the 'Source | |
| | | Point Code' of the | |
| | | resulting MTPP primitive. | |
| | | * When used in an 'Request | |
| | | for Congestion Status' | |
| | | operation, this field | |
| | | indicates which Source Pt | |
| | | Code is trying to abate the| |
| | | congestion of the concerned| |
| | | Pt Code. In terms of the | |
| | | original SS7 MSUs (the | |
| | | Route Congestion Test MSU) | |
| | | that is used to poll for | |
| | | congestion, the DPC of the | |
| | | RCT is the 'Concerned Point| |
| | | Code' of the MTPP primitive| |
| | | and the OPC of the RCT is | |
| | | the 'Source Point Code' of | |
| | | the MTPP primitive. | |
+------------------------------------------------------------------+
| 2 | Congestion | This field is used on the | Integer |
| | Level | 'Congested Destination' and | |
| | | 'Request for Congestion | |
| | | Status' operations to | |
| | | indicate the congestion level| |
| | | of the destination. This | |
| | | integer field uses the | |
| | | following encodings: | |
| | | 0x0000 = Congestion Level 0 | |
| | | 0x0001 = Congestion Level 1 | |
| | | 0x0002 = Congestion Level 2 | |
| | | 0x0003 = Congestion Level 3 | |
+------------------------------------------------------------------+
| 2 | Cause Code | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate the | |
| | | Cause Code for why the UPU is| |
| | | being sent. This integer | |
| | | field uses the following | |
| | | encodings: | |
| | | 0x0000 = Cause Unknown | |
| | | 0x0001 = User Part Unequipped| |
| | | 0x0002 = User Part | |
| | | Inaccessible | |
+------------------------------------------------------------------+
| 2 | User ID | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate which | |
| | | user part is unavailable. The| |
| | | User ID field identifies the | |
| | | type of traffic that was | |
| | | unavailable (0=SNM, 3=SCCP, | |
| | | 5=ISUP, etc). | |
+------------------------------------------------------------------+
| 2 | User ID | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate which | |
| | | user part is unavailable. The| |
| | | User ID field identifies the | |
| | | type of traffic that was | |
| | | unavailable (0=SNM, 3=SCCP, | |
| | | 5=ISUP, etc). | |
+------------------------------------------------------------------+
Table 26: Message Data Structure for use with the 'mtpp' Primitive
表26：与“mtpp”原语一起使用的消息数据结构
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 26 based on the MTPP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
下表显示了表26中基于MTPP操作字段的消息数据结构的每个字段的必需（R）或不适用（NA）状态。如前所述，未使用的字段（标记为NA的字段）应由发送方初始化为0，并由接收方忽略。
+------------------------------------------------------------------+
| Field | Concerned | Source | Congestion | Cause | User |
| | Point | Point | Level | Code | ID |
| Operation | Code | Code | | | |
+------------------------------------------------------------------+
| PC Unavailable | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| PC Available | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| Request for PC | R | NA | NA | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Unavailable | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Available | | | | | |
+------------------------------------------------------------------+
| Request for | R | NA | NA | NA | NA |
| Cluster Status | | | | | |
+------------------------------------------------------------------+
| Congested | | | | | |
| Destination w/ | R | R | R | NA | NA |
| Cong. Level | | | | | |
+------------------------------------------------------------------+
| Request for | | | | | |
| Congestion | R | R | R | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| User Part | R | NA | NA | R | R |
| Unavailable | | | | | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Field | Concerned | Source | Congestion | Cause | User |
| | Point | Point | Level | Code | ID |
| Operation | Code | Code | | | |
+------------------------------------------------------------------+
| PC Unavailable | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| PC Available | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| Request for PC | R | NA | NA | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Unavailable | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Available | | | | | |
+------------------------------------------------------------------+
| Request for | R | NA | NA | NA | NA |
| Cluster Status | | | | | |
+------------------------------------------------------------------+
| Congested | | | | | |
| Destination w/ | R | R | R | NA | NA |
| Cong. Level | | | | | |
+------------------------------------------------------------------+
| Request for | | | | | |
| Congestion | R | R | R | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| User Part | R | NA | NA | R | R |
| Unavailable | | | | | |
+------------------------------------------------------------------+
Table 27: Required/Not Applicable Fields for MTPP Operations
表27:MTPP操作的必填/不适用字段
The 'sorp' primitive allows IP nodes to set various options on a socket by socket basis. This allows the IP node some control over the communication that will occur across the TALI connection. The 'sorp' primitives allows this socket option control to be transferred in-band, via TALI messages, to the IP nodes.
“sorp”原语允许IP节点逐个套接字设置各种选项。这允许IP节点对将通过TALI连接发生的通信进行某种控制。“sorp”原语允许此套接字选项控制通过TALI消息在频带内传输到IP节点。
The SORP primitives capabilities that are available to the IP device in SG are as follows:
SG中IP设备可用的SORP原语功能如下：
* Set SORP Flags: Used to set the flags bit field. The receiver of this message should store the bit settings indicated in the SORP Flag field.
* 设置SORP标志：用于设置标志位字段。此消息的接收者应存储SORP标志字段中指示的位设置。
* Request Current SORP Flags Settings: Used to poll for the status of the bit field options. The receiver of this message should send a Reply w/ Current SORP Flag settings.
* 请求当前SORP标志设置：用于轮询位字段选项的状态。此消息的接收者应发送带有当前SORP标志设置的回复。
* Reply w/ Current SORP Flag Settings: Used to reply to a poll, indicating the current bit field settings to the far end.
* 带当前SORP标志设置的回复：用于回复轮询，表示远端的当前位字段设置。
As of TALI 2.0, each socket option is stored as a bit in a 32 bit bit-field. Each bit in the field indicates the setting for 1 option. A bit field with a 0 value indicates the option is DISABLED. A bit field with a 1 value indicates the option is ENABLED. The following options are currently supported:
从TALI 2.0开始，每个套接字选项都以位形式存储在32位字段中。字段中的每一位表示1选项的设置。值为0的位字段表示该选项已禁用。值为1的位字段表示该选项已启用。当前支持以下选项：
* ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES: Traditional STPs send Broadcast Phase TFPs and TFAs to all adjacent nodes when the point code availability changes for destinations in the STP's SS7 routing table. These Broadcast Phase TFA/TFP SS7 messages are converted into TALI mtpp primitives by SG nodes such as the SG. The ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES options allow each IP node to tell the remote end whether the IP node wants to receive the mtpp primitives that result from SS7 broadcast phase messages.
* 启用/禁用广播阶段MTPP原语：当STP的SS7路由表中目的地的点代码可用性发生变化时，传统STP向所有相邻节点发送广播阶段TFP和TFA。这些广播阶段TFA/TFP SS7消息由SG节点（如SG）转换为TALI mtpp原语。启用/禁用广播阶段MTPP原语选项允许每个IP节点告知远程端IP节点是否希望接收SS7广播阶段消息产生的MTPP原语。
* As an implementation note: In the SG, each defined socket has a flag, 'enable_broadcast_phase_primitives', which is initialized to FALSE each time the socket connects. The IP node should send the ENABLE BROADCAST PHASE MESSAGES operation to the SG to announce that it wants to receive unsolicited status changes for a particular socket. As the SG is determining where to send broadcast phase TFAs/TFPs, it will interrogate the 'enable_broadcast_phase_primitives' flag for each socket on that socket.
* 作为一个实现注意事项：在SG中，每个定义的套接字都有一个标志“enable_broadcast_phase_primitives”，每次套接字连接时，该标志都被初始化为FALSE。IP节点应向SG发送ENABLE BROADCAST PHASE MESSAGES（启用广播阶段消息）操作，以宣布其希望接收特定套接字的未经请求的状态更改。当SG决定向何处发送广播阶段TFA/TFP时，它将为该套接字上的每个套接字询问“启用广播阶段原语”标志。
* ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES: Traditional STPs send Response Method TFPs to adjacent nodes when the adjacent nodes continue to send MSUs to the STP that can not be delivered (ie: the STP has told the adjacent node that a destination is Unavailable, but the adjacent node continues to send traffic destined for that unavailable DPC to the STP). These Response Method messages are sent in response to MSUs that are received at the STP. These Response Method TFP messages are converted into TALI mtpp primitives by SG nodes such as the SG. The ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES options allow each IP node to tell the remote end whether the IP node wants to
* 启用/禁用响应方法MTPP原语：当相邻节点继续向无法交付的STP发送MSU时，传统STP向相邻节点发送响应方法TFPs（即：STP已告知相邻节点目的地不可用，但相邻节点继续向STP发送目的地为该不可用DPC的流量）。这些响应方法消息被发送以响应STP接收到的MSU。这些响应方法TFP消息由SG节点（如SG）转换为TALI mtpp原语。启用/禁用响应方法mtpp原语选项允许每个IP节点告知远程端IP节点是否要
receive the mtpp primitives that result from SS7 response method messages. In addition to response method TFPs, 2 other SS7 Network Management messages, namely TFCs (transfer controlled) and UPUs (user part unavailable), fall into this RESPONSE METHOD grouping. TFCs and UPUs are similar to response method TFPs due to the fact that a previous action by the IP Node (sending traffic toward some destination) has caused a response method event back to the IP Node. The primary difference between response method TFPs versus response method TFCs/UPUs is that the response method TFP is converted to an MTPP primitive and sent back to only the original socket, while response method TFCs/UPUs may need to be replicated to multiple sockets (after being converted to mtpp primitives) since there is no way to tell which socket caused the response method event.
接收来自SS7响应方法消息的mtpp原语。除了响应方法TFPs外，其他2条SS7网络管理消息，即TFCs（传输控制）和UPU（用户部分不可用），也属于此响应方法分组。TFCs和UPU与响应方法TFPs类似，因为IP节点先前的操作（向某个目的地发送流量）已导致响应方法事件返回IP节点。响应方法TFPs与响应方法TFCs/UPU之间的主要区别在于，响应方法TFP被转换为MTPP原语并仅发送回原始套接字，而响应方法TFCs/UPU可能需要复制到多个套接字（转换为MTPP原语后）因为无法判断是哪个套接字导致了响应方法事件。
* As an implementation node: In the SG, each defined socket has a flag, 'enable_response_method_primitives', which is initialized to FALSE each time the socket connects. The IP node should send the ENABLE RESPONSE METHOD MTPP PRIMITIVES operation to the SG to announce that it wants to receive response method TFPs when appropriate for a particular socket. Before the SG sends a response method TFP (converted to a mtpp primitive) back to an IP node, the SG will interrogate the 'enable_response_method_primitives' flag for that socket and only perform the send if the flag allows it.
* 作为一个实现节点：在SG中，每个定义的套接字都有一个标志“enable_response_method_primitives”，每次套接字连接时，该标志都被初始化为FALSE。IP节点应向SG发送ENABLE RESPONSE METHOD MTPP PRIMITIVES（启用响应方法MTPP原语）操作，以宣布它希望在适合特定套接字时接收响应方法TFPs。在SG将响应方法TFP（转换为mtpp原语）发送回IP节点之前，SG将询问该套接字的“enable_response_method_primitives”标志，并仅在该标志允许的情况下执行发送。
* ENABLE/DISABLE NORMALIZED SCCP: Version 1.0 of TALI specified that the 'sccp' TALI opcode must be used on point to multipoint connections in order to transmit SCCP MSUs between the SG and IP nodes. When using the 'sccp' opcode, the MTP3 header portion of the original SS7 MSU was stripped from the MSU and was NOT part of the data transmitted across the TALI connection. The sender of the 'sccp' TALI message was responsible for duplicating the DPC/OPC fields from the MTP3 header into appropriate fields in the SCCP portion of the message (into the Called/Calling Party Address Pt Code fields) before sending as a 'sccp' opcode. This option provides a way to send SCCP MSUs across TALI point to multipoint connections that includes the MTP3 header as part of the data transmitted, and does NOT involve any modification to the original SS7 SCCP MSU. When the ENABLE NORMALIZED SCCP primitive is received, SCCP MSUs should be sent across the TALI interface using the 'mtp3' opcode. This transmission should include the entire MTP3 header + the sccp portion of the original MSU. No modification of the original SS7 MSU should occur. When the DISABLE NORMALIZED SCCP primitive is received, SCCP MSUs should be sent across the TALI interface using the 'sccp' opcode as specified in version 1.0 of TALI.
* 启用/禁用规范化SCCP：TALI的1.0版规定必须在点对多点连接上使用“SCCP”TALI操作码，以便在SG和IP节点之间传输SCCP MSU。当使用“sccp”操作码时，原始SS7 MSU的MTP3头部分从MSU中剥离，并且不是通过TALI连接传输的数据的一部分。“sccp”TALI报文的发送方负责将MTP3报头中的DPC/OPC字段复制到报文sccp部分的相应字段中（复制到被叫方/主叫方地址Pt代码字段中），然后作为“sccp”操作码发送。该选项提供了一种通过TALI点对多点连接发送SCCP MSU的方法，该连接包括MTP3报头作为传输数据的一部分，并且不涉及对原始SS7 SCCP MSU的任何修改。当接收到启用规范化SCCP原语时，应使用“mtp3”操作码通过TALI接口发送SCCP MSU。该传输应包括整个MTP3头+原始MSU的sccp部分。不应对原SS7 MSU进行任何修改。当接收到禁用规范化SCCP原语时，应使用TALI版本1.0中指定的“SCCP”操作码通过TALI接口发送SCCP MSU。
* ENABLE/DISABLE NORMALIZED ISUP: Version 1.0 of TALI specified that the 'isot' TALI opcode must be used on point to multipoint connections in order to transmit ISUP MSUs between the SG and IP nodes. When using the 'isot' opcode, the original SS7 MSU, including the MTP3 header portion, was transmitted in a 'isot' TALI message. This option indicates that the far end would prefer to receive ISUP MSUs using the 'mtp3' TALI opcode as opposed to the 'isot' opcode. When the option is ENABLED, the 'mtp3' opcode is used to transmit ISUP MSUs, including the MTP3 header, across the TALI connection. When the option is DISABLED, the 'isot' opcode is used as in TALI Release 1.0.
* 启用/禁用标准化ISUP：TALI的1.0版规定必须在点对多点连接上使用“isot”TALI操作码，以便在SG和IP节点之间传输ISUP MSU。使用“isot”操作码时，原始SS7 MSU（包括MTP3头部分）以“isot”TALI消息传输。此选项表示远端希望使用“mtp3”TALI操作码而不是“isot”操作码接收ISUP MSU。启用该选项时，“mtp3”操作码用于通过TALI连接传输ISUP MSU，包括mtp3标头。当该选项被禁用时，“isot”操作码将与TALI 1.0版一样使用。
The data structure used for 'sorp' messages is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
用于“sorp”消息的数据结构如下表所示。下面的数据结构应该从TALI消息的字节14开始，如表12所示。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | SORP | Identifies which 'sorp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = Set SORP Flags | |
| | | 0x0002 = Request Current | |
| | | SORP Flags Settings | |
| | | 0x0003 = Reply w/ Current | |
| | | SORP Flag Settings | |
+------------------------------------------------------------------+
| 2 | SORP Flags | A 4 byte bit-field that uses | Bit-Field |
| | | each bit as an enabled/ | |
| | | disabled flag for a | |
| | | particular socket option. | |
| | | Bit x = 0 indicates the | |
| | | option is DISABLED. | |
| | | Bit x = 1 indicates the | |
| | | option is ENABLED. | |
| | | The assignments for each BIT | |
| | | are as follows: | |
| | | Bit 0 = Broadcast Phase MTPP | |
| | | Primitives | |
| | | Bit 1 = Response Method MTPP | |
| | | Primitives | |
| | | Bit 2 = Normalized SCCP | |
| | | Bit 3 = Normalized ISUP | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | SORP | Identifies which 'sorp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = Set SORP Flags | |
| | | 0x0002 = Request Current | |
| | | SORP Flags Settings | |
| | | 0x0003 = Reply w/ Current | |
| | | SORP Flag Settings | |
+------------------------------------------------------------------+
| 2 | SORP Flags | A 4 byte bit-field that uses | Bit-Field |
| | | each bit as an enabled/ | |
| | | disabled flag for a | |
| | | particular socket option. | |
| | | Bit x = 0 indicates the | |
| | | option is DISABLED. | |
| | | Bit x = 1 indicates the | |
| | | option is ENABLED. | |
| | | The assignments for each BIT | |
| | | are as follows: | |
| | | Bit 0 = Broadcast Phase MTPP | |
| | | Primitives | |
| | | Bit 1 = Response Method MTPP | |
| | | Primitives | |
| | | Bit 2 = Normalized SCCP | |
| | | Bit 3 = Normalized ISUP | |
+------------------------------------------------------------------+
Table 28: Message Data Structure to be used for 'sorp' Primitive
表28：用于“sorp”原语的消息数据结构
The Extended Service, 'xsrv', opcode is added to the TALI 2.0 protocol to lay the groundwork for providing a means to transport other types of service traffic (beyond 'sccp', 'isot', 'mtp3', and 'saal') in future revisions of this protocol without having to define a new opcode as each new service type is identified and added. The PRIMITIVE field will uniquely identify each new service type as they are added. It is envisioned that some 'xsrv' messages can be received and processed in any of the TALI NEx-FEx state, while some other 'xsrv' messages can only be received and processed in the NEA-FEA state (such as Service data in version 1.0 of TALI).
将扩展服务“xsrv”操作码添加到TALI 2.0协议中，为在本协议的未来版本中提供传输其他类型服务流量的方法奠定基础（除了“sccp”、“isot”、“mtp3”和“saal”），而无需在识别和添加每种新服务类型时定义新的操作码。原语字段将唯一地标识添加的每个新服务类型。可以预见，一些“xsrv”消息可以在任何TALI NEx FEx状态下接收和处理，而一些其他“xsrv”消息只能在NEA-FEA状态下接收和处理（如TALI 1.0版中的服务数据）。
There are no specific PRIMITIVES defined for this opcode in this release. It is expected that some new service messages will be added in the future. This opcode provides for grouping of the new service data types.
此版本中没有为此操作码定义特定的原语。预计未来将添加一些新的服务消息。此操作码提供了新服务数据类型的分组。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'xsrv' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | To be determined |
+------------------------------------------------------------------+
| 14.. | Message | To be determined |
| 2000 | Data | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'xsrv' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | To be determined |
+------------------------------------------------------------------+
| 14.. | Message | To be determined |
| 2000 | Data | |
+------------------------------------------------------------------+
The Special Message, 'spcl', opcode is added to the TALI 2.0 protocol to provide a way for vendors to build special services into their TALI implementations that are only activated when the implementation is connected to other equipment implementing the same special services. 'spcl' messages can be received and processed in any of the TALI NEx-FEx states. This opcode is intended to provide a general means to discover more information regarding who the TALI session is connected to, and to provide means to enable special features based on the vendor/implementation on the far end.
TALI 2.0协议中添加了特殊消息“spcl”操作码，以提供一种方式，供供应商将特殊服务构建到其TALI实现中，只有当实现连接到实现相同特殊服务的其他设备时，才会激活这些实现。”spcl信息可在任何TALI NEx FEx状态下接收和处理。本操作码旨在提供一种通用方法，以发现有关TALI会话连接到谁的更多信息，并提供基于远端供应商/实现的特殊功能的方法。
As part of the 2.0 specification, 4 primitives are initially defined for this opcode:
作为2.0规范的一部分，最初为此操作码定义了4个原语：
* 'smns' - Special Messages Not Supported. * 'qury' - Query. * 'rply' - Reply. * 'usim' - UnSolicited Information Message.
* “smns”-不支持特殊消息。*”qury'-Query.*'rply'-回复。*'usim”-未经请求的信息消息。
Additional primitives can be added in future versions of the TALI protocol.
可以在未来版本的TALI协议中添加其他原语。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' - special messages not supported |
| | | 'qury' - query |
| | | 'rply' - reply |
| | | 'usim' - UIM (unsolicited information msg)|
+------------------------------------------------------------------+
| 14..X | Data | Vendor dependent |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' - special messages not supported |
| | | 'qury' - query |
| | | 'rply' - reply |
| | | 'usim' - UIM (unsolicited information msg)|
+------------------------------------------------------------------+
| 14..X | Data | Vendor dependent |
+------------------------------------------------------------------+
This message is sent as a response to a 'spcl' message with a 'qury' PRIMITIVE. A node may send out this message when it wants the Far End to know that it does not support 'spcl' messages and wishes not to receive them in the future.
此消息作为对带有“qury”原语的“spcl”消息的响应发送。当节点希望远端知道它不支持“spcl”消息并且希望将来不接收它们时，它可以发送该消息。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' |
+------------------------------------------------------------------+
This message can be sent to Query the far end of the connection (ie: try to find out more information about the VENDOR, TALI version, or other features). It is expected that each 2.0 implementation would respond to a 'qury' with a 'rply'.
可以发送此消息以查询连接的远端（即：尝试查找有关供应商、TALI版本或其他功能的更多信息）。预计每个2.0实现都会以“rply”响应“qury”。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'qury' |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'qury' |
+------------------------------------------------------------------+
The 'rply' message provides a way for a TALI 2.0 implementation to identify itself in more detail. The information included in the reply includes:
“rply”消息为TALI 2.0实现提供了一种更详细地识别自身的方法。答复中包括的信息包括：
* PEC - a 2 byte field that identifies the vendor for the TALI implemenation.
* PEC-一个2字节字段，用于标识TALI实施的供应商。
* Version Number - a 12 byte field that identifies the TALI version of the implementation.
* 版本号-一个12字节的字段，用于标识实现的TALI版本。
* Other Vendor Specific Data - the format of any remaining data that a particular vendor wants to provide is specific to each vendor.
* 其他特定于供应商的数据-特定供应商希望提供的任何剩余数据的格式特定于每个供应商。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rply' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rply' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
*See Table 4 for details on the PEC field.
*有关PEC字段的详细信息，请参见表4。
A 'usim' provides the same information as the 'rply' primitive. The 'usim' can be sent at any time by a 2.0 implementation (whereas the 'rply' should only be sent in reply to a 'qury').
“usim”提供与“rply”原语相同的信息。“usim”可以在任何时候通过2.0实现发送（而“rply”只能在回复“qury”时发送）。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'usim' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'usim' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
Version 2.0 of the TALI specification does not introduce any new timers. The T1-T4 timers defined previously remain in effect.
TALI规范2.0版未引入任何新计时器。先前定义的T1-T4计时器仍然有效。
While, it is expected that most implementations wishing to identify themselves as 2.0 (or later) would use a non-zero value for T4 - this is a not a hard requirement. The only requirement for identifying yourself as 2.0 is to send at least 1 'moni' as per the 2.0 format upon connection establishment.
然而，预计大多数希望将自己标识为2.0（或更高版本）的实现将使用T4的非零值-这不是一个硬性要求。将自己标识为2.0的唯一要求是在建立连接时按照2.0格式发送至少1个“moni”。
Version 2.0 of the TALI specification does not introduce any new user events. The user events defined in Section 3.4 (mgmt open, mgmt close, mgmt allow, mgmt proh, connection established, connection lost) remain in effect.
TALI规范2.0版未引入任何新的用户事件。第3.4节中定义的用户事件（管理打开、管理关闭、管理允许、管理前置、连接建立、连接丢失）仍然有效。
Version 2.0 of the TALI specification does not introduce any new TALI states. The TALI states defined in Section 3.6 remain in effect.
TALI规范2.0版未引入任何新的TALI状态。第3.6节中定义的TALI状态仍然有效。
This section provides the state machine that must be followed by each TALI 2.0 implementation in order to be compliant with this specification. As mentioned throughout this document, a 2.0 implementation is based on several small additions to a 1.0 implementation and each 2.0 implementation must be willing to inter-operate in a backwards compatible mode (a 2.0 implementation connected to a 1.0 implementation must fall back to 1.0 features only).
本节提供了每个TALI 2.0实现必须遵循的状态机，以符合本规范。如本文档所述，2.0实现基于对1.0实现的几个小的添加，每个2.0实现必须愿意在向后兼容模式下进行交互操作（连接到1.0实现的2.0实现必须仅返回到1.0功能）。
Before presenting the actual state machine, several concepts are discussed.
在介绍实际的状态机之前，讨论了几个概念。
A set of general protocol rules was presented in the 1.0 specification, in section 3.7.1.1; those rules are still applicable to 2.0 implementations. In addition to those earlier rules, the following rules are also applicable to 2.0 nodes:
1.0规范第3.7.1.1节介绍了一套通用协议规则；这些规则仍然适用于2.0实现。除这些早期规则外，以下规则也适用于2.0节点：
* A 2.0 implementation should identify the TALI version it has implemented via the 'moni' message
* 2.0实现应通过“moni”消息识别其已实现的TALI版本
* A 2.0 implementation should process any received 'moni' messages, attempting to determine the TALI version of the far end. A 2.0 implementation must use an internal flag, such as 'far_end_version', to track the TALI version that the far end of the connection has implemented. The 'far_end_version' flag should be initialized to version 1.0.
* 2.0实现应处理任何接收到的“moni”消息，试图确定远端的TALI版本。2.0实现必须使用内部标志（如“远端版本”）来跟踪连接远端已实现的TALI版本。“远端版本”标志应初始化为1.0版。
* A 2.0 implementation should reject/ignore internal requests (from software layers in it's own product, or requests from the management interface for the device) to send TALI messages that require 2.0 opcodes when the far end is a 1.0 implementation. A 2.0 implementation should only send TALI messages that require new 2.0 opcodes (mgmt, xsrv, spcl) when it knows the far end is capable of processing those opcodes (when 'far_end_version' is 2.0 or greater).
* 当远端为1.0实现时，2.0实现应拒绝/忽略内部请求（来自自身产品中的软件层，或来自设备管理界面的请求），以发送需要2.0操作码的TALI消息。当2.0实现知道远端能够处理这些操作码时（当“远端版本”为2.0或更高版本时），仅应发送需要新2.0操作码（mgmt、xsrv、spcl）的TALI消息。
* Upon receiving a TALI message with a 2.0 opcode, a 2.0 implementation should interrogate its 'far_end_flag'; if the far end is not 2.0 or greater, the arrival of the message should be treated as a Protocol Violation. If the far end is 2.0 or greater, the message should be processed according to the nodes 2.0 capabilities, or ignored (if the node has chosen not to implement any 2.0 functionalities).
* 在接收到带有2.0操作码的TALI消息后，2.0实现应询问其“远端”标志；如果远端不是2.0或更高，则消息的到达应视为协议冲突。如果远端为2.0或更高，则应根据节点2.0功能处理消息，或忽略消息（如果节点选择不实现任何2.0功能）。
The steps to perform a graceful shutdown of each socket were presented in the 1.0 specification, in section 3.7.1.2. Those steps are not changed for 2.0 implementations.
第3.7.1.2节中的1.0规范中介绍了执行每个插座正常关闭的步骤。对于2.0实现，这些步骤没有更改。
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include:
每个TALI实施必须检测何时发生违反TALI协议的情况，并作出相应反应。违反协议的行为包括：
* Invalid sync code in a received message
* 接收到的消息中的同步代码无效
* Invalid opcode in a received message
* 接收到的消息中的操作码无效
* Invalid length field in a received message
* 接收到的消息中的长度字段无效
* Not receiving an 'allo' or 'proh', in response to the origination of a 'test' , before the T2 timer expires
* 在T2定时器到期之前，未收到响应“测试”发起的“allo”或“proh”
* Receiving Service Messages on a prohibited socket.
* 在禁止的套接字上接收服务消息。
* TCP Socket errors - Connection Lost
* TCP套接字错误-连接丢失
* Receiving a TALI message with a 2.0 opcode ('mgmt', 'xsrv', ' spcl') from a far end that has not identified itself as a 2.0 implementation.
* 从未将自身标识为2.0实现的远端接收带有2.0操作码（“mgmt”、“xsrv”、“spcl”）的TALI消息。
In the state machine that follows, State/Event combinations that should be treated as protocol violations are indicated via a 'PV' in the state/event cell. All of the 'PV' events are then processed as per the 'Protocol Violation' row in the table.
在随后的状态机中，应视为违反协议的状态/事件组合通过状态/事件单元中的“PV”指示。然后根据表中的“协议冲突”行处理所有“PV”事件。
Internal Data required for State Machine:
状态机所需的内部数据：
* boolean sock_allowed. This flag indicate whether the NE is allowed to carry Service Messages.
* 允许布尔sock_。此标志指示是否允许网元承载服务消息。
* Far_end_version. This enumeration should track the TALI version of the far end of the socket.
* 远端版本。此枚举应跟踪套接字远端的TALI版本。
Initial Conditions: sock_allowed = FALSE far_end_version = 1.0 state = OOS no timers running
初始条件：sock\u allowed=FALSE far\u end\u version=1.0 state=OOS无定时器运行
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Update |Update |Update |Update |
| | | |'far end |'far end |'far end |'far end |
| | | |version' |version' |version' |version' |
| | | |based on |based on |based on |based on |
| | | |moni |moni |moni |moni |
| | | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Update |Update |Update |Update |
| | | |'far end |'far end |'far end |'far end |
| | | |version' |version' |version' |version' |
| | | |based on |based on |based on |based on |
| | | |moni |moni |moni |moni |
| | | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Rcv mgmt| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv xsrv| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv spcl| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Rcv mgmt| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv xsrv| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv spcl| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|mgmt | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|xsrv | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|spcl | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|mgmt | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|xsrv | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|spcl | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
Table 29: TALI 2.0 State Machine
表29:TALI2.0状态机
Several limitations with the TALI 2.0 specification are identified. These are considered possible areas for expansion of the protocol in the future:
确定了TALI 2.0规范的几个限制。这些被认为是今后扩大议定书的可能领域：
* Support for different types of routing keys is limited. It is envisioned that new routing key types will need to be added and supported as new applications are identified.
* 对不同类型路由密钥的支持是有限的。可以预见，随着新应用程序的确定，将需要添加和支持新的路由密钥类型。
* An opcode, or new primitive within an existing opcode, could be added as a means of returning unknown or unsupported data to the sender. In addition to discarding and storing internal debug data, an implementation may want to return the original TALI message to the sender when the receiver of the message deems the message to be unknown, unsupported, or incorrectly formatted.
* 可以添加操作码或现有操作码中的新原语，作为向发送方返回未知或不受支持数据的一种方式。除了丢弃和存储内部调试数据外，当消息的接收者认为消息未知、不受支持或格式不正确时，实现可能还希望将原始TALI消息返回给发送者。
The following list provides all the known success/failure codes that are being used for the rkrp feature. New defines will be added to the end of the list as they are identified.
下表提供了用于rkrp功能的所有已知成功/失败代码。新定义将在确定后添加到列表的末尾。
Error # Meaning 1 Transaction successfully completed. 2 Length of TALI msg is insufficient to contain all required information for rkrp operation 3 Unsupported 'rkrp' operation 4 Invalid SI. SI must be in range 0..15 5 Invalid SI/operation combination. Split and resize only supported for SI=4,5,13. Enter, delete and override supported for all SI. 6 Invalid DPC. Point code cannot be zero, and must be full point code. 7 Invalid SSN. SSN must be in range 0..255. 8 Invalid OPC. Point code cannot be zero, and must be full point code. 9 Invalid CICS. Must be in range appropriate for SI and PC type. 10 Invalid CICE. Must be in range appropriate for SI and PC type. 11 Invalid CIC range. CICS must be less than or equal to CICE. On a split operation, CICS must be strictly less than than CICE (cannot split an range with only one entry). 12 Invalid NCICS. Must be in range appropriate for SI and PC type.
错误#表示1笔交易成功完成。2 TALI msg的长度不足以包含rkrp操作所需的所有信息3不支持的“rkrp”操作4无效SI。SI必须在0到15之间。5无效的SI/操作组合。仅SI=4,5,13支持拆分和调整大小。输入、删除和覆盖所有SI支持的内容。6无效的DPC。点代码不能为零，并且必须为完整点代码。7无效的SSN。SSN必须在0到255之间。8无效的OPC。点代码不能为零，并且必须为完整点代码。9无效的CICS。必须在适用于SI和PC类型的范围内。10无效CICE。必须在适用于SI和PC类型的范围内。11无效的CIC范围。CICS必须小于或等于CICE。在拆分操作中，CICS必须严格小于CICE（不能仅使用一个条目拆分范围）。12个无效NCIC。必须在适用于SI和PC类型的范围内。
13 Invalid NCICE. Must be in range appropriate for SI and PC type. 14 Invalid new CIC range. NCICS must be less than or equal to NCICE. 15 Invalid SPLIT value. Must be in range appropriate for SI and PC type. Must be greater than CICS and less than or equal to CICE. 16 No free entries in table. 17 CIC range overlaps but does not match existing entry. 18 Entry already has 16 associations. 19 Entry to be changed not found in table. 20 New entry would overlap another entry (allowed to overlap the entry being changed, but no others). 21 Entry to be deleted not found in table. 22 TUP routing keys are not supported for ANSI networks
13无效的NCICE。必须在适用于SI和PC类型的范围内。14无效的新CIC范围。NCICS必须小于或等于NCICE。15无效的分割值。必须在适用于SI和PC类型的范围内。必须大于CICS且小于或等于CICE。16表中没有自由项。17 CIC范围重叠，但与现有条目不匹配。18个条目已经有16个关联。19在表中找不到要更改的条目。20新条目将与另一条目重叠（允许与正在更改的条目重叠，但不允许与其他条目重叠）。21在表中找不到要删除的条目。ANSI网络不支持22个TUP路由键
TALI is an interface for the transport of SS7 traffic and management messages across an IP network. As with traditional PSTN networks, the IP networks using TALI are expected to well engineered systems. The use of virtual private networks and firewalls is to be expected. In addition, the use of IPSEC will bring added security benefit to the network.
TALI是通过IP网络传输SS7流量和管理消息的接口。与传统的PSTN网络一样，使用TALI的IP网络预计能够很好地构建系统。预计将使用虚拟专用网络和防火墙。此外，IPSEC的使用将为网络带来额外的安全好处。
[1] Bell Communications Research, Specification of Signaling System Number 7, GT-246-CORE, Bellcore, Issue 1, December 1994.
[1] 贝尔通信研究，第7号信号系统规范，GT-246-CORE，贝尔CORE，第1期，1994年12月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[3] Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4] 《传输控制协议》，标准7，RFC 793，1981年9月。
[5] Logical Link Control, IEEE 802.2 and ISO 8802.2
[5] 逻辑链路控制，IEEE 802.2和ISO 8802.2
[6] Carrier Sense Multiple Access with Collision Detection (Ethernet), IEEE 802.3 and ISO 8802-3 CSMA/CD.
[6] 带冲突检测的载波侦听多址接入（以太网）、IEEE 802.3和ISO 8802-3 CSMA/CD。
[7] Virtual LAN, IEEE 802.1 Q and ISO 8802-1Q CSMA/CD.
[7] Virtual LAN, IEEE 802.1 Q and ISO 8802-1Q CSMA/CD.translate error, please retry
[8] Bell Communications Research, Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links (HSLs), GR-2878-CORE, Issue 1, Bellcore, November 1995.
[8] 贝尔通信研究，支持ATM高速信令链路（HSL）的CCS节点的一般要求，GR-2878-CORE，第1期，贝尔CORE，1995年11月。
[9] Bell Communications Research, Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE, Bellcore.
[9] 贝尔通信研究，异步传输模式（ATM）和ATM适配层（AAL）协议，GR-1113-CORE，贝尔核心。
[10] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), T1.637.
[10] 美国国家标准协会，B-ISDN信令ATM适配层-面向服务的连接协议（SSCOP），T1.637。
[11] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SSCF at the NNI), T1.645.
[11] 美国国家标准协会，B-ISDN信令ATM适配层-支持网络节点接口（NNI的SSCF）信令的特定服务协调功能，T1.645。
[12] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, T1.652.
[12] 美国国家标准协会，NNI SAAL的B-ISDN信令ATM适配层管理，T1.652。
The authors would like to thank Ken Morneault for his comments and contributions to the document.
作者要感谢Ken Morneault对该文件的评论和贡献。
David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com
David Sprague Tekelec 5200派拉蒙Pkwy。莫里斯维尔，北卡罗来纳州27560电话：+1919-460-5563电子邮件：大卫。sprague@tekelec.com
Dan Brendes Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-2162 EMail: dan.brendes@tekelec.com
Dan Brendes Tekelec 5200派拉蒙Pkwy。莫里斯维尔，北卡罗来纳州27560电话：+1919-460-2162电子邮件：丹。brendes@tekelec.com
Robby Benedyk Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5533 EMail: robby.benedyk@tekelec.com
罗比·贝内迪克·泰克5200派拉蒙Pkwy。北卡罗来纳州莫里斯维尔27560电话：+1919-460-5533电子邮件：robby。benedyk@tekelec.com
Joe Keller Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5549 EMail: joe.keller@tekelec.com
Joe Keller Tekelec 5200派拉蒙Pkwy。莫里斯维尔，北卡罗来纳州27560电话：+1919-460-5549电子邮件：乔。keller@tekelec.com
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。