RFC 3094
Tekelec's Transport Adapter Layer Interface
Pages: 106
Informational
Informational
Part 3 of 4 – Pages 51 to 83
4.3 Backwards Compatibility
As part of adding new functionality to the TALI specification, backwards compatibility from TALI version 2.0 to version 1.0 is required. Backwards compatibility is important since TALI 2.0 nodes may be connected to far ends that only support version 1.0; it is important that these 2 implementations continue to inter-operate, and that the 2.0 node falls back to supporting only 1.0 opcodes in this situation. The previous section described how a TALI 2.0 implementation can use the 'moni' it sends to identify itself as a 2.0 node and how it can use the 'moni' it receives to determine if the far end is also a 2.0
node. In addition to the discussion in the previous section, the
following bullets provide details regarding how backwards
compatibility must be achieved:
* As documented in the version 1.0 specification, TALI 1.0
implementations that receive TALI messages with 'mgmt', 'xsrv',
and 'spcl' opcodes will treat the message as a Protocol Violation
(invalid opcode received). The Protocol Violation will cause the
socket to be dropped immediately.
* It is therefore required that a 2.0 implementation only send
'mgmt', 'xsrv', and 'spcl' opcodes, after it has used a received
'moni' message to determine that the far end is a 2.0 (or later)
implementation and has identified itself as a 2.0 (or later)
implementation.
* Each TALI 2.0 implementations must use the 'moni' as described in
the previous section to identify themselves as 2.0, and to learn
if the far end is 2.0.
* Each TALI 2.0 implementation should maintain a variable as part of
its state machine, 'far_end_version'. The 'far_end_version'
should be initialized to 1.0 when the socket is established. Each
time a 2.0 implementation receives 'moni', it should update the
'far_end_version' variable. If the 'moni' did not contain a
version label, the 'far_end_version' should be reset to 1.0. If
the 'moni' did contain a version label for 2.0 (or a later
version), the 'far_end_version' should be set accordingly.
* Each time a 2.0 implementation receives a new 2.0 opcode ('mgmt',
'xsrv', and 'spcl') from the far end, it should examine the '
far_end_version'. If the 'far_end_version' indicates the far end
is a 1.0 implementation, the received TALI message should be
treated as a Protocol Violation (invalid opcode). If the
'far_end_version' is 2.0 (or later), the 2.0 implementation should
process the received 'mgmt/xsrv/spcl' according to that nodes
capabilities for that opcode.
* Each time a 2.0 implementation receives a request to send a TALI
message with a 2.0 opcode ('mgmt/xsrv/spcl') from a higher layer
of software, it should examine the 'far_end_version'. If the
'far_end_version' indicates the far end is a 1.0 implementation,
the request to send the 2.0 opcode should be denied or ignored (an
implementation decision) and the 2.0 opcode must NOT be sent to
the far end. If the 'far_end_version' indicates the far end is
2.0 (or later), the request can be satisfied and the TALI message
with the 2.0 opcode can be sent to the far end.
* Each TALI 2.0 implementation can provide a varying level of
support for each of the three new 2.0 opcodes ('mgmt/xsrv/spcl').
In other words, an implementation may wish to only support SOME OF
the primitives within the new opcodes. The level of support for
each 2.0 opcode ('mgmt/xsrv/spcl') is independent of the other two
2.0 opcodes.
* The basic message structure for TALI messages using the new 2.0
opcodes is presented in Table 9.
* The minimal level of support that is required for each of the 2.0
opcodes (mgmt/xsrv/spcl) is to be able to receive TALI messages
with these opcodes, recognize the new opcode, and ignore the
message without affecting the state machine. The TALI state
should not change. The socket connection should stay up. In
other words, a 2.0 implementation can elect to ignore any received
'mgmt/xsrv/spcl' messages, if that implementation does not care to
support the capability intended by that particular opcode.
* A partial level of support for a 2.0 opcode could be implemented.
Partial support may consist of understanding the data structure
for the 2.0 opcode, but only supporting some of the variants of
the opcode. The message structure for each of the new 2.0 opcodes
consists of an extra 'Primitive' field that follows the TALI
opcode and message length fields. Each 'Primitive' is used to
differentiate a variant of the opcode. It is envisioned that each
new 2.0 opcode can be extended by adding new 'Primitives', as more
capabilities are defined for the opcode, without having to add new
TALI opcodes. A 2.0 implementation may understand and be willing
to act on some of the 'Primitives' for an opcode, but not others.
Receiving variants of a 2.0 opcode that an implementation does not
understand need to be ignored and not affect the 2.0 state
machine.
* The full level of support for a 2.0 opcode could be implemented.
This support would consist of understanding and fully supporting
every 'Primitive' within the 2.0 opcode.
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt', 'xsrv' or 'spcl' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (length of the rest | Integer |
| | | of this packet) | |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'wxyz', or a 4 byte text | 4 byte |
| | See note | that is appropriate for the | ASCII |
| | | given opcode | |
+------------------------------------------------------------------+
| 14..X | DATA | The content of the data area | Variable |
| | | is dependent on the opcode/ | |
| | | primitive combination | |
+------------------------------------------------------------------+
Table 9: Basic Message Structure for New 2.0 TALI Opcodes
NOTE: The Primitive field acts as a modifier for each opcode.
Within an opcode, different operations or groups of operations can be
defined and supported. The Primitive identifies each different
operation or set of operations.
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
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.
* 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.
+-----------+------------------------------------------------------+ |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. |
+------------------------------------------------------------------+ |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 |
| |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.04.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.
+------------------------------------------------------------------+ | 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. | +------------------------------------------------------------------+
| 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:
+------------------------------------------------------------------+
| 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.
* 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.
+--------+------------+--------------------------------+-----------+
|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
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
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.
+------------------------------------------------------------------+ | 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.
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. | |
+------------------------------------------------------------------+ | 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. | |
+------------------------------------------------------------------+ | 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. | |
| | | 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.
+------------------------------------------------------------------+ | 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 Keys4.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.
+------------------------------------------------------------------+ | 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 | |
| | | 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.
+--------------------------------------------+
| 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. | |
+------------------------------------------------------------------+ | 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. | | +------------------------------------------------------------------+
| 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.
+------------------------------------------------------------------+ | 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 | |
| | | 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.
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 | |
| | | 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
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:
+------------------------------------------------------------------+
| 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
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.
(page 83 continued on part 4)