rfc3094.txt

RFC 的详细文档！

   The 'proa' message is sent by a TALI implementation each time a
   'proh' is received from the far end.  This message is sent to
   indicate to the far end that his 'prohibit' message was received
   correctly and will be acted on accordingly.




Sprague, et al.              Informational                     [Page 22]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'proa'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length = 0                                |
   +------------------------------------------------------------------+

3.2.1.5 Monitor Message (moni)

   The 'moni' message provides a generic ECHO capability that can be
   used by each TALI implementation as that implementation sees fit.  A
   TALI version 1.0 implementation does not have to originate a 'moni'
   message to be compliant with the 1.0 specification.  The primary
   intent of this message is to provide a way for the TALI layer to test
   the round-trip message transfer time on a socket.  A 'mona' message
   must be sent in reply to each received 'moni' message.  The DATA
   portion of a 'moni' message is vendor implementation dependent.  The
   DATA portion of each 'mona' reply must exactly match the DATA portion
   of the 'moni' that is replied to.  Regardless of whether an
   implementation chooses to send 'moni' or not, 'mona' must be sent in
   response to each 'moni' in order to remain compliant with the TALI
   protocol.

   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'moni'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..X  | DATA PAYLOAD| Vendor Dependent                          |
   +------------------------------------------------------------------+

3.2.1.6 Monitor Acknowledge Message (mona)

   As mentioned above, the 'mona' must be sent in reply to each received
   'moni'.  The contents of the 'mona' DATA area must match the DATA
   area of the received 'moni' message.








Sprague, et al.              Informational                     [Page 23]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'mona'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..X  | DATA PAYLOAD| Vendor Dependent                          |
   +------------------------------------------------------------------+

3.2.2 Service Messages

   The following subsections provide more information regarding the TALI
   Service messages that are implemented in version 1.0.  TALI Service
   messages are used to carry SS7 MSUs across the IP network.  The
   information in this section includes details with respect to how to
   encapsulate SS7 MSUs into TCP/IP frames using each of the TALI
   service opcodes.  The TALI service messages originate at the layer
   above TALI, are transported across the IP network via a TALI service
   message, and are delivered to the layer above TALI at the far end of
   the TALI connection.

3.2.2.1 SCCP Service Message (sccp)

   The 'sccp' opcode is used to deliver SS7 MSUs with a Service
   Indicator of 3 (SCCP) over a TALI connection.  This opcode is only
   used on TALI protocol stacks that are implemented without SAAL.  The
   MTP3 layer of the SS7 MSU is NOT part of the data transferred across
   TCP/IP for this opcode; the data portion of the TALI 'sccp' message
   begins with the first byte of the SCCP data area in the SS7 MSU
   (after the MTP3 routing label).  The first byte in the SCCP data area
   is an SCCP message type field.

   Several restrictions on the SCCP messages that this TALI opcode can
   carry exist.  These restrictions are as follows:

   *  SCCP messages contain an SCCP message type field.  The SCCP
      messages that are supported by TALI 1.0 implementations are
      limited to Class 0 and Class 1 SCCP messages with a message type
      field of either:

      *  UDT
      *  UDTS
      *  XUDT
      *  XUDTS




Sprague, et al.              Informational                     [Page 24]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


   *  SCCP messages must contain a Point Code in the 'calling party'
      area in order to be transferred across the TCP/IP connection as a
      'sccp' message.  An implementation may choose to modify the
      original SCCP MSU to add an appropriate calling party point code
      before transmission across TALI if desired.

   *  SCCP messages must contain a Point Code in the 'called party' area
      in order to be transferred across the TCP/IP connection as a
      'sccp' message.  An implementation may choose to modify the
      original SCCP MSU to add an appropriate called party point code
      before transmission across TALI if desired.

   *  The encoding of the SS7 SCCP MSUs, as they are transmitted across
      TALI via 'sccp', should remain compliant with the ANSI
      specifications (T1.112 and T1.114) that apply to the SCCP and TCAP
      portions of the message respectively.

   NOTE 1: SCCP Subsystem Management for the IP based SCP's is supported
   via this 'sccp' opcode.  SS7 SCCP Management messages are controlled
   by an SCMG SS7 process.  SCMG sends the management messages via SCCP
   UNITDATA (UDT) messages.  Therefore, the SCMG messages can be sent
   across the TALI connection.

   NOTE 2: 'sccp' TALI messages will not include the MTP3 header and
   therefore will not retain the original DPC/OPC of the SS7 MSU.  Each
   TALI implementation needs to consider if/how to provide this DPC/OPC
   information in the SCCP portion of the message.  For example the DPC
   can be replicated to the point code in the SCCP Called Party Address
   area and the OPC can be replicated to the point code in the SCCP
   Calling Party Address area.

   +------------------------------------------------------------------+
   | Octets | Field Name  | Description                               |
   +------------------------------------------------------------------+
   | 0..3   | SYNC        | 'TALI'                                    |
   +------------------------------------------------------------------+
   | 4..7   | OPCODE      | 'sccp'                                    |
   +------------------------------------------------------------------+
   | 8..9   | LENGTH      | Length                                    |
   +------------------------------------------------------------------+
   | 10..X  | SCCP Data   | SCCP data starting at the first byte after|
   |        |             | the Layer 3 Routing Label (data does not  |
   |        |             | include the SIO or Routing Label)         |
   +------------------------------------------------------------------+







Sprague, et al.              Informational                     [Page 25]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


3.2.2.1.1 SCCP Encapsulation using TALI

   When an SCCP MSU arrives at an SG from a 56 Kbps or DS1 link and is
   routed within the SG for transmission to an IP device, the SG
   performs the following processing on the SS7 MSU:

   *  discards the MTP Layer 2 information, CRC and flags

   *  places the DPC from MTP Layer 3 into the Called Party Address
      field of the SCCP layer; the Calling Party Address field is
      created if it does not exist and then filled

   *  places the OPC from MTP Layer 3 into the Calling Party Address
      field of the SCCP layer if there is no Calling Party Point Code

   *  places the modified SCCP and unchanged TCAP data in the service
      payload area of the TALI packet

   *  The SYNC field is set

   *  The OPCODE is set to 'sccp'

   * The LENGTH is set to the number of octets in the SERVICE field

   Once the fully formed 'sccp' TALI packet is created, it is handed to
   the TCP socket layer and transmitted.  The transmission process will
   add TCP, IP and MAC header information.

   Since the routing information from MTP Layer 3 is placed in the SCCP
   part of the outgoing message, no routing information needs to be
   saved by the SG.




















Sprague, et al.              Informational                     [Page 26]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


                                SS7 MSU

           |          Layer 3          |     Layer 2      |
           |                           |                  |
      +----+---+-----+-----+-------+---+--+---+---+---+---+----+
      |Flag|FCS|TCAP |SCCP |Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
      |    |   |Layer|Layer| Label |   |  |   |   |   |   |    |
      +----+---+-----+-----+-------+---+--+---+---+---+---+----+
               |           |
               |           |
               |           |
        TALI   +-----------+---+------+----+
        Packet |  Service  |LEN|Opcode|SYNC|
               +-----------+---+------+----+
               |                           |
               |                           |
               |                           |
               +---------------------------+------+------+------+
        IP     | TALI Packet               |TCP   | IP   | MAC  |
        Packet |                           |Header|Header|Header|
               +---------------------------+------+------+------+

   Figure 6: Encapsulation of SCCP MSUs using the TALI 'sccp' opcode

   When an 'sccp' TALI packet is received on by an SG from an IP device,
   the SG performs the following processing on the 'sccp' packet:

   *  validates the TALI header

   *  Allocates space for a new SS7 message

   *  Regenerates the SIO with the Sub-Service Field set to National
      Network, priority of zero (0), Service Indicator set to SCCP

   *  extracts the SCCP/TCAP data from the SERVICE area and places it in
      the new SS7 message

   *  sets the DPC to the SCCP Called Party Point Code

   *  sets the OPC to the SCCP Calling Party Point Code

   *  randomly generates the SLS

   Once the 'sccp' packet is transformed back into a normal SS7 MSU, the
   MSU is routed within the SG according to the normal SS7 routing
   procedures.





Sprague, et al.              Informational                     [Page 27]

RFC 3094      Tekelec's Transport Adapter Layer Interface     April 2001


3.2.2.2 ISUP Service Message (isot)

   The 'isot' opcode is used to deliver SS7 MSUs with a Service
   Indicator of 5 (ISUP) over a TALI connection.  This opcode is only
   used on TALI protocol stacks that are implemented without SAAL.  The
   MTP3 layer of the SS7 MSU IS part of the data transferred across
   TCP/IP for this opcode; the data portion of the TALI 'isot' message
   begins with the SIO byte of the MTP3 header in the SS7 MSU.