RFC 3094
Tekelec's Transport Adapter Layer Interface
Pages: 106
Informational
Informational
Part 4 of 4 – Pages 83 to 106
4.5.1.2 MTP3 Primitive (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. 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: * 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. * 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. * 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. * CLUSTER UNAVAILABLE: This primitive operation announces that an entire Cluster of SS7 Point Codes (ex: 10-10-*) are Unavailable (ie: the SG has NO route available to send traffic for any of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with. * CLUSTER AVAILABLE: This primitive operation announces that at least 1 SS7 Point Code within a cluster is Available (ie: the SG
has SOME route available to send traffic for at least 1 of the
destinations in that cluster). The PT CODE field indicates which
SS7 Cluster Pt Code this operation is concerned with.
* 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.
* 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.
* 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.
* 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.
* 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.
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.
+------------------------------------------------------------------+ | Octets | Field Name | Description | Field Type | +------------------------------------------------------------------+ | 2 | MTPP | Identifies which 'mtpp' | Integer | | | Operation | operation/capability is | | | | | provided in this message. | | | | | This integer field uses the | | | | | following encodings: | | | | | 0x0001 = PC Unavailable | | | | | 0x0002 = PC Available | | | | | 0x0003 = Request for PC | | | | | Status | | | | | 0x0004 = Cluster Unavailable | | | | | 0x0005 = Cluster Available | | | | | 0x0006 = Request for Cluster | | | | | Status | | | | | 0x0007 = Congested | | | | | Destination, w/Cong | | | | | Level | | | | | 0x0008 = Request for | | | | | Congestion Status | | | | | 0x0009 = User Part | | | | | Unavailable | | +------------------------------------------------------------------+ | 4 | Concerned | Identifies the SS7 Point Code| SS7 Point | | | Point | that is relevant to the mtpp | Code | | | Code | operation. The mtpp | | | | | operation is concerning this | | | | | point code (or cluster). | | +------------------------------------------------------------------+ | 4 | Source | This field is only used on | SS7 Point | | | Point | the 'Congested Destination' | Code | | | Code | and 'Request for Congestion | | | | | Status' operations. | | | | | * When used in an 'Congestion| | | | | Destination' operation, | | | | | this field contains the Pt | | | | | Code of the Source of the | | | | | traffic that was | | | | | experiencing congestion as | | | | | it made its way to the | | | | | Concerned Pt Code. In | | | | | terms of the original SS7 | | | | | MSUs (the TransFer | | | | | Controlled MSU) that | | | | | provided congestion | | | | | information, the CPC of the| | | | | TFC is the 'Concerned Point| |
| | | Code' of the resulting MTPP| | | | | primitive and the DPC of | | | | | the TFC is the 'Source | | | | | Point Code' of the | | | | | resulting MTPP primitive. | | | | | * When used in an 'Request | | | | | for Congestion Status' | | | | | operation, this field | | | | | indicates which Source Pt | | | | | Code is trying to abate the| | | | | congestion of the concerned| | | | | Pt Code. In terms of the | | | | | original SS7 MSUs (the | | | | | Route Congestion Test MSU) | | | | | that is used to poll for | | | | | congestion, the DPC of the | | | | | RCT is the 'Concerned Point| | | | | Code' of the MTPP primitive| | | | | and the OPC of the RCT is | | | | | the 'Source Point Code' of | | | | | the MTPP primitive. | | +------------------------------------------------------------------+ | 2 | Congestion | This field is used on the | Integer | | | Level | 'Congested Destination' and | | | | | 'Request for Congestion | | | | | Status' operations to | | | | | indicate the congestion level| | | | | of the destination. This | | | | | integer field uses the | | | | | following encodings: | | | | | 0x0000 = Congestion Level 0 | | | | | 0x0001 = Congestion Level 1 | | | | | 0x0002 = Congestion Level 2 | | | | | 0x0003 = Congestion Level 3 | | +------------------------------------------------------------------+ | 2 | Cause Code | This field is used on the | Integer | | | | 'User Part Unavailable' | | | | | operation to indicate the | | | | | Cause Code for why the UPU is| | | | | being sent. This integer | | | | | field uses the following | | | | | encodings: | | | | | 0x0000 = Cause Unknown | | | | | 0x0001 = User Part Unequipped| | | | | 0x0002 = User Part | | | | | Inaccessible | | +------------------------------------------------------------------+
| 2 | User ID | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate which | |
| | | user part is unavailable. The| |
| | | User ID field identifies the | |
| | | type of traffic that was | |
| | | unavailable (0=SNM, 3=SCCP, | |
| | | 5=ISUP, etc). | |
+------------------------------------------------------------------+
Table 26: Message Data Structure for use with the 'mtpp' Primitive
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.
+------------------------------------------------------------------+
| Field | Concerned | Source | Congestion | Cause | User |
| | Point | Point | Level | Code | ID |
| Operation | Code | Code | | | |
+------------------------------------------------------------------+
| PC Unavailable | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| PC Available | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| Request for PC | R | NA | NA | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Unavailable | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Available | | | | | |
+------------------------------------------------------------------+
| Request for | R | NA | NA | NA | NA |
| Cluster Status | | | | | |
+------------------------------------------------------------------+
| Congested | | | | | |
| Destination w/ | R | R | R | NA | NA |
| Cong. Level | | | | | |
+------------------------------------------------------------------+
| Request for | | | | | |
| Congestion | R | R | R | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| User Part | R | NA | NA | R | R |
| Unavailable | | | | | |
+------------------------------------------------------------------+
Table 27: Required/Not Applicable Fields for MTPP Operations
4.5.1.3 Socket Option Registration Primitive (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.
The SORP primitives capabilities that are available to the IP device
in SG are as follows:
* 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.
* 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.
* Reply w/ Current SORP Flag Settings: Used to reply to a poll,
indicating the current bit field settings to the far end.
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:
* 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.
* 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.
* 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
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.
* 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.
* 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.
* 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.
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.
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | SORP | Identifies which 'sorp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = Set SORP Flags | |
| | | 0x0002 = Request Current | |
| | | SORP Flags Settings | |
| | | 0x0003 = Reply w/ Current | |
| | | SORP Flag Settings | |
+------------------------------------------------------------------+
| 2 | SORP Flags | A 4 byte bit-field that uses | Bit-Field |
| | | each bit as an enabled/ | |
| | | disabled flag for a | |
| | | particular socket option. | |
| | | Bit x = 0 indicates the | |
| | | option is DISABLED. | |
| | | Bit x = 1 indicates the | |
| | | option is ENABLED. | |
| | | The assignments for each BIT | |
| | | are as follows: | |
| | | Bit 0 = Broadcast Phase MTPP | |
| | | Primitives | |
| | | Bit 1 = Response Method MTPP | |
| | | Primitives | |
| | | Bit 2 = Normalized SCCP | |
| | | Bit 3 = Normalized ISUP | |
+------------------------------------------------------------------+
Table 28: Message Data Structure to be used for 'sorp' Primitive
4.5.2 Extended Service Message (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).
There are no specific PRIMITIVES defined for this opcode in this release. It is expected that some new service messages will be added in the future. This opcode provides for grouping of the new service data types. +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'xsrv' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | To be determined | +------------------------------------------------------------------+ | 14.. | Message | To be determined | | 2000 | Data | | +------------------------------------------------------------------+4.5.3 Special Message (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. As part of the 2.0 specification, 4 primitives are initially defined for this opcode: * 'smns' - Special Messages Not Supported. * 'qury' - Query. * 'rply' - Reply. * 'usim' - UnSolicited Information Message. Additional primitives can be added in future versions of the TALI protocol.
+------------------------------------------------------------------+ | 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 | +------------------------------------------------------------------+4.5.3.1 Special Messages Not Supported (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. +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'smns' | +------------------------------------------------------------------+4.5.3.2 Query Message (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'.
+------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'qury' | +------------------------------------------------------------------+4.5.3.3 Reply Message (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: * PEC - a 2 byte field that identifies the vendor for the TALI implemenation. * Version Number - a 12 byte field that identifies the TALI version of the implementation. * Other Vendor Specific Data - the format of any remaining data that a particular vendor wants to provide is specific to each vendor. +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'rply' | +------------------------------------------------------------------+ | 14..15 | PEC | Private Enterprise Code * | | | | (Vendor ID Number, Integer Field) | +------------------------------------------------------------------+ | 16..27 | Version | 'vers xxx.yyy' | | | Label | | +------------------------------------------------------------------+ | 28..? | Other Vendor| Free Format data area, specific to each | | | Specific | vendor | | | Data | | +------------------------------------------------------------------+
*See Table 4 for details on the PEC field.4.5.3.4 Unsolicited Information Message (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'). +------------------------------------------------------------------+ | 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 | | +------------------------------------------------------------------+4.6 TALI Timers
Version 2.0 of the TALI specification does not introduce any new timers. The T1-T4 timers defined previously remain in effect. 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.4.7 TALI User Events
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.
4.8 TALI States
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.4.9 TALI Version 2.0 State Machine
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).4.9.1 State Machine Concepts
Before presenting the actual state machine, several concepts are discussed.4.9.1.1 General Protocol Rules
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: * A 2.0 implementation should identify the TALI version it has implemented via the 'moni' message * 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. * 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).
* 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).
4.9.1.2 Graceful Shutdown of a Socket
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.
4.9.1.3 TALI Protocol Violations
Each TALI implementation must detect when violations of the TALI
protocol have occurred and react accordingly. Protocol violations
include:
* Invalid sync code in a received message
* Invalid opcode in a received message
* Invalid length field in a received message
* Not receiving an 'allo' or 'proh', in response to the origination
of a 'test' , before the T2 timer expires
* Receiving Service Messages on a prohibited socket.
* TCP Socket errors - Connection 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.
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.
4.9.2 The State Machine
Internal Data required for State Machine:
* boolean sock_allowed. This flag indicate whether the NE is
allowed to carry Service Messages.
* Far_end_version. This enumeration should track the TALI version
of the far end of the socket.
Initial Conditions:
sock_allowed = FALSE
far_end_version = 1.0
state = OOS
no timers running
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Update |Update |Update |Update |
| | | |'far end |'far end |'far end |'far end |
| | | |version' |version' |version' |version' |
| | | |based on |based on |based on |based on |
| | | |moni |moni |moni |moni |
| | | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-| | | | |tation |tation |tation |tation | | | | |dependent|dependent|dependent|dependent| +------------------------------------------------------------------+ |Rcv | | | PV |If T3 run| PV |Process | | Service| | | | Process | | | | | | | |Else PV | | | +------------------------------------------------------------------+ |Rcv mgmt| | |If FE< |If FE< |If FE< |If FE< | | | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV | | | | |Else |Else |Else |Else | | | | | Process | Process | Process | Process | +------------------------------------------------------------------+ |Rcv xsrv| | |If FE< |If FE< |If FE< |If FE< | | | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV | | | | |Else |Else |Else |Else | | | | | Process | Process | Process | Process | +------------------------------------------------------------------+ |Rcv spcl| | |If FE< |If FE< |If FE< |If FE< | | | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV | | | | |Else |Else |Else |Else | | | | | Process | Process | Process | Process | +------------------------------------------------------------------+ |Connect.| | Start T1 | | | | | |Estab. | | Start T2 | | | | | | | | Start T4 | | | | | | | |(if non-0)| | | | | | | |if sock_ | | | | | | | | allowed | | | | | | | | = TRUE | | | | | | | | send allo| | | | | | | | send test| | | | | | | | NEA-FEP | | | | | | | |else | | | | | | | | send proh| | | | | | | | send test| | | | | | | | NEP-FEP | | | | | +------------------------------------------------------------------+ |Connect.| | | PV | PV | PV | PV | |Lost | | | | | | | +------------------------------------------------------------------+ |Protocol| | |Stop all |Stop all |Stop all |Stop all | |Violat. | | | timers | timers | timers | timers | | | | |Close the|Close the|Close the|Close the| | | | | socket | socket | socket | socket | | | | |Connect- |Connect- |Connect- |Connect- | | | | | ing | ing | ing | ing | +------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|mgmt | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|xsrv | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|spcl | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
Table 29: TALI 2.0 State Machine
4.10 TALI 2.0 Specification Limitations
Several limitations with the TALI 2.0 specification are identified. These are considered possible areas for expansion of the protocol in the future: * 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.5. Success/Failure Codes
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. 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.
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
6. Security Considerations
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.
7. References
[1] Bell Communications Research, Specification of Signaling System
Number 7, GT-246-CORE, Bellcore, Issue 1, December 1994.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[5] Logical Link Control, IEEE 802.2 and ISO 8802.2
[6] Carrier Sense Multiple Access with Collision Detection
(Ethernet), IEEE 802.3 and ISO 8802-3 CSMA/CD.
[7] Virtual LAN, IEEE 802.1 Q and ISO 8802-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.
[9] Bell Communications Research, Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE, Bellcore. [10] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), T1.637. [11] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SSCF at the NNI), T1.645. [12] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, T1.652.8. Acknowledgments
The authors would like to thank Ken Morneault for his comments and contributions to the document.
9. Authors' Addresses
David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com Dan Brendes Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-2162 EMail: dan.brendes@tekelec.com Robby Benedyk Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5533 EMail: robby.benedyk@tekelec.com Joe Keller Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5549 EMail: joe.keller@tekelec.com
Full Copyright Statement
Copyright (C) The Internet Society (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. 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.