Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3094

Tekelec's Transport Adapter Layer Interface

Pages: 106
Informational
Part 4 of 4 – Pages 83 to 106
First   Prev   None

Top   ToC   RFC3094 - Page 83   prevText
4.5.1.2 MTP3 Primitive (mtpp)
The 'mtpp' primitive allows IP nodes to receive status regarding point code (un)availability and congestion levels. These messages provide information similar to the TFP/TFA (TransFer Prohibited and TransFer Allowed), TFC (TransFer Congested) and RCT (Route Congestion Test) messages that are encoded as SS7 SNM (Signaling Network Management) MSUs in traditional SS7 networks. The 'mtp3 primitives' allow this status information to be transferred in-band, via TALI messages, to the IP nodes. The specific information provided in each 'mtpp' message is indicated via an 'MTPP Operation' field. These capabilities provided by the various MTPP Operation fields include: * POINT CODE UNAVAILABLE: This primitive operation announces that an SS7 Point Code is Unavailable (ie: the SG has NO route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with. * POINT CODE AVAILABLE: This primitive operation announces that an SS7 Point Code is Available (ie: the SG has SOME route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with. * REQUEST FOR POINT CODE STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the available/unavailable status of a specific SS7 pt code. For instance, the IP node can poll the SG - Can you send traffic successfully for the destination indicated? The receiver of the request will reply to the request with either a point code available or pt code unavailable primitive respectively. * CLUSTER UNAVAILABLE: This primitive operation announces that an entire Cluster of SS7 Point Codes (ex: 10-10-*) are Unavailable (ie: the SG has NO route available to send traffic for any of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with. * CLUSTER AVAILABLE: This primitive operation announces that at least 1 SS7 Point Code within a cluster is Available (ie: the SG
Top   ToC   RFC3094 - Page 84
      has SOME route available to send traffic for at least 1 of the
      destinations in that cluster).  The PT CODE field indicates which
      SS7 Cluster Pt Code this operation is concerned with.

   *  REQUEST FOR CLUSTER STATUS: This primitive operation provides a
      way for one end of the connection to poll the other end for the
      available/unavailable status of a cluster of SS7 pt codes.  For
      instance, the IP node can poll the SG - Can you send traffic
      successfully for any of the destinations in the cluster?  The
      receiver of the request will reply to the request with either a
      cluster available or cluster unavailable primitive respectively.

   *  CONGESTED DESTINATION: This primitive operation announces that the
      path towards an SS7 Point Code is Congested.  The PT CODE field
      indicates which SS7 Pt Code this operation is concerned with.  The
      CONGESTION LEVEL field indicates the severity of the congestion.

   *  REQUEST FOR CONGESTION STATUS: This primitive operation provides a
      way for one end of the connection to poll the other end for the
      congestion status of an SS7 pt code.  For instance, the IP node
      can poll the SG - Is the path to the specified destination still
      congested?  This request is used to abate congestion towards an
      SS7 destination.

      *  As an implementation note: Upon receiving this request, the SG
         will generate and send a Route Congestion Test (RCT), SS7
         Network Management Message with a priority set to match the
         congestion level in the request.  The RCT is sent towards the
         SS7 destination.  If the SS7 destination is still congested,
         the RCT will result an SS7 Transfer Controlled (TFC) arriving
         back at the SG, which will be converted into a CONGESTED
         DESTINATION primitive and sent on to the IP node.

   *  USER PART UNAVAILABLE: SS7 nodes send User Part Unavailable
      messages when a user part that is mounted on a node is no longer
      available for service.  This primitive operation provides a way
      for an IP Node to receive the same information as the SS7 UPU
      message.

   In order to simplify the implementation, a single data structure is
   defined to be used for all of the 'mtpp' operations.  Depending on
   the 'mtpp operation', some of the fields will be required, and some
   of the fields will not be applicable for each MTPP message.  Unused
   fields should be initialized to 0 by the sender and ignored by the
   receiver.  The data structure used for 'mtpp' messages is as
   presented in the next table.  The data structure below should begin
   at byte 14 of the TALI message as shown in Table 12.
Top   ToC   RFC3094 - Page 85
   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                  | Field Type |
   +------------------------------------------------------------------+
   | 2      | MTPP        | Identifies which 'mtpp'      | Integer    |
   |        | Operation   | operation/capability is      |            |
   |        |             | provided in this message.    |            |
   |        |             | This integer field uses the  |            |
   |        |             | following encodings:         |            |
   |        |             | 0x0001 = PC Unavailable      |            |
   |        |             | 0x0002 = PC Available        |            |
   |        |             | 0x0003 = Request for PC      |            |
   |        |             |          Status              |            |
   |        |             | 0x0004 = Cluster Unavailable |            |
   |        |             | 0x0005 = Cluster Available   |            |
   |        |             | 0x0006 = Request for Cluster |            |
   |        |             |          Status              |            |
   |        |             | 0x0007 = Congested           |            |
   |        |             |          Destination, w/Cong |            |
   |        |             |          Level               |            |
   |        |             | 0x0008 = Request for         |            |
   |        |             |          Congestion Status   |            |
   |        |             | 0x0009 = User Part           |            |
   |        |             |          Unavailable         |            |
   +------------------------------------------------------------------+
   | 4      | Concerned   | Identifies the SS7 Point Code| SS7 Point  |
   |        | Point       | that is relevant to the mtpp | Code       |
   |        | Code        | operation.  The mtpp         |            |
   |        |             | operation is concerning this |            |
   |        |             | point code (or cluster).     |            |
   +------------------------------------------------------------------+
   | 4      | Source      | This field is only used on   | SS7 Point  |
   |        | Point       | the 'Congested Destination'  | Code       |
   |        | Code        | and 'Request for Congestion  |            |
   |        |             | Status' operations.          |            |
   |        |             | * When used in an 'Congestion|            |
   |        |             |   Destination' operation,    |            |
   |        |             |   this field contains the Pt |            |
   |        |             |   Code of the Source of the  |            |
   |        |             |   traffic that was           |            |
   |        |             |   experiencing congestion as |            |
   |        |             |   it made its way to the     |            |
   |        |             |   Concerned Pt Code.  In     |            |
   |        |             |   terms of the original SS7  |            |
   |        |             |   MSUs (the TransFer         |            |
   |        |             |   Controlled MSU) that       |            |
   |        |             |   provided congestion        |            |
   |        |             |   information, the CPC of the|            |
   |        |             |   TFC is the 'Concerned Point|            |
Top   ToC   RFC3094 - Page 86
   |        |             |   Code' of the resulting MTPP|            |
   |        |             |   primitive and the DPC of   |            |
   |        |             |   the TFC is the 'Source     |            |
   |        |             |   Point Code' of the         |            |
   |        |             |   resulting MTPP primitive.  |            |
   |        |             | * When used in an 'Request   |            |
   |        |             |   for Congestion Status'     |            |
   |        |             |   operation, this field      |            |
   |        |             |   indicates which Source Pt  |            |
   |        |             |   Code is trying to abate the|            |
   |        |             |   congestion of the concerned|            |
   |        |             |   Pt Code.  In terms of the  |            |
   |        |             |   original SS7 MSUs (the     |            |
   |        |             |   Route Congestion Test MSU) |            |
   |        |             |   that is used to poll for   |            |
   |        |             |   congestion, the DPC of the |            |
   |        |             |   RCT is the 'Concerned Point|            |
   |        |             |   Code' of the MTPP primitive|            |
   |        |             |   and the OPC of the RCT is  |            |
   |        |             |   the 'Source Point Code' of |            |
   |        |             |   the MTPP primitive.        |            |
   +------------------------------------------------------------------+
   | 2      | Congestion  | This field is used on the    | Integer    |
   |        | Level       | 'Congested Destination' and  |            |
   |        |             | 'Request for Congestion      |            |
   |        |             | Status' operations to        |            |
   |        |             | indicate the congestion level|            |
   |        |             | of the destination.  This    |            |
   |        |             | integer field uses the       |            |
   |        |             | following encodings:         |            |
   |        |             | 0x0000 = Congestion Level 0  |            |
   |        |             | 0x0001 = Congestion Level 1  |            |
   |        |             | 0x0002 = Congestion Level 2  |            |
   |        |             | 0x0003 = Congestion Level 3  |            |
   +------------------------------------------------------------------+
   | 2      | Cause Code  | This field is used on the    | Integer    |
   |        |             | 'User Part Unavailable'      |            |
   |        |             | operation to indicate the    |            |
   |        |             | Cause Code for why the UPU is|            |
   |        |             | being sent.  This integer    |            |
   |        |             | field uses the following     |            |
   |        |             | encodings:                   |            |
   |        |             | 0x0000 = Cause Unknown       |            |
   |        |             | 0x0001 = User Part Unequipped|            |
   |        |             | 0x0002 = User Part           |            |
   |        |             |          Inaccessible        |            |
   +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 87
   | 2      | User ID     | This field is used on the    | Integer    |
   |        |             | 'User Part Unavailable'      |            |
   |        |             | operation to indicate which  |            |
   |        |             | user part is unavailable. The|            |
   |        |             | User ID field identifies the |            |
   |        |             | type of traffic that was     |            |
   |        |             | unavailable (0=SNM, 3=SCCP,  |            |
   |        |             | 5=ISUP, etc).                |            |
   +------------------------------------------------------------------+

    Table 26: Message Data Structure for use with the 'mtpp' Primitive

   The following table indicates the Required (R), or Not Applicable
   (NA) status for each field of the message data structure in Table 26
   based on the MTPP Operation field.  As mentioned previously, unused
   fields (those marked NA) should be initialized to 0 by the sender and
   ignored by the receiver.
Top   ToC   RFC3094 - Page 88
   +------------------------------------------------------------------+
   |          Field  | Concerned | Source | Congestion | Cause | User |
   |                 | Point     | Point  |  Level     | Code  | ID   |
   | Operation       | Code      | Code   |            |       |      |
   +------------------------------------------------------------------+
   | PC Unavailable  | R         | NA     | NA         | NA    | NA   |
   +------------------------------------------------------------------+
   | PC Available    | R         | NA     | NA         | NA    | NA   |
   +------------------------------------------------------------------+
   | Request for PC  | R         | NA     | NA         | NA    | NA   |
   | Status          |           |        |            |       |      |
   +------------------------------------------------------------------+
   | Cluster         | R         | NA     | NA         | NA    | NA   |
   | Unavailable     |           |        |            |       |      |
   +------------------------------------------------------------------+
   | Cluster         | R         | NA     | NA         | NA    | NA   |
   | Available       |           |        |            |       |      |
   +------------------------------------------------------------------+
   | Request for     | R         | NA     | NA         | NA    | NA   |
   | Cluster Status  |           |        |            |       |      |
   +------------------------------------------------------------------+
   | Congested       |           |        |            |       |      |
   | Destination w/  | R         | R      | R          | NA    | NA   |
   | Cong. Level     |           |        |            |       |      |
   +------------------------------------------------------------------+
   | Request for     |           |        |            |       |      |
   | Congestion      | R         | R      | R          | NA    | NA   |
   | Status          |           |        |            |       |      |
   +------------------------------------------------------------------+
   | User Part       | R         | NA     | NA         | R     | R    |
   | Unavailable     |           |        |            |       |      |
   +------------------------------------------------------------------+

      Table 27: Required/Not Applicable Fields for MTPP Operations

4.5.1.3 Socket Option Registration Primitive (sorp)
The 'sorp' primitive allows IP nodes to set various options on a socket by socket basis. This allows the IP node some control over the communication that will occur across the TALI connection. The 'sorp' primitives allows this socket option control to be transferred in-band, via TALI messages, to the IP nodes. The SORP primitives capabilities that are available to the IP device in SG are as follows:
Top   ToC   RFC3094 - Page 89
   *  Set SORP Flags: Used to set the flags bit field.  The receiver of
      this message should store the bit settings indicated in the SORP
      Flag field.

   *  Request Current SORP Flags Settings: Used to poll for the status
      of the bit field options.  The receiver of this message should
      send a Reply w/ Current SORP Flag settings.

   *  Reply w/ Current SORP Flag Settings: Used to reply to a poll,
      indicating the current bit field settings to the far end.

   As of TALI 2.0, each socket option is stored as a bit in a 32 bit
   bit-field.  Each bit in the field indicates the setting for 1 option.
   A bit field with a 0 value indicates the option is DISABLED.  A bit
   field with a 1 value indicates the option is ENABLED.  The following
   options are currently supported:

   *  ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES: Traditional STPs
      send Broadcast Phase TFPs and TFAs to all adjacent nodes when the
      point code availability changes for destinations in the STP's SS7
      routing table.  These Broadcast Phase TFA/TFP SS7 messages are
      converted into TALI mtpp primitives by SG nodes such as the SG.
      The ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES options allow
      each IP node to tell the remote end whether the IP node wants to
      receive the mtpp primitives that result from SS7 broadcast phase
      messages.

      *  As an implementation note: In the SG, each defined socket has a
         flag, 'enable_broadcast_phase_primitives', which is initialized
         to FALSE each time the socket connects.  The IP node should
         send the ENABLE BROADCAST PHASE MESSAGES operation to the SG to
         announce that it wants to receive unsolicited status changes
         for a particular socket.  As the SG is determining where to
         send broadcast phase TFAs/TFPs, it will interrogate the
         'enable_broadcast_phase_primitives' flag for each socket on
         that socket.

   *  ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES: Traditional STPs
      send Response Method TFPs to adjacent nodes when the adjacent
      nodes continue to send MSUs to the STP that can not be delivered
      (ie: the STP has told the adjacent node that a destination is
      Unavailable, but the adjacent node continues to send traffic
      destined for that unavailable DPC to the STP).  These Response
      Method messages are sent in response to MSUs that are received at
      the STP.  These Response Method TFP messages are converted into
      TALI mtpp primitives by SG nodes such as the SG.  The
      ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES options allow each
      IP node to tell the remote end whether the IP node wants to
Top   ToC   RFC3094 - Page 90
      receive the mtpp primitives that result from SS7 response method
      messages.  In addition to response method TFPs, 2 other SS7
      Network Management messages, namely TFCs (transfer controlled) and
      UPUs (user part unavailable), fall into this RESPONSE METHOD
      grouping.  TFCs and UPUs are similar to response method TFPs due
      to the fact that a previous action by the IP Node (sending traffic
      toward some destination) has caused a response method event back
      to the IP Node.  The primary difference between response method
      TFPs versus response method TFCs/UPUs is that the response method
      TFP is converted to an MTPP primitive and sent back to only the
      original socket, while response method TFCs/UPUs may need to be
      replicated to multiple sockets (after being converted to mtpp
      primitives) since there is no way to tell which socket caused the
      response method event.

      *  As an implementation node: In the SG, each defined socket has a
         flag, 'enable_response_method_primitives', which is initialized
         to FALSE each time the socket connects.  The IP node should
         send the ENABLE RESPONSE METHOD MTPP PRIMITIVES operation to
         the SG to announce that it wants to receive response method
         TFPs when appropriate for a particular socket.  Before the SG
         sends a response method TFP (converted to a mtpp primitive)
         back to an IP node, the SG will interrogate the
         'enable_response_method_primitives' flag for that socket and
         only perform the send if the flag allows it.

   *  ENABLE/DISABLE NORMALIZED SCCP: Version 1.0 of TALI specified that
      the 'sccp' TALI opcode must be used on point to multipoint
      connections in order to transmit SCCP MSUs between the SG and IP
      nodes.  When using the 'sccp' opcode, the MTP3 header portion of
      the original SS7 MSU was stripped from the MSU and was NOT part of
      the data transmitted across the TALI connection.  The sender of
      the 'sccp' TALI message was responsible for duplicating the
      DPC/OPC fields from the MTP3 header into appropriate fields in the
      SCCP portion of the message (into the Called/Calling Party Address
      Pt Code fields) before sending as a 'sccp' opcode.  This option
      provides a way to send SCCP MSUs across TALI point to multipoint
      connections that includes the MTP3 header as part of the data
      transmitted, and does NOT involve any modification to the original
      SS7 SCCP MSU.  When the ENABLE NORMALIZED SCCP primitive is
      received, SCCP MSUs should be sent across the TALI interface using
      the 'mtp3' opcode.  This transmission should include the entire
      MTP3 header + the sccp portion of the original MSU.  No
      modification of the original SS7 MSU should occur.  When the
      DISABLE NORMALIZED SCCP primitive is received, SCCP MSUs should be
      sent across the TALI interface using the 'sccp' opcode as
      specified in version 1.0 of TALI.
Top   ToC   RFC3094 - Page 91
   *  ENABLE/DISABLE NORMALIZED ISUP: Version 1.0 of TALI specified that
      the 'isot' TALI opcode must be used on point to multipoint
      connections in order to transmit ISUP MSUs between the SG and IP
      nodes.  When using the 'isot' opcode, the original SS7 MSU,
      including the MTP3 header portion, was transmitted in a 'isot'
      TALI message.  This option indicates that the far end would prefer
      to receive ISUP MSUs using the 'mtp3' TALI opcode as opposed to
      the 'isot' opcode.  When the option is ENABLED, the 'mtp3' opcode
      is used to transmit ISUP MSUs, including the MTP3 header, across
      the TALI connection.  When the option is DISABLED, the 'isot'
      opcode is used as in TALI Release 1.0.

   The data structure used for 'sorp' messages is as presented in the
   next table.  The data structure below should begin at byte 14 of the
   TALI message as shown in Table 12.
Top   ToC   RFC3094 - Page 92
   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                  | Field Type |
   +------------------------------------------------------------------+
   | 2      | SORP        | Identifies which 'sorp'      | Integer    |
   |        | Operation   | operation/capability is      |            |
   |        |             | provided in this message.    |            |
   |        |             | This integer field uses the  |            |
   |        |             | following encodings:         |            |
   |        |             | 0x0001 = Set SORP Flags      |            |
   |        |             | 0x0002 = Request Current     |            |
   |        |             |          SORP Flags Settings |            |
   |        |             | 0x0003 = Reply w/ Current    |            |
   |        |             |          SORP Flag Settings  |            |
   +------------------------------------------------------------------+
   | 2      | SORP Flags  | A 4 byte bit-field that uses | Bit-Field  |
   |        |             | each bit as an enabled/      |            |
   |        |             | disabled flag for a          |            |
   |        |             | particular socket option.    |            |
   |        |             | Bit x = 0 indicates the      |            |
   |        |             |         option is DISABLED.  |            |
   |        |             | Bit x = 1 indicates the      |            |
   |        |             |         option is ENABLED.   |            |
   |        |             | The assignments for each BIT |            |
   |        |             | are as follows:              |            |
   |        |             | Bit 0 = Broadcast Phase MTPP |            |
   |        |             |         Primitives           |            |
   |        |             | Bit 1 = Response Method MTPP |            |
   |        |             |         Primitives           |            |
   |        |             | Bit 2 = Normalized SCCP      |            |
   |        |             | Bit 3 = Normalized ISUP      |            |
   +------------------------------------------------------------------+

     Table 28: Message Data Structure to be used for 'sorp' Primitive

4.5.2 Extended Service Message (xsrv)

The Extended Service, 'xsrv', opcode is added to the TALI 2.0 protocol to lay the groundwork for providing a means to transport other types of service traffic (beyond 'sccp', 'isot', 'mtp3', and 'saal') in future revisions of this protocol without having to define a new opcode as each new service type is identified and added. The PRIMITIVE field will uniquely identify each new service type as they are added. It is envisioned that some 'xsrv' messages can be received and processed in any of the TALI NEx-FEx state, while some other 'xsrv' messages can only be received and processed in the NEA- FEA state (such as Service data in version 1.0 of TALI).
Top   ToC   RFC3094 - Page 93
   There are no specific PRIMITIVES defined for this opcode in this
   release.  It is expected that some new service messages will be added
   in the future.  This opcode provides for grouping of the new service
   data types.

   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'xsrv'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..13 | Primitive   | To be determined                          |
   +------------------------------------------------------------------+
   | 14..   | Message     | To be determined                          |
   |   2000 | Data        |                                           |
   +------------------------------------------------------------------+

4.5.3 Special Message (spcl)

The Special Message, 'spcl', opcode is added to the TALI 2.0 protocol to provide a way for vendors to build special services into their TALI implementations that are only activated when the implementation is connected to other equipment implementing the same special services. 'spcl' messages can be received and processed in any of the TALI NEx-FEx states. This opcode is intended to provide a general means to discover more information regarding who the TALI session is connected to, and to provide means to enable special features based on the vendor/implementation on the far end. As part of the 2.0 specification, 4 primitives are initially defined for this opcode: * 'smns' - Special Messages Not Supported. * 'qury' - Query. * 'rply' - Reply. * 'usim' - UnSolicited Information Message. Additional primitives can be added in future versions of the TALI protocol.
Top   ToC   RFC3094 - Page 94
   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'spcl'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..13 | Primitive   | 'smns' - special messages not supported   |
   |        |             | 'qury' - query                            |
   |        |             | 'rply' - reply                            |
   |        |             | 'usim' - UIM (unsolicited information msg)|
   +------------------------------------------------------------------+
   | 14..X  | Data        | Vendor dependent                          |
   +------------------------------------------------------------------+

4.5.3.1 Special Messages Not Supported (smns)
This message is sent as a response to a 'spcl' message with a 'qury' PRIMITIVE. A node may send out this message when it wants the Far End to know that it does not support 'spcl' messages and wishes not to receive them in the future. +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'smns' | +------------------------------------------------------------------+
4.5.3.2 Query Message (qury)
This message can be sent to Query the far end of the connection (ie: try to find out more information about the VENDOR, TALI version, or other features). It is expected that each 2.0 implementation would respond to a 'qury' with a 'rply'.
Top   ToC   RFC3094 - Page 95
   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'spcl'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..13 | Primitive   | 'qury'                                    |
   +------------------------------------------------------------------+

4.5.3.3 Reply Message (rply)
The 'rply' message provides a way for a TALI 2.0 implementation to identify itself in more detail. The information included in the reply includes: * PEC - a 2 byte field that identifies the vendor for the TALI implemenation. * Version Number - a 12 byte field that identifies the TALI version of the implementation. * Other Vendor Specific Data - the format of any remaining data that a particular vendor wants to provide is specific to each vendor. +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'rply' | +------------------------------------------------------------------+ | 14..15 | PEC | Private Enterprise Code * | | | | (Vendor ID Number, Integer Field) | +------------------------------------------------------------------+ | 16..27 | Version | 'vers xxx.yyy' | | | Label | | +------------------------------------------------------------------+ | 28..? | Other Vendor| Free Format data area, specific to each | | | Specific | vendor | | | Data | | +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 96
   *See Table 4 for details on the PEC field.

4.5.3.4 Unsolicited Information Message (USIM)
A 'usim' provides the same information as the 'rply' primitive. The 'usim' can be sent at any time by a 2.0 implementation (whereas the 'rply' should only be sent in reply to a 'qury'). +------------------------------------------------------------------+ | Octets | Field Name | Description | +------------------------------------------------------------------+ | 0..3 | SYNC | 'TALI' | +------------------------------------------------------------------+ | 4..7 | OPCODE | 'spcl' | +------------------------------------------------------------------+ | 8..9 | LENGTH | Length | +------------------------------------------------------------------+ | 10..13 | Primitive | 'usim' | +------------------------------------------------------------------+ | 14..15 | PEC | Private Enterprise Code * | | | | (Vendor ID Number, Integer Field) | +------------------------------------------------------------------+ | 16..27 | Version | 'vers xxx.yyy' | | | Label | | +------------------------------------------------------------------+ | 28..? | Other Vendor| Free Format data area, specific to each | | | Specific | vendor | | | Data | | +------------------------------------------------------------------+

4.6 TALI Timers

Version 2.0 of the TALI specification does not introduce any new timers. The T1-T4 timers defined previously remain in effect. While, it is expected that most implementations wishing to identify themselves as 2.0 (or later) would use a non-zero value for T4 - this is a not a hard requirement. The only requirement for identifying yourself as 2.0 is to send at least 1 'moni' as per the 2.0 format upon connection establishment.

4.7 TALI User Events

Version 2.0 of the TALI specification does not introduce any new user events. The user events defined in Section 3.4 (mgmt open, mgmt close, mgmt allow, mgmt proh, connection established, connection lost) remain in effect.
Top   ToC   RFC3094 - Page 97

4.8 TALI States

Version 2.0 of the TALI specification does not introduce any new TALI states. The TALI states defined in Section 3.6 remain in effect.

4.9 TALI Version 2.0 State Machine

This section provides the state machine that must be followed by each TALI 2.0 implementation in order to be compliant with this specification. As mentioned throughout this document, a 2.0 implementation is based on several small additions to a 1.0 implementation and each 2.0 implementation must be willing to inter- operate in a backwards compatible mode (a 2.0 implementation connected to a 1.0 implementation must fall back to 1.0 features only).

4.9.1 State Machine Concepts

Before presenting the actual state machine, several concepts are discussed.
4.9.1.1 General Protocol Rules
A set of general protocol rules was presented in the 1.0 specification, in section 3.7.1.1; those rules are still applicable to 2.0 implementations. In addition to those earlier rules, the following rules are also applicable to 2.0 nodes: * A 2.0 implementation should identify the TALI version it has implemented via the 'moni' message * A 2.0 implementation should process any received 'moni' messages, attempting to determine the TALI version of the far end. A 2.0 implementation must use an internal flag, such as 'far_end_version', to track the TALI version that the far end of the connection has implemented. The 'far_end_version' flag should be initialized to version 1.0. * A 2.0 implementation should reject/ignore internal requests (from software layers in it's own product, or requests from the management interface for the device) to send TALI messages that require 2.0 opcodes when the far end is a 1.0 implementation. A 2.0 implementation should only send TALI messages that require new 2.0 opcodes (mgmt, xsrv, spcl) when it knows the far end is capable of processing those opcodes (when 'far_end_version' is 2.0 or greater).
Top   ToC   RFC3094 - Page 98
   *  Upon receiving a TALI message with a 2.0 opcode, a 2.0
      implementation should interrogate its 'far_end_flag'; if the far
      end is not 2.0 or greater, the arrival of the message should be
      treated as a Protocol Violation.  If the far end is 2.0 or
      greater, the message should be processed according to the nodes
      2.0 capabilities, or ignored (if the node has chosen not to
      implement any 2.0 functionalities).

4.9.1.2 Graceful Shutdown of a Socket
The steps to perform a graceful shutdown of each socket were presented in the 1.0 specification, in section 3.7.1.2. Those steps are not changed for 2.0 implementations.
4.9.1.3 TALI Protocol Violations
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include: * Invalid sync code in a received message * Invalid opcode in a received message * Invalid length field in a received message * Not receiving an 'allo' or 'proh', in response to the origination of a 'test' , before the T2 timer expires * Receiving Service Messages on a prohibited socket. * TCP Socket errors - Connection Lost * Receiving a TALI message with a 2.0 opcode ('mgmt', 'xsrv', ' spcl') from a far end that has not identified itself as a 2.0 implementation. In the state machine that follows, State/Event combinations that should be treated as protocol violations are indicated via a 'PV' in the state/event cell. All of the 'PV' events are then processed as per the 'Protocol Violation' row in the table.

4.9.2 The State Machine

Internal Data required for State Machine: * boolean sock_allowed. This flag indicate whether the NE is allowed to carry Service Messages.
Top   ToC   RFC3094 - Page 99
   *  Far_end_version.  This enumeration should track the TALI version
      of the far end of the socket.

   Initial Conditions:
   sock_allowed = FALSE
   far_end_version = 1.0
   state = OOS
   no timers running

   +------------------------------------------------------------------+
   |   State| OOS  |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
   |Event   |      |          |         |         |         |         |
   +------------------------------------------------------------------+
   |T1 Exp. |      |          |Send test|Send test|Send test|Send test|
   |        |      |          |Start T1 |Start T1 |Start T1 |Start T1 |
   |        |      |          |Start T2 |Start T2 |Start T2 |Start T2 |
   +------------------------------------------------------------------+
   |T2 Exp. |      |          |   PV    |   PV    |   PV    |   PV    |
   +------------------------------------------------------------------+
   |T3 Exp. |      |          |   PV    |   PV    |         |         |
   +------------------------------------------------------------------+
   |T4 Exp. |      |          |Send moni|Send moni|Send moni|Send moni|
   |        |      |          |Start T4 |Start T4 |Start T4 |Start T4 |
   +------------------------------------------------------------------+
   |Rcv test|      |          |Send proh|Send proh|Send allo|Send allo|
   +------------------------------------------------------------------+
   |Rcv allo|      |          | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
   |        |      |          | NEP-FEA |         | NEA-FEA |         |
   +------------------------------------------------------------------+
   |Rcv proh|      |          | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
   |        |      |          |Send proa|Send proa|Send proa|Flush or |
   |        |      |          |         | NEP-FEP |         | reroute |
   |        |      |          |         |         |         |Send proa|
   |        |      |          |         |         |         | NEA-FEP |
   +------------------------------------------------------------------+
   |Rcv proa|      |          | Stop T3 | Stop T3 |         |         |
   +------------------------------------------------------------------+
   |Rcv moni|      |          |Update   |Update   |Update   |Update   |
   |        |      |          |'far end |'far end |'far end |'far end |
   |        |      |          |version' |version' |version' |version' |
   |        |      |          |based on |based on |based on |based on |
   |        |      |          |moni     |moni     |moni     |moni     |
   |        |      |          |Convert  |Convert  |Convert  |Convert  |
   |        |      |          | to mona | to mona | to mona | to mona |
   |        |      |          |Send mona|Send mona|Send mona|Send mona|
   +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 100
   |Rcv mona|      |          |Implemen-|Implemen-|Implemen-|Implemen-|
   |        |      |          |tation   |tation   |tation   |tation   |
   |        |      |          |dependent|dependent|dependent|dependent|
   +------------------------------------------------------------------+
   |Rcv     |      |          |   PV    |If T3 run|   PV    |Process  |
   | Service|      |          |         | Process |         |         |
   |        |      |          |         |Else PV  |         |         |
   +------------------------------------------------------------------+
   |Rcv mgmt|      |          |If FE<   |If FE<   |If FE<   |If FE<   |
   |        |      |          | 2.0 PV  | 2.0 PV  | 2.0 PV  | 2.0 PV  |
   |        |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+
   |Rcv xsrv|      |          |If FE<   |If FE<   |If FE<   |If FE<   |
   |        |      |          | 2.0 PV  | 2.0 PV  | 2.0 PV  | 2.0 PV  |
   |        |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+
   |Rcv spcl|      |          |If FE<   |If FE<   |If FE<   |If FE<   |
   |        |      |          | 2.0 PV  | 2.0 PV  | 2.0 PV  | 2.0 PV  |
   |        |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+
   |Connect.|      | Start T1 |         |         |         |         |
   |Estab.  |      | Start T2 |         |         |         |         |
   |        |      | Start T4 |         |         |         |         |
   |        |      |(if non-0)|         |         |         |         |
   |        |      |if sock_  |         |         |         |         |
   |        |      |  allowed |         |         |         |         |
   |        |      |  = TRUE  |         |         |         |         |
   |        |      | send allo|         |         |         |         |
   |        |      | send test|         |         |         |         |
   |        |      | NEA-FEP  |         |         |         |         |
   |        |      |else      |         |         |         |         |
   |        |      | send proh|         |         |         |         |
   |        |      | send test|         |         |         |         |
   |        |      | NEP-FEP  |         |         |         |         |
   +------------------------------------------------------------------+
   |Connect.|      |          |   PV    |   PV    |   PV    |   PV    |
   |Lost    |      |          |         |         |         |         |
   +------------------------------------------------------------------+
   |Protocol|      |          |Stop all |Stop all |Stop all |Stop all |
   |Violat. |      |          | timers  | timers  | timers  | timers  |
   |        |      |          |Close the|Close the|Close the|Close the|
   |        |      |          | socket  | socket  | socket  | socket  |
   |        |      |          |Connect- |Connect- |Connect- |Connect- |
   |        |      |          |  ing    |  ing    |  ing    |  ing    |
   +------------------------------------------------------------------+
Top   ToC   RFC3094 - Page 101
   |Mgmt.   |Open  |          |         |         |         |         |
   |Open    |socket|          |         |         |         |         |
   |Socket  |Conne-|          |         |         |         |         |
   |        | cting|          |         |         |         |         |
   +------------------------------------------------------------------+
   |Mgmt.   |      |Close the |Stop all |Stop all |Stop all |Stop all |
   |Close   |      | socket   | timers  | timers  | timers  | timers  |
   |Socket  |      |OOS       |Close the|Close the|Close the|Close the|
   |        |      |          | socket  | socket  | socket  | socket  |
   |        |      |          |OOS      |OOS      |OOS      |OOS      |
   +------------------------------------------------------------------+
   |Mgmt.   |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
   |Prohibit|allow-| wed=FALSE| owed=   | owed=   | owed=   | owed=   |
   |Socket  |ed =  |          | FALSE   | FALSE   | FALSE   | FALSE   |
   |        |FALSE |          |         |         |send proh|send proh|
   |        |      |          |         |         |start t3 |start t3 |
   |        |      |          |         |         | NEP-FEP | NEP-FEA |
   |        |      |          |         |         |         |         |
   +------------------------------------------------------------------+
   |Mgmt.   |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
   |Allow   |allow-| wed=TRUE | owed=   | owed=   | owed=   | owed=   |
   |Traffic |ed =  |          | TRUE    | FALSE   | TRUE    | TRUE    |
   |        |TRUE  |          |send allo|send allo|         |         |
   |        |      |          | NEA-FEP | NEA-FEA |         |         |
   +------------------------------------------------------------------+
   |User    |reject| reject   | reject  | reject  | reject  | send    |
   |Part    |data  | data     | data    | data    | data    | data    |
   |Msgs.   |      |          |         |         |         |         |
   +------------------------------------------------------------------+
   |Request |      |          |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
   |to Tx   |      |          | Ignore  | Ignore  | Ignore  | Ignore  |
   |mgmt    |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+
   |Request |      |          |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
   |to Tx   |      |          | Ignore  | Ignore  | Ignore  | Ignore  |
   |xsrv    |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+
   |Request |      |          |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
   |to Tx   |      |          | Ignore  | Ignore  | Ignore  | Ignore  |
   |spcl    |      |          |Else     |Else     |Else     |Else     |
   |        |      |          | Process | Process | Process | Process |
   +------------------------------------------------------------------+

                   Table 29: TALI 2.0 State Machine
Top   ToC   RFC3094 - Page 102

4.10 TALI 2.0 Specification Limitations

Several limitations with the TALI 2.0 specification are identified. These are considered possible areas for expansion of the protocol in the future: * Support for different types of routing keys is limited. It is envisioned that new routing key types will need to be added and supported as new applications are identified. * An opcode, or new primitive within an existing opcode, could be added as a means of returning unknown or unsupported data to the sender. In addition to discarding and storing internal debug data, an implementation may want to return the original TALI message to the sender when the receiver of the message deems the message to be unknown, unsupported, or incorrectly formatted.

5. Success/Failure Codes

The following list provides all the known success/failure codes that are being used for the rkrp feature. New defines will be added to the end of the list as they are identified. Error # Meaning 1 Transaction successfully completed. 2 Length of TALI msg is insufficient to contain all required information for rkrp operation 3 Unsupported 'rkrp' operation 4 Invalid SI. SI must be in range 0..15 5 Invalid SI/operation combination. Split and resize only supported for SI=4,5,13. Enter, delete and override supported for all SI. 6 Invalid DPC. Point code cannot be zero, and must be full point code. 7 Invalid SSN. SSN must be in range 0..255. 8 Invalid OPC. Point code cannot be zero, and must be full point code. 9 Invalid CICS. Must be in range appropriate for SI and PC type. 10 Invalid CICE. Must be in range appropriate for SI and PC type. 11 Invalid CIC range. CICS must be less than or equal to CICE. On a split operation, CICS must be strictly less than than CICE (cannot split an range with only one entry). 12 Invalid NCICS. Must be in range appropriate for SI and PC type.
Top   ToC   RFC3094 - Page 103
   13         Invalid NCICE.  Must be in range appropriate for SI and
              PC type.
   14         Invalid new CIC range.  NCICS must be less than or equal
              to NCICE.
   15         Invalid SPLIT value.   Must be in range appropriate for
              SI and PC type.  Must be greater than CICS and less than
              or equal to CICE.
   16         No free entries in table.
   17         CIC range overlaps but does not match existing entry.
   18         Entry already has 16 associations.
   19         Entry to be changed not found in table.
   20         New entry would overlap another entry (allowed to overlap
              the entry being changed, but no others).
   21         Entry to be deleted not found in table.
   22         TUP routing keys are not supported for ANSI networks

6. Security Considerations

TALI is an interface for the transport of SS7 traffic and management messages across an IP network. As with traditional PSTN networks, the IP networks using TALI are expected to well engineered systems. The use of virtual private networks and firewalls is to be expected. In addition, the use of IPSEC will bring added security benefit to the network.

7. References

[1] Bell Communications Research, Specification of Signaling System Number 7, GT-246-CORE, Bellcore, Issue 1, December 1994. [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [5] Logical Link Control, IEEE 802.2 and ISO 8802.2 [6] Carrier Sense Multiple Access with Collision Detection (Ethernet), IEEE 802.3 and ISO 8802-3 CSMA/CD. [7] Virtual LAN, IEEE 802.1 Q and ISO 8802-1Q CSMA/CD. [8] Bell Communications Research, Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links (HSLs), GR-2878-CORE, Issue 1, Bellcore, November 1995.
Top   ToC   RFC3094 - Page 104
   [9]  Bell Communications Research, Asynchronous Transfer Mode (ATM)
        and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE,
        Bellcore.

   [10] American National Standards Institute, B-ISDN Signaling ATM
        Adaptation Layer - Service Specific Connection Oriented Protocol
        (SSCOP), T1.637.

   [11] American National Standards Institute, B-ISDN Signaling ATM
        Adaptation Layer - Service Specific Coordination Function for
        Support of Signaling at the Network Node Interface (SSCF at the
        NNI), T1.645.

   [12] American National Standards Institute, B-ISDN Signaling ATM
        Adaptation Layer - Layer Management for the SAAL at the NNI,
        T1.652.

8. Acknowledgments

The authors would like to thank Ken Morneault for his comments and contributions to the document.
Top   ToC   RFC3094 - Page 105

9. Authors' Addresses

David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com Dan Brendes Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-2162 EMail: dan.brendes@tekelec.com Robby Benedyk Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5533 EMail: robby.benedyk@tekelec.com Joe Keller Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5549 EMail: joe.keller@tekelec.com
Top   ToC   RFC3094 - Page 106

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.