RFC3094 日本語訳
3094 Tekelec's Transport Adapter Layer Interface. D. Sprague, R.Benedyk, D. Brendes, J. Keller. April 2001. (Format: TXT=265099 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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's Transport Adapter Layer Interface
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
IESG Note:
IESG Note:
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.
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.
Abstract
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.
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.
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.
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.
Sprague, et al. Informational [Page 1] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 1] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Table of Contents
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. 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
Sprague, et al. Informational [Page 2] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 2] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
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 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
Sprague, et al. Informational [Page 3] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 3] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
1. Introduction
1. Introduction
This document is organized into the following 6 sections:
This document is organized into the following 6 sections:
- Introduction to the document - Overview of the TALI Protocol - TALI Version 1.0 - TALI Version 2.0 - Success/Failure Codes - Security Considerations
- Introduction to the document - Overview of the TALI Protocol - TALI Version 1.0 - TALI Version 2.0 - Success/Failure Codes - Security Considerations
The following terms are used throughout this document.
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.
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.
Changeover/Changeback (co/cb): SS7 MTP3 procedure related to link failure and re-establishment.
Changeover/Changeback (co/cb): SS7 MTP3 procedure related to link failure and re-establishment.
Far End (FE): The remote endpoint of a socket connection.
Far End (FE): The remote endpoint of a socket connection.
Far End Allowed (FEA): The FE is ready to use the socket for service PDUs.
Far End Allowed (FEA): The FE is ready to use the socket for service PDUs.
Far End Prohibited (FEP): The FE is not ready to use the socket for service PDUs.
Far End Prohibited (FEP): The FE is not ready to use the socket for service PDUs.
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.
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.
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.
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.
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.
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.
Sprague, et al. Informational [Page 4] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 4] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
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.
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.
MTP3 Framing (MTP3F): TALI does not require full MTP3 procedures support but rather uses the MTP3 framing structure (ie: SIO, Routing Label, etc)
MTP3 Framing (MTP3F): TALI does not require full MTP3 procedures support but rather uses the MTP3 framing structure (ie: SIO, Routing Label, etc)
Near End (NE): The local endpoint of a socket connection.
Near End (NE): The local endpoint of a socket connection.
Near End Allowed (NEA): The NE is ready to use the socket for service PDUs.
Near End Allowed (NEA): The NE is ready to use the socket for service PDUs.
Near End Prohibited (NEP): The NE is not ready to use the socket for service PDUs.
Near End Prohibited (NEP): The NE is not ready to use the socket for service PDUs.
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: 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.
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.
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.
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).
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).
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:
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:
Sprague, et al. Informational [Page 5] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 5] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
- Local Retrieve of messages to support link changeover procedures - Flow control with four levels of congestion
- 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.
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.
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:
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:
- In-Sequence Delivery - Flow Control - Error Detection/Correction - Keep Alive - Local Data Retrieval - Connection Control - Protocol Error Detection and Recovery
- 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.
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.
2. Overview of the TALI Protocol
2. Overview of the TALI Protocol
2.1 Traditional PSTN SS7 Networks
2.1 Traditional PSTN SS7 Networks
The traditional PSTN SS7 network consists of 3 types of devices connected via dedicated SS7 signaling links.
The traditional PSTN SS7 network consists of 3 types of devices connected via dedicated SS7 signaling links.
The 3 primary device types for PSTN networks are:
The 3 primary device types for PSTN networks are:
* 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: 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.
Sprague, et al. Informational [Page 6] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 6] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
* 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: 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.
* SCP: Signaling Control Point. These nodes act as databases.
These nodes contain stored data that is used to turn SS7 Queries
into SS7 Replies.
* SCP: Signaling Control Point. These nodes act as databases. These nodes contain stored data that is used to turn SS7 Queries into SS7 Replies.
There are 3 primary types of dedicated SS7 signaling links:
There are 3 primary types of dedicated SS7 signaling links:
* 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) links. These links implement the MTP-1 and MTP-2 protocols as defined in [1].
* 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 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].
* E1 Links.
* E1 Links.
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.
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.
Sprague, et al. Informational [Page 7] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 7] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
^
/ \
/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
Figure 1: The Traditional PSTN Network
2.2 Converged SS7 Networks
2.2 Converged SS7 Networks
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.
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.
Signaling Gateways are new devices that may also function as an STP in the converged network. SGs provide interfaces to:
Signaling Gateways are new devices that may also function as an STP in the converged network. SGs provide interfaces to:
* devices on the SCN (traditional SSPs, STPs, and SCPs)
* devices on the SCN (traditional SSPs, STPs, and SCPs)
* other SGs
* other SGs
* new devices on the IP network
* new devices on the IP network
SGs also continue to perform STP functions such as SS7 network management and some database services (such as GTT and LNP).
SGs also continue to perform STP functions such as SS7 network management and some database services (such as GTT and LNP).
Sprague, et al. Informational [Page 8] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 8] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
New devices on the IP network include:
New devices on the IP network include:
* Media Gateway Controllers. In addition to other functions, these
devices control Media Gateways and perform call processing.
* 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.
* 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.
* IP based SCPs. The database services that are related to SS7 can
be moved onto devices on the IP network.
* IP based SCPs. The database services that are related to SS7 can be moved onto devices on the IP network.
Figure 2 provides an overview of the converged SS7 network.
Figure 2 provides an overview of the converged SS7 network.
----- +----+
/\ / \-------------| 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
Figure 2: The Converged SS7 Network
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:
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:
Sprague, et al. Informational [Page 9] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 9] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
- 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.
- 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.
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:
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:
- For SG to SG communication - For SG to MGC communication - For SG to IP based SCP communication
- For SG to SG communication - For SG to MGC communication - For SG to IP based SCP communication
2.3 TALI Protocol Stack Overview
2.3 TALI Protocol Stack Overview
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.
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.
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.
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.
Sprague, et al. Informational [Page 10] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
Sprague, et al. Informational [Page 10] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
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
Figure 3: TALI Protocol to carry SS7 over TCP/IP
From Figure 3, several observations can be made:
From Figure 3, several observations can be made:
* The TALI layer is used when transferring SS7 over IP.
* The TALI layer is used when transferring SS7 over IP.
* 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
* IPネットワークの上までSS7トラフィックを運ぶとき、伝統的な56Kbpsの層がリンクするMTP2とMTP1をTALI、TCP、IP、およびMAC層に取り替えます。
* The TALI layer sits on top of the TCP layer.
* TCP層の上にTALI層があります。
* 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サービスデータ・パケットのデータ部として運ばれます。
Sprague, et al. Informational [Page 11] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[11ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
* 単一のTCPソケットの上にそれぞれのTALI接続を提供します。
* The standard Berkeley sockets interface to the TCP is used by
the TALI layer to provide connection oriented service from
endpoint to peer endpoint.
* TCPへの標準のバークレーのソケットインタフェースはTALI層によって使用されて、コネクション型サービスを終点から同輩終点に提供します。
* 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ソケットはClient/サーバー・アーキテクチャに基づいています。 'サーバ側'、他の終わりが'クライアント'であると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.
* クライアント/サーバーの役割が単に2終点の間にTCP接続を育てるのにおいて重要である、接続がいったん確立されると、両端はデータを移すという同じバークレーのソケット要求(発信してください、recv)を使用します。
* The TCP socket must be connected before the 2 TALI endpoints
can begin communicating.
* 2つのTALI終点が、交信し始めることができる前にTCPソケットを接続しなければなりません。
* 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はPeerメッセージにPeerを提供します。 これらのメッセージは、接続の1つの終点のTALI層から発して、もう片方の終点のTALI層で終えられます。 使用されるPeerメッセージとしてじっと見てください:
* 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はメッセージをServiceに供給します。 これらのメッセージは、層でもう片方の終点のTALI層を超えて接続の1つの終点のTALI層の上の層から溯源して、わたって終えられます。
Sprague, et al. Informational [Page 12] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[12ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.
* 私たちが後で見るように、異なったService opcodesはTALIソケットの向こう側にそれぞれのSS7メッセージがちょうどどうカプセル化されたかを伝えるのに使用されます。
* A set of TALI timers is defined. These timers are used to
correctly implement the TALI state machine.
* 1セットのTALIタイマは定義されます。 これらのタイマは、正しくTALI州のマシンを実装するのに使用されます。
2.3.1 An Alternate TALI Protocol Stack using the SAAL Layer
2.3.1 SAAL層を使用する代替の崖錐プロトコル・スタック
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はSGのSS7側面とIPデバイスでSS7MSUを輸送するのに使用できる基本的なTALIプロトコル・スタックを目立たせた簡単なイラストを56個のKbpsリンクの間に供給しました。
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 以下では、データの一部がTCP/IP接続の向こう側に移されたのでSAAL層を含んでいる代替のTALIプロトコル・スタックが例証します。
Sprague, et al. Informational [Page 13] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[13ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
SS7 traffic SS7 traffic
via DS1 links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
TALI+を通したDS1リンクを通したSS7トラフィックSS7トラフィック-----------+ +----+ +--------+ |伝統的| | SG| | IP| |SS7デバイス| <、-、-、-、-、--、>| | <、-、-、-、-、-、-、--、>| デバイス| +-----------+ +----+ +--------+
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プロトコル・スタックプロトコル・スタック+-----------------+ +-----------------+ | SS7アプリケーション| | SS7アプリケーション| | 層| | 層| +--------+--------+ +--------+--------+ | TCAP| ISUP| | TCAP| ISUP| +--------+ | +--------+ | | SCCP| | | SCCP| | +--------+--------+ +--------+--------+ | MTP3| | MTP3| +-----------------+ +-----------------+ | SAAL| | SAAL| |(SSCF、MAAL、SSCOP)| |(SSCF、MAAL、SSCOP)| +-----------------+ +-----------------+ | AAL5| | 崖錐| +-----------------+ +-----------------+ | 気圧| | TCP| | (phy。 | +-----------------+ | 層) | | IP| +-----------------+ +-----------------+ | Mac| | (phy。 | | 層) | +-----------------+
Figure 4: An Alternate TALI Protocol Stack with SAAL
図4: SAALがある代替の崖錐プロトコル・スタック
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:
以下の弾丸はこれらの2個のプロトコル・スタックの違い、2個のプロトコル・スタックを持つ理由、およびそれぞれの利点についての議論を提供します:
* 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プロトコル・スタックが図3のようにSAAL層なしで実装されるとき、SS7 MSUのSEQUENCE NUMBERはTCP/IP接続の向こう側に移されたデータの一部ではありません。 56個のKbps SS7リンクでは、MTP2ヘッダーは各MSUのための8ビットの一連番号を含んでいます。 一連番号は、メッセージ配列を保存して、複雑なSS7手順がリンク転換の間、MSU検索にかかわって、changebackであるとサポートするのに使用されます。 図3にみられるように、MTP2ヘッダーは移されたデータの一部ではありません。
Sprague, et al. Informational [Page 14] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[14ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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接続の向こう側に。 SS7転換とchangebackが手順であるとSAALのないTALIプロトコル・スタックはまだSS7データの正しい配列を保証していて(TCP層の一連番号でこの配列を提供します)、しかしながら、そのプロトコル・スタックは、サポートすることができません。
* 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.
* TALIプロトコル・スタックが図4のようにSAAL層で実装されるとき、データのSS7 MSU IS部分のSEQUENCE NUMBERはTCP/IPの向こう側に移しました。 SS7 DS1リンクでは、SSCOPトレーラは各MSUのための24ビットの一連番号を含んでいます。 この24ビットの一連番号は8ビットのSS7一連番号と同じ目的に役立ちます。 図4にみられるように、SSCOPトレーラはTCP/IP接続の向こう側に移されたデータの一部です。 図4のプロトコル・スタックは、SS7転換とchangebackが手順であるとサポートすることができます。
* 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共同/cbとデータの検索のサポートを前提として、SS7リンクが非活性化されるときMSUの損失を最小にするのを助けることができます。 しかしながら、SAALを実装するのは、ざらにある出来事ではありません。 SAAL層は3つの副層(SSCF、SSCOP、およびMAAL)から成ります。その1つはかなり伴われます(SSCOP)。 それは思い描かれます。TCP/IPアプリケーションへのほとんどのSS7は、SAALを実装するのを選ばないでしょう。
2.3.2 An Alternate TALI Protocol Stack using SCTP
2.3.2 SCTPを使用する代替の崖錐プロトコル・スタック
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は唯一の信頼できて、立証されたトランスポート層でした。 簡単なControl Transportプロトコル(SCTP)は、後で現在、特に合図するように輸送として設計される予定です。 かつて、SCTPが立証されて受け入れられたトランスポート・プロトコルである、そして、TCPに代わって図3と4に示されるようにSCTPを使用できます。
2.4 Inputs to the TALI Version 1.0 State Machine
崖錐バージョン1.0への2.4の入力がマシンを述べます。
Figure 5 illustrates the inputs that affect the TALI State Machine. Inputs to the state machine include:
図5はTALI州Machineに影響する入力を例証します。 州のマシンへの入力は:
* Management events (ie: requests from the human user of the TALI
connection) to control the operation of a particular TALI session.
* 特定のTALIセッションの操作を制御する管理イベント(ie: TALI接続の人間のユーザからの要求)。
* TALI messages received from the Peer. These messages include peer
to peer messages as well as service data messages.
* TALIメッセージはPeerから受信されました。 これらのメッセージはサービスデータメッセージと同様にピアツーピアメッセージを含んでいます。
* 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のUserからのイベントは層にされます。 ユーザはプロトコル・スタックのTALIの上の層、SS7であるかSAALが層にします。
Sprague, et al. Informational [Page 15] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[15ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.
* タイマイベント。
Sprague, et al. Informational [Page 16] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[16ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+====+ +============+
| | +---------+ +-------------+ | |
|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 |
| |
+============+
+====+ +============+ | | +---------+ +-------------+ | | |ユーザ| | サービス| | 管理。 開いてください。| | 管理| |部分| <-->、| メッセージ| | 管理。 閉鎖| <-->、|、|、|、|、|、|、| 管理。 Proh。 | | | | | +---------+ | 管理。 許容します。| +============+ +====+ ^ +-------------+ | ^ | | v対+========================================================+ | 崖錐州のマシン| +========================================================+ ^ ^ ^ ^ | | | | | | | | v| | | +---------+ +-----------------+ +-----------+ +------------+ | 受信します。| | 接続est。 | | プロトコル| | T1は期限が切れました。| | 'テスト'| | 接続は損をしました。| | 違反| | T2は期限が切れました。| | '異'| | | | | | T3は期限が切れました。| | 'proh'| +-----------------+ +-----------+ | T4は期限が切れました。| | '快速帆船'| ^ ^ +------------+ | 'moni'| | | ^ | 'mona'| | | | | または| | | | | サービス| | | | | メッセージ| +========================================+ +---------+ | 実装| ^ | 扶養家族| | +========================================+ | +に対して============+ | 同輩| | | +============+
Figure 5: Overview of Inputs to the TALI 1.0 State Machine
図5: 崖錐1.0州のマシンへの入力の概要
Sprague, et al. Informational [Page 17] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[17ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3. TALI Version 1.0
3. 崖錐バージョン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プロトコル層を提供するために実装しなければならない州、メッセージ、交換処理規則、および州のマシンを提供します。
3.1 Overview of the TALI Message Structure
3.1 崖錐メッセージ構造の概要
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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| 記述| サイズ| 値| タイプ| +------------------------------------------------------------------+ | 0..3 | 同時性| 4つの八重奏| | 4バイト| | | | | | ASCII| +------------------------------------------------------------------+ | | 崖錐| | '崖錐'| | +------------------------------------------------------------------+ | 4..7 | OPCODE| 4つの八重奏| | 4バイト| | | | | | ASCII| +------------------------------------------------------------------+ | | テストサービス| | 'テスト'| | | | サービスを許してください。| | '異'| | | | サービスを禁止してください。| | 'proh'| | | | サービスAckを禁止してください。| | '快速帆船'| | | | モニターソケット| | 'moni'| | | | モニターソケットAck| | 'mona'| | | | SCCPサービス| | 'sccp'| | | | ISUPサービスオーバー崖錐| | 'isot'| | | | MTP3サービスオーバー崖錐| | 'mtp3'| | | | サービスオーバーSAAL| | 'saal'| | +------------------------------------------------------------------+ | 8..9 | 長さ| 2つの八重奏| | 整数| | | (最も重要でない、| | | | | | バイト、1番目) 非0| | | | | | またはサービスである。| | | | | | ソケットモニターメッセージ| | | | +------------------------------------------------------------------+ | 10..X| データペイロード| 変数| | 変数| +------------------------------------------------------------------+
Table 2: Message Structure for TALI 1.0
テーブル2: 崖錐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.0opcodeのためにLENGTH分野の有効値を示します。 いつもLENGTH分野は一般的なTALIメッセージのDATA PAYLOAD部分に含まれたバイトの#のしるしです。
Sprague, et al. Informational [Page 18] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[18ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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| 有効な長さの値| コメント| +------------------------------------------------------------------+ | テスト| 0バイト| | +------------------------------------------------------------------+ | 異| 0バイト| | +------------------------------------------------------------------+ | proh| 0バイト| | +------------------------------------------------------------------+ | 快速帆船| 0バイト| | +------------------------------------------------------------------+ | moni| 0-200バイト| 最大の長さを非常に提供します。| | | | それは最大のイーサネットフレームです。| | | | サイズは超えられていません。 | +------------------------------------------------------------------+ | mona| 0-200バイト| モナ回答の長さと内容はそうしなければなりません。| | | | オリジナルのmoniを合わせてください、(| | | | opcodeの例外、)| +------------------------------------------------------------------+ | sccp| 12-265バイト| これらは有効なサイズです。| | | | SCCP UDTのSCCPだけ部分| | | | MSU| +------------------------------------------------------------------+ | isot| 8-273バイト| 長さは八重奏の数です。| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さのインクルード| | | | SIOバイト、MTP3ルーティング| | | | そしてラベル、CICコード。| | | | ISUP Message Type分野、およびいずれも| | | | 部分として存在するかもしれない他のバイト| | | | SIF(サービス情報| | | | 分野)について| +------------------------------------------------------------------+ | mtp3| 5-280バイト| 長さは八重奏の数です。| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さのインクルード| | | | SIOバイトとMTP3ルーティング| | | | labeld、およびいかなる他のバイト、もそれ| | | | SIFの一部として存在するかもしれません。| | | | (サービス情報フィールド) | +------------------------------------------------------------------+ | saal| 11-280バイト| 長さは八重奏の数です。| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さのインクルード| | | | SIOバイトと中のすべてのバイト| | | | SIF(サービス情報フィールド)| | | | さばきます。 MTP3ルーティングラベルはそうです。| | | | SIF分野の一部。 7(7)|
Sprague, et al. Informational [Page 19] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[19ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | octets of SSCOP trailer is added | | | | to the message. The SSCOP trailer| | | | bytes are also included in the | | | | length. | +------------------------------------------------------------------+
| | | SSCOPトレーラの八重奏は加えられます。| | | | メッセージに。 SSCOPトレーラ| | | | また、バイトは含まれています。| | | | 長さ。 | +------------------------------------------------------------------+
Table 3: Valid Length Fields for Each Opcode in TALI 1.0
テーブル3: 崖錐1.0における各Opcodeに、有効な長さの分野
3.1.1 Types of TALI Fields
3.1.1 崖錐分野のタイプ
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 |
+------------------------------------------------------------------+ |フィールド・タイプ| そのTypeのための実装Notes| +------------------------------------------------------------------+ |4バイト| * 4バイトのASCIIテキスト文字列は定義するのにおいて使用されています。| |ASCIIテキスト| 基本のTALIメッセージのコードとopcodeを同期させてください、|| | * これらの分野が大文字と小文字を区別している、コード化| | | それぞれの同時性とopcodeリテラルは、合う必要があります。| | | ケースはTable2で指定しました。 | | | * 変換テーブルが使用されている標準のASCII| | | 各キャラクタを1バイトに変えてください。 | | | * ASCII文字の注文は重要です。 | | | ストリングにおける最初のキャラクタはそうであるに違いありません。| | | まず最初に、キャラクタはワイヤの向こう側に伝わりました。 | | | * コード化されるストリングが例えば'abCD'であるなら| | | それらはバイトですが、移して、注文します。| | | ワイヤ必須の上では、である: | | | 最初のバイト: 0×61 ('a')3番目のバイト: 0×43 ('C')| | | 2番目のバイト: 0×62 ('b')4番目のバイト: 0×44('D')| | | * 各実装のためのソフトウェアはそうであるべきです。| | | 必要を説明する方法で、書かれています。| | | トランスミッションのバイトオーダー、(ie;
Sprague, et al. Informational [Page 20] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[20ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | 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. | +------------------------------------------------------------------+
| | opcodeに、DATA PAYLOADが始まる'mtp3'を通して| | | MTP3ルーティングラベルのSIOバイト。 The| | | 全体のDATA PAYLOADのための構造は決定されます。| | | [1]で定義されたMTP3メッセージ構造のそばで。 | +------------------------------------------------------------------+ |Xバイト| * 4バイト以外のサイズに関するASCIIテキストフィールド| |ASCIIテキスト| 同じ規則に従って、サポートされるべきです。| | | ASCIIテキストフィールドを4バイト提示しました。 for| | | インスタンス、'ab01cd23'などの8バイトのストリングはそうすることができました。| | | 'a'が最初のバイトであるところで使用されてください。| | | 野原はワイヤから伝わりました。 | +------------------------------------------------------------------+
Table 4: Implementation Notes for each Type of TALI field
テーブル4: TALIの各TypeのためのNotesがさばく実装
3.2 Detailed TALI Message Structure
3.2 詳細な崖錐メッセージ構造
3.2.1 TALI Peer to Peer Messages
3.2.1 崖錐ピアツーピアメッセージ
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で実装されるPeerメッセージにTALI Peerに関する詳しい情報を提供します。 TALIピアツーピアメッセージは、ソケットの1つの端のTALI層で接続(近い終わり)を溯源して、接続の遠端のTALI層で終えられます。
3.2.1.1 Test Message (test)
3.2.1.1 テストメッセージ(テスト)
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実装によって使用されて、リモートエンドがSS7サービスデータを運ぶ意欲に関してTALI接続のリモートエンドについて質問します。 このメッセージはもう一方の端を尋ねます: あなたはサービスデータを運ぶ準備ができていますか? T1タイマ間隔に基づくそれぞれのTALI実装は定期的にこのメッセージを送ります。 'テスト'を受けると、TALI実装は、そのTALI接続の上までSS7サービスデータを運ぶノード意欲を示すために'proh'か'異'のどちらかで返答しなければなりません。
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'test' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length = 0 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'テスト'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ=0| +------------------------------------------------------------------+
Sprague, et al. Informational [Page 21] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[21ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.2.1.2 Allow Message (allo)
3.2.1.2 メッセージを許容してください。(異)
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.
TALI実装が、TALIセッションの間、SS7サービスデータを運んでも構わないと思っているのを示すために'テスト'質問に対して何らかの内部の実装イベントに対応して'異'メッセージを送ります。 このメッセージはソケットの上にSS7トラフィックを伝えることができる遠い終わりに知らせます。 '異'は'テスト'メッセージに関する2つの可能な回答の1つです。 ソケットの上までSS7トラフィックを運ぶことができる前に、接続の両端は、'異'メッセージを送る必要があります。
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'allo' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length = 0 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| '異'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ=0| +------------------------------------------------------------------+
3.2.1.3 Prohibit Message (proh)
3.2.1.3 メッセージを禁止してください。(proh)
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.
TALI実現がTALIセッションの間、SS7サービスデータを運ぶことを望んでいないのを示すために'テスト'質問に対していくつかの内部の実現出来事に対応して'proh'メッセージを送ります。 このメッセージはソケットの上にSS7交通を伝えることができない遠い終わりに知らせます。 'proh'は'テスト'メッセージに関する2つの可能な回答の1つです。 接続の1つの終わりが'禁止された'州に残っている限り、ソケットの上までSS7交通を運ぶことができません。
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'proh' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length = 0 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'proh'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ=0| +------------------------------------------------------------------+
3.2.1.4 Prohibit Acknowledgement Message (proa)
3.2.1.4 確認メッセージを禁止してください。(快速帆船)
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実現で'快速帆船'メッセージを送ります。 彼の'禁止'メッセージが正しく受け取られて、それに従って、影響されるのを遠端に示すためにこのメッセージを送ります。
Sprague, et al. Informational [Page 22] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[22ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'proa' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length = 0 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| '快速帆船'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ=0| +------------------------------------------------------------------+
3.2.1.5 Monitor Message (moni)
3.2.1.5 モニターメッセージ(moni)
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実現で使用できる一般的なECHO能力を提供します。 TALIバージョン1.0実現は1.0仕様で言いなりになる'moni'メッセージを溯源する必要はありません。 このメッセージの第一の意図はTALI層がソケットの上に往復のメッセージ転送時間をテストする方法を提供することです。 それぞれの受信された'moni'メッセージに対して'mona'メッセージを送らなければなりません。 'moni'メッセージのDATA部分は業者実現に依存しています。 それぞれの'mona'回答のDATA部分はまさに答えられる'moni'のDATA部分に合わなければなりません。 実現が、'moni'を送るのを選ぶかどうかにかかわらず、TALIプロトコルで言いなりになったままで残るために各'moni'に対応して'mona'を送らなければなりません。
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'moni' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..X | DATA PAYLOAD| Vendor Dependent | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'moni'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| データペイロード| 業者に依存しています。| +------------------------------------------------------------------+
3.2.1.6 Monitor Acknowledge Message (mona)
3.2.1.6 モニターはメッセージを承認します。(mona)
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.
以上のように、それぞれの容認された'moni'に対して'mona'を送らなければなりません。 'mona'DATA領域のコンテンツは受信された'moni'メッセージのDATA領域に合わなければなりません。
Sprague, et al. Informational [Page 23] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[23ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'mona' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..X | DATA PAYLOAD| Vendor Dependent | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'mona'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| データペイロード| 業者に依存しています。| +------------------------------------------------------------------+
3.2.2 Service Messages
3.2.2 サービスメッセージ
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 Serviceメッセージに関する詳しい情報を提供します。 TALI Serviceメッセージは、IPネットワークの向こう側にSS7MSUを運ぶのに使用されます。 このセクションの情報はそれぞれのTALIサービスopcodesを使用することでどうTCP/IPフレームにSS7MSUを要約するかに関して詳細を含んでいます。 TALIサービスメッセージをTALIの上の層で由来して、IPネットワークの向こう側にTALIサービスメッセージで輸送して、TALI接続の遠端でTALIの上の層に渡します。
3.2.2.1 SCCP Service Message (sccp)
3.2.2.1 SCCP業務報(sccp)
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'opcodeは、TALI接続の上の3(SCCP)のService Indicatorと共にMSUをSS7に渡すのに使用されます。 このopcodeはSAALなしで実行されるTALIプロトコル・スタックの上で使用されるだけです。 SS7 MSUのMTP3層はこのopcodeのためにTCP/IPの向こう側に移されたデータの一部ではありません。 TALI'sccp'メッセージのデータ部はSS7 MSU(MTP3ルーティングラベルの後の)における、SCCPデータ領域の最初のバイトで始まります。 SCCPデータ領域における最初のバイトはSCCPメッセージタイプ分野です。
Several restrictions on the SCCP messages that this TALI opcode can carry exist. These restrictions are as follows:
このTALI opcodeが運ぶことができるという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の実現がメッセージでClass0とClass1SCCPメッセージに制限されるということであるSCCPメッセージはどちらかの分野をタイプします:
* UDT
* UDTS
* XUDT
* XUDTS
* UDT*UDTS*XUDT*XUDTS
Sprague, et al. Informational [Page 24] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[24ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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接続の向こう側に移すために'起呼側'領域にPoint Codeを保管しなければなりません。 望まれているなら、実現は、トランスミッションの前に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接続の向こう側に移すために'被呼者'領域にPoint Codeを保管しなければなりません。 望まれているなら、実現は、トランスミッションの前に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.
* それらが'sccp'を通してTALIの向こう側に伝えられるようにSS7 SCCP MSUのコード化はそれぞれメッセージの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: IPがSCPのものを基礎づけたので、SCCP Subsystem Managementはこの'sccp'opcodeを通して支持されます。 SS7 SCCP Managementメッセージは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情報を提供するかが/であるならメッセージを分配すると考える必要があります。 SCCP CalledパーティAddress領域でポイントコードに例えばDPCを模写できます、そして、SCCP CallingパーティAddress領域でポイントコードにOPCを模写できます。
+------------------------------------------------------------------+ | 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) | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'sccp'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| SCCPデータ| 後の最初のバイトで始まるSCCPデータ| | | | Layer3ルート設定Label(データは| | | | どんなインクルードにもSIOかルート設定Labelをしません)| +------------------------------------------------------------------+
Sprague, et al. Informational [Page 25] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[25ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.2.2.1.1 SCCP Encapsulation using TALI
3.2.2.1.1 崖錐を使用するSCCPカプセル化
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が56KbpsかDS1リンクからSGに到着して、IP装置への伝送のためSGの中で発送されるとき、SGは以下の処理をSS7 MSUに実行します:
* discards the MTP Layer 2 information, CRC and flags
* MTP Layer2情報、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
* SCCPのCalledパーティAddress分野へのMTP Layer3からのDPCが層にする場所。 存在しないで、次に、いっぱいになったなら、CallingパーティAddress分野は作成されます。
* 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
* CallingパーティPoint Codeが全くなければSCCPのCallingパーティAddress分野へのMTP Layer3からのOPCが層にする場所
* 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
* SYNC分野は設定されます。
* The OPCODE is set to 'sccp'
* OPCODEは'sccp'に用意ができています。
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICE分野の八重奏の数に用意ができています。
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 Layer3からのルーティング情報が送信されるメッセージのSCCP部分に置かれるので、どんなルーティング情報も、SGによって救われる必要がありません。
Sprague, et al. Informational [Page 26] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[26ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
SS7 MSU
SS7MSU
| 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|
+---------------------------+------+------+------+
| 層3| 層2| | | | +----+---+-----+-----+-------+---+--+---+---+---+---+----+ |旗|FCS|TCAP|SCCP|ルート設定|SIO|李|空言|FSN|よだれ掛け|BSN|旗| | | |層|層| ラベル| | | | | | | | +----+---+-----+-----+-------+---+--+---+---+---+---+----+ | | | | | | 崖錐+-----------+---+------+----+ パケット| サービス|レン|Opcode|同時性| +-----------+---+------+----+ | | | | | | +---------------------------+------+------+------+ IP| 崖錐パケット|TCP| IP| Mac| パケット| |ヘッダー|ヘッダー|ヘッダー| +---------------------------+------+------+------+
Figure 6: Encapsulation of SCCP MSUs using the TALI 'sccp' opcode
図6: TALI'sccp'opcodeを使用する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:
'sccp'TALIパケットにSGによってIP装置から受け取られるとき、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
* Fieldがナショナル・ネットワークに設定するSub-サービス、(0)がない、SCCPに用意ができているService Indicatorの優先権でSIOを作り直します。
* extracts the SCCP/TCAP data from the SERVICE area and places it in
the new SS7 message
* SERVICE領域からSCCP/TCAPデータを抜粋して、新しいSS7メッセージにそれを置きます。
* sets the DPC to the SCCP Called Party Point Code
* SCCP CalledパーティPoint CodeにDPCを設定します。
* sets the OPC to the SCCP Calling Party Point Code
* SCCP CallingパーティPoint CodeにOPCを設定します。
* 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に変えて戻されると、正常なSS7ルーティング手順に応じて、MSUはSGの中で発送されます。
Sprague, et al. Informational [Page 27] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[27ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.2.2.2 ISUP Service Message (isot)
3.2.2.2 ISUP業務報(isot)
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'opcodeは、TALI接続の上の5(ISUP)のService Indicatorと共にMSUをSS7に渡すのに使用されます。 このopcodeはSAALなしで実行されるTALIプロトコル・スタックの上で使用されるだけです。 データのSS7 MSU IS部分のMTP3層はこのopcodeのためにTCP/IPの向こう側に移されました。 MTP3ヘッダーのSIOバイトがSS7 MSUにある状態で、TALI'isot'メッセージのデータ部は始まります。
+------------------------------------------------------------------+ | 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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'isot'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| ISUPデータ| Layer3SIOで始まる生のISUPデータ| | | | さばきます。 | +------------------------------------------------------------------+
3.2.2.2.1 ISUP Encapsulation using TALI
3.2.2.2.1 崖錐を使用するISUPカプセル化
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が56KbpsかDS1リンクからSGに到着して、SGの中でIP装置に発送されるとき、SGは以下の処理をSS7 MSUに実行します:
* discards the MTP Layer 2 information, CRC and flags
* MTP Layer2情報、CRC、および旗を捨てます。
* places MTP Layer 3 into the SERVICE payload area of the TALI
packet
* TALIパケットのSERVICEペイロード領域にMTP Layer3を置きます。
* The SYNC field is set
* SYNC分野は設定されます。
* The OPCODE is set to 'isot'
* OPCODEは'isot'に用意ができています。
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICE分野の八重奏の数に用意ができています。
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 Packetに置かれるので、どんなルーティング情報も、SGによって救われる必要がありません。
Sprague, et al. Informational [Page 28] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[28ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
SS7 MSU
SS7MSU
| 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|
+----------------------------+------+------+------+
| 層3| 層2| | | | +----+---+----+----+---+-------+---+--+---+---+---+---+----+ |旗|FCS|ISUP|エムエスジー| CIC|ルート設定|SIO|李|空言|FSN|よだれ掛け|BSN|旗| | | |部分|タイプ| |ラベル| | | | | | | | +----+---+----+----+---+-------+---+--+---+---+---+---+----+ | / | / | | 崖錐+-----------------------+---+------+----+ パケット| サービス|レン|Opcode|同時性| +-----------------------+---+------+----+ | / | --------- | / +----------------------------+------+------+------+ IP| 崖錐パケット|TCP| IP| Mac| パケット| |ヘッダー|ヘッダー|ヘッダー| +----------------------------+------+------+------+
Figure 7: Encapsulation of ISUP MSUs using the TALI 'isot' opcode
図7: TALI'isot'opcodeを使用する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
* SERVICE領域からMTP Layer3データを抜粋して、新しい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に変えて戻されると、正常なSS7ルーティング手順に応じて、MSUはSGの中で発送されます。
3.2.2.3 MTP3 Service Message (mtp3)
3.2.2.3 MTP3業務報(mtp3)
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'opcodeは0-2、4のService IndicatorがあるMSUをSS7に渡すのに使用されます、TALI接続の上の(非SCCPと、非ISUP)の6-15。 このopcodeはSAALなしで実行されるTALIプロトコル・スタックの上で使用されるだけです。 データのSS7 MSU IS部分のMTP3層はこのopcodeのためにTCP/IPの向こう側に移されました。 MTP3ヘッダーのSIOバイトがSS7 MSUにある状態で、TALI'mtp3'メッセージのデータ部は始まります。
Sprague, et al. Informational [Page 29] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[29ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'mtp3'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| 層3のMSU| Layer3SIOで始まる生のMSUデータ| | | データ| さばきます。 | +------------------------------------------------------------------+
3.2.2.3.1 MTP3 Encapsulation using TALI
3.2.2.3.1 崖錐を使用するMTP3カプセル化
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があるSS7 MSUが0-2と等しいときに、4、6-15は、56KbpsかDS1リンクからSGに到着して、SGの中でIP装置に発送されて、SGは以下の処理をSS7 MSUに実行します:
* discards the MTP Layer 2 information, CRC and flags
* MTP Layer2情報、CRC、および旗を捨てます。
* places MTP Layer 3 into the SERVICE payload area of TALI packet
* TALIパケットのSERVICEペイロード領域にMTP Layer3を置きます。
* The SYNC field is set
* SYNC分野は設定されます。
* The OPCODE is set to 'mtp3'
* OPCODEは'mtp3'に用意ができています。
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICE分野の八重奏の数に用意ができています。
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ヘッダー情報を加えるでしょう。
Sprague, et al. Informational [Page 30] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[30ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
SS7 MSU
SS7MSU
| 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|
+----------------------------+------+------+------+
| 層3| 層2| | | | +----+---+-----------+-------+---+--+---+---+---+---+----+ |旗|FCS|他の層|ルート設定|SIO|李|空言|FSN|よだれ掛け|BSN|旗| | | |3つのデータ|ラベル| | | | | | | | +----+---+-----------+-------+---+--+---+---+---+---+----+ | / | ------ | /崖錐+----------------+---+------+----+ パケット| サービス|レン|Opcode|同時性| +----------------+---+------+----+ | / | -- | / +----------------------------+------+------+------+ IP| 崖錐パケット|TCP| IP| Mac| パケット| |ヘッダー|ヘッダー|ヘッダー| +----------------------------+------+------+------+
Figure 8: Encapsulation of SS7 MSUs with SI!=3,5,13 using 'mtp3'
エイト環: 5、13が'mtp3を使用することでのSI!があるSS7MSUのカプセル化=3
When an 'mtp3' TALI packet is received by an SG from an IP device, the SG performs the following processing on the 'mtp3' packet:
'mtp3'TALIパケットがSGによってIP装置から受け取られるとき、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
* SERVICE領域からMTP Layer3データを抜粋して、新しい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に変えて戻されると、正常なSS7ルーティング手順に応じて、MSUはSGの中で発送されます。
3.2.2.4 SAAL Service Message (saal)
3.2.2.4 SAAL業務報(saal)
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'opcodeは、TALI接続の上のどんなService Indicatorと共にもMSUをSS7に渡すのに使用されます。 このopcodeはSAALと共に実行されるTALIプロトコル・スタックの上で使用されるだけです。 また、'saal'opcodeは、SAALピアツーピアパケット(SSCFピアツーピアパケットとSS7サービスデータ以外のSSCOPピアツーピアパケット)をTALI接続の上に伝えるのに使用されます。
Sprague, et al. Informational [Page 31] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[31ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
SS7MSUを移すのに使用されると、このopcodeのためにTCP/IPの向こう側に移されたデータのSS7 MSU IS部分のMTP3層です。 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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'saal'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| 層3| Layer3SIOで始まる生のMSUデータ| | | データ| さばきます。 | +------------------------------------------------------------------+ | (X+1) | SSCOP| 詰め物の3(3)八重奏に(0)のゼロを合わせてください。| | ..Y| トレーラ| トレーラデータのためのプラス4八重奏。 The| | | | そしてLayer3Dataの全長。| | | | SSCOPトレーラは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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'saal'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..X| SAAL同輩| 生のSSCF/SSCOPピアツーピアパケットはそうです。| | | じっと見るために| また、TALI接続の上に移します。| | | メッセージ| この'saal'opcodeを使用します。 | +------------------------------------------------------------------+
3.2.2.4.1 MTP3 and SAAL Peer to Peer Encapsulation using TALI
3.2.2.4.1 MTP3と崖錐を使用するSAALピアツーピアカプセル化
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があるも)が56KbpsかDS1リンクからSGに到着して、IP装置への伝送のためSGの中で発送されるとき、SGは以下の処理をSS7 MSUに実行します:
Sprague, et al. Informational [Page 32] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[32ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* discards the MTP Layer 2 information, CRC and flags
* MTP Layer2情報、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(それがSSCOP PDUのピアツーピアSAALメッセージかSS7 MSUであることにかかわらず)はTALIパケットのSERVICEペイロード領域にコピーされます。
* The SYNC field is set
* SYNC分野は設定されます。
* The OPCODE is set to 'saal'
* OPCODEは'saal'に用意ができています。
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICE分野の八重奏の数に用意ができています。
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 Packetに置かれるので、どんなルーティング情報も、SGによって救われる必要がありません。
Sprague, et al. Informational [Page 33] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[33ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
SS7 MSU
SS7MSU
| 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|
+----------------------------+------+------+------+
| 層3| 層2| | | | +----+---+-----------+-------+---+--+---+---+---+---+----+ |旗|FCS|他の層|ルート設定|SIO|李|空言|FSN|よだれ掛け|BSN|旗| | | |3つのデータ|ラベル| | | | | | | | +----+---+-----------+-------+---+--+---+---+---+---+----+ | | | | | | +-------+-----------------------+ |SSCOP| サービス| |トレーラ| | +-------+-----------------------+ | | +-------+-----------------------+---+------+----+ |SSCOPトレーラとのサービス|レン|Opcode|同時性| +-------+-----------------------+---+------+----+ | / | ----------------- | / +----------------------------+------+------+------+ | 崖錐パケット|TCP| IP| Mac| | |ヘッダー|ヘッダー|ヘッダー| +----------------------------+------+------+------+
Figure 9: Encapsulation of SAAL PDUs using the TALI 'saal' opcode
図9: TALI'saal'opcodeを使用するSAAL PDUsのカプセル化
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
* SERVICE領域から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の中で発送されます。
Sprague, et al. Informational [Page 34] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[34ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.3 TALI Timers
3.3 崖錐タイマ
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はTALI州のマシンの一部として使用される4個のTALIタイマを定義しました。 これらのタイマは'T4'を通して一般的に'T1'と命名されます。 それぞれのタイマの簡単な説明を以下の小区分に提供します。 それぞれの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タイマ値は遠端での設定の如何にかかわらず接続の各端のセットであるかもしれません。 各タイマに関しては、デフォルト値と範囲は以下のセクションでお勧めです。
3.3.1 T1 Timer
3.3.1 T1タイマ
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実現は'テスト'を送るべきです。
3.3.2 T2 Timer
3.3.2 T2タイマ
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タイマはPeerが'テスト'に対応して'異'か'proh'を返さなければならない時間を表します。 T2が期限が切れる前に遠端が'異'か'proh'で返答しないなら、'テスト'の送付者はT2満了をプロトコル違反として扱います。 T2がこれらのタイマが設計されているように動作するためには<T1でなければならないことに注意してください。
3.3.3 T3 Timer
3.3.3 T3タイマ
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タイマは、近い終わりが、どれくらい長い間Management Prohibit Traffic Eventが起こった(近い終わりに)後に遠端から受け取られるService Dataを処理し続けるべきであるかを制御します。 NEA-FEA(サービスデータを送ることができた両端)からNEP-FEA(サービスデータを送っても構わないと思っている遠端だけ)までの変遷が起こるとき、このタイマは使用されています。 その変遷のときに、遠端がTALI州のマシンを調整して、このソケットから遠くにサービスデータ通信量を紛らすいくらかの時間を必要とすると予想するのは妥当です。 T3タイマは遠端が交通を紛らさなければならない時間に制御されます。
3.3.4 T4 Timer
3.3.4 T4タイマ
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タイマはそれぞれのTALI実現のときに'moni'メッセージの創作の時間間隔を表します。 各回のT4は期限が切れて、TALI実現は'moni'を送るべきです。
Sprague, et al. Informational [Page 35] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[35ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.3.5 Recommended Defaults and Ranges for the TALI Timers
3.3.5 崖錐タイマのためのお勧めのデフォルトと範囲
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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ |名前| 分| マックス|デフォルト| 記述| +------------------------------------------------------------------+ | T1| 100ms| 60秒| 4秒| テストPDUタイマを送ってください。| +------------------------------------------------------------------+ | T2| 100ms| 60秒| 3秒| 異かprohのための応答タイマ| | | | | | メッセージをテストする応答。 | +------------------------------------------------------------------+ | T3| 100ms| 60秒| 5秒| 処理するためにどれくらい長いタイマ制御装置| | | | | | NEの後のrcvd servデータ| | | | | | NEAからNEPまでの変遷。 システム| | | | | | 快速帆船応答は待っています。| | | | | | NEであるときに、最初のprohは発信します。| | | | | | NEAからNEPまでの変遷。 | +------------------------------------------------------------------+ | T4| 100ms| 60秒|10秒| moni PDUタイマを送ってください。| +------------------------------------------------------------------+
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(1)ミリセカンドと同じくらい大きくなければなりません。 これは、T1の満期の状態の留置所からシステムを防ぐためのものです。 T1がT2同輩か以下であるなら、それは、期限が切れて、T2を再開して、テストメッセージへの応答を実施しないでしょう。
Enforcement of minimum and maximum timer values is implementation dependent.
最小の、そして、最大のタイマ値の実施は実現に依存しています。
3.4 TALI User Events
3.4 崖錐ユーザ出来事
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州のマシンの働きの数個のユーザイベントコントロールを提供しなければなりません。 これらの能力を提供するユーザーインタフェースは実現特有です。
3.4.1 Management Open Socket Event
3.4.1 管理の開いているソケットイベント
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.
'管理の開いているソケット'出来事で、ユーザは、'管理の近いソケット'出来事と共にそれぞれの定義されたTALI接続がいつTCPソケット接続を形成するかを制御できます。 特定のTALI接続のための'開いているソケット'が起こると、TALI接続はTCPソケット接続を同輩に形成しようとし始めるべきです。
Sprague, et al. Informational [Page 36] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[36ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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()
ソケット()ひも()が()を聴く、受諾()
3.4.2 Management Close Socket Event
3.4.2 管理の近いソケットイベント
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.
それが望まれているとき、ユーザが'管理の近いソケット'出来事を発行できる、それ、TCPソケット、TALIソケットに関しては、至急、終えられるか、または同輩に接する試みを中止してください。 '近いソケット'に影響した後に、'管理の開いているソケット'が発行されるまで、TALI接続は確立されないでしょう。
3.4.3 Management Allow Traffic Event
3.4.3 経営者側は交通イベントを許容します。
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(終わり頃に許容されている)に移行するべきです。
3.4.4 Management Prohibit Traffic Event
3.4.4 経営者側は交通イベントを禁止します。
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(終わり頃に禁止される)に移行するべきです。
Sprague, et al. Informational [Page 37] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[37ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.5 Other Implementation Dependent TALI Events
3.5 他の実現の依存する崖錐出来事
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で.3に.1について議論するとき、TALIのどんな違反も議定書を作ります。
3.6 TALI States
3.6 崖錐州
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状態を維持します。
Sprague, et al. Informational [Page 38] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[38ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 名前| 記述| +------------------------------------------------------------------+ | OOS| TALI接続は使われなくなっています。 これほど通常| | | ソケットを'閉じる'ためにユーザ出来事に対応しています。| | | または、'SS7リンクを非活性化してください'へのユーザ出来事。 | +------------------------------------------------------------------+ | 接続| TALI層は、TCPを設立するのを試みています。| | | 同輩とのソケット接続。 サーバはそうです。| | | クライアントは、'受諾'と'接続しています'。 | +------------------------------------------------------------------+ | NEP-FEP| TCPソケット接続は確立されます。 どちらも| | | 接続の側面はソケットを使用する準備ができています。| | | サービスPDUsのために。 | +------------------------------------------------------------------+ | NEP-FEA| TCPソケット接続は確立されます。 NEはそうです。| | | サービスPDUsにソケットを使用する準備ができていません。 The| | | FEはサービスPDUsにソケットを使用する準備ができています。 | +------------------------------------------------------------------+ | シビルの部屋-FEP| TCPソケット接続は確立されます。 NEはそうです。| | | サービスPDUsにソケットを使用する準備ができています。 FEはそうです。| | | サービスPDUsにソケットを使用する準備ができていません。 | +------------------------------------------------------------------+ | シビルの部屋-FEA| TCPソケット接続は確立されます。 両方| | | 側はサービスPDUsにソケットを使用する準備ができています。 | | | これは標準双方向であるところの唯一の状態です。| | | SS7データ転送は起こります。 | +------------------------------------------------------------------+
Table 6: TALI States
テーブル6: 崖錐州
3.7 TALI Version 1.0 State Machine
3.7 崖錐バージョン1.0州のマシン
This section provides the state machine that must be followed by each TALI implementation in order to be compliant with this specification.
このセクションはそれぞれのTALI実現がこの仕様で言いなりになるためにあとに続かなければならない州のマシンを提供します。
3.7.1 State Machine Concepts
3.7.1 州のマシン概念
Before presenting the actual state machine, several concepts are discussed.
実際の州のマシンを贈る前に、いくつかの概念について議論します。
3.7.1.1 General Protocol Rules
3.7.1.1 一般プロトコル規則
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. それぞれの側は両方のために終わりとほぼ遠端で状態を禁止に初期化します。
Sprague, et al. Informational [Page 39] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[39ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3. State changes between the NEx-FEx states are signaled with either
an 'allo' or 'proh'.
3. NEx-FEx州の間の州の変化は'異'か'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. それぞれの側は遠い終わりにaで、あらゆる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. 'テスト'に関する回答は、'異'か'proh'のどちらかです。
8. A far end signals the last service PDU has been transmitted with
either a 'proh' or a 'proa'.
8. 最後のサービスPDUが'proh'か'快速帆船'のどちらかで伝えられたという遠端信号。
9. Upon receiving a 'proh', the receiver must always reply with
'proa'.
9. 'proh'を受けると、受信機はいつも'快速帆船'で返答しなければなりません。
10. The NE cannot gracefully close a socket unless a 'proh' is sent
and 'proa' is received.
10. 'proh'を送って、'快速帆船'が受け取られていない場合、NEは優雅にソケットを閉じることができません。
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'を送った後に、近い終わりは、'快速帆船'が受け取られているか、またはT3タイマが期限が切れるまで受信されたサービスデータを処理し続けなければなりません。
3.7.1.2 Graceful Shutdown of a Socket
3.7.1.2 ソケットの優雅な閉鎖
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:
ステートテーブルは'困難な'閉鎖としてソケットを閉じるという管理要求を扱います。 すなわち、それはすぐ現状にかかわらずソケットを閉じるでしょう。 したがって、ソケット(FEAが述べるNEA_FEPかNEA_からの)の優雅な閉鎖がそうであることを保証する正しいステップ:
1. Management issues a Management Prohibit Traffic Event on the
socket.
1. 経営者側はソケットの上にManagement Prohibit Traffic Eventを発行します。
2. Management will wait for T3 to expire.
2. 経営者側は、T3が期限が切れるのを待つでしょう。
3. Management can then issue a Close Socket Event on the socket.
3. そして、経営者側はソケットの上にClose Socket Eventを発行できます。
3.7.1.3 TALI Protocol Violations
3.7.1.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
* 受信されたメッセージの無効の同時性コード
Sprague, et al. Informational [Page 40] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[40ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* Invalid opcode in a received message
* 受信されたメッセージの無効のopcode
* 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タイマが期限が切れる前に'テスト'の創作に対応して'異'か'proh'を受けません。
* Receiving Service Messages on a prohibited socket.
* 禁止されたソケットの上にService Messagesを受けます。
* TCP Socket errors - Connection Lost
* TCP Socket誤り--接続Lost
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'出来事のすべてがテーブルの'プロトコルViolation'列に従って処理されます。
3.7.2 The State Machine
3.7.2 州のマシン
Internal Data required for State Machine:
内部のDataが州Machineに必要です:
boolean sock_allowed. This flag indicates whether the NE is allowed to carry Service Messages.
_が許容した論理演算子ソックス。 この旗は、NEがService Messagesを運ぶことができるかどうかを示します。
Initial Conditions: sock_allowed = FALSE state = OOS no timers running
状態に頭文字をつけてください: ソックス_は=FALSE状態=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 | |
+------------------------------------------------------------------+ | 状態| OOS|接続| NEP-FEP| NEP-FEA| シビルの部屋-FEP| シビルの部屋-FEA| |出来事| | | | | | | +------------------------------------------------------------------+ |T1 Exp。 | | |テストを送ってください。|テストを送ってください。|テストを送ってください。|テストを送ってください。| | | | |T1を始動してください。|T1を始動してください。|T1を始動してください。|T1を始動してください。| | | | |T2を始動してください。|T2を始動してください。|T2を始動してください。|T2を始動してください。| +------------------------------------------------------------------+ |T2 Exp。 | | | PV| PV| PV| PV| +------------------------------------------------------------------+ |T3 Exp。 | | | PV| PV| | | +------------------------------------------------------------------+ |T4 Exp。 | | |moniを送ってください。|moniを送ってください。|moniを送ってください。|moniを送ってください。| | | | |T4を始動してください。|T4を始動してください。|T4を始動してください。|T4を始動してください。| +------------------------------------------------------------------+ |Rcvテスト| | |prohを送ってください。|prohを送ってください。|異を送ってください。|異を送ってください。| +------------------------------------------------------------------+ |Rcv異| | | T2を止めてください。| T2を止めてください。| T2を止めてください。| T2を止めてください。| | | | | NEP-FEA| | シビルの部屋-FEA| |
Sprague, et al. Informational [Page 41] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[41ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ |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| | | T2を止めてください。| T2を止めてください。| T2を止めてください。| T2を止めてください。| | | | |快速帆船を送ってください。|快速帆船を送ってください。|快速帆船を送ってください。|または豊富である。| | | | | | NEP-FEP| | コースを変更してください。| | | | | | | |快速帆船を送ってください。| | | | | | | | シビルの部屋-FEP| +------------------------------------------------------------------+ |Rcv快速帆船| | | T3を止めてください。| T3を止めてください。| | | +------------------------------------------------------------------+ |Rcv moni| | |転向者|転向者|転向者|転向者| | | | | monaに| monaに| monaに| monaに| | | | |monaを送ってください。|monaを送ってください。|monaを送ってください。|monaを送ってください。| +------------------------------------------------------------------+ |Rcv mona| | |Implemen|Implemen|Implemen|Implemen| | | | |tation|tation|tation|tation| | | | |扶養家族|扶養家族|扶養家族|扶養家族| +------------------------------------------------------------------+ |Rcv| | | PV|T3が走るなら| PV|過程| | サービス| | | | 過程| | | | | | | |ほかのPV| | | +------------------------------------------------------------------+ |接続してください、|| T1を始動してください。| | | | | |Estab。 | | T2を始動してください。| | | | | | | | T4を始動してください。| | | | | | | |(非0であるなら)| | | | | | | |_を強打してくださいなら| | | | | | | | 許容されています。| | | | | | | | = 本当| | | | | | | | 異を送ってください。| | | | | | | | テストを送ってください。| | | | | | | | シビルの部屋-FEP| | | | | | | |ほか| | | | | | | | prohを送ってください。| | | | | | | | テストを送ってください。| | | | | | | | NEP-FEP| | | | | +------------------------------------------------------------------+ |接続してください、|| | PV| PV| PV| PV| |失われています。| | | | | | | +------------------------------------------------------------------+ |プロトコル| | |すべてを止めてください。|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。| |Violat。 | | | タイマ| タイマ| タイマ| タイマ| | | | |近く|近く|近く|近く| | | | | ソケット| ソケット| ソケット| ソケット| | | | |接続してください。|接続してください。|接続してください。|接続してください。| | | | | ing| ing| ing| ing|
Sprague, et al. Informational [Page 42] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[42ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ |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. | | | | | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ |管理。 |開いてください。| | | | | | |開いてください。|ソケット| | | | | | |ソケット|Conne| | | | | | | | cting| | | | | | +------------------------------------------------------------------+ |管理。 | |近く|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。| |閉鎖| | ソケット| タイマ| タイマ| タイマ| タイマ| |ソケット| |OOS|近く|近く|近く|近く| | | | | ソケット| ソケット| ソケット| ソケット| | | | |OOS|OOS|OOS|OOS| +------------------------------------------------------------------+ |管理。 |ソックス_|ソックス_異、-|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール| |禁止します。|許容します。| = 虚偽で結婚されます。| =を負っています。| =を負っています。| =を負っています。| =を負っています。| |ソケット|教育=| | 誤る| 誤る| 誤る| 誤る| | |誤る| | | |prohを送ってください。|prohを送ってください。| | | | | | |t3を始動してください。|t3を始動してください。| | | | | | | NEP-FEP| NEP-FEA| | | | | | | | | +------------------------------------------------------------------+ |管理。 |ソックス_|ソックス_異、-|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール| |許容します。|許容します。| = 本当に結婚されます。| =を負っています。| =を負っています。| =を負っています。| =を負っています。| |交通|教育=| | 本当| 誤る| 本当| 本当| | |本当| |異を送ってください。|異を送ってください。| | | | | | | シビルの部屋-FEP| シビルの部屋-FEA| | | +------------------------------------------------------------------+ |ユーザ|廃棄物| 廃棄物| 廃棄物| 廃棄物| 廃棄物| 発信してください。| |部分|データ| データ| データ| データ| データ| データ| |Msgs。 | | | | | | | +------------------------------------------------------------------+
Table 7: TALI 1.0 State Machine
テーブル7: 崖錐1.0州のマシン
3.8 TALI 1.0 Implementation Notes
3.8 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.
予想されたTALI1.0実現のいくつかの局面は州のマシンか前のテキストに明確に記述されていません(それらは、提示されましたが、ここで繰り返されるでしょう)。 いくつかの場合、これらの実現注意はTALI層の上のソフトウェア層の予想された動きと関係があります。
3.8.1 Failure on a TCP/IP Socket
3.8.1 TCP/IPソケットの上の失敗
* The failure to read or write from a TCP socket shall be detected
and generate a connection lost event.
* TCPソケットから読むか、または書かないと、検出されて、接続無くなっている出来事を発生させるでしょう。
Sprague, et al. Informational [Page 43] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[43ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
3.8.2 Congestion on a TCP/IP Socket
3.8.2 TCP/IPソケットにおける混雑
* 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.
* 前の要件のための混雑の1つの可能な定義がTCPソケットが妨げられる時であるかもしれません。
3.9 TALI 1.0 Limitations
3.9 崖錐1.0の制限
Several limitations with the TALI 1.0 specification and implementation are identified:
TALI1.0仕様と実装があるいくつかの制限が特定されます:
* For SCCP traffic, only UDT and XUDT Class 0 and Class 1 traffic
should be managed by this protocol.
* SCCPトラフィックにおいて、UDT、XUDT Class0、およびClass1トラフィックだけがこのプロトコルによって管理されるべきです。
* 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ルート設定Labelがワイヤの向こう側に送られたデータの一部でないときに、SIOが作り直されるとき、優先権ゼロ(0)トラフィックはすべてのトラフィックに使用されます。
4. TALI Version 2.0
4. 崖錐バージョン2.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仕様にいくつかの追加を提供します。 3新しいTALI opcodesを導入することによって、2.0の追加を提供します。 基本機能とTALI1.0実装の詳細の大部分は2.0の追加によって変えられません。
Sprague, et al. Informational [Page 44] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[44ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| 記述| サイズ| 値| タイプ| +------------------------------------------------------------------+ | 0..3 | 同時性| 4つの八重奏| | 4バイトのASCII| +------------------------------------------------------------------+ | | 崖錐| | '崖錐'| | +------------------------------------------------------------------+ | 4..7 | OPCODE| 4つの八重奏| | 4バイトのASCII| +------------------------------------------------------------------+ | | テストサービス| | 'テスト'| | | | サービスを許してください。| | '異'| | | | サービスを禁止してください。| | 'proh'| | | | サービスAckを禁止してください。| | '快速帆船'| | | | モニターソケット| | 'moni'| | | | モニターソケットAck| | 'mona'| | | | SCCPサービス| | 'sccp'| | | | ISUPサービスo/崖錐| | 'isot'| | | | MTP3サービスo/崖錐| | 'mtp3'| | | | サービスo/SAAL| | 'saal'| | | | 管理メッセージ| | '管理'| | | | 拡張サービスエムエスジー| | 'xsrv'| | | | 特別教書| | 'spcl'| | +------------------------------------------------------------------+ | 8..9 | 長さ| 2つの八重奏| | 整数| | | (最も重要でない、| | | | | | バイト、1番目) 非0| | | | | | またはサービスである。| | | | | | ソケットモニターmsg| | | | +------------------------------------------------------------------+ | 10..X| データペイロード| 変数| | 変数| +------------------------------------------------------------------+
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
* 1.0実装に対してTALI実装は2.0であるとどう名乗ることができるかの詳細な情報
* Detailed information regarding how to provide backward
compatibility for a connection to a far end that is only TALI 1.0
capable
* どうできるTALI1.0であるにすぎない遠端との接続に後方の互換性を提供するかの詳細な情報
* Detailed information regarding the new 2.0 opcodes
* 新しい2.0opcodesの詳細な情報
Sprague, et al. Informational [Page 45] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[45ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.
したがって、本章の読者は新しい2.0の特徴をサポートするように既存のTALI1.0実装を変更する観点からこれを読むべきです。
4.1 Overview of TALI Version 2.0 Features
4.1 崖錐バージョン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:
1.0TALI実装への少ない数の変化が、2.0をサポートするのに必要です。 図10は2.0TALI州Machineに影響する入力を例証します。 読者は、1.0のための入力からの唯一の違いが以下の通りであるのに気付くかもしれません:
Three new TALI opcodes can be sent/received between a TALI node and its peer. The new opcodes are:
TALIノードとその同輩の間に3新しいTALI opcodesを送るか、または受け取ることができます。 新しいopcodesは以下の通りです。
* '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.
3つの新しいUser Part能力が、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の新しいopcodesに関する詳しい情報を提供します。 しかしながら、それぞれのこれらのopcodesの目的の簡単な説明は以下の通りです:
* '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:
* '管理'--このopcodeがTALI終点の間を通るためにデバイスの操作を管理するMANAGEMENTデータ、またはデータを許容することを意図します。 この管理データに関する例は:
* 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 Network Managementデータがコード化する、(不-、)、有用性と混雑。
* Enabling/disabling various socket options, such as options
regarding which messages are supported, or how to format data.
* どのメッセージがサポートされるか、そして、またはどのようにデータをフォーマットするかに関するオプションなどの様々なソケットオプションを可能にするか、または無効にします。
Sprague, et al. Informational [Page 46] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[46ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* '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'--拡張サービスOpcodes。 それを思い描きました。1.0サービスデータopcodes('sccp'、'isot'、'mtp3'、または'saal')でカバーされていない他のタイプのトラフィックを運ぶためにTALIが議定書を作るのを広げることができました。 新しい'xsrv'サービスopcodeを定義することによって、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実装に組み込みたがっているかもしれないということです。 このopcodeがだれにとって、TALIセッションが接続されているかに関する詳しい情報を発見する一般的な手段、および遠端でベンダー/実装に基づく特徴を可能にする手段を提供することを意図します。
Sprague, et al. Informational [Page 47] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[47ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+====+ +---------+ +============+
| | | 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 |
| |
+============+
+====+ +---------+ +============+ | | | サービス| +-------------+ | | |ユーザ| | メッセージ| | 管理。 開いてください。| | 管理| |部分| <-->、| 管理| | 管理。 閉鎖| <-->、|、|、|、|、| XSRV| | 管理。 Proh。 | | | | | | SPCL| | 管理。 許容します。| +============+ +====+ +---------+ +-------------+ ^ ^ | | v対+========================================================+ | 崖錐州のマシン| +========================================================+ ^ ^ ^ ^ | | | | v| | | +---------+ | | | | 受信します。| +-----------------+ +-----------+ +------------+ | 'テストしてください'| | 接続est。 | | プロトコル| | T1は期限が切れました。| | '異'| | 接続は損をしました。| | 違反| | T2は期限が切れました。| | 'proh'| | | | | | T3は期限が切れました。| | '快速帆船'| +-----------------+ +-----------+ | T4は期限が切れました。| | 'moni'| ^ ^ +------------+ | 'mona'| | | ^ | '管理'| | | | | 'xsrv'| | | | | 'spcl'| | | | | または| +========================================+ | サービス| | 実装| | メッセージ| | 扶養家族| +---------+ +========================================+ ^ | +に対して============+ | 同輩| | | +============+
Figure 10: Overview of Inputs to the TALI 2.0 State Machine
図10: 崖錐2.0州のマシンへの入力の概要
4.2 TALI Version Identification
4.2 崖錐バージョン識別
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.
TALI1.0仕様はTALIバージョン識別を実行する簡潔な方法を提供しませんでした。 しかしながら、2.0におけるこの問題を解決するのに1.0からの汎用の'moni'メッセージを使用できます。
Sprague, et al. Informational [Page 48] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[48ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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'メッセージのプライマリ目的は汎用のECHO能力を提供することでした。 それは思い描かれました。ECHO能力が提供できた重要な仕事はRound Trip TALI/TALI処理時間を測定するだろうことです。
* 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'を送るなら、それは、外向的な'moni'の頻度を制御するのにT4タイマを使用するでしょうに。
* 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:
TALI2.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.
* 汎用のECHO能力にそれを提供し続けているのをRound Trip時間を測定するか、または他の実装の特定のタスクを実行するのに使用できます。
* The data portion of the 'moni' message is now divided into 2
portions
* 'moni'メッセージのデータ部は現在、2つの部分に分割されます。
* 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.
* 'moni'のためのデータ部の全長はまだ200バイトを超えているべきではありません。 これが、最大'moni'opcodeの200バイトの長さがないかどうかチェックするかもしれない1.0の実装との後方の互換性を維持するのに必要です。
Sprague, et al. Informational [Page 49] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[49ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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ノードであると認識したいなら、それはTable8に従ってコード化された'moni'を送らなければなりません。 それが送るあらゆる'moni'がTable8でのコード化に従うべきです。 バージョンラベルは'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'メッセージも調べて、それらがTable8での新しいより厳しい'moni'コード化に従うかどうかわからなければなりません。 'moni'を受けると、TALI2.0ノードは、それが接続されるTALIノードの機能性を決定するためにVER LABEL分野で12バイトのデータを予定されたストリングのリストにたとえるでしょう。 データが予定されたストリングのいずれにも合っていないなら、Far EndはTALI1.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実装は、到着'moni'が、遠端が、TALIがバージョン2.0であるとサポートすると発表するまで接続の遠端が1.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').
* TALI1.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を実装したデバイスに接続しました)。
Sprague, et al. Informational [Page 50] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[50ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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. | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'|4バイトのASCII| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'moni'|4バイトのASCII| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ(バージョン| 整数| | | | ラベルとデータ・フィールドを含んでいます)| | +------------------------------------------------------------------+ | 10..21 | Verラベル| 'vers xxx.yyy'| 12バイト| | | 注意を見てください。| | ASCII| +------------------------------------------------------------------+ | 22..X| データ| ベンダーに依存しています。| 変数| | | | 最大の長さのこれ| | | | | メッセージ(八重奏8| | | | | -9でコード化されて、バイト10-Xに保存されるように)| | | | | 200バイトを超えるべきではありません。 | | +------------------------------------------------------------------+
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仕様のリリース番号をメージャーとMinorに供給します。 001.000 = 崖錐バージョン1.0 002.000は崖錐バージョン2.0// この仕様と等しいです。 002.001は崖錐バージョン2.1// 2.0 003.000=崖錐バージョン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.
'vers002.000'分野はフィールド・タイプ'ASCIIテキスト'の12バイトの分野です。 そういうものとして、'v'はワイヤから伝えられる野原の最初のバイトであるべきです。
4.3 Backwards Compatibility
4.3 遅れている互換性
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までの互換性が必要です。 後方に、ノードがTALI2.0にバージョン1.0をサポートするだけである遠端に接続されるかもしれないので、互換性は重要です。 これらの2つの実装が、共同利用し続けて、2.0ノードがこの状況で1.0opcodesだけをサポートすることへ後ろへ下がるのは、重要です。
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
前項は、TALI2.0実装がどのようにそれがそれ自体が2.0ノードであると認識するために送る'moni'を使用できるか、そして、それがどのようにまた、遠端が2.0であるかどうか決定するために受ける'moni'を使用できるかを説明しました。
Sprague, et al. Informational [Page 51] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[51ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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仕様に記録されるように、TALI1.0'管理'でTALIメッセージを受け取る実装、'xsrv'、および'spcl'opcodesはプロトコルViolationとしてメッセージを扱うでしょう(無効のopcodeは受信されました)。 プロトコルViolationはすぐに、ソケットを下げさせるでしょう。
* 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実装が'管理'、'xsrv'、および'spcl'opcodesを送るだけであるのが必要です、遠端が2.0(後で)実装であることを決定する受信された'moni'メッセージを使用して、それ自体が2.0(後で)実装であると認識した後に。
* 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の実装が2.0として自分たちを特定して、遠端が2.0であるかどうか学ぶために前項で説明されるように'moni'を使用しなければなりません。
* 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.
* それぞれのTALI2.0実装は州のマシンの一部、'遠い_終わり_バージョン'として変数を維持するべきです。 ソケットが設立されるとき、'遠い_終わり_バージョン'は1.0に初期化されるべきです。 2.0実装が'moni'を受けるたびにそれは'遠い_終わり_バージョン'変数をアップデートするべきです。 'moni'がバージョンラベルを含んでいないなら、'遠い_終わり_バージョン'は1.0にリセットされるでしょうに。 'moni'が2.0(または、後のバージョン)のためのバージョンラベルを含んでいるなら、'遠い_終わり_バージョン'はそれに従って、設定されるでしょうに。
* 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.0opcode('管理'、'xsrv'、および'spcl')を受ける各回、それは'遠い_終わり_バージョン'を調べるべきです。 '遠い_終わり_バージョン'が、遠端が1.0実装であることを示すなら、受信されたTALIメッセージはプロトコルViolation(無効のopcode)として扱われるべきです。 '遠い_終わり_バージョン'が2.0(後で)であるなら、2.0実装はそのopcodeのためにそれに従った容認された'管理/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.0opcode('管理/xsrv/spcl')で、より高い層のソフトウェアからTALIメッセージを送るという要求を受け取る各回、それは'遠い_終わり_バージョン'を調べるべきです。 '遠い_終わり_バージョン'が、遠端が1.0実装であることを示すなら、2.0opcodeを送るという要求を否定するべきであるか、または無視するべきです、そして、(実装決定)2.0opcodeを遠端に送ってはいけません。 '遠い_終わり_バージョン'が、遠端が2.0(後で)であることを示すなら、要望に応じることができます、そして、2.0opcodeがあるTALIメッセージを遠端に送ることができます。
Sprague, et al. Informational [Page 52] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[52ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.
* TALI2.0実装が異なったレベルを提供できるそれぞれが、それぞれ3つのために新しい2.0opcodesが('管理/xsrv/spcl')であるとサポートします。 言い換えれば、実装は新しいopcodesの中でSOME OFに基関数をサポートするだけでありたいかもしれません。 それぞれの2.0opcode('管理/xsrv/spcl')のためのサポート水準がもう片方の如何にかかわらずあります。2.0がopcodesする2。
* The basic message structure for TALI messages using the new 2.0
opcodes is presented in Table 9.
* 新しい2.0opcodesを使用するTALIメッセージのための基本的なメッセージ構造はTable9に提示されます。
* 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.0opcodes(管理/xsrv/spcl)に必要である最小量のサポート水準はこれらのopcodesでTALIメッセージを受け取って、新しいopcodeを認識して、州のマシンに影響しないでメッセージを無視することであることができます。 TALI状態は変化するべきではありません。 ソケット接続は寝ずに起きているべきです。 言い換えれば、2.0実装は、どんな受信された'管理/xsrv/spcl'メッセージも無視するのを選ぶことができます、その実装が、その特定のopcodeによって意図された能力をサポートするのを気にかけないなら。
* 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.0opcodeのための部分的なサポート水準を実装することができました。 部分的なサポートは2.0opcodeのためにデータ構造を理解していますが、opcodeのいくつかの異形をサポートするだけから成るかもしれません。 それぞれの新しい2.0opcodesのためのメッセージ構造はTALI opcodeとメッセージ長野原に続く付加的な'原始'の分野から成ります。 各'原始'は、opcodeの異形を差別化するのに使用されます。 それぞれそんなに新しい状態で思い描かれて、新しい'基関数'を加えることによって、2.0opcodeを広げることができます、より多くの能力がopcodeのために定義されるとき、新しいTALI opcodesを加える必要はなくてことです。 2.0実装は、分かって、他のものではなく、opcodeのための'基関数'のいくつかに影響しても構わないと思っているかもしれません。 実装がする2.0opcodeの受信異形は、無視されるべき必要性を理解しないで、また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.0opcodeに、完全なサポート水準を実装することができました。 このサポートは2.0opcodeの中であらゆる'原始'を理解して、完全、サポートするのから成るでしょう。
Sprague, et al. Informational [Page 53] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[53ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'|4バイトのASCII| +------------------------------------------------------------------+ | 4..7 | OPCODE| '管理'、'xsrv'または'spcl'|4バイトのASCII| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ、(残りの長さ| 整数|、|、|、|、このパケット)| | +------------------------------------------------------------------+ | 10..13 | 原始| 'wxyz'、または4バイトのテキスト| 4バイト| | | 注意を見てください。| それは適切です。| ASCII| | | | 与えられたopcode| | +------------------------------------------------------------------+ | 14..X| データ| データ領域の内容| 変数| | | | 扶養家族はopcode/にいますか?| | | | | 原始の組み合わせ| | +------------------------------------------------------------------+
Table 9: Basic Message Structure for New 2.0 TALI Opcodes
テーブル9: 2.0新しい崖錐Opcodesに、基本的なメッセージ構造
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.
以下に注意してください。 Primitive分野は各opcodeのための修飾語として機能します。 opcodeの中では、操作の異なった操作かグループを定義して、サポートすることができます。 Primitiveはそれぞれの異なった操作かセットの操作を特定します。
4.3.1 Generating Protocol Violations based on Received Messages
4.3.1 Received Messagesに基づくプロトコルViolationsを生成すること。
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.
Table9の前でいくつかの弾丸によって含意されるように、それは受信されたTALIメッセージの処理に関連している誤りの照合のいくつかを弛緩する2.0TALI仕様の目標です。
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はそれぞれの受信されたメッセージがないかどうかチェックされた分野を詳しく述べるのにおいて非常に厳しかったです。 それぞれの受信されたメッセージが処理されたとき、メッセージのSYNCコード、opcode、および長さの分野はチェックされました。 これらの分野のどれかが無効であったなら、内部のプロトコル違反は生成されました。 プロトコル違反の処理はソケットが落ちました。 3つの特定のチェック(同時性、opcode、長さ)に加えて、バージョン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はopcodesの部分的なサポート、基関数の部分的なサポート、および多岐の部分的なサポート(ITU Pt Codesではなく、ANSI Pt Codesのサポートなどの)の可能性を導入します。 その結果、弛緩しますどう、受信機がサポートしない受信データを扱うかに関する総合的な哲学が、必要がある。
Sprague, et al. Informational [Page 54] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[54ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.0opcodesのための同時性コードに対するチェック、opcodes、および長さは実行されるべきです(Table3とTable11に対して)。 これらの分野の無効のデータはプロトコル違反の原因として扱われるべきです。
* 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.0opcodes(管理/xsrv/spcl)があるメッセージのためのopcode分野に対するチェックは、実装でメッセージを処理できるかどうか決定するために実行されるべきです。 実装が、特定の2.0opcodeをサポートしないのを選ぶなら、受信されたメッセージは捨てられるべきです、そして、内部のデータ(測定値、メッセージ、ユーザ通知に関するログなどの)はイベントを記録するかもしれません、そして、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.0opcodes(管理/xsrv/spcl)があるメッセージのための原始の分野に対するチェックは、実装でメッセージを処理できるかどうか決定するために実行されるべきです。 実装に、特定の基関数を理解していないか、または特定の基関数のための特徴を実装する選ばれたNOTがあるなら、受信されたメッセージは捨てられるべきです、そして、内部のデータ(測定値、メッセージ、ユーザ通知に関するログなどの)はイベントを記録するかもしれません、そして、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.0opcodes(有効なPt CodeタイプがないかどうかPoint Code分野のコード化をチェックなどなどの)があるメッセージの他のフィールド・タイプに対するチェックは'柔らかい'方法で実行されるべきです。 個々の野原で発見される誤りは捨てられるべき受信されたメッセージを引き起こすべきです、そして、内部のデータ(測定値、メッセージ、ユーザ通知に関するログなどの)はイベントを記録するかもしれません、そして、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メッセージにもかかわらず、接続(ie: 続けるには、SS7データを輸送する)のプライマリ目的を実行するためにソケットを手入れするために
Sprague, et al. Informational [Page 55] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[55ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.
* プロトコルの伸展性を増強するために。 よりゆるく、受信してください。チェックは、それらが定義されるとき新しい基関数の、そして、新しい原始の操作を加えることができるように好まれます。
4.4 Overview of the TALI Message Structure
4.4 崖錐メッセージ構造の概要
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.0opcodesの追加で変わりがありません。 ベースTALIヘッダーはTable2で説明されるようにSYNC+OPCODE+LENGTHからまだ成っています。
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.0opcodesのためのメッセージ構造はTable9で見せられました。 これらのメッセージは付加的な必須項目、Table2のLENGTH野原に続くPRIMITIVEを定義します。
4.4.1 Types of TALI Fields
4.4.1 崖錐分野のタイプ
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は、Table4に提供されたタイプを皆、使用し続けて、また、新しい2.0opcodesを使用するTALIメッセージで使用されるいくつかの新しい分野を定義します。 以下のテーブルはバージョン2.0で導入される新しいフィールド・タイプを導入します。 Table10のタイプは、2.0TALIプロトコルを実装するのにTable4のタイプに加えて使用されます。
Sprague, et al. Informational [Page 56] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[56ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+-----------+------------------------------------------------------+ |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. |
+-----------+------------------------------------------------------+ |フィールド・タイプ| そのTypeのための実装Notes| +------------------------------------------------------------------+ |SS7ポイント| または以前はよくANSIのためのポイントコード情報を伝えていた。| |コード| TALIインタフェースの向こう側のポイントコードのITU異形| | | * ポイントコード構造は4バイトです。 バイト3は使用されています。| | | ポイントコードのTYPEを特定するために。 実際| | | 次に、ポイントコードがバイトでコード化される、0-2 (バイト0| | | 最も重要でないバイトであり、最初のバイトで|、|、|、ワイヤの向こう側に伝えられる、)| | | * バイト3: コード(PC)をポイントのタイプにコード化します。| | | 0はANSIの完全なPCと等しいです。| | | 1は3/8/3のコード化でITUの国際Full PCと等しいです。| | | ゾーン/領域/識別子を計画してください。| | | 2は14ビットの生のPCでITU National Full PCと等しいです。| | | 3=未使用です。| | | 4はANSIクラスタPCと等しいです。| | | * バイト3=0があるANSI Full PCのために。 これらのポイントコードはそうです。| | | 24は以下のポイントコードに噛み付きました: | | | バイト2=ネットワーク| | | バイト1=クラスタ| | | バイト0=メンバー| | | * バイト3=1があるITUの国際Full PC(3/8/3)のために。 | | | これらのポイントコードは14ビット(14では、| | | バイト0と1で表現される最下位ビットを保存する)を使用します。 バイト2はそうです。| | | 未使用。 14ビットは3として解釈されるべきです。| | | ゾーンのビット、領域と3ビットの8ビット| | | シグナリングは識別子を指します。 3ビット| | | シグナリングポイント識別子は3最少です。| | | 重要なビット。 | | | * バイト3=2があるITU National Full PCのために。 これらは指します。| | | コードは14ビット(14最少| | | 重要なビットで、バイト0と1で保存される)を使用します。 バイト2は未使用です。 | | | 14ビットがただ一つの14ビットの量を表す、それ| | | ポイントコードを構成します。 | | | * バイト3=3で、未使用です。 バイト0〜2はそうです。| | | 未定義。 | | | * バイト3=4があるANSI Cluster PCのために。 これらのポイントコード| | | 以下の24ビットのポイントコードです: | | | バイト2=ネットワーク| | | バイト1=クラスタ| | | バイト0 = 0。 この分野は、無視されて、あるべきです。| | | 0として、コード化されます…クラスタのすべてのメンバーが含意されます。| | | * バイト0は横切って伝えられる最初のバイトです。| | | バイト1、バイト2、当時のバイト3があとに続いたワイヤ。 |
Sprague, et al. Informational [Page 57] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[57ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ |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 |
+------------------------------------------------------------------+ |ビット分野| * NがaであるNビットの配列を含む分野| | | 8の倍数。 ビットフィールド・タイプはそうであるべきです。| | | 伝える、ビット0を含むバイト| | | 最初にワイヤの向こう側に7を通して伝えられます。| | | 8〜15にビットを含むバイトはあとに続いています。| | | など | | | * 各実装のためのソフトウェアはそうであるべきです。| | | 必要を説明する方法で、書かれています。| | | トランスミッションのバイトオーダー、(ieに、: Big Endian/| | | プロセッサの小さいEndianの特性は|必要とします|、|、ソフトウェアで対処される、) | +------------------------------------------------------------------+ |バージョン|TALIバージョンラベルは12バイトのASCIIテキストフィールドです。 | |ラベル|ラベルは形式'vers xxx.yyy'、どこxxx.yyyのものであるか。| | |002.000などのバージョンを特定するために、使用されます。 as| | |他のASCIIテキスト分野、最初のバイト| | |テキストフィールド('v')は最初のバイトであるべきです。| | |ワイヤから、伝えられます。 | +------------------------------------------------------------------+ |原始|新しいTALI2.0opcodesを使用するメッセージがすべて、aを持っています。| | |4バイトのテキストASCII分野はPrimitiveを呼びました。 | | |Primitiveはopcodeのための修飾語として機能します。 これ| | |単一のopcodeが倍数を実行するのに使用されるのを許容します。| | |動作。 | +------------------------------------------------------------------+ |原始|詳細を指定するのにPrimitiveを使用できます。| |操作|動作の動作かセット。 時はPrimitive分野です。| | |1セットの機能、操作を指定するために、使用されます。| | |分野は、それの中で特定の操作を選ぶのに使用されます。| | |動作のグループ。 オペレーション欄は4バイトの整数です。| +------------------------------------------------------------------+ |個人的|様々なRFCドキュメントは割り当てられることのセットについて詳述しました。| |エンタープライズ|数(RFC1700、Assigned民数記)と定義されたデータ| |コード|構造(|RFC1155、Structure、およびIdentification| (PEC)| IPベースのInternetsのための管理情報)| | |それは、ネットワークを提供するのにIPネットワークで使用されます。| | |経営情報。 | | |ネットワークManagement Object Identifiers(OID)は使用されています。| | |特定の組織、会社を認識するために| | |すべてのベンダーがそうすることができる方法によるプロトコルなど| | |同意します。 | | |Object Identifierが存在している、どれ、唯一、説明するか。| | |データ/telecommのビジネスをする各社| | |産業。 OIDは'SMI Networkと呼ばれます'| | |私たちがそうである'管理兵士のエンタープライズCode'| | |これでPECの兵士のエンタープライズCodeに短くすること。| | |簡単さのために、記録します。 PECにはある思われるそれぞれ|
Sprague, et al. Informational [Page 58] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[58ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| |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は接頭語を定義しました。| | |または'iso.org.dod.internet.private.enterprise'。| | |(1.3.6.1.4.1). | | | | | |以下でファイルで各社のためのPECを見つけることができます。 | | | ftp://ftp.isi.edu/in-notes/iana/assignments/ | | | 企業番号| | | | | |ベンダーのために各実装でPECをコード化するために| | |TALIでは、2バイトの整数分野は使用されています。 コンテンツ| | |分野がPECコードに合うべきである整数について| | |前記のようにファイルのその会社。 | | | | | |例えば、Tekelec(323のPECを持っている)はそうするでしょう。| | |'0×0143'としてこの2バイトの分野をコード化してください。 | | | | | |他の整数分野のように、PEC値はそうです。| | |Least Significant Byteは最初に、横切って伝えました。| | |イーサネットワイヤ。 | +------------------------------------------------------------------+
Table 10: Implementation for new field types introduced in TALI 2.0
テーブル10: TALI2.0で導入された新しいフィールド・タイプのための実装
4.5 Detailed TALI Message Structures for New 2.0 Opcodes
4.5 新しい2.0Opcodesのための詳細な崖錐メッセージ構造
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で定義されたopcodesのためのメッセージ構造は、より早く提示された情報から変わりがありません、'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.0opcodesのための詳細なメッセージ構造、および能力の議論を以下のセクションに提供します。 個別に各opcodeについて議論する前に、Table11はそれぞれの新しいopcode('moni/mona'と同様に)のためにサポートされるべきであるLENGTH分野の最小の、そして、最大の値を提供します。 テーブル11はさらに、2.0で加えられたITUサポートの影響を示しています。 ANSIが必要であるようにITUポイントコードのためのルーティングラベルは7つの八重奏の代わりに4つの八重奏しか使用しません。
Sprague, et al. Informational [Page 59] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[59ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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| 有効な長さ| コメント| | | 分野値| | +------------------------------------------------------------------+ | moni| 0-200バイト| データ部の全長| | | | TALI2.0実装の'moni'のために| | | | バージョン1.0から、変わりがありません。| | | | 200バイトにおける仕様と残り| | | | 互換性を後方に提供するために。 | +------------------------------------------------------------------+ | mona| 0-200バイト| データ部の全長| | | | TALI2.0実装の'mona'のために| | | | バージョン1.0から、変わりがありません。| | | | 200バイトにおける仕様と残り| | | | 互換性を後方に提供するために。 | +------------------------------------------------------------------+ | 管理| 4-4096バイト| 最低4バイトの長さが必要です。| | | | Primitive分野にスペースを提供するために|| | | 最大の長さは大きいTCPを許容します。| | | | 望まれているならサポートされるパケット。 | +------------------------------------------------------------------+ | xsrv| 4-4096バイト| 最低4バイトの長さが必要です。| | | | Primitive分野にスペースを提供するために|| | | 最大の長さは大きいTCPを許容します。| | | | 望まれているならサポートされるパケット。 | +------------------------------------------------------------------+ | spcl| 4-4096バイト| 最低4バイトの長さが必要です。| | | | Primitive分野にスペースを提供するために|| | | 最大の長さは大きいTCPを許容します。| | | | 望まれているならサポートされるパケット。 | +------------------------------------------------------------------+ | sccp| 9-265バイト| これらは有効なサイズです。| | | | SCCP UDT MSUのSCCPだけ部分。 | +------------------------------------------------------------------+ | isot| 8-273バイト| 長さが八重奏の数である、それ| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さはSIOを含んでいます。| | | | バイトとSIF(サービス| | | | 情報Field)分野のすべてのバイト。 MTP3| | | | ルーティングラベルはSIF分野の一部です。 | +------------------------------------------------------------------+ | mtp3| 8-280バイト| 長さが八重奏の数である、それ| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さはSIOを含んでいます。| | | | バイトとSIF(サービス| | | | 情報Field)分野のすべてのバイト。 MTP3| | | | ルーティングラベルはSIF分野の一部です。 | +------------------------------------------------------------------+
Sprague, et al. Informational [Page 60] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[60ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| 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バイト| 長さが八重奏の数である、それ| | | | MTP3で、より高いのが(s)を層にするコネ| | | | SS7MSU。 この長さはSIOを含んでいます。| | | | バイトとSIF(サービス| | | | 情報Field)分野のすべてのバイト。 MTP3| | | | ルーティングラベルはSIF分野の一部です。 | | | | SSCOPトレーラの7(7)八重奏はそうです。| | | | メッセージに追加されます。 SSCOPトレーラ| | | | また、バイトは長さに含まれています。 | +------------------------------------------------------------------+
Table 11: Valid Length Fields for Opcodes Affected by TALI 2.0
テーブル11: 崖錐2.0で影響を受けるOpcodesに、有効な長さの分野
4.5.1 Management Message (mgmt)
4.5.1 管理メッセージ(管理)
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:
'管理'opcodeがTALI終点の間をソケット接続の上に通るためにデバイスの操作を管理するManagementデータ、またはデータを許容することを意図します。 TALI NEx-FEx州のいずれでも'管理'メッセージを受け取って、処理できます。 3PRIMITIVESがこのopcodeとの使用のために定義されます:
* '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 MTP3に許容する、(不-、)、IPデバイスSGに渡されるSS7デバイスの有用性と混雑州。
* '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現在、'管理'opcodeのための唯一の定義された基関数が、'rkrp'と、'mtpp'と、'sorp'です。 将来、SGかIPデバイスのManagement能力を広げるためにこのopcodeにより多くの基関数を加えることができます。 これらのすべての3つの基関数への2.0の'管理'メッセージのための基本的なメッセージ構造は以下の通りです:
Sprague, et al. Informational [Page 61] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[61ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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. | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| '管理'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| これらの'rkrp'、'mtpp'または'sorp'Each| | | | 基関数は適切のグループを指定します。| | | | 管理操作。 | +------------------------------------------------------------------+ | 14..17 | 原始| オペレーション欄はものを指定します。| | | 操作| 操作のグループの中の操作| | | | 原始で、特定されます。 | +------------------------------------------------------------------+ | 18.. | メッセージ| メッセージデータ領域の内容はそうです。| | | データ| opcode/の組み合わせに依存しています。| | | | 原始の/オペレーション欄。 それぞれのもの| | | | 組み合わせは異なったメッセージを使用するかもしれません。| | | | データ構造。 | +------------------------------------------------------------------+
Table 12: Message Structure for 'mgmt' opcode
テーブル12: '管理'opcodeのためのメッセージStructure
4.5.1.1 Routing Key Registration Primitive (rkrp)
4.5.1.1 原始的に主要な登録を発送すること。(rkrp)
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ノードは、SGで彼らが各ソケットの上に受けたがっているSS7トラフィックストリームを構成するメッセージをTALIに送ることによって、アプリケーションルーティングキーテーブルを変更できます。 この'ルーティングキー登録'は実行されたTALIを通したバンドのメッセージです、ルーティングキーを構成するのにSGユーザーインタフェースを使用することに代わる手段として。
Recall from earlier discussion in this document that the specification supports five (5) types of fully specified routing keys:
以前の議論から、本書では、仕様が完全に指定されたルーティングキーの5(5)タイプをサポートすると思い出してください:
* A key for SCCP traffic, where key = DPC-SI-SSN, where SI=3.
* SCCPトラフィックのためのキー。(そこでは、キーが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 Rangeと等しいです)。そこでは、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 Rangeと等しいです)。そこでは、SIが4と等しいです。 このキーはITUネットワークのために支えられるだけです。 TUPキーのためのCIC値はITUネットワークで12ビットの量です。
Sprague, et al. Informational [Page 62] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[62ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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トラフィック(32ビットのCICコードを使用するISUPの拡大)のためのキー。(そこでは、キーがDPC SI OPC CICと等しいです)。そこでは、SIが13と等しいです。 QBICCキーのためのCIC値はANSIとITUネットワークのための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に合っている完全に指定されたキーを見つけるのを試みた後に、使用されるだけです。
Sprague, et al. Informational [Page 63] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[63ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+--------+------------+--------------------------------+-----------+ |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. | | +--------+------------+--------------------------------+-----------+
+--------+------------+--------------------------------+-----------+ |キー| キー| コメント| 十字| |タイプ| 属性| | 参照| +--------+------------+--------------------------------+-----------+ |部分的| DPC SI OPC|バックアップルートとして、CICのために、使用されます。| 4.5.1.1.2 | | | |ベースのトラフィック、(無視、| | | | | CIC分野、) | | +--------+------------+--------------------------------+-----------+ |部分的| DPC-SI|バックアップルートとして、CICのために、使用されます。| 4.5.1.1.4 | | | |ベースかSCCPトラフィック(しかし、| | | | | OPC-CICを無視するか、SSN)。 | | | | |唯一基づくトラフィックを発送します。| | | | |MSUのDPCとSI。 | | +--------+------------+--------------------------------+-----------+ |部分的| DPC|バックアップルートとして、いずれのためにも、使用されます。| 4.5.1.1.4 | | | |MSUタイプ。 トラフィックが基礎づけたルート| | | | |唯一DPCフィールドで。 | | +--------+------------+--------------------------------+-----------+ |部分的| SI|バックアップルートとして、いずれのためにも、使用されます。| 4.5.1.1.4 | | | |MSUタイプ。 トラフィックが基礎づけたルート| | | | |唯一SIフィールドで。 | | +--------+------------+--------------------------------+-----------+ |デフォルト| - |いいえ、ルーティングキーの他のタイプなら| 4.5.1.1.5 | | | |MSUを見つけることができるので使用| | | | |この1つ。 | | +--------+------------+--------------------------------+-----------+
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 Operation'分野を通って示されます。 これらの能力は:
* 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.
* 入ります: ENTER操作は特定のソケットと特定のアプリケーションルーティングキーとの協会を創設します。 いつも協会のソケットは'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
* 削除します: DELETE操作は特定のソケットと特定のアプリケーションルーティングキーとの協会を削除します。 いつも協会のソケットは'rkrp'がそうであったソケットです。
Sprague, et al. Informational [Page 64] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[64ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
受け取られている。 同じアプリケーションルーティングキーのための他のソケット協会は削除で影響を受けません。 ルーティングキーのための前回のソケット協会を削除するとき、データベースから全体のルーティングキーエントリーを取り除きます。 DELETE操作操作は完全に指定された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.
* 以下を分けてください。 SPLIT操作は単一のアプリケーションルーティングキーを2アプリケーションに変換するのに使用されて、そんなに一緒にいるルーティングキーがオリジナルのキーと同じSS7トラフィックストリームをカバーしているということです。 股割りが実行される直後、結果として起こるエントリーの両方がオリジナルのルーティングキーと同じソケット協会を保有します。 分裂が終了しているとき、もう片方の範囲の如何にかかわらずそれぞれの2つの結果として起こる範囲にソケット協会を変更できます。 分裂操作は単に完全に指定されたCICベースのキー(ISUP、QBICC、およびTUP)に適切です。 それぞれの完全に指定されたCICベースのキーはDPC/SI/OPC/CIC範囲の組み合わせで唯一特定されます。 CICS(始める)からCICE(終わり)までCIC範囲は連続した一連の数字です。 アプリケーションルーティングキーの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).
* 以下をリサイズしてください。 RESIZE操作は、単一のアプリケーションルーティングキーを受けそうでCIC範囲を変更するのに使用されます。 リサイズ操作は単に完全に指定されたCICベースのルーティングキーに適切です。 リサイズ操作は新しいCIC範囲(NCICS/NCICE)によって主要なルーティングのためにCICS/CICE値に取って代わります。 既存のCICS/CICEに基づいてさまざまなNCICS/NCICE範囲をサポートすることができます。 ほとんど唯一の制限は新しい範囲がデータベースに既に存在できないで、いかなる他のデータベースへの登録も重ね合わせることができないということです。 ルーティングキーのためのソケット協会はCICS/CICEにおける変化で影響を受けません。 SPLIT操作は完全に指定された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 Operations(そして、彼らのencodings)のリストは以下の通りです:
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
ISUPキー0x0002を入れてください--ISUPキー0x0003を削除してください--分裂ISUPキー0x0004(リサイズISUPキー0x0005)がQ.BICC ISUPキー0x0006を入れるという0×0001はQ.BICC ISUPキー0x0007を削除します--分裂Q.BICC ISUPキー0x0008(リサイズQ.BICC ISUPキー0x0009)はSCCPの主要な0x000Aに入ります--SCCPキーを削除してください。
Sprague, et al. Informational [Page 65] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[65ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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--ENTER OTHER-MTP3-SI KEY 0x000C--DELETE OTHER-MTP3-SI KEY 0x000D--ENTER TUP KEY(ITU専用)0x000E--DELETE TUP KEY(ITU専用)0x000F--SPLIT TUP KEY(ITU専用)0×0010--RESIZE TUP KEY(ITU専用)0×0011--ENTER DPC SI OPC PARTIAL KEY0×0012--DELETE DPC SI OPC PARTIAL KEY; 0×0013--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 Operationが指定されるかに基づいて'rkrp'メッセージのメッセージデータ領域は異なるでしょう。 いくつかの異なった構造が使用されている、RKRP Operation分野で正しい構造を特定できます。
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に初期化されて、受信機によって無視されるべきです。
4.5.1.1.1 RKRP Data Structures
4.5.1.1.1 RKRPデータ構造
4.5.1.1.1.1 Common Fields in all RKRP Messages
4.5.1.1.1.1 すべてのRKRP Messagesの一般的なフィールズ
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操作に使用されるべき異なったデータ構造が提示されます。 それぞれのこれらのデータ構造が以下の分野が共通であることに注意されるべきです。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
Sprague, et al. Informational [Page 66] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[66ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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. | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | | +------------------------------------------------------------------+ | 2 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | コネからのencodingsは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要求メッセージを受け取るとき、分からないで、それは、操作がサポートされないのを(Unsupported rkrp OperationのRKRP Reply Codeと共に)示すのに要求を回答に変えて、成功/失敗コードを使用するべきです。
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操作がこの仕様に追加されるので使用され続けているという要件です。 これは、前のパラグラフで説明された能力がいつも存在するのを確実にするでしょう。
Sprague, et al. Informational [Page 67] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[67ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
4.5.1.1.1.2 CIC Based Routing Key Operations
4.5.1.1.1.2 CICはルート設定の主要な操作を基礎づけました。
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(ISUP、Q. BICC ISUP、およびTUP(ITU専用))であるMSUに関連する'rkrp'メッセージに使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
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操作(0×0001--0×0004)が構造で対応する分野から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操作(0×0005--0×0008)が構造で対応する分野から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--0×0010)が構造で対応する分野から12ビットのCIC値を使用すると思われます。 32ビットのCIC分野の12の最下位ビットだけが使用されるでしょう。 TUP操作はANSIネットワークのためにサポートされません。
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. | |
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | |
Sprague, et al. Informational [Page 68] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[68ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | セクションで記載されたencodings| | | | | 5. | | +------------------------------------------------------------------+ | 2 | RKRP旗| これは2バイトのビット分野です。| ビット分野| | | | それは可能な16を提供します。| | | | | 制御されることができる旗| | | | | 種々相| | | | | 操作。 | | | | | ビット0--Overrideビットはそうです。| | | | | ENTER操作のときに、使用されます。| | | | | その方法を制御する、ソケット| | | | | ルーティングのための協会| | | | | キーは操作されるべきです。 | | | | | この旗は確認します。| | | | | ENTERは付与を加えることになっています。| | | | | aのソケット協会| | | | | または'負荷分割法'モード。| | | | | 新連合はそうするべきです。| | | | | すべてを取り替えてください(くつがえします)。| | | | | 既存の協会。 これ| | | | | 旗は調べられるだけです。| | | | | ENTER操作。 | | | | | ビット0=0、負荷分割法モード| | | | | ビット0=1、オーバーライドモード| | | | | 現在のビット1-15| | | | | 未定義| | +------------------------------------------------------------------+ | 1 | SI| インディケータを修理してください。 SI| 整数| | | | SS7 MSUの分野| | | | | タイプを特定します。| | | | | 運ばれるトラフィック| | | | | MSU(| | | | | 0=SNM、3=SCCP、5=ISUPなど)。 各アプリケーション| | | | | ルーティングキーはaを指定しなければなりません。| | | | | 特定のSIがそれを評価する、それ| | | | | 関連します。 | | | | | SI、ISUPキーのための5はそうであるべきです|| | | | SIはQ. BICCのための13であるべきです。| | | | | ISUPキー。 | | | | | SIはTUPキーのための4であるべきです。 | |
Sprague, et al. Informational [Page 69] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[69ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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| 目的地ポイントコード。 それぞれ| SS7ポイント| | | | SS7 MSUがDPCを含んでいる、それ| コード| | | | 目的地を特定します。| | | | | MSUのために。 それぞれ| | | | | アプリケーションルーティングキーはそうしなければなりません。| | | | | 特定のDPC値を指定してください。| | | | | それ、それは関連します。 | | +------------------------------------------------------------------+ | 4 | OPC| 創作ポイントコード。 それぞれ| SS7ポイント| | | | SS7 MSUがOPCを含んでいる、それ| コード| | | | ソースを特定します。| | | | | MSU。 ISUPルーティングキーはそうしなければなりません。| | | | | それぞれが独身のOPCを指定します。| | | | | それはアプリケーションルーティングです。| | | | | キーは関連します。 | | +------------------------------------------------------------------+ | 4 | CICS| 回路識別コード| 整数| | | | 始まってください。 それぞれのSS7 ISUP MSU| | | | | CICコードを含んでいます。 それぞれ| | | | | ISUP/QBICC/TUPルーティングキー| | | | | さまざまなCICを特定します。| | | | | 適切な値| | | | | ルーティングキーのために。 The| | | | | CICS値はローエンドです。| | | | | CIC範囲。 | | +------------------------------------------------------------------+ | 4 | CICE| 回路識別コード| 整数| | | | 終わってください。 それぞれのSS7 ISUP MSU| | | | | CICコードを含んでいます。 それぞれ| | | | | ISUP/QBICC/TUPルーティングキー| | | | | さまざまなCICを特定します。| | | | | 適切な値| | | | | ルーティングキーのために。 The| | | | | CICE値は上位です。| | | | | CICでは、及んでください。 | | +------------------------------------------------------------------+ | 4 | CICを分割してください。| 分野が使用されるSPLIT| 整数| | | | SPLIT操作| | | | | 存在で指定するところで指定してください。| | | | | 既存のルーティングが合わせるCIC範囲(CICS/| | | | | CICEによって与えられています)| | | | | 2に分けられるべきです。| | | | | キーを発送します。 有効になるように| | | | | 以下の関係| | | | | SPLITの前で本当でなければなりません。| | | | | 実行されます: | | | | | CICS<は<=CICEを分割しました。 | |
Sprague, et al. Informational [Page 70] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[70ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | 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. | | +------------------------------------------------------------------+
| | | SPLITが実行された後に| | | | | ルーティングキーがある2| | | | | 続きます: | | | | | 分裂-1へのCICS| | | | | CICEに分けられます。| | +------------------------------------------------------------------+ | 4 | NCICS| NCICSとNCICE分野| 整数| | | | RESIZEでは、使用されます。| | | | | その方法を指定する操作| | | | | 存在するためのCIC範囲| | | | | ルーティングキーはそうであるべきです。| | | | | 変更にされる。 NCICSは指定します。| | | | | 新しいそうするべきである値| | | | | 既存のCICSを取り替えてください。| | | | | ルーティングキーの値。 | | +------------------------------------------------------------------+ | 4 | NCICE| NCICSとNCICE分野| 整数| | | | RESIZEでは、使用されます。| | | | | その方法を指定する操作| | | | | 存在するためのCIC範囲| | | | | ルーティングキーはそうであるべきです。| | | | | 変更にされる。 NCICEは指定します。| | | | | 新しいそうするべきである値| | | | | 既存のCICEを取り替えてください。| | | | | ルーティングキーの値。 | | +------------------------------------------------------------------+
Table 15: Message Data Structure CIC based Routing Key Operations
テーブル15: メッセージのData StructureのCICのベースのルート設定Key Operations
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.
以下のテーブルはRKRP Operation分野に基づくTable15のメッセージデータ構造の各分野にRequired(R)、またはNot Applicable(NA)状態を示します。 既述のとおり、未使用の分野(NAであるとマークされたもの)は、送付者によって0に初期化されて、受信機によって無視されるべきです。
Sprague, et al. Informational [Page 71] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[71ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 操作| 入ってください。| 削除します。| 分けられます。| リサイズ| 入るか、または削除します。| | | (| | ISUP、(| | ISUP、(| | ISUP、(| 部分的なDPC| | SI OPCキー| | 分野| ISUP、| | QBICC、| QBICC、| QBICC、| QBICC、雄羊)雄羊)雄羊)雄羊) | | +------------------------------------------------------------------+ | 要求/回答| R| R| R| R| R| +------------------------------------------------------------------+ | 成功/失敗| R| R| R| R| R| +------------------------------------------------------------------+ | RKRP旗| 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| +------------------------------------------------------------------+ | 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のためのApplicableフィールズではなく、必要な/がRoutingキーズを基礎づけました。
4.5.1.1.1.3 SCCP Routing Key Operations
4.5.1.1.1.3 SCCPのルート設定の主要な操作
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'メッセージに使用されるデータ構造は次のテーブルに提示されます。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
Sprague, et al. Informational [Page 72] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[72ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | |
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | | +------------------------------------------------------------------+ | 2 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | セクションで記載されたencodings| | | | | 5. | | +------------------------------------------------------------------+ | 2 | RKRP旗| これは2バイトのビット分野です。| ビット分野| | | | それは可能な16を提供します。| | | | | 制御されることができる旗| | | | | 種々相| | | | | 操作。 | | | | | ビット0--Overrideビットはそうです。| | | | | ENTER操作のときに、使用されます。| | | | | その方法を制御する、ソケット| | | | | ルーティングのための協会| | | | | キーは操作されるべきです。 | | | | | この旗は確認します。| | | | | ENTERは付与を加えることになっています。| | | | | aのソケット協会| | | | | または'負荷分割法'モード。| | | | | 新連合はそうするべきです。| | | | | すべてを取り替えてください(くつがえします)。| | | | | 既存の協会。 これ| | | | | 旗は調べられるだけです。| | | | | ENTER操作。 | | | | | ビット0=0、負荷分割法モード| |
Sprague, et al. Informational [Page 73] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[73ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | 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. | | +------------------------------------------------------------------+
| | | ビット0=1、オーバーライドモード| | | | | 現在のビット1-15| | | | | 未定義| | +------------------------------------------------------------------+ | 1 | SI| インディケータを修理してください。 SI| 整数| | | | SS7 MSUの分野| | | | | タイプを特定します。| | | | | 運ばれる交通| | | | | MSU(| | | | | 0=SNM、3=SCCP、5=ISUPなど)。 各アプリケーション| | | | | ルーティングキーはaを指定しなければなりません。| | | | | 特定のSIがそれを評価する、それ| | | | | 関連します。 | | | | | SI、SCCPキーのための3はそうであるべきです|| +------------------------------------------------------------------+ | 4 | DPC| 目的地ポイントコード。 それぞれ| SS7ポイント| | | | SS7 MSUがDPCを含んでいる、それ| コード| | | | 目的地を特定します。| | | | | MSUのために。 それぞれ| | | | | アプリケーションルーティングキーはそうしなければなりません。| | | | | 特定のDPC値を指定してください。| | | | | それ、それは関連します。 | | +------------------------------------------------------------------+ | 1 | SSN| サブシステム番号。 各SCCP| 整数| | | | MSUはサブシステムを含んでいます。| | | | | それが特定する数| | | | | そうするべきであるSCCPサブシステム| | | | | MSUを処理してください。 SCCP| | | | | ルーティングキーはそれぞれそうしなければなりません。| | | | | 独身のSSNを指定してください、それ| | | | | アプリケーションルーティングキー| | | | | 関連します。 | | +------------------------------------------------------------------+
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.
以下のテーブルはRKRP Operation分野に基づくTable17のメッセージデータ構造の各分野にRequired(R)、またはNot Applicable(NA)状態を示します。 既述のとおり、未使用の分野(NAであるとマークされたもの)は、送付者によって0に初期化されて、受信機によって無視されるべきです。
Sprague, et al. Informational [Page 74] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[74ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+--------------------------------------------+
| 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 |
+--------------------------------------------+
+--------------------------------------------+ | 操作| SCCPに入ってください。| SCCPを削除してください。| | 分野| | | +--------------------------------------------+ | 要求/回答| R| R| +--------------------------------------------+ | 成功/失敗| R| R| +--------------------------------------------+ | RKRP旗| R| R| +--------------------------------------------+ | SI| R| R| +--------------------------------------------+ | DPC| R| R| +--------------------------------------------+ | SSN| R| R| +--------------------------------------------+
Table 18: Required/Not Applicable Fields for SCCP Routing Keys
テーブル18: 適切な分野ではなく、SCCPルート設定キーのための必要な/
4.5.1.1.1.4 DPC-SI, DPC and SI based Routing Key Operations
4.5.1.1.1.4 DPC-SI、DPC、およびSIのベースのルート設定Key Operations
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'(部分的なキー)操作に使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
+------------------------------------------------------------------+ | 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 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | |
Sprague, et al. Informational [Page 75] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[75ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | セクション5からのencodings。 | | +------------------------------------------------------------------+ | 2 | RKRP旗| これは2バイトのビット分野です。| ビット分野| | | | それは可能な16を提供します。| | | | | 制御されることができる旗| | | | | 種々相| | | | | 操作。 | | | | | ビット0--Overrideビットはそうです。| | | | | ENTER操作のときに、使用されます。| | | | | その方法を制御する、ソケット| | | | | ルーティングのための協会| | | | | キーは操作されるべきです。 | | | | | この旗は確認します。| | | | | ENTERは付与を加えることになっています。| | | | | aのソケット協会| | | | | または'負荷分割法'モード。| | | | | 新連合はそうするべきです。| | | | | すべてを取り替えてください(くつがえします)。| | | | | 既存の協会。 これ| | | | | 旗は調べられるだけです。| | | | | ENTER操作。 | | | | | ビット0=0、負荷分割法モード| | | | | ビット0=1、オーバーライドモード| | | | | 現在のビット1-15| | | | | 未定義| | +------------------------------------------------------------------+ | 1 | SI| インディケータを修理してください。 SI| 整数| | | | SS7 MSUの分野| | | | | タイプを特定します。| | | | | 運ばれる交通| | | | | MSU(| | | | | 0=SNM、3=SCCP、5=ISUPなど)。 各アプリケーション| | | | | ルーティングキーはaを指定しなければなりません。| | | | | 特定のSIがそれを評価する、それ| | | | | 関連します。 | | +------------------------------------------------------------------+
Sprague, et al. Informational [Page 76] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[76ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| 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| 目的地ポイントコード。 それぞれ| SS7ポイント| | | | SS7 MSUがDPCを含んでいる、それ| コード| | | | 目的地を特定します。| | | | | MSUのために。 それぞれ| | | | | アプリケーションルーティングキーはそうしなければなりません。| | | | | 特定のDPC値を指定してください。| | | | | それ、それは関連します。 | | +------------------------------------------------------------------+ テーブル19: メッセージData Structure DPC/SI、DPC、およびSIのベースのルート設定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.
以下のテーブルはRKRP Operation分野に基づくTable19のメッセージデータ構造の各分野にRequired(R)、またはNot Applicable(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 |
+-------------------------------------------------------+
+-------------------------------------------------------+ | 操作| /に入ってください。| /に入ってください。| /に入ってください。| /に入ってください。| | | 削除します。| 削除します。| 削除します。| 削除します。| | | 他| DPC-SI| DPC| SI| | 分野| MTP3SI| 部分的| 唯一| 唯一| +-------------------------------------------------------+ | 要求/回答| R| R| R| R| +-------------------------------------------------------+ | 成功/失敗| R| R| R| R| +-------------------------------------------------------+ | RKRP旗| 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: Applicableフィールズではなく、DPC/SI、DPC、およびSIのベースのRoutingキーズに、必要な/
4.5.1.1.1.5 Default Routing Key Operations
4.5.1.1.1.5 デフォルトのルート設定の主要な操作
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'メッセージに使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
Sprague, et al. Informational [Page 77] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[77ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | |
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | | +------------------------------------------------------------------+ | 2 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | セクションで記載されたencodings| | | | | 5. | | +------------------------------------------------------------------+ | 2 | RKRP旗| これは2バイトのビット分野です。| ビット分野| | | | それは可能な16を提供します。| | | | | 制御されることができる旗| | | | | 種々相| | | | | 操作。 | | | | | ビット0--Overrideビットはそうです。| | | | | ENTER操作のときに、使用されます。| | | | | その方法を制御する、ソケット| | | | | ルーティングのための協会| | | | | キーは操作されるべきです。 | | | | | この旗は確認します。| | | | | ENTERは付与を加えることになっています。| | | | | aのソケット協会| | | | | または'負荷分割法'モード。| | | | | 新連合はそうするべきです。| | | | | すべてを取り替えてください(くつがえします)。| | | | | 既存の協会。 これ| | | | | 旗は調べられるだけです。| | | | | ENTER操作。 | | | | | ビット0=0、負荷分割法モード| |
Sprague, et al. Informational [Page 78] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[78ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | Bit 0=1, Override Mode | | | | | Bits 1-15, currently | | | | | undefined | | +------------------------------------------------------------------+
| | | ビット0=1、オーバーライドモード| | | | | 現在のビット1-15| | | | | 未定義| | +------------------------------------------------------------------+
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.
以下のテーブルはRKRP Operation分野に基づくTable21のメッセージデータ構造の各分野にRequired(R)、またはNot Applicable(NA)状態を示します。 既述のとおり、未使用の分野(NAであるとマークされたもの)は、送付者によって0に初期化されて、受信機によって無視されるべきです。
+-------------------------------------+
| Operation | ENTER | DELETE |
| Field | DEFAULT | DEFAULT |
+-------------------------------------+
| Request/Reply | R | R |
+-------------------------------------+
| Success/Failure | R | R |
+-------------------------------------+
| RKRP Flags | R | R |
+-------------------------------------+
+-------------------------------------+ | 操作| 入ってください。| 削除します。| | 分野| デフォルト| デフォルト| +-------------------------------------+ | 要求/回答| R| R| +-------------------------------------+ | 成功/失敗| R| R| +-------------------------------------+ | RKRP旗| R| R| +-------------------------------------+
Table 22: Required/Not Applicable Fields for Default Routing Keys
テーブル22: 適切な分野ではなく、デフォルトルート設定キーのための必要な/
4.5.1.1.1.6 Support for Multiple RKRP Registration Operations
4.5.1.1.1.6 複数のRKRP登録操作のサポート
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メッセージ(opcodeは'管理'、原始の='rkrp'と等しい)の中の複数のRKRP操作のサポートの意図はネットワーク送信のときに大規模な登録系列を実行するとき、頭上でメッセージカウントとバイトを減少させることです。
This functionality is added by 2 mechanisms:
この機能性は2つのメカニズムによって加えられます:
* 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、MULTIPLE REGISTRATIONS SUPPORT)は定義されます。 この操作は、そのような能力を使用する前に遠端が複数のTALIメッセージあたりのRKRP登録証明書を支持するかどうか決定するのに質問/回答方法で使用されることになっています。
* The basic 'rkrp' message structure is extended to allow multiple
rkrp operations to follow one another in a tali message.
* 基本的な'rkrp'メッセージ構造は、複数のrkrp操作が崖錐メッセージでお互いに続くのを許容するために広げられます。
4.5.1.1.1.6.1 Multiple Registrations Support
4.5.1.1.1.6.1 複数の登録証明書サポート
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登録操作を支持するかどうか決定するために定義されます。
Sprague, et al. Informational [Page 79] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[79ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
'複数の登録証明書サポート'操作に使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
+------------------------------------------------------------------+ | 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 | |
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | RKRP| どの'rkrp'を特定するか。| 整数| | | 操作| 操作は望まれています。 | | +------------------------------------------------------------------+ | 2 | 要求/| 特定、'rkrp'| 整数| | | 返信| メッセージが要求である、(| | | | | SGへのIPノード、)、何人かのタイプ| | | | | 'rkrp'動作、または回答について| | | | | 前の要求(| | | | |IPノードへのSG)に。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0000=要求| | | | | 0×0001は回答と等しいです。 成功/を見てください。| | | | | 詳しい情報のための失敗コード。 | | +------------------------------------------------------------------+ | 2 | 成功/| 成功/失敗を提供します。| 整数| | | 失敗| 部分としての指示| | | | コード| IPノードに応じて戻ってください。| | | | | それぞれの処理要求のために。 | | | | | この分野が使用されるだけである、いつ| | | | | Request/回答分野はそうです。| | | | | 0×0001。 この分野は使用します。| | | | | セクションで記載されたencodings| | | | | 5. | | +------------------------------------------------------------------+ | 4 | 操作| この分野は使用されます。| 整数| | | メッセージ単位で| 返答して、リクエスタを言ってください。| | | | | RKRPの最大#| | | | | 登録操作| | | | | TALIメッセージ| | | | | サポートされます。| | | | | 実装。 | | | | | * この分野は設定されるべきです。| | | | | 0、要求/です。| | | | | 回答分野は設定されます。| | | | | 要求します。 | | | | | * この分野は設定されるべきです。| | | | | 操作のMaximum#| | | | | TALIに従って、そのaを通信させてください。| | | | | TALI実装はそうです。| |
Sprague, et al. Informational [Page 80] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[80ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | willing to support when the| |
| | | request/reply field is set | |
| | | to Reply. | |
+------------------------------------------------------------------+
Table 23: Message Data Structure for Multiple Registrations Support
Operation
| | | 望むいつをサポートするかを| | | | | 要求/回答分野は設定されます。| | | | | 返答するために。 | | +------------------------------------------------------------------+ テーブル23: 複数の登録証明書サポート操作のためのメッセージデータ構造
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.
以下のテーブルはRequired(R)、またはNot Applicable(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 | | |
+-------------------------------------------------+
+-------------------------------------------------+ | 操作| 倍数| 倍数| | | 登録証明書| 登録証明書| | | サポート| サポート| | 分野| 要求| 返信| +-------------------------------------------------+ | 要求/回答| R| R| +-------------------------------------------------+ | 成功/失敗| R| R| +-------------------------------------------------+ | 操作| R| R| | メッセージ| | | +-------------------------------------------------+
Table 24: Required/Not Applicable Fields for Multiple Registrations
Support Operation
テーブル24: 複数の登録証明書のためのどんな適切な分野も操作をサポートしない必要な/
4.5.1.1.1.6.2 Multiple RKRP Operations in a Single Message
4.5.1.1.1.6.2 ただ一つのメッセージにおける複数のRKRP操作
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操作をサポートすることを決定するのにMULTIPLE REGISTRATIONS SUPPORT操作を使用した後に、この機能性を使用したがっているデバイスは、1メッセージあたり1つ以上の登録要求/回答を送り始めることができます。 そうするために、'管理'opcode(Table12では、提示される)に、基本的なメッセージ構造を広げることができるので、各操作は直接TALIメッセージにおける古い手術痕に続きます。 3つのRKRP操作がそれにある状態でTALIメッセージを示している例は以下の通りに見えるでしょう:
Sprague, et al. Informational [Page 81] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[81ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| '管理'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ。 長さは設定そのようなものがそれであるならそうするでしょうに。| | | | 操作はそうです。| | | | 説明されます。 | +------------------------------------------------------------------+ | 10..13 | 原始| 'rkrp'| +------------------------------------------------------------------+ | 14..17 | 原始| fisrtオペレーション欄はaを特定します。| | | 操作| 実行されるべき特定のrkrp操作。 | | | #1 | | +------------------------------------------------------------------+ | 18..x| メッセージ| そして、メッセージデータの長さ、(| | | | それらのバイトの解釈のためのデータ、)| | | 操作| 操作#1はメッセージデータによります。| | | #1 | rkrp操作#1のために、必要です。| +------------------------------------------------------------------+ | x+1。 | 原始| fisrtオペレーション欄はaを特定します。| | x+4| 操作| 実行されるべき特定のrkrp操作。 | | | #2 | | +------------------------------------------------------------------+ | x+5。y| メッセージ| そして、メッセージデータの長さ、(| | | | それらのバイトの解釈のためのデータ、)| | | 操作| 操作#2はメッセージデータによります。| | | #2 | rkrp操作#2のために、必要です。| +------------------------------------------------------------------+ | y+1。 | 原始| fisrtオペレーション欄はaを特定します。| | y+4| 操作| 実行されるべき特定のrkrp操作。 | | | #3 | | +------------------------------------------------------------------+ | y+5。z| メッセージ| そして、メッセージデータの長さ、(| | | | それらのバイトの解釈のためのデータ、)| | | 操作| 操作#3はメッセージデータによります。| | | #3 | rkrp操作#3のために、必要です。| +------------------------------------------------------------------+
Table 25: Message Structure for 'mgmt' opcode with multiple
'rkrp' operations in 1 TALI Message
テーブル25: 複数の'rkrp'操作が1TALI Messageにある'管理'opcodeのためのメッセージStructure
Sprague, et al. Informational [Page 82] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[82ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
'複数の1TALI msgあたりの登録証明書'能力を使用するノードが予測できない振舞いを避けるために遠端デバイスが能力をサポートするのを確信していなければならないのが繰り返されるべきです。 これが確かである唯一の方法は、首尾よくMULTIPLE REGISTRATION SUPPORT要求を送って、MULTIPLE REGISTRATION SUPPORT回答を受け取ることです。
4.5.1.2 MTP3 Primitive (mtpp)
4.5.1.2 MTP3原始的です。(mtpp)
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.
IPノードが'mtpp'基関数でポイントコードに関する状態を取ることができる、(不-、)、有用性と混雑レベル。 これらのメッセージはTFP/TFA(TransFer ProhibitedとTransFer Allowed)と同様の情報を提供します、SS7 SNM(シグナリングNetwork Management)MSUとして伝統的なSS7ネットワークでコード化されるTFC(TransFer Congested)とRCT(ルートCongestion Test)メッセージ。 '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 Operation'分野を通って示されます。 様々なMTPP Operation分野によって提供されたこれらの能力は:
* 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 Point CodeがUnavailableであることを示します(ie: SGには、トラフィックを目的地に送るために利用可能などんなルートもありません)。 PT CODE分野は、この操作はどのSS7 Pt Codeに関係があるかを示します。
* 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 Point CodeがAvailableであることを示します(ie: SGには、トラフィックを目的地に送るために利用可能なSOMEルートがあります)。 PT CODE分野は、この操作はどのSS7 Pt Codeに関係があるかを示します。
* 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.
* コード状態をポイントに要求してください: この原始の操作は接続の片端が特定のSS7Ptコードの利用可能であるか入手できない状態にもう一方の端に投票する方法を提供します。 例えば、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.
* 入手できないクラスタ: この原始の操作は、SS7 Point Codes(例えば、10-10*)の全体のClusterがUnavailableであることを示します(ie: SGはそれの目的地のどれかにトラフィックを送るために利用可能などんなルートもクラスタリングさせません)。 PT CODE分野は、この操作はどのSS7 Cluster Pt Codeに関係があるかを示します。
* CLUSTER AVAILABLE: This primitive operation announces that at
least 1 SS7 Point Code within a cluster is Available (ie: the SG
* 利用可能な状態で、クラスタリングしてください: この原始の操作が、クラスタの中の少なくとも1SS7 Point CodeがAvailableであることを示す、(ie: SG
Sprague, et al. Informational [Page 83] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[83ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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つにトラフィックを送るために利用可能なSOMEルート) PT CODE分野は、この操作はどのSS7 Cluster Pt Codeに関係があるかを示します。
* 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.
* クラスタ状態に以下を要求してください。 この原始の操作は接続の片端がSS7Ptコードのクラスタの利用可能であるか入手できない状態にもう一方の端に投票する方法を提供します。 例えば、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 Point Codeに向かった経路がCongestedであることを示します。 PT CODE分野は、この操作はどのSS7 Pt Codeに関係があるかを示します。 CONGESTION LEVEL分野は混雑の厳しさを示します。
* 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.
* 混雑には、状態を要求してください: この原始の操作は接続の片端がSS7Ptコードの混雑状態にもう一方の端に投票する方法を提供します。 例えば、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はRoute Congestion Test(RCT)(要求における混雑レベルを合わせるように設定された優先があるSS7 Network Management Message)を生成して、送るでしょう。 SS7の目的地に向かってRCTを送ります。 SS7の目的地がまだ充血しているなら、RCTは、SG(CONGESTED DESTINATIONに原始的に変換されて、IPノードに送られる)で帰って来ながら、SS7 Transfer Controlled(TFC)を結果に望んでいます。
* 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ノードはメッセージをUser Part Unavailableに送ります。 この原始の操作はIP Nodeが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'メッセージに使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
Sprague, et al. Informational [Page 84] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[84ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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| |
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | MTPP| どの'mtpp'を特定するか。| 整数| | | 操作| 操作/能力はそうです。| | | | | このメッセージに提供します。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 入手できない0×0001=PC| | | | | 利用可能な0×0002=PC| | | | | PCを求める0×0003=要求| | | | | 状態| | | | | 入手できない0×0004=クラスタ| | | | | 利用可能な0×0005=クラスタ| | | | | クラスタを求める0×0006=要求| | | | | 状態| | | | | 0×0007 =は充血しました。| | | | | Congがある目的地| | | | | レベル| | | | | 0×0008は要求と等しいです。| | | | | 混雑状態| | | | | 0×0009 =ユーザ部分| | | | | 入手できません| | +------------------------------------------------------------------+ | 4 | 関係があります。| SS7ポイントコードを特定します。| SS7ポイント| | | ポイント| それはmtppに関連しています。| コード| | | コード| 操作。 mtpp| | | | | これに関して操作があります。| | | | | コードを指してください(クラスタリングしてください)。 | | +------------------------------------------------------------------+ | 4 | ソース| この分野は使用されるだけです。| SS7ポイント| | | ポイント| '混雑している目的地'| コード| | | コード| '混雑を求める要求'| | | | | 状態の操作。 | | | | | * '混雑'に使用されるいつ| | | | | '目的地'操作| | | | | この分野はPtを含んでいます。| | | | | ソースのコード| | | | | それがトラフィックであった| | | | | 混雑を経験します。| | | | | それは進んでいました。| | | | | 関係があるPtコード。 コネ| | | | | オリジナルのSS7の用語| | | | | MSU、(TransFer| | | | | 制御MSU)それ| | | | | 提供された混雑| | | | | 情報、CPC| | | | | TFCは'関係があるPoint'です。| |
Sprague, et al. Informational [Page 85] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[85ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| | | 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 | | +------------------------------------------------------------------+
| | | 結果として起こるMTPPの'コード'| | | | | 基関数とDPC| | | | | TFCは'ソース'です。| | | | | 'コードを指します'| | | | | MTPP原始的になること。 | | | | | * '要求'で使用されるいつ| | | | | 混雑状態のものに| | | | | 操作、この分野| | | | | どのSource Ptを示すか。| | | | | コードは減少しようとしています。| | | | | 関係があることの混雑| | | | | Ptコード。 the| | | | | オリジナルのSS7MSU、(| | | | | ルートCongestion Test MSU、)| | | | | それは、投票するのに使用されます。| | | | | 混雑、DPC| | | | | RCTは'関係があるPoint'です。| | | | | MTPP基関数の'コード'| | | | | そして、RCTのOPCはそうです。| | | | | 'ポイントコードの出典を明示します'| | | | | MTPP基関数。 | | +------------------------------------------------------------------+ | 2 | 混雑| この分野は使用されます。| 整数| | | レベル| そして'混雑している目的地'。| | | | | '混雑を求める要求'| | | | | 状態の操作| | | | | 混雑レベルを示してください。| | | | | 目的地について。 これ| | | | | 整数分野用途| | | | | 次のencodings: | | | | | 0×0000 =混雑レベル0| | | | | 0×0001 =混雑レベル1| | | | | 0×0002 =混雑レベル2| | | | | 0×0003 =混雑レベル3| | +------------------------------------------------------------------+ | 2 | 原因コード| この分野は使用されます。| 整数| | | | '入手できないユーザ部分'| | | | | 必要とする操作| | | | | UPUがある理由の原因Code| | | | | 送ること。 この整数| | | | | 分野は以下を使用します。| | | | | encodings: | | | | | 0×0000=原因未知| | | | | 0×0001 =ユーザパートUnequipped| | | | | 0×0002 =ユーザ部分| | | | | 近づきがたい| | +------------------------------------------------------------------+
Sprague, et al. Informational [Page 86] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[86ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
| 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 | ユーザID| この分野は使用されます。| 整数| | | | '入手できないユーザ部分'| | | | | どれを示すか操作| | | | | ユーザ部分は入手できません。 The| | | | | ユーザID分野は特定します。| | | | | そうするトラフィックのタイプ| | | | | 入手できません(| | | | | 0=SNM、3=SCCP、5=ISUPなど)。 | | +------------------------------------------------------------------+
Table 26: Message Data Structure for use with the 'mtpp' Primitive
テーブル26: 'mtpp'Primitiveとの使用のためのメッセージData Structure
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.
以下のテーブルはMTPP Operation分野に基づくTable26のメッセージデータ構造の各分野にRequired(R)、またはNot Applicable(NA)状態を示します。 既述のとおり、未使用の分野(NAであるとマークされたもの)は、送付者によって0に初期化されて、受信機によって無視されるべきです。
Sprague, et al. Informational [Page 87] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[87ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | | | | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 分野| 関係があります。| ソース| 混雑| 原因| ユーザ| | | ポイント| ポイント| レベル| コード| ID| | 操作| コード| コード| | | | +------------------------------------------------------------------+ | 入手できないPC| R| Na| Na| Na| Na| +------------------------------------------------------------------+ | 利用可能なPC| R| Na| Na| Na| Na| +------------------------------------------------------------------+ | PCを求める要求| R| Na| Na| Na| Na| | 状態| | | | | | +------------------------------------------------------------------+ | クラスタ| R| Na| Na| Na| Na| | 入手できません| | | | | | +------------------------------------------------------------------+ | クラスタ| R| Na| Na| Na| Na| | 利用可能| | | | | | +------------------------------------------------------------------+ | 要求| R| Na| Na| Na| Na| | クラスタ状態| | | | | | +------------------------------------------------------------------+ | 充血します。| | | | | | | 目的地| R| R| R| Na| Na| | Cong。 レベル| | | | | | +------------------------------------------------------------------+ | 要求| | | | | | | 混雑| R| R| R| Na| Na| | 状態| | | | | | +------------------------------------------------------------------+ | ユーザ部分| R| Na| Na| R| R| | 入手できません| | | | | | +------------------------------------------------------------------+
Table 27: Required/Not Applicable Fields for MTPP Operations
テーブル27: 適切な分野ではなく、MTPP操作のための必要な/
4.5.1.3 Socket Option Registration Primitive (sorp)
4.5.1.3 ソケットオプション登録原始的です。(sorp)
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ノードはソケットの上にソケット基礎で様々なオプションを設定できます。 これはTALI接続の向こう側に現れるコミュニケーションの何らかのコントロールをIPノードに許します。 IPノードへのこのソケットオプション制御装置が基関数が許容する'sorp'であるわたっているTALIを通したバンドのメッセージ。
The SORP primitives capabilities that are available to the IP device in SG are as follows:
SGのIPデバイスについて、あるSORP基関数能力は以下の通りです:
Sprague, et al. Informational [Page 88] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[88ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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 Flag分野で示したビットを保存するはずです。
* 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が設定に旗を揚げさせるよう要求してください: 噛み付いている分野オプションの状態に投票するのにおいて、使用されています。 このメッセージの受信機はCurrent SORP Flag設定で返信するはずです。
* 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:
TALI2.0現在、それぞれのソケットオプションはしばらくとして32ビットのビット分野に保存されます。 その分野の各ビットは1つのオプションのために設定を示します。 少し、0値がある分野は、オプションがDISABLEDであることを示します。 少し、1つの値がある分野は、オプションがENABLEDであることを示します。 以下のオプションは現在、サポートされます:
* 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経路指定テーブルの目的地に変化するとき、伝統的なSTPsはすべての隣接しているノードにBroadcast Phase TFPsとTFAsを送ります。 これらのBroadcast Phase TFA/TFP SS7メッセージはSGなどのSGノードによってTALI mtpp基関数に変換されます。 ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVESオプションで、それぞれのIPノードは、SS7から生じるmtpp基関数を受け取るIPノード必需品がフェーズメッセージを放送するかどうかリモートエンドに言うことができます。
* 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では、それぞれの定義されたソケットは旗、'_放送_フェーズ_基関数を可能にしてください'を持っています。(ソケットが接続するたびにそれは、FALSEに初期化されます)。 IPノードは、特定のソケットのために求められていない状態変化を受けたがっていると発表するためにENABLE BROADCAST PHASE MESSAGES操作をSGに送るはずです。 SGが、放送フェーズTFAs/TFPsをどこに送るかを決定しているとき、それはそのソケットの上の各ソケットのために'_放送_フェーズ_基関数を可能にしてください'という旗について査問するでしょう。
* 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を送り続けているとき(ie: STPは、目的地がUnavailableですが、隣接しているノードが、その入手できないDPCのためにSTPに運命づけられたトラフィックを送り続けていると隣接しているノードに言いました)、伝統的なSTPsは隣接しているノードにResponse Method TFPsを送ります。 STPに受け取られるMSUに対応してこれらのResponse Methodメッセージを送ります。 これらのResponse Method TFPメッセージはSGなどのSGノードによってTALI mtpp基関数に変換されます。 それぞれのIPノードは、ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVESオプションでIPノードがそうしたいかどうかリモートエンドに言うことができます。
Sprague, et al. Informational [Page 89] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[89ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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 Network Managementメッセージ(すなわち、TFCs(転送は制御された)とUPUs(入手できないユーザ部分))が、このRESPONSE METHOD組分けになります。 TFCsとUPUsはIP Node(いくつかの目的地に向かった送付トラフィック)による前の動作が応答メソッドイベントをIP Nodeに引き起こして戻したという事実のために応答メソッドTFPsと同様です。 応答メソッドTFPsのプライマリ違いは対応答メソッドTFCs/UPUs応答メソッドTFPがMTPPに原始的に変換されて、オリジナルのソケットだけに返送されるということです、応答メソッドTFCs/UPUsは、どのソケットが応答メソッドイベントを引き起こしたかを言う方法が全くないので複数のソケット(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では、それぞれの定義されたソケットは旗、'_応答_メソッド_基関数を可能にしてください'を持っています。(ソケットが接続するたびにそれは、FALSEに初期化されます)。 IPノードは、特定のソケットに適切であるときに、応答メソッドTFPsを受け取りたがっていると発表するためにENABLE RESPONSE METHOD MTPP PRIMITIVES操作をSGに送るはずです。 IPノードへの応答メソッドTFP(mtppに原始的に変える)後部を送る前に、SGがそのソケットのために'_応答_メソッド_基関数を可能にしてください'という旗について査問して、働くだけである、旗がそれを許容するなら、発信してください。
* 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は、SGとIPノードの間にSCCP MSUを送るのにポイントの上で'sccp'TALI opcodeをマルチポイント接続に使用しなければならないと指定しました。 'sccp'opcodeを使用するとき、オリジナルのSS7 MSUのMTP3ヘッダー部分は、MSUから剥取られて、TALI接続の向こう側に送られたデータの一部ではありませんでした。 'sccp'TALIメッセージの送付者は'sccp'opcodeとして発信する前にメッセージ(Called/呼ぶパーティAddress Pt Code分野への)のSCCP部分にMTP3ヘッダーから適切な分野にDPC/OPC野原をコピーするのに責任がありました。 このオプションはマルチポイント接続へのデータの一部がオリジナルのSS7 SCCP MSUへの少しの変更も伝えて、かかわらないときMTP3ヘッダーを含んでいるTALIポイントの向こう側にMSUをSCCPに送る方法を提供します。 ENABLE NORMALIZED SCCPであるときに、原始的であるのは、TALIインタフェースの向こう側に'mtp3'opcodeを使用することで受け取られていているSCCP MSUを送るべきであるということです。 このトランスミッションは+ sccpが分配するオリジナルのMSUの全体のMTP3ヘッダーを含むべきです。 オリジナルのSS7 MSUの変更は全く起こるべきではありません。 DISABLE NORMALIZED SCCPであるときに、原始的であるのは、TALIインタフェースの向こう側にTALIのバージョン1.0の指定されるとしての'sccp'opcodeを使用することで受け取られていているSCCP MSUを送るべきであるということです。
Sprague, et al. Informational [Page 90] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[90ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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は、SGとIPノードの間にISUP MSUを送るのにポイントの上で'isot'TALI opcodeをマルチポイント接続に使用しなければならないと指定しました。 'isot'opcodeを使用するとき、MTP3ヘッダー部分を含むオリジナルのSS7 MSUは'isot'TALIメッセージで伝えられました。 このオプションは、遠端が、'isot'opcodeと対照的に'mtp3'TALI opcodeを使用することでISUP MSUを受け取るのを好むのを示します。 オプションがENABLEDであるときに、'mtp3'opcodeはISUP MSUを送るのに使用されます、MTP3ヘッダーを含んでいて、TALI接続の向こう側に。 オプションがDISABLEDであるときに、'isot'opcodeはTALI Release1.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'メッセージに使用されるデータ構造が次のテーブルに提示されるようにあります。 以下のデータ構造はTable12に示されるようにTALIメッセージのバイト14で始まるべきです。
Sprague, et al. Informational [Page 91] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[91ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| フィールド・タイプ| +------------------------------------------------------------------+ | 2 | SORP| どの'sorp'を特定するか。| 整数| | | 操作| 操作/能力はそうです。| | | | | このメッセージに提供します。 | | | | | この整数分野は使用します。| | | | | 次のencodings: | | | | | 0×0001 =セットSORP旗| | | | | 0×0002 =要求電流| | | | | SORPは設定に旗を揚げさせます。| | | | | 電流との0×0003=回答| | | | | SORP旗の設定| | +------------------------------------------------------------------+ | 2 | SORP旗| それが使用する4バイトのビット分野| ビット分野| | | | それぞれが噛み付いた、/を可能にします。| | | | | 身体障害者はaのために弛みます。| | | | | 特定のソケットオプション。 | | | | | ビットx=0は示します。| | | | | オプションはDISABLEDです。 | | | | | ビットx=1は示します。| | | | | オプションはENABLEDです。 | | | | | 各BITのための課題| | | | | 以下の通りです: | | | | | ビット0は放送フェーズMTPPと等しいです。| | | | | 基関数| | | | | ビット1は応答メソッドMTPPと等しいです。| | | | | 基関数| | | | | ビット2=はSCCPを正常にしました。| | | | | ビット3=はISUPを正常にしました。| | +------------------------------------------------------------------+
Table 28: Message Data Structure to be used for 'sorp' Primitive
テーブル28: 'sorp'Primitiveに使用されるべきメッセージData Structure
4.5.2 Extended Service Message (xsrv)
4.5.2 拡張業務報(xsrv)
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).
Extended Service、'xsrv'、opcodeは、それぞれの新しいサービスタイプが特定されて、加えられるとき新しいopcodeを定義する必要はなくてこのプロトコルの今後の改正で他のタイプの業務用輸送を輸送する('sccp'、'isot'、'mtp3'、および'saal'を超えて)手段を提供するために土台を作るためにTALI2.0プロトコルに追加されます。 それらが加えられるとき、PRIMITIVE分野は唯一それぞれの新しいサービスタイプを特定するでしょう。 思い描かれて、TALI NEx-FEx状態のどれかでそのいくつかの'xsrv'メッセージを受け取って、処理できます、NEA- FEA状態(TALIのバージョン1.0のServiceデータなどの)である他の'xsrv'メッセージを受け取って、処理できるだけですがことです。
Sprague, et al. Informational [Page 92] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[92ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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.
このリリースにはこのopcodeのために定義されたどんな特定のPRIMITIVESもありません。 いくつかの新しいサービスメッセージが将来加えられると予想されます。 このopcodeは新しいサービスデータ型の組分けに備えます。
+------------------------------------------------------------------+ | 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 | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'xsrv'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 断固とするために| +------------------------------------------------------------------+ | 14.. | メッセージ| 断固とするために| | 2000 | データ| | +------------------------------------------------------------------+
4.5.3 Special Message (spcl)
4.5.3 特別教書(spcl)
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.
Special Message、'spcl'、opcodeは、ベンダーが特殊業務を実装が同じ特殊業務を実装する他の設備に関連づけられるときだけ活性化するそれらのTALI実装に組み込む方法を提供するためにTALI2.0プロトコルに追加されます。 TALI NEx-FEx州のいずれでも'spcl'メッセージを受け取って、処理できます。 このopcodeがだれにとって、TALIセッションが接続されているかに関する詳しい情報を発見して、遠端でベンダー/実装に基づく特徴を可能にする手段を提供する一般的な手段を提供することを意図します。
As part of the 2.0 specification, 4 primitives are initially defined for this opcode:
2.0仕様の一部と、4つの基関数が初めは、このopcodeのために定義されます:
* 'smns' - Special Messages Not Supported. * 'qury' - Query. * 'rply' - Reply. * 'usim' - UnSolicited Information Message.
* 'smns'--サポートされなかった特別教書。 * 'qury'--質問します。 * 'rply'--返答してください。 * 'usim'--求められていない情報メッセージ。
Additional primitives can be added in future versions of the TALI protocol.
TALIプロトコルの将来のバージョンで追加基関数を加えることができます。
Sprague, et al. Informational [Page 93] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[93ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | 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 | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'spcl'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 'smns'--サポートされなかった特別教書| | | | 'qury'--質問| | | | 'rply'--返答してください。| | | | 'usim'--UIM(求められていない情報msg)| +------------------------------------------------------------------+ | 14..X| データ| ベンダーに依存しています。| +------------------------------------------------------------------+
4.5.3.1 Special Messages Not Supported (smns)
4.5.3.1 サポートされなかった特別教書(smns)
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'PRIMITIVEがある'spcl'メッセージへの応答としてこのメッセージを送ります。 Far Endに、'spcl'メッセージをサポートしないのを知って欲しく、将来それらを受けたがっていないとき、ノードはこのメッセージを出すかもしれません。
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'smns' | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'spcl'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 'smns'| +------------------------------------------------------------------+
4.5.3.2 Query Message (qury)
4.5.3.2 質問メッセージ(qury)
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'.
接続の遠い終わりにこのメッセージをQueryに送ることができます(ie: VENDOR、TALIバージョン、または他の特徴に関する詳しい情報を見つけるようにしてください)。 それぞれの2.0実装が'rply'で'qury'に応じると予想されます。
Sprague, et al. Informational [Page 94] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[94ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'qury' | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'spcl'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 'qury'| +------------------------------------------------------------------+
4.5.3.3 Reply Message (rply)
4.5.3.3 応答メッセージ(rply)
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'メッセージはTALI2.0実装がさらに詳細にそれ自体を特定する方法を提供します。 回答に含まれていた情報は:
* PEC - a 2 byte field that identifies the vendor for the TALI
implemenation.
* PEC--TALI implemenationのためにベンダーを特定する2バイトの分野。
* Version Number - a 12 byte field that identifies the TALI version
of the implementation.
* バージョンNumber--実装のTALIバージョンを特定する12バイトの分野。
* Other Vendor Specific Data - the format of any remaining data that
a particular vendor wants to provide is specific to each vendor.
* 他のVendor Specific 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 | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'spcl'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 'rply'| +------------------------------------------------------------------+ | 14..15 | 胸筋| 私企業コード*| | | | (ベンダーID番号、整数分野) | +------------------------------------------------------------------+ | 16..27 | バージョン| 'vers xxx.yyy'| | | ラベル| | +------------------------------------------------------------------+ | 28..? | 他のベンダー| それぞれに特定の自由なFormatデータ領域| | | 特定| ベンダー| | | データ| | +------------------------------------------------------------------+
Sprague, et al. Informational [Page 95] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[95ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
*See Table 4 for details on the PEC field.
*PECフィールドに関する詳細に関してTable4を見てください。
4.5.3.4 Unsolicited Information Message (USIM)
4.5.3.4 求められていない情報メッセージ(USIM)
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'と同じ情報を提供します。 2.0実装はいつでも、'usim'を送ることができます('qury'に対して'rply'を送るだけであるべきです)。
+------------------------------------------------------------------+ | 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 | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 八重奏| フィールド名| 記述| +------------------------------------------------------------------+ | 0..3 | 同時性| '崖錐'| +------------------------------------------------------------------+ | 4..7 | OPCODE| 'spcl'| +------------------------------------------------------------------+ | 8..9 | 長さ| 長さ| +------------------------------------------------------------------+ | 10..13 | 原始| 'usim'| +------------------------------------------------------------------+ | 14..15 | 胸筋| 私企業コード*| | | | (ベンダーID番号、整数分野) | +------------------------------------------------------------------+ | 16..27 | バージョン| 'vers xxx.yyy'| | | ラベル| | +------------------------------------------------------------------+ | 28..? | 他のベンダー| それぞれに特定の自由なFormatデータ領域| | | 特定| ベンダー| | | データ| | +------------------------------------------------------------------+
4.6 TALI Timers
4.6 崖錐タイマ
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に非ゼロ値を使用するようにほとんどの実装が自分たちを特定したがっていて、これが確実な要件ではなく、aであると予想されます。 2.0として自分を特定するための唯一の要件はコネクション確立の2.0形式に従って少なくとも1'moni'を送ることです。
4.7 TALI User Events
4.7 崖錐ユーザイベント
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(管理戸外、管理は閉じます、と管理が許容します、接続が、接続がなくしたのを確証した管理proh)で定義されたユーザイベントは有効なままで残っています。
Sprague, et al. Informational [Page 96] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[96ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
4.8 TALI States
4.8 崖錐州
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州は有効なままで残っています。
4.9 TALI Version 2.0 State Machine
4.9 崖錐バージョン2.0州のマシン
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).
このセクションはそれぞれのTALI2.0実装がこの仕様で言いなりになるためにあとに続かなければならない州のマシンを提供します。 このドキュメント中で言及されるように、2.0実装は1.0実装へのいくつかの小さい追加に基づいています、そして、それぞれの2.0実装は後方にaで相互コンパチブル・モードを操作しても構わないと思っているに違いありません(1.0実装に関連づけられた2.0実装は1.0の特徴だけまで後ろへ下がらなければなりません)。
4.9.1 State Machine Concepts
4.9.1 州のマシン概念
Before presenting the actual state machine, several concepts are discussed.
実際の州のマシンを贈る前に、いくつかの概念について議論します。
4.9.1.1 General Protocol Rules
4.9.1.1 一般プロトコル規則
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セットの一般的なプロトコル規則は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.
* 遠端のTALIバージョンを決定するのを試みて、2.0実現はどんな受信された'moni'メッセージも処理するべきです。 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).
* 2.0実現は、遠端が1.0実現であるときに2.0opcodesを必要とするメッセージをTALIに送るという内部の要求(ソフトウェアから、それの層による自製品、または装置のための管理インタフェースからの要求である)を拒絶するべきであるか、または無視するべきです。 2.0実現は遠端は処理ができるのを知っているとき新しい2.0opcodes(管理、xsrv、spcl)を必要とするTALIメッセージにそれらのopcodesを送るだけであるべきです('遠い_終わり_バージョン'が2.0以上であるときに)。
Sprague, et al. Informational [Page 97] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[97ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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.0opcodeでTALIメッセージを受け取ると、2.0実現は'遠い_終わり_旗'について査問するべきです。 遠端が2.0以上でないなら、メッセージの到着はプロトコルViolationとして扱われるべきです。 ノードに従って、2.0以上、メッセージは遠端がそうなら処理されるべきです。2.0の能力、または無視されています(ノードが、少しの2.0の機能性も実行しないのを選んだなら)。
4.9.1.2 Graceful Shutdown of a Socket
4.9.1.2 ソケットの優雅な閉鎖
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.
それぞれのソケットの優雅な閉鎖を実行するステップは1.0仕様、セクション3.7.1で.2に提示されました。 それらのステップは2.0の実現のために変えられません。
4.9.1.3 TALI Protocol Violations
4.9.1.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
* 受信されたメッセージの無効のopcode
* 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タイマが期限が切れる前に'テスト'の創作に対応して'異'か'proh'を受けません。
* Receiving Service Messages on a prohibited socket.
* 禁止されたソケットの上にService Messagesを受けます。
* TCP Socket errors - Connection Lost
* TCP Socket誤り--接続Lost
* 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.0opcode('管理'、'xsrv''spcl')でそれ自体が2.0実現であると認識していない遠端から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'出来事のすべてがテーブルの'プロトコルViolation'列に従って処理されます。
4.9.2 The State Machine
4.9.2 州のマシン
Internal Data required for State Machine:
内部のDataが州Machineに必要です:
* boolean sock_allowed. This flag indicate whether the NE is
allowed to carry Service Messages.
* _が許容した論理演算子ソックス。 この旗は、NEがService Messagesを運ぶことができるかどうかを示します。
Sprague, et al. Informational [Page 98] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[98ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
* 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
状態に頭文字をつけてください: ソックス_は=FALSEの遠い_終わり_バージョン=1.0状態=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| +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 状態| OOS|接続| NEP-FEP| NEP-FEA| シビルの部屋-FEP| シビルの部屋-FEA| |出来事| | | | | | | +------------------------------------------------------------------+ |T1 Exp。 | | |テストを送ってください。|テストを送ってください。|テストを送ってください。|テストを送ってください。| | | | |T1を始動してください。|T1を始動してください。|T1を始動してください。|T1を始動してください。| | | | |T2を始動してください。|T2を始動してください。|T2を始動してください。|T2を始動してください。| +------------------------------------------------------------------+ |T2 Exp。 | | | PV| PV| PV| PV| +------------------------------------------------------------------+ |T3 Exp。 | | | PV| PV| | | +------------------------------------------------------------------+ |T4 Exp。 | | |moniを送ってください。|moniを送ってください。|moniを送ってください。|moniを送ってください。| | | | |T4を始動してください。|T4を始動してください。|T4を始動してください。|T4を始動してください。| +------------------------------------------------------------------+ |Rcvテスト| | |prohを送ってください。|prohを送ってください。|異を送ってください。|異を送ってください。| +------------------------------------------------------------------+ |Rcv異| | | T2を止めてください。| T2を止めてください。| T2を止めてください。| T2を止めてください。| | | | | NEP-FEA| | シビルの部屋-FEA| | +------------------------------------------------------------------+ |Rcv proh| | | T2を止めてください。| T2を止めてください。| T2を止めてください。| T2を止めてください。| | | | |快速帆船を送ってください。|快速帆船を送ってください。|快速帆船を送ってください。|または豊富である。| | | | | | NEP-FEP| | コースを変更してください。| | | | | | | |快速帆船を送ってください。| | | | | | | | シビルの部屋-FEP| +------------------------------------------------------------------+ |Rcv快速帆船| | | T3を止めてください。| T3を止めてください。| | | +------------------------------------------------------------------+ |Rcv moni| | |アップデート|アップデート|アップデート|アップデート| | | | |'遠い終わり'|'遠い終わり'|'遠い終わり'|'遠い終わり'| | | | |'バージョン'|'バージョン'|'バージョン'|'バージョン'| | | | |ベース|ベース|ベース|ベース| | | | |moni|moni|moni|moni| | | | |転向者|転向者|転向者|転向者| | | | | monaに| monaに| monaに| monaに| | | | |monaを送ってください。|monaを送ってください。|monaを送ってください。|monaを送ってください。| +------------------------------------------------------------------+
Sprague, et al. Informational [Page 99] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[99ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
|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| | | | |扶養家族|扶養家族|扶養家族|扶養家族| +------------------------------------------------------------------+ |Rcv| | | PV|T3が走るなら| PV|過程| | サービス| | | | 過程| | | | | | | |ほかのPV| | | +------------------------------------------------------------------+ |Rcv管理| | |FE<です。|FE<です。|FE<です。|FE<です。| | | | | 2.0 PV| 2.0 PV| 2.0 PV| 2.0 PV| | | | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+ |Rcv xsrv| | |FE<です。|FE<です。|FE<です。|FE<です。| | | | | 2.0 PV| 2.0 PV| 2.0 PV| 2.0 PV| | | | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+ |Rcv spcl| | |FE<です。|FE<です。|FE<です。|FE<です。| | | | | 2.0 PV| 2.0 PV| 2.0 PV| 2.0 PV| | | | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+ |接続してください、|| T1を始動してください。| | | | | |Estab。 | | T2を始動してください。| | | | | | | | T4を始動してください。| | | | | | | |(非0であるなら)| | | | | | | |_を強打してくださいなら| | | | | | | | 許容されています。| | | | | | | | = 本当| | | | | | | | 異を送ってください。| | | | | | | | テストを送ってください。| | | | | | | | シビルの部屋-FEP| | | | | | | |ほか| | | | | | | | prohを送ってください。| | | | | | | | テストを送ってください。| | | | | | | | NEP-FEP| | | | | +------------------------------------------------------------------+ |接続してください、|| | PV| PV| PV| PV| |失われています。| | | | | | | +------------------------------------------------------------------+ |プロトコル| | |すべてを止めてください。|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。| |Violat。 | | | タイマ| タイマ| タイマ| タイマ| | | | |近く|近く|近く|近く| | | | | ソケット| ソケット| ソケット| ソケット| | | | |接続してください。|接続してください。|接続してください。|接続してください。| | | | | ing| ing| ing| ing| +------------------------------------------------------------------+
Sprague, et al. Informational [Page 100] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[100ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
|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 | +------------------------------------------------------------------+
| 管理。 |開いてください。| | | | | | |開いてください。|ソケット| | | | | | |ソケット|Conne| | | | | | | | cting| | | | | | +------------------------------------------------------------------+ |管理。 | |近く|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。|すべてを止めてください。| |閉鎖| | ソケット| タイマ| タイマ| タイマ| タイマ| |ソケット| |OOS|近く|近く|近く|近く| | | | | ソケット| ソケット| ソケット| ソケット| | | | |OOS|OOS|OOS|OOS| +------------------------------------------------------------------+ |管理。 |ソックス_|ソックス_異、-|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール| |禁止します。|許容します。| = 虚偽で結婚されます。| =を負っています。| =を負っています。| =を負っています。| =を負っています。| |ソケット|教育=| | 誤る| 誤る| 誤る| 誤る| | |誤る| | | |prohを送ってください。|prohを送ってください。| | | | | | |t3を始動してください。|t3を始動してください。| | | | | | | NEP-FEP| NEP-FEA| | | | | | | | | +------------------------------------------------------------------+ |管理。 |ソックス_|ソックス_異、-|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール|_を強打してください、オール| |許容します。|許容します。| = 本当に結婚されます。| =を負っています。| =を負っています。| =を負っています。| =を負っています。| |交通|教育=| | 本当| 誤る| 本当| 本当| | |本当| |異を送ってください。|異を送ってください。| | | | | | | シビルの部屋-FEP| シビルの部屋-FEA| | | +------------------------------------------------------------------+ |ユーザ|廃棄物| 廃棄物| 廃棄物| 廃棄物| 廃棄物| 発信してください。| |部分|データ| データ| データ| データ| データ| データ| |Msgs。 | | | | | | | +------------------------------------------------------------------+ |要求| | |FE<2.0です。|FE<2.0です。|FE<2.0です。|FE<2.0です。| |Txに| | | 無視します。| 無視します。| 無視します。| 無視します。| |管理| | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+ |要求| | |FE<2.0です。|FE<2.0です。|FE<2.0です。|FE<2.0です。| |Txに| | | 無視します。| 無視します。| 無視します。| 無視します。| |xsrv| | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+ |要求| | |FE<2.0です。|FE<2.0です。|FE<2.0です。|FE<2.0です。| |Txに| | | 無視します。| 無視します。| 無視します。| 無視します。| |spcl| | |ほか|ほか|ほか|ほか| | | | | 過程| 過程| 過程| 過程| +------------------------------------------------------------------+
Table 29: TALI 2.0 State Machine
テーブル29: 崖錐2.0州のマシン
Sprague, et al. Informational [Page 101] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[101ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
4.10 TALI 2.0 Specification Limitations
4.10 2.0の崖錐仕様制限
Several limitations with the TALI 2.0 specification are identified. These are considered possible areas for expansion of the protocol in the future:
TALI2.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.
* 未知の、または、サポートされないデータを送付者に返す手段としてopcode、または既存のopcodeの中の新しい基関数を加えることができました。 メッセージの受信機であるときに、データ、実現がオリジナルのTALIメッセージを返したがっているかもしれない内部のデバッグを捨てて、格納することに加えて、送付者は、メッセージが未知、サポートされないか、または不当にフォーマットされていると考えます。
5. Success/Failure Codes
5. 成功/失敗コード
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.
首尾よく完成した誤り#Meaning1Transaction。 2 TALI msgの長さは、rkrp操作3Unsupported'rkrp'操作4Invalid 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(1つのエントリーだけで範囲を分けることができない)より厳密に少なくなければなりません。 12 無効のNCICS。 SIに、適切な範囲とPCタイプであるに違いありません。
Sprague, et al. Informational [Page 102] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[102ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
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 無効のSPLIT値。 SIに、適切な範囲とPCタイプであるに違いありません。 CICSと、よりCICEよりすばらしくいなければならなくなってください。 16 テーブルで自由参入がありません。 17CIC範囲は、重なりますが、既存のエントリーに合っていません。 18 エントリーには、16の協会が既にあります。 テーブルで見つけられなかった変えられるべき19エントリー。 20 新しいエントリーは別のエントリー(変えられるエントリーを重ね合わせますが、どんな他のものも重ね合わせないのが許容されている)を重ね合わせるでしょう。 テーブルで見つけられなかった削除されるべき21エントリー。 22 TUPルーティングキーはANSIネットワークのために支えられません。
6. Security Considerations
6. セキュリティ問題
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の使用は加えられたセキュリティ利益をネットワークにもたらすでしょう。
7. References
7. 参照
[1] Bell Communications Research, Specification of Signaling System
Number 7, GT-246-CORE, Bellcore, Issue 1, December 1994.
[1] ベルコミュニケーションズ・リサーチ、シグナリングシステムNo.7、GT246コア、Bellcoreの仕様は1、1994年12月を発行します。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[3] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[4] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[5] Logical Link Control, IEEE 802.2 and ISO 8802.2
[5] 論理的なリンク制御、IEEE802.2、およびISO8802.2
[6] Carrier Sense Multiple Access with Collision Detection
(Ethernet), IEEE 802.3 and ISO 8802-3 CSMA/CD.
[6] 衝突検出型搬送波検知多重アクセス(イーサネット)、IEEE802.3、およびISO8802-3CSMA/CD。
[7] Virtual LAN, IEEE 802.1 Q and ISO 8802-1Q CSMA/CD.
[7]バーチャルLAN、IEEE802.1Q、およびISO8802-1Q CSMA/CD。
[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] ベルコミュニケーションズ・リサーチ、気圧の高速シグナリングリンク(HSLs)を支えるCCSノードのための一般的な要件(GR2878コア)は1を発行します、Bellcore、1995年11月。
Sprague, et al. Informational [Page 103] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[103ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
[9] Bell Communications Research, Asynchronous Transfer Mode (ATM)
and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE,
Bellcore.
[9] ベルコミュニケーションズ・リサーチ、非同期通信モード(気圧)、および気圧適合は(AAL)プロトコル、1113年のGRコア、Bellcoreを層にします。
[10] American National Standards Institute, B-ISDN Signaling ATM
Adaptation Layer - Service Specific Connection Oriented Protocol
(SSCOP), T1.637.
[10]American National Standards Institut、B-ISDNシグナリング気圧適合層--T1.637、サービスの特定の接続はプロトコル(SSCOP)を適応させました。
[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] American National Standards Institut、B-ISDNシグナリング気圧適合は層にされます--ネットワーク・ノードインタフェース(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] American National Standards Institut、B-ISDNシグナリング気圧適合は層にされます--NNI、T1.652のSAALのための層の管理。
8. Acknowledgments
8. 承認
The authors would like to thank Ken Morneault for his comments and contributions to the document.
作者はドキュメントへの彼のコメントと貢献についてケンMorneaultに感謝したがっています。
Sprague, et al. Informational [Page 104] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[104ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
9. Authors' Addresses
9. 作者のアドレス
David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com
デヴィッドスプレーグTekelec5200パラマウントPkwy。 Morrisville、NC 27560は以下に電話をします。 +1 919-460-5563 メールしてください: david.sprague@tekelec.com
Dan Brendes Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-2162 EMail: dan.brendes@tekelec.com
ダンBrendes Tekelec5200パラマウントPkwy。 Morrisville、NC 27560は以下に電話をします。 +1 919-460-2162 メールしてください: dan.brendes@tekelec.com
Robby Benedyk Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5533 EMail: robby.benedyk@tekelec.com
ロビーBenedyk Tekelec5200パラマウントPkwy。 Morrisville、NC 27560は以下に電話をします。 +1 919-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
ジョーケラーTekelec5200パラマウントPkwy。 Morrisville、NC 27560は以下に電話をします。 +1 919-460-5549 メールしてください: joe.keller@tekelec.com
Sprague, et al. Informational [Page 105] RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
スプレーグ、他 情報[105ページ]のRFC3094Tekelecの輸送アダプター層のインタフェース2001年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Sprague, et al. Informational [Page 106]
スプレーグ、他 情報[106ページ]
一覧
スポンサーリンク
