Using TCAP over GDI

The Generic Data Interface (GDI) allows TCAP to run over TCP. This allows TCAP applications to communicate using an IP network.

TCAP accesses to GDI and SCCP are similar to those over a normal SS7 stack but there are three differences:

TCAP messages have a maximum component portion size of 4000 bytes. The remaining 90 bytes are used for TCAP header encoding.
Error codes are specific to GDI or SCCP.
TCAP requests a connection on GDI using the Sub-System Number (SSN) 256.




	NOTE: The SSN 256 is reserved for applications using the GDI protocol and cannot be used for SCCP connections.

The GDI interface is defined by Bellcore as "ISCP Generic Data Interface for TCP/IP", with versions:

5.0 January 97
4.1 May 96

HP OpenCall SS7 implements all GDI 4.1 features, and can interoperate with 5.0. The HP OpenCall SS7 stack provides the transport protocol part of GDI.

GDI Access (Application Interface Layer)

TCAP accesses GDI and SCCP in a similar way, with the following exceptions:

GDI messages can be longer than those run over SCCP. The maximum GDI message length is 4096 bytes (6 bytes of header). GDI messages are versioned.
Error codes are specific to GDI.
The sub layer (SCCP or GDI) to which a message must be routed is determined by the SubSystem Number (SSN) during the TCAP connection phase. The TCAP API requests a connection to GDI using the SSN 256. This SSN is reserved for GDI.
The Distant GDI Point Code (DGPC) maps a logical connection to a remote host (client or server).

GDI Connectivity

This section lists some rules for GDI connectivity:

Connections are made using the OS socket interface.
The transport layer is TCP.
The GDI stack can run as a server or as a client. The server listens and accepts client connection requests. If a connection between a GDI client and a GDI server goes down, the GDI client tries to reconnect periodically until the connection is reestablished. Once a connection has been established, either the client or the server can initiate a transaction.
A GDI server accepts client connections only if a TCAP application is connected to its SSN (256). If not, the connection is refused.
A GDI application is located on a host defined by a Port Service Number (PSN) and by one or two IP address(es).
Keep Alive Mechanism: If no response is received during the specified time, the connection is closed. The timer value is specified in the file sys.<className>.gdi.
Transport Error Handling: if an error occurs at GDI level, the GDI layer (server or client) closes the connection and refuses all outstanding requests for that connection.
Security Implementation: to prevent unauthorized access, the GDI server only accepts connections from preconfigured IP addresses.
2-host platform: a 2-host HP OpenCall SS7 platform has one active host and one peer host. Only connection requests to the active host are accepted. The peer host refuses client connections.
Dual signaling LAN: GDI uses the two LANs to do loadsharing. However, as TCP/IP cannot ensure delivery order over more than one LAN a transaction is always kept on the same LAN. If one of the two LANs goes down, traffic is ensured on the other one. All open transactions are lost if a LAN switchover occurs.

TCAP Addressing Mode

A remote host is defined by its Distant GDI Point Code (DGPC). In TCAP, the DGPC maps directly to the DPC in the tc_address structure. This means that the DPC_SSN addressing mode must be used to identify a remote host. The DSSN value in tc_address structure must be set to 0.

Notifications

GDI uses the SCCP_USER_STATUS primitive to indicate to the TCAP user whether a connection to a remote GDI host is available or not.(Return values are Out of Service and In Service). This differs from SCCP where it indicates that a remote SCCP user is in service or out of service.

GDI uses the TC_NOTICE primitive to indicate GDI transport errors to the TCAP user. The GDI transport error is returned in the report_cause field of the TC_NOTICE primitive.

Transport errors:

generalFailure:: One or more errors occurred either on route to the server or on the server system
incompatibleVersions:: The version number in the GDI message header does not match the versions supported on the server
queue full:: The server cannot process the request at this time due to a full input queue
resultsTooLong:: The response message exceeds the maximum message size of a GDI message
taskrefused:: The request was refused by the server system
timerExpired:: The timer on the server expired
unauthorizedRequest:: The request was refused by the server system because of security
systemNotResponding:: The server site is not responding

Managing Stack Switchovers

For general information on GDI, see the HP OpenCall SS7 Welcome Guide.

Chapter 2 “General System Guidelines” and Chapter 3 “General API Guidelines” of the current guide contain general guidelines.

You should also take into account the following GDI-specific points:

During a switchover, connections to the remote GDI hosts are unavailable.
When a standby SS7 stack becomes active, the local TCAP user is notified by the SCCP_USER_STATUS primitive, which indicates that the connection to the remote GDI host is again available (In Service).
When an active SS7 stack becomes standby, the remote TCAP user receives an SCCP_USER_STATUS primitive indicating that the connection to it is unavailable (Out of Service), and a second SCCP_USER_STATUS primitive indicating that the connection to the host with the active SS7 stack is available (In Service). (DGPC1 is In Service, DGPC2 is Out Of Service seen from host 1). The TCAP application is responsible for managing both DGPCs.




	NOTE: All active transactions are lost on switchover. The TCAP user must reset its local timer and state-machines.

After a switchover, the newly active SS7 stack can accept connection requests from GDI client hosts. It is the responsibility of the GDI client to set the reconnection attempt period to a meaningful value. In the worst case, the interruption of service time is equal to the switchover time plus the reconnection attempt period.

Figure 6-17 GDI Connectivity in HP OpenCall SS7 Product

GDI Connectivity in HP OpenCall SS7 Product GDIconnectivityconnectivityGDI

Managing Dual Signaling LANs

Load Sharing Using Two LANs

GDI uses two LANs to do loadsharing.

As TCP does not ensure transaction integrity over multiple LANs, each transaction must be kept on the same LAN.

TCP hides LAN failures from the upper layers. Only the GDI Keep Alive mechanism checks whether the LAN connection is still there or not. This means that a broken LAN continues be seen as In Service until the Keep Alive timer pops and that GDI continues to send transactions on the broken LAN. These transactions will be lost.

For an example, see Figure 6-18 “GDI Dual LANS - Failure of One LAN ” and the explanatory text that follows the figure.

When the keep alive timer pops, GDI indicates the error to the TCAP user by sending a TC_NOTICE primitive (report_cause field set to systemNotResponding) for any transaction in progress.

Hewlett-Packard recommends that the application manages timeouts on transactions in order to avoid traffic stopping when a GDI signaling LAN goes down. This can be done either by implementing timeout transaction management in the application, or by letting the stack do it by uncommenting the setTimerPeriod.

To do this, use the cfgTcap command (for a description, see the man page). See also the HP OpenCall SS7 Operations Guide.

Figure 6-18 GDI Dual LANS - Failure of One LAN

GDI Dual LANS - Failure of One LAN GDILAN failuredual LANsfailure (GDI)LANsGDI (failure of one LAN)failureLAN (GDI)

GDI Keep Alive Mechanism

To verify that the LAN is still available, the GDI protocol layer sends a Keep Alive request at regular intervals. The frequency of this request is 1.5 times the value of the GDI Keep Alive Timeout specified in the sys.<className>.gdi file.

The default value of this timer is 40,000 milliseconds. With the default setting of the timer, a Keep Alive request will be sent every minute (1.5 x 40,000 ms). In the figure, this is represented by the thick blue arrows.

The destination GDI application responds with a Keep Alive response almost immediately afterwards (within milliseconds). In the figure, this is represented by the thinner green arrows. This is the normal behavior when no LAN fault occurs, and is shown on the left side of the figure.

When a LAN Fault Occurs

When a LAN fault occurs, there is a period during which traffic is disturbed. During this period:

All transactions in progress on the LAN that failed are lost.
Half of all new transactions which start during this period are lost.

In the worst case, the maximum period of disturbed traffic is equal to:

1.5 x (Keep Alive Timeout) + 1 period = 2.5 x (Keep Alive Timeout)

After the period of disturbed traffic, the initial level of traffic returns on the remaining LAN.

During the disturbed period, either the application must handle a TCAP transaction timer, or you can set the TCAP setTimerPeriod timer to a value which suits the traffic. To do this, use the cfgTcap command (for a description, see the man page). This is to ensure that uncompleted TCAP transactions are aborted when the timer pops and that further TCAP transactions can be started.

Choosing a GDI Timer Value

The default timer value is 40,000 ms, which causes a KeepAliveRequest to be sent every minute. However, reducing the 40,000 ms value increases the frequency of the KeepAliveRequests but also creates increased traffic on the LAN. Using the information in the figure, a compromise must be made between the required reactivity to a LAN failure and the level of Keep Alive traffic that is acceptable.