Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3094

Tekelec's Transport Adapter Layer Interface

Pages: 106
Informational
Part 3 of 4 – Pages 51 to 83
First   Prev   Next

Top   ToC   RFC3094 - Page 51   prevText

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
Top   ToC   RFC3094 - Page 52
   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.
Top   ToC   RFC3094 - Page 53
   *  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.
Top   ToC   RFC3094 - Page 54
   +------------------------------------------------------------------+
   | 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
Top   ToC   RFC3094 - Page 55
   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.
Top   ToC   RFC3094 - Page 56
   *  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.
Top   ToC   RFC3094 - Page 57
   +-----------+------------------------------------------------------+
   |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. |
Top   ToC   RFC3094 - Page 58
   +------------------------------------------------------------------+
   |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 |
Top   ToC   RFC3094 - Page 59
   |           |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.
Top   ToC   RFC3094 - Page 60
   +------------------------------------------------------------------+
   | 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.  |
   +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 61
   | 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:
Top   ToC   RFC3094 - Page 62
   +------------------------------------------------------------------+
   | 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.
Top   ToC   RFC3094 - Page 63
   *  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.
Top   ToC   RFC3094 - Page 64
   +--------+------------+--------------------------------+-----------+
   |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
Top   ToC   RFC3094 - Page 65
      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
Top   ToC   RFC3094 - Page 66
               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.
Top   ToC   RFC3094 - Page 67
   +------------------------------------------------------------------+
   | 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.
Top   ToC   RFC3094 - Page 68
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.  |            |
Top   ToC   RFC3094 - Page 69
   +------------------------------------------------------------------+
   | 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. |            |
Top   ToC   RFC3094 - Page 70
   +------------------------------------------------------------------+
   | 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.     |            |
Top   ToC   RFC3094 - Page 71
   |        |             | 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.
Top   ToC   RFC3094 - Page 72
   +------------------------------------------------------------------+
   |      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.
Top   ToC   RFC3094 - Page 73
   +------------------------------------------------------------------+
   | 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   |            |
Top   ToC   RFC3094 - Page 74
   |        |             | 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.
Top   ToC   RFC3094 - Page 75
              +--------------------------------------------+
              |      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.  |            |
Top   ToC   RFC3094 - Page 76
   +------------------------------------------------------------------+
   | 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.                  |            |
   +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 77
   | 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.
Top   ToC   RFC3094 - Page 78
   +------------------------------------------------------------------+
   | 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   |            |
Top   ToC   RFC3094 - Page 79
   |        |             | 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.
Top   ToC   RFC3094 - Page 80
   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     |            |
Top   ToC   RFC3094 - Page 81
   |        |             |   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:
Top   ToC   RFC3094 - Page 82
   +------------------------------------------------------------------+
   | 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
Top   ToC   RFC3094 - Page 83
   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)

Next Section