4.3.1 Generating Protocol Violations based on Received Messages
As implied by some of the bullets before Table 9, it is a goal of the
2.0 TALI specification to relax some of the error checking associated
with the processing of received TALI messages.
Version 1.0 of this specification was very strict in detailing the
fields that were checked for each received message. As each received
message was processed, the SYNC code, opcode and length field of the
message was checked; if any of these fields were invalid an internal
protocol violation was generated. The processing of the protocol
violation caused the socket to go down. In addition to the 3
specific checks (sync, opcode, length), the overall philosophy of
version 1.0 was to treat any received data that the receiver did not
understand, or which the receiver deemed to contain incorrectly coded
fields as protocol violations.
Version 2.0 introduces the possibility of partial support for
opcodes, partial support for primitives, and partial support for
various fields (such as support for ANSI Pt Codes, but not ITU Pt
Codes). Thus, the overall philosophy of how to treat received data
that the receiver does not support needs to be relaxed from the
-------------------------------------------------------------[Page 54]
strict treatment in version 1.0. Version 2.0 implementations should
be more tolerant when they receive messages they do not support (or
which they believe contain incorrectly coded fields). This tolerance
should include NOT treating these receives as protocol violations.
Version 2.0 implementations should perform the following level of
strict/loose checks on the received messages:
* Checks against the sync codes, opcodes and lengths for version 1.0
and version 2.0 opcodes should be performed (against Table 3 and
Table 11). Invalid data in these fields should be treated as
cause for protocol violations.
* Checks against the opcode field for messages with new 2.0 opcodes
(mgmt/xsrv/spcl) should be performed to determine whether the
message can be processed by the implementation. If an
implementation chooses to NOT support a particular 2.0 opcode, the
received message should be discarded, internal data (such as
measurements, logs of messages, user notifications) could record
the event, and the TALI state should NOT be affected.
* Checks against the primitive field for messages with new 2.0
opcodes (mgmt/xsrv/spcl) should be performed to determine whether
the message can be processed by the implementation. If an
implementation does not understand a particular primitive, or has
chosen NOT to implement the features for a particular primitive,
the received message should be discarded, internal data (such as
measurements, logs of messages, user notifications) could record
the event, and the TALI state should NOT be affected.
* Checks against other field types in messages with new 2.0 opcodes
(such as checking the encoding of a Point Code field for a valid
Pt Code type) should also be performed in a 'soft' manner. Errors
found in individual fields should cause the received message to be
discarded, internal data (such as measurements, logs of messages,
user notifications) could record the event, and the TALI state
should NOT be affected.
The goals behind introducing this gentler treatment of errors in
received data are as follows:
* To keep the socket up in order to perform the primary purpose of
the connection (ie: to continue to transport SS7 data) in spite of
improperly formatted/unsupported TALI messages related to other
features/extensions/etc.
-------------------------------------------------------------[Page 55]
* To allow applications to support and use some of the features for
a particular TALI revision without requiring the application to
implement all of the functionality for the TALI revision.
* To increase the extensibility of the protocol. Looser receive
checks are preferred in order to be able to add new primitives and
new primitive operations as they are defined.
4.4 Overview of the TALI Message Structure
The basic message structure for all TALI messages is unchanged with
the addition of new 2.0 opcodes. The base TALI header still consists
of SYNC + OPCODE + LENGTH, as described in Table 2.
The message structure for the new 2.0 opcodes was shown in Table 9.
These messages define an extra required field, PRIMITIVE, that
follows the LENGTH field of Table 2.
4.4.1 Types of TALI Fields
Table 4 in the version 1.0 specification provided implementation
notes for all the 'types of fields' found in the 1.0 specification.
Version 2.0 of TALI continues to use all of the types provided in
Table 4, and also defines some new fields that are used in TALI
messages that use the new 2.0 opcodes. The following table
introduces the new field types that are introduced with version 2.0.
The types in Table 10 are used in addition to the types in Table 4 to
implement the 2.0 TALI protocol.
-------------------------------------------------------------[Page 56]
+-----------+------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|SS7 Point | Used to transmit point code information for ANSI or |
|Code | ITU variants of point codes across the TALI interface|
| | * The point code structure is 4 bytes. Byte 3 is used|
| | to identify the TYPE of point code. The actual |
| | point code is then encoded in bytes 0-2 (w/byte 0 |
| | being the least significant byte and the first byte|
| | transmitted across the wire) |
| | * Byte 3: encoding of the type of point code (PC) |
| | 0 = an ANSI Full PC |
| | 1 = an ITU International Full PC w/ a 3/8/3 coding |
| | scheme for zone/area/identifier |
| | 2 = an ITU National Full PC w/ a raw 14 bit PC |
| | 3 = unused |
| | 4 = an ANSI Cluster PC |
| | * For ANSI Full PC w/byte 3=0. These point codes are|
| | 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = Member |
| | * For ITU International Full PC (3/8/3) w/byte 3=1. |
| | These point codes use 14 bits (stored in the 14 |
| | least significant bits in bytes 0&1). Byte 2 is |
| | unused. The 14 bits should be interpreted as 3 |
| | bits of zone, 8 bits of area and 3 bits of |
| | signaling point identifier. The 3 bits of |
| | signaling point identifier are the 3 least |
| | significant bits. |
| | * For ITU National Full PC w/byte 3=2. These point |
| | codes use 14 bits (stored in the 14 least |
| | significant bits in bytes 0&1). Byte 2 is unused. |
| | The 14 bits represent a single 14-bit quantity that|
| | constitutes the point code. |
| | * For unused w/byte 3=3. Bytes 0 through 2 are |
| | undefined. |
| | * For ANSI Cluster PC, w/byte 3=4. These point codes|
| | are 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = 0. This field is ignored and should be |
| | coded as 0...all members of the cluster are implied|
| | * Byte 0 is the first byte that is transmitted across|
| | the wire, followed by byte 1, byte 2, then byte 3. |
-------------------------------------------------------------[Page 57]
+------------------------------------------------------------------+
|Bit-Field | * Field containing an array of N bits, where N is a |
| | multiple of 8. Bit-Field types should be |
| | transmitted such that the byte containing bits 0 |
| | through 7 is transmitted across the wire first, |
| | followed by the byte containing bits 8 through 15, |
| | etc. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor need|
| | to be dealt with in the software). |
+------------------------------------------------------------------+
|Version |A TALI version label is a 12 byte ASCII text field. |
|Label |The label is of a format 'vers xxx.yyy', where xxx.yyy|
| |are used to identify the version such as 002.000. As |
| |with other ASCII text fields, the first byte of the |
| |text field (the 'v') should be the first byte |
| |transmitted out the wire. |
+------------------------------------------------------------------+
|Primitive |Messages that use the new TALI 2.0 opcodes all have a |
| |4 byte text ASCII field referred to as a Primitive. |
| |The Primitive acts as a modifier for the opcode. This |
| |allows a single opcode to be used to perform multiple |
| |actions. |
+------------------------------------------------------------------+
|Primitive |A Primitive can be used to specify either a specific |
|Operation |action or a set of actions. When the Primitive field |
| |is used to specify a set of actions, an operation |
| |field is used to pick a specific operation within that|
| |group of actions. Operation fields are 4 byte integers|
+------------------------------------------------------------------+
|Private |Various RFC documents have detailed a set of assigned |
|Enterprise |numbers (RFC 1700, Assigned Numbers) and defined data |
|Code |structures (RFC 1155, Structure and Identification of |
|(PEC) |Management Information for IP-based Internets) |
| |that are used on IP networks to provide network |
| |management information. |
| |Network Management Object Identifiers (OID) are used |
| |to recognize specific organizations, companies, |
| |protocols, and so on, in a manner that all vendors can|
| |agree on. |
| |An Object Identifier exists which uniquely describes |
| |each company that does business in the data/telecomm |
| |industry. That OID is referred to as an 'SMI Network |
| |Management Private Enterprise Code', which we are |
| |shortening to Private Enterprise Code of PEC in this |
| |document for simplicity. Each PEC is assumed to have |
-------------------------------------------------------------[Page 58]
| |a defined prefix of |
| |'iso.org.dod.internet.private.enterprise' or |
| |(1.3.6.1.4.1). |
| | |
| |The PEC for each company can be found via a file at: |
| |ftp://ftp.isi.edu/in-notes/iana/assignments/ |
| | enterprise-numbers |
| | |
| |To encode the PEC for a vendor in each implementation |
| |of TALI, a 2 byte integer field is used. The contents|
| |of the integer field should match the PEC code for |
| |that company in the file mentioned above. |
| | |
| |For example, Tekelec, which has a PEC of 323, will |
| |code this 2 byte field as '0x0143'. |
| | |
| |Like other integer fields, the PEC value is |
| |transmitted Least Significant Byte first across the |
| |ethernet wire. |
+------------------------------------------------------------------+
Table 10: Implementation for new field types introduced in TALI 2.0
4.5 Detailed TALI Message Structures for New 2.0 Opcodes
The message structures for opcodes defined in version 1.0 of TALI are
unchanged from the information presented earlier, with the exception
of the 'moni' message. The 2.0 format for the 'moni' message was
described earlier.
Detailed message structures, and discussion of the capabilities, for
each of the new 2.0 opcodes is provided in the following sections.
Before discussing each opcode individually, Table 11 provides the
minimum and maximum value of the LENGTH field that should be
supported for each new opcode (as well as 'moni/mona'). Table 11
additionally shows the impact of ITU support that was added in 2.0.
The routing label for ITU point codes only uses 4 octets instead of 7
octets as ANSI requires.
-------------------------------------------------------------[Page 59]
+------------------------------------------------------------------+
| Opcode | Valid Length | Comments |
| | Field Values | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | The overall length of the data portion |
| | | for 'moni' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | The overall length of the data portion |
| | | for 'mona' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mgmt | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| xsrv | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| spcl | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| sccp | 9-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT MSUs. |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| mtp3 | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 60]
| saal | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
| | | Seven (7) octets of SSCOP trailer is |
| | | added to the message. The SSCOP trailer |
| | | bytes are also included in the length. |
+------------------------------------------------------------------+
Table 11: Valid Length Fields for Opcodes Affected by TALI 2.0
4.5.1 Management Message (mgmt)
The 'mgmt' opcode is intended to allow Management data, or data that
will manage the operation of the device, to pass between the TALI
endpoints over the socket connection. 'mgmt' messages can be
received and processed in any of the TALI NEx-FEx states. Three
PRIMITIVES are defined for use with this opcode:
* 'rkrp' - Routing Key Registration Primitive. This primitive
allows the nodes to configure the SS7 traffic streams that they
wish to receive over each socket. This 'routing key registration'
is performed in-band, via TALI messages.
* 'mtpp' - MTP3 Primitives. This primitive allows SS7 MTP3 network
management messages regarding the (un)availability and congestion
states of SS7 devices to be passed to the IP devices SG.
* 'sorp' - Socket Options Registration Primitive. This primitive
allows various socket options to be enabled/disabled by each TALI
device.
As of version 2.0, the only defined primitives for the 'mgmt' opcode
are 'rkrp', 'mtpp', and 'sorp'. In the future, more primitives can
be added to this opcode to extend the Management capabilities of the
SG or IP devices. The basic message structure for the 2.0 'mgmt'
messages for all 3 of these primitives is as follows:
-------------------------------------------------------------[Page 61]
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp', 'mtpp' or 'sorp' Each of these |
| | | primitives specify a group of applicable |
| | | management operations. |
+------------------------------------------------------------------+
| 14..17 | Primitive | The operation field specifies the one |
| | Operation | operation within the group of operations |
| | | identified by the primitive. |
+------------------------------------------------------------------+
| 18.. | Message | The content of the message data area is |
| | Data | dependent on the combination of opcode/ |
| | | primitive/operation fields. Each of those|
| | | combinations could use a different message|
| | | data structure. |
+------------------------------------------------------------------+
Table 12: Message Structure for 'mgmt' opcode
4.5.1.1 Routing Key Registration Primitive (rkrp)
The 'rkrp' primitive allows IP nodes to modify the application
routing key table in the SG by sending TALI messages to configure the
SS7 traffic streams that they wish to receive over each socket. This
'routing key registration' is performed in-band, via TALI messages,
as an alternative to using the SG user interface to configure the
routing keys.
Recall from earlier discussion in this document that the
specification supports five (5) types of fully specified routing
keys:
* A key for SCCP traffic, where key = DPC-SI-SSN, where SI=3.
* A key for ISUP traffic, where key = DPC-SI-OPC-CIC Range, where
SI=5. The CIC values for traditional ISUP are 14 bit quantities
in ANSI networks and 12 bit quantities in ITU networks.
* A key for TUP traffic, where key = DPC-SI-OPC-CIC Range, where
SI=4. This key is only supported for ITU networks. The CIC
values for TUP keys are 12 bit quantities in ITU networks.
-------------------------------------------------------------[Page 62]
* A key for QBICC traffic (an extension of ISUP which uses 32 bit
CIC codes), where key = DPC-SI-OPC-CIC, where SI=13. The CIC
values for QBICC keys are 32 bit quantities for ANSI and ITU
networks.
* A key for OTHER-MTP3-SI (non-SCCP, non-ISUP, non-QBICC for ANSI
and non-SCCP, non-ISUP, non-QBICC, non-TUP for ITU) traffic, where
key = DPC-SI
Each of these keys is fully specified key where the exact content of
the MSU to be routed must match the data in the routing key.
Extensions to the routing keys have been added that will support
'partial match' or 'default' routing keys. The purpose of these
extensions is to improve the handling of MSU traffic when no fully
specified routing key exists that matches the MSU. Partial match and
default routing keys are used when the SG can not find a fully
specified routing key that can be used to route an MSU. Partial
match keys can be used to provide closest-match routing such as
'ignore the CIC' for ISUP/QBICC/TUP traffic, or 'ignore the SSN' for
SCCP traffic. Default keys are used when no full or partial routing
key has been found as a last resort destination to route the MSU to.
The types of partial and default keys defined by the protocol are
discussed in the following table. The 4th column in the table
indicates the data structure that is used in the TALI rkrp message to
perform operations on each partial/default key type. Note: The order
of the keys in the table (from top to bottom) matches the
hierarchical search order that an SG will use to attempt to find a
routing key to use for an MSU. The partial and default keys are only
used after attempting to find a fully specified key that matches the
MSU.
-------------------------------------------------------------[Page 63]
+--------+------------+--------------------------------+-----------+
|Key | Key | Comments | Cross |
|Type | Attributes | | Reference |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI-OPC |Used as backup routes for CIC | 4.5.1.1.2 |
| | |based traffic (but ignoring the | |
| | |CIC field). | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI |Used as backup routes for CIC | 4.5.1.1.4 |
| | |based or SCCP traffic (but | |
| | |ignoring the OPC-CIC or SSN). | |
| | |Routes traffic based solely on | |
| | |DPC and SI of the MSU. | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the DPC field. | |
+--------+------------+--------------------------------+-----------+
|Partial | SI |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the SI field. | |
+--------+------------+--------------------------------+-----------+
|Default | - |If no other type of routing key | 4.5.1.1.5 |
| | |for an MSU can be found, use | |
| | |this one. | |
+--------+------------+--------------------------------+-----------+
Table 13: Partial and Default Routing Keys (in hierarchical order)
The specific capability requested in each 'rkrp' message is indicated
via an 'RKRP Operation' field. These capabilities include:
* ENTER: The ENTER operation creates an association between a
specific socket and a specific application routing key. The
socket of the association is always the socket that the 'rkrp' was
received on. The application routing key identifies an SS7
traffic stream that should be carried over that socket. Multiple
sockets can be associated with the same application routing key,
if so, they all receive traffic in a 'load sharing' mode. An
override field can be used to remove any other socket associations
for a particular routing key and add a single socket association.
The ENTER operation is applicable for fully specified SCCP keys,
CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and
all types of partial keys and to the default routing key.
* DELETE: The DELETE operation deletes an association between a
specific socket and a specific application routing key. The
socket of the association is always the socket that the 'rkrp' was
-------------------------------------------------------------[Page 64]
received on. Other socket associations for the same application
routing key are NOT affected by the deletion. When the last
socket association for a routing key is deleted, the entire
routing key entry is removed from the database. The DELETE
operation operation is applicable for fully specified SCCP keys,
CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and
all types of partial keys and to the default routing key.
* SPLIT: The SPLIT operation is used to convert a single application
routing key into 2 application routing keys that together cover
the same SS7 traffic stream as the original key. Immediately
after a split is performed, both of the resulting entries retain
the same socket associations as the original routing key. When
the split is completed, the socket associations can be modified
for each of the 2 resulting ranges independent of the other range.
The split operation is only applicable to fully specified CIC
based keys (ISUP, QBICC, and TUP). Each fully specified CIC based
key is uniquely identified by the combination of DPC/SI/OPC/CIC
range. The CIC range is a continuous set of numbers from
CICS(start) to CICE(end); the CIC range in the application routing
key corresponds to the CIC value in a CIC based MSU.
* RESIZE: The RESIZE operation is used to modify the CIC range in
for a single application routing key. The resize operation is
only applicable to fully specified CIC based routing keys. The
resize operation replaces the CICS/CICE values for a routing key
with a new CIC range (NCICS/NCICE). A wide variety of NCICS/NCICE
ranges can be supported based on the existing CICS/CICE; just
about the only restriction is that the new range can not already
exist in the database and can not overlap any other entry in the
database. The socket associations for the routing key are NOT
affected by the change in CICS/CICE. The SPLIT operation is
applicable only to fully specified CIC based keys (ISUP, Q.BICC,
and TUP).
The list of RKRP Operations (and their encodings) that are supported
for TALI version 2.0 is as follows:
0x0001 - ENTER ISUP KEY
0x0002 - DELETE ISUP KEY
0x0003 - SPLIT ISUP KEY
0x0004 - RESIZE ISUP KEY
0x0005 - ENTER Q.BICC ISUP KEY
0x0006 - DELETE Q.BICC ISUP KEY
0x0007 - SPLIT Q.BICC ISUP KEY
0x0008 - RESIZE Q.BICC ISUP KEY
0x0009 - ENTER SCCP KEY
0x000A - DELETE SCCP KEY
-------------------------------------------------------------[Page 65]
0x000B - ENTER OTHER-MTP3-SI KEY
0x000C - DELETE OTHER-MTP3-SI KEY
0x000D - ENTER TUP KEY (ITU only)
0x000E - DELETE TUP KEY (ITU only)
0x000F - SPLIT TUP KEY (ITU only)
0x0010 - RESIZE TUP KEY (ITU only)
0x0011 - ENTER DPC-SI-OPC PARTIAL KEY
0x0012 - DELETE DPC-SI-OPC PARTIAL KEY
0x0013 - ENTER DPC-SI PARTIAL KEY
0x0014 - DELETE DPC-SI PARTIAL KEY
0x0015 - ENTER DPC PARTIAL KEY
0x0016 - DELETE DPC PARTIAL KEY
0x0017 - ENTER SI PARTIAL KEY
0x0018 - DELETE SI PARTIAL KEY
0x0019 - ENTER DEFAULT
0x001A - DELETE DEFAULT KEY
0x001B - MULTIPLE REGISTRATION SUPPORT
The message data area of the 'rkrp' messages will differ based on
which RKRP Operation is specified. Several different structures are
used, the correct structure can be identified by the RKRP Operation
field.
In order to simplify the implementation, each of these structures
will define a structure that will support all of the operations
required for the key type. This means that based on the rkrp
operation, some of the fields will be required, and some of the
fields will not be applicable for each RKRP message. Unused fields
should be initialized to 0 by the sender and ignored by the receiver.
4.5.1.1.1 RKRP Data Structures
4.5.1.1.1.1 Common Fields in all RKRP Messages
In the following subsections several different data structures to be
used for various RKRP operations are presented. It should be noted
that each of these data structures has the following fields in
common. The data structure below should begin at byte 14 of the TALI
message as shown in Table 12.
-------------------------------------------------------------[Page 66]
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from in section 5. | |
+------------------------------------------------------------------+
Table 14: Common Fields in ALL 'rkrp' Data Structures
The primary purpose of requiring the data structures for all RKRP
operations to begin with these same fields, is to provide a means for
a receiver to reply to unknown RKRP messages in a consistent manner.
When an implementation receives an RKRP request message it does not
understand, it should turn the request into a reply and use the
success/failure code to indicate that the operation is not supported
(with an RKRP Reply Code of Unsupported rkrp Operation).
It is a requirement that these common fields continue to be used as
new RKRP operations are added to this specification. This will
ensure that the capability described in the previous paragraph will
always exist.
-------------------------------------------------------------[Page 67]
4.5.1.1.1.2 CIC Based Routing Key Operations
The data structure used for 'rkrp' messages related to MSUs which are
CIC based (ISUP, Q.BICC ISUP, and TUP (ITU only)) is as presented in
the next table. The data structure below should begin at byte 14 of
the TALI message as shown in Table 12.
Note 1: The number of bits used in each CIC field will vary based on
the SI and network type.
* ISUP operations (0x0001 - 0x0004) are assumed to use 14 bit CIC
values from the corresponding fields in the structure when DPC/OPC
indicate an ANSI network (12 bits used in ITU networks). Only the
14(12) least significant bits of the 32 bit CIC field will be
used.
* Q.BICC ISUP operations (0x0005 - 0x0008) are assumed to use 32 bit
CIC values from the corresponding fields in the structure.
* TUP operations (0x000d - 0x0010) are assumed to use 12 bit CIC
values from the corresponding fields in the structure when DPC/OPC
indicate an ITU network. Only the 12 least significant bits of
the 32 bit CIC field will be used. TUP operations are not
supported for ANSI networks.
Note 2: This same structure should be used to specify the partial key
= DPC-SI-OPC(ignoreCIC). When specifying a DPC-SI-OPC partial key,
the CIC fields in this structure should be set to 0 by the sender.
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
-------------------------------------------------------------[Page 68]
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 5 for ISUP keys.| |
| | | SI should be 13 for Q.BICC | |
| | | ISUP keys. | |
| | | SI should be 4 for TUP keys. | |
-------------------------------------------------------------[Page 69]
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 4 | OPC | Origination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a OPC that | Code |
| | | identifies the source of the | |
| | | MSU. ISUP routing keys must | |
| | | each specify a single OPC | |
| | | that the application routing | |
| | | key relates to. | |
+------------------------------------------------------------------+
| 4 | CICS | Circuit Identification Code | Integer |
| | | Start. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICS value is the low end of | |
| | | the CIC range. | |
+------------------------------------------------------------------+
| 4 | CICE | Circuit Identification Code | Integer |
| | | End. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICE value is the high end | |
| | | of the CIC range. | |
+------------------------------------------------------------------+
| 4 | SPLIT CIC | The SPLIT field is used on | Integer |
| | | the SPLIT operation to | |
| | | specify where in the existing| |
| | | CIC range (given by CICS/ | |
| | | CICE) an existing routing key| |
| | | should be split into 2 | |
| | | routing keys. To be valid, | |
| | | the following relationship | |
| | | must be true before the SPLIT| |
| | | is performed: | |
| | | CICS < SPLIT <= CICE. | |
-------------------------------------------------------------[Page 70]
| | | After the SPLIT is performed,| |
| | | the 2 routing keys are as | |
| | | follows: | |
| | | CICS to SPLIT-1 | |
| | | SPLIT to CICE | |
+------------------------------------------------------------------+
| 4 | NCICS | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICS specifies | |
| | | the new value that should | |
| | | replace the existing CICS | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
| 4 | NCICE | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICE specifies | |
| | | the new value that should | |
| | | replace the existing CICE | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
Table 15: Message Data Structure CIC based Routing Key Operations
The following table indicates the Required (R), or Not Applicable
(NA) status for each field of the message data structure in Table 15
based on the RKRP Operation field. As mentioned previously, unused
fields (those marked NA) should be initialized to 0 by the sender and
ignored by the receiver.
-------------------------------------------------------------[Page 71]
+------------------------------------------------------------------+
| Operation | ENTER | DELETE | SPLIT | RESIZE | ENTER/DELETE |
| | (ISUP,| (ISUP, | (ISUP,| (ISUP, | PARTIAL DPC |
| | QBICC,| QBICC, | QBICC,| QBICC, | SI OPC KEY |
| Field | TUP) | TUP) | TUP) | TUP) | |
+------------------------------------------------------------------+
| Request/Reply | R | R | R | R | R |
+------------------------------------------------------------------+
| Success/Failure | R | R | R | R | R |
+------------------------------------------------------------------+
| RKRP Flags | R | R | R | R | R |
+------------------------------------------------------------------+
| SI | R | R | R | R | R |
+------------------------------------------------------------------+
| DPC | R | R | R | R | R |
+------------------------------------------------------------------+
| OPC | R | R | R | R | R |
+------------------------------------------------------------------+
| CICS | R | R | R | R | NA |
+------------------------------------------------------------------+
| CICE | R | R | R | R | NA |
+------------------------------------------------------------------+
| SPLIT CIC | NA | NA | R | NA | NA |
+------------------------------------------------------------------+
| NCICS | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
| NCICE | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
Table 16: Required/Not Applicable Fields for CIC based Routing Keys
4.5.1.1.1.3 SCCP Routing Key Operations
The data structure used for 'rkrp' messages related to SCCP routing
keys is presented in the next table. The data structure below should
begin at byte 14 of the TALI message as shown in Table 12.
-------------------------------------------------------------[Page 72]
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
-------------------------------------------------------------[Page 73]
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 3 for SCCP keys.| |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 1 | SSN | SubSystem Number. Each SCCP | Integer |
| | | MSU contains a subsystem | |
| | | number that identifies the | |
| | | SCCP subsystem that should | |
| | | process the MSU. SCCP | |
| | | routing keys must each | |
| | | specify a single SSN that | |
| | | the application routing key | |
| | | relates to. | |
+------------------------------------------------------------------+
Table 17: Message Data Structure SCCP Routing Key Operations
The following table indicates the Required (R), or Not Applicable
(NA) status for each field of the message data structure in Table 17
based on the RKRP Operation field. As mentioned previously, unused
fields (those marked NA) should be initialized to 0 by the sender and
ignored by the receiver.
-------------------------------------------------------------[Page 74]
+--------------------------------------------+
| Operation | ENTER SCCP | DELETE SCCP |
| Field | | |
+--------------------------------------------+
| Request/Reply | R | R |
+--------------------------------------------+
| Success/Failure | R | R |
+--------------------------------------------+
| RKRP Flags | R | R |
+--------------------------------------------+
| SI | R | R |
+--------------------------------------------+
| DPC | R | R |
+--------------------------------------------+
| SSN | R | R |
+--------------------------------------------+
Table 18: Required/Not Applicable Fields for SCCP Routing Keys
4.5.1.1.1.4 DPC-SI, DPC and SI based Routing Key Operations
The data structure used for 'rkrp' messages related to DPC-SI based
(either full keys for non-sccp, non-cic based traffic, or partial
keys for CIC based or SCCP), DPC based (partial key), and SI based
(partial key) operations is as presented in the next table. The data
structure below should begin at byte 14 of the TALI message as shown
in Table 12.
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
-------------------------------------------------------------[Page 75]
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from section 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
+------------------------------------------------------------------+
-------------------------------------------------------------[Page 76]
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
Table 19: Message Data Structure DPC/SI, DPC and SI based Routing
Key Operations
The following table indicates the Required (R), or Not Applicable
(NA) status for each field of the message data structure in Table 19
based on the RKRP Operation field. As mentioned previously, unused
fields (those marked NA) should be initialized to 0 by the sender and
ignored by the receiver.
+-------------------------------------------------------+
| Operation | ENTER/ | ENTER/ | ENTER/ | ENTER/ |
| | DELETE | DELETE | DELETE | DELETE |
| | OTHER | DPC-SI | DPC | SI |
| Field | MTP3 SI | PARTIAL | ONLY | ONLY |
+-------------------------------------------------------+
| Request/Reply | R | R | R | R |
+-------------------------------------------------------+
| Success/Failure | R | R | R | R |
+-------------------------------------------------------+
| RKRP Flags | R | R | R | R |
+-------------------------------------------------------+
| SI | R | R | NA | R |
+-------------------------------------------------------+
| DPC | R | R | R | NA |
+-------------------------------------------------------+
Table 20: Required/Not Applicable Fields for DPC/SI, DPC
and SI based Routing Keys
4.5.1.1.1.5 Default Routing Key Operations
The data structure used for 'rkrp' messages related to entering and
deleting a default routing key is as presented in the next table.
The data structure below should begin at byte 14 of the TALI message
as shown in Table 12.
-------------------------------------------------------------[Page 77]
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
-------------------------------------------------------------[Page 78]
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
Table 21: Message Data Structure for Default Routing Keys
The following table indicates the Required (R), or Not Applicable
(NA) status for each field of the message data structure in Table 21
based on the RKRP Operation field. As mentioned previously, unused
fields (those marked NA) should be initialized to 0 by the sender and
ignored by the receiver.
+-------------------------------------+
| Operation | ENTER | DELETE |
| Field | DEFAULT | DEFAULT |
+-------------------------------------+
| Request/Reply | R | R |
+-------------------------------------+
| Success/Failure | R | R |
+-------------------------------------+
| RKRP Flags | R | R |
+-------------------------------------+
Table 22: Required/Not Applicable Fields for Default Routing Keys
4.5.1.1.1.6 Support for Multiple RKRP Registration Operations
The intent of support for multiple RKRP operations within a single
TALI message (opcode = 'mgmt', primitive = 'rkrp') is to decrease the
message count and byte overhead on network transmission when
performing massive registration sequences.
This functionality is added by 2 mechanisms:
* a new RKRP operation (0X001B, MULTIPLE REGISTRATIONS SUPPORT) is
defined. This operation is meant to be used in a query/reply
manner to determine if the far end supports multiple RKRP
registrations per TALI message before using such capability.
* The basic 'rkrp' message structure is extended to allow multiple
rkrp operations to follow one another in a tali message.
4.5.1.1.1.6.1 Multiple Registrations Support
A new RKRP operation and accompanying data structure are defined to
determine if a far end device supports multiple RKRP registration
operations per TALI message.
-------------------------------------------------------------[Page 79]
The data structure used for the 'multiple registrations support'
operation is as presented in the next table. The data structure
below should begin at byte 14 of the TALI message as shown in Table
12.
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 4 | Operations | This field is used by the | Integer |
| | Per Message | reply to tell the requester | |
| | | the maximum # of RKRP | |
| | | registration operations per | |
| | | TALI message that are | |
| | | supported by the | |
| | | implementation. | |
| | | * This field should be set | |
| | | to 0 when the request/ | |
| | | reply field is set to | |
| | | Request. | |
| | | * This field should be set to| |
| | | the Maximum # of operations| |
| | | per TALI message that a | |
| | | TALI implementation is | |
-------------------------------------------------------------[Page 80]
| | | willing to support when the| |
| | | request/reply field is set | |
| | | to Reply. | |
+------------------------------------------------------------------+
Table 23: Message Data Structure for Multiple Registrations Support
Operation
The following table indicates the Required (R), or Not Applicable
(NA) status for each field of the message data structure above. As
mentioned previously, unused fields (those marked NA) should be
initialized to 0 by the sender and ignored by the receiver.
+-------------------------------------------------+
| Operation | MULTIPLE | MULTIPLE |
| | REGISTRATIONS | REGISTRATIONS |
| | SUPPORT | SUPPORT |
| Field | REQUEST | REPLY |
+-------------------------------------------------+
| Request/Reply | R | R |
+-------------------------------------------------+
| Success/Failure | R | R |
+-------------------------------------------------+
| Operations Per | R | R |
| Message | | |
+-------------------------------------------------+
Table 24: Required/Not Applicable Fields for Multiple Registrations
Support Operation
Next To :: Tekelec's Transport Adapter Layer Interface - Part 4
Credits
-- UnKnown --
|