In this section:


The interface between the SS7 and TCP/IP environments using the UAP is managed by doing the following:

  • disabling the Nagle algorithm that delays TCP/IP transmission
  • configuring TCP/IP for a non-blocking interface
  • implementing a heartbeat message to detect network failures
  • creating a message header to delimit message boundaries
Note

Ribbon implements the UAP TCP/IP interface in the CMConnection class of the ptutil library.

Disabling the Nagle Algorithm

The Nagle algorithm has been introduced to optimize TCP/IP network utilization for low-bandwidth applications. This algorithm delays the transmission of a packet until a sufficiently large transmit buffer is accumulated or until a certain period of time elapses. This time period is usually 200 milliseconds.

Due to the real-time nature of SS7 traffic, it is recommended that you disable the Nagle algorithm for socket communication with the DSC Platform. Failure to do so, introduces an unnecessary delay in the SS7 message flow.

On most UNIX-based platforms, you can disable the Nagle algorithm by issuing the following system call on the socket’s file descriptor:

/* set the TCP No-delay flag (disable Nagle algorithm) */
int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

Most other languages and platforms have a similar feature (usually known as the TCP_NODELAY option).

Configuring TCP/IP for a Non-Blocking Interface

By default, most operating systems provide a blocking interface for TCP/IP sockets. Although this interface may allow for an improved error recovery scheme, the blocking interface does impact the performance of the communication channel. For example, a system call such as send() with a blocking interface does not return until the operating system confirms that the message is successfully stored in the transmit buffer.

You can configure TCP/IP for a non-blocking interface to improve performance and support asynchronous events using the select() function call on a UNIX-based architecture.

To set up a non-blocking socket interface, use the following call on the newly created socket:

/* set the socket to non blocking */
fcntl( fd, F_SETFL, O_NONBLOCK );

Most other languages and platforms have a similar feature.


Detecting Network Failures

The original goal of TCP/IP was to provide a reliable connection-oriented session between two remote computers across a slow and unreliable network. In trying to achieve this goal, an elaborate retransmission scheme was designed and implemented. This retransmission scheme allows for network failures to be undetected under a no load situation, and ensures a retry period of up to 10 minutes when waiting for an acknowledgment for a transmitted message. The retransmission scheme is valuable for most applications such as http and ftp, but is insufficient for near real-time applications such as SS7 over TCP/IP.

A typical method for detecting network failures is to use a probing message that forces the remote system to provide an immediate response or heartbeat message. This message has been implemented in the core DSC Platform messages as part of the four-octet header defined in the next section. For more information, see Using a Message Header to Delimit Message Boundaries.

Using a Message Header to Delimit Message Boundaries

The nature of the sliding window acknowledgement scheme used in IP creates the possibility of fragmentation of messages at the TCP/IP level.

Note

The sliding window is the method of flow control used by TCP. The purpose of the sliding window is to prevent the sender dispatching too many packets that would create an overflow in network resources or the receiver's buffer.

For example, a system may send 48 octets at once. The system on the receiving end may receive 16 octets, and then in a subsequent system call receive the remaining 32 octets. In another situation, a system may send two messages of 48 octets each by issuing two separate system calls, yet the receiving end receives a single 96-octet message.

To distinguish separate messages, every message sent between the DSC Platform and the IP application over TCP/IP is prefixed with a four-octet header that contains the type and length of the message that follows.

Message Header

The Message Header is a four octet header that describes the nature and size of the content of the message that follows. The offsets are indicated in number of bytes from the beginning of the message. The format of the message header is shown in the following table.

Message Header Format

Sub-Field Name  Offset Description
Message Class1Message class. Reserved for future use. Always coded as 0x00.
Message Command  1 Message command. For more information, see Message Command.
Message Length

(MSB)

(LSB)

2

3

The length of the message, excluding the message header. Stored as a binary number, with a maximum value of 4092.
Note

The CMConnection class handles encoding and decoding of the Message Header transparently and TCP/IP for SS7 configuration by using the following options in the setOptions () function:

  • COMM_NON_BLOCK_CONNECT
  • COMM_TCP_NODELAY
  • COMM_KEEP_ALIVE


Message Command

The Message Command sub-field contains the commands pertaining to the connection. As shown in the following table, these commands can be sent in either direction.

Message Commands

Command Value Description
No Command 0 Receiving a No Command (message only) invokes no procedures.
Acknowledgement Request 1
When receiving an Acknowledgment Request (are you alive?) command, both the DSC Platform and the IP application are required to respond immediately with an Acknowledge Response command. Failure to do so may cause the DSC Platform to close the TCP/IP socket.
Acknowledge Response 2
If an IP application does not receive an Acknowledgment Response (I’m alive) command after a predetermined period of time and/or a number of retries, this application may conclude that a network failure occurred and try to re-establish its connection to the DSC Platform at a later date.
N/A 3 to 255 Reserved for future use.


  • No labels