📄 rfc3094.txt
字号:
v | | |
+---------+ +-----------------+ +-----------+ +------------+
| Received| | Connection est. | | Protocol | | T1 Expired |
| 'test' | | Connection lost | | Violation | | T2 Expired |
| 'allo' | | | | | | T3 Expired |
| 'proh' | +-----------------+ +-----------+ | T4 Expired |
| 'proa' | ^ ^ +------------+
| 'moni' | | | ^
| 'mona' | | | |
| or | | | |
| Service | | | |
| Message | +========================================+
+---------+ | IMPLEMENTATION |
^ | DEPENDENT |
| +========================================+
|
v
+============+
| PEER |
| |
+============+
Figure 5: Overview of Inputs to the TALI 1.0 State Machine
Sprague, et al. Informational [Page 17]
RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
3. TALI Version 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.
3.1 Overview of the TALI Message Structure
Table 2 provides a summary of the messages and message structure used
in TALI version 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 |
+------------------------------------------------------------------+
Table 2: Message Structure for TALI 1.0
Table 3 indicates the valid values of the LENGTH field for each
version 1.0 opcode. The LENGTH field is always an indication of the
# of bytes contained in the DATA PAYLOAD portion of a general TALI
message.
Sprague, et al. Informational [Page 18]
RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
+------------------------------------------------------------------+
| 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) |
Sprague, et al. Informational [Page 19]
RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
| | | octets of SSCOP trailer is added |
| | | to the message. The SSCOP trailer|
| | | bytes are also included in the |
| | | length. |
+------------------------------------------------------------------+
Table 3: Valid Length Fields for Each Opcode in TALI 1.0
3.1.1 Types of TALI Fields
Several field types are used in the general TALI message structure.
+------------------------------------------------------------------+
|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 |
Sprague, et al. Informational [Page 20]
RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
| | via a 'mtp3' opcode, the DATA PAYLOAD begins with |
| | the SIO byte of the MTP3 routing label. The |
| | structure for the entire DATA PAYLOAD is governed |
| | by the MTP3 message structure defined in [1]. |
+------------------------------------------------------------------+
|X byte | * ASCII text fields of sizes other than 4 bytes |
|ASCII text | should be supported according to the same rules |
| | presented for the 4 byte ASCII text fields. For |
| | instance, an 8 byte string such as 'ab01cd23' could|
| | be used, where the 'a' would be the first byte of |
| | the field transmitted out the wire. |
+------------------------------------------------------------------+
Table 4: Implementation Notes for each Type of TALI field
3.2 Detailed TALI Message Structure
3.2.1 TALI Peer to Peer Messages
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.
3.2.1.1 Test Message (test)
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.
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'test' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
Sprague, et al. Informational [Page 21]
RFC 3094 Tekelec's Transport Adapter Layer Interface April 2001
3.2.1.2 Allow Message (allo)
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.
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'allo' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
3.2.1.3 Prohibit Message (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.
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proh' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
3.2.1.4 Prohibit Acknowledgement Message (proa)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -