tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3094

 
 
 

Tekelec's Transport Adapter Layer Interface

Part 4 of 4, p. 83 to 106
Prev RFC Part

 


prevText      Top      Up      ToC       Page 83 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.