4.5.1.1.1.6.2 Multiple RKRP Operations in a Single Message
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:
-------------------------------------------------------------[Page 81]
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length. The length should be set such that|
| | | all (3 in this example) operations are |
| | | accounted for. |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp' |
+------------------------------------------------------------------+
| 14..17 | Primitive | The fisrt operation field identifies a |
| | Operation | specific rkrp operation to be performed. |
| | #1 | |
+------------------------------------------------------------------+
| 18..x | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #1 depends on the message data |
| | #1 | required for rkrp operation #1 |
+------------------------------------------------------------------+
| x+1.. | Primitive | The fisrt operation field identifies a |
| x+4 | Operation | specific rkrp operation to be performed. |
| | #2 | |
+------------------------------------------------------------------+
| x+5..y | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #2 depends on the message data |
| | #2 | required for rkrp operation #2 |
+------------------------------------------------------------------+
| y+1.. | Primitive | The fisrt operation field identifies a |
| y+4 | Operation | specific rkrp operation to be performed. |
| | #3 | |
+------------------------------------------------------------------+
| y+5..z | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #3 depends on the message data |
| | #3 | required for rkrp operation #3 |
+------------------------------------------------------------------+
Table 25: Message Structure for 'mgmt' opcode with multiple
'rkrp' operations in 1 TALI Message
-------------------------------------------------------------[Page 82]
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.
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
-------------------------------------------------------------[Page 83]
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.
-------------------------------------------------------------[Page 84]
+------------------------------------------------------------------+
| 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| |
-------------------------------------------------------------[Page 85]
| | | 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 | |
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 86]
| 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.
-------------------------------------------------------------[Page 87]
+------------------------------------------------------------------+
| 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:
-------------------------------------------------------------[Page 88]
* 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
-------------------------------------------------------------[Page 89]
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.
-------------------------------------------------------------[Page 90]
* 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.
-------------------------------------------------------------[Page 91]
+------------------------------------------------------------------+
| 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).
-------------------------------------------------------------[Page 92]
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.
-------------------------------------------------------------[Page 93]
+------------------------------------------------------------------+
| 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'.
-------------------------------------------------------------[Page 94]
+------------------------------------------------------------------+
| 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 | |
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 95]
*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.
-------------------------------------------------------------[Page 96]
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).
-------------------------------------------------------------[Page 97]
* 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.
-------------------------------------------------------------[Page 98]
* 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|
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 99]
|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 |
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 100]
|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
-------------------------------------------------------------[Page 101]
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.
-------------------------------------------------------------[Page 102]
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.
-------------------------------------------------------------[Page 103]
[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.
-------------------------------------------------------------[Page 104]
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
-------------------------------------------------------------[Page 105]
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.
-------------------------------------------------------------[Page 106]
Credits
-- UnKnown --
|