Tech Note

Radwares Solution for

SMPP / UCP / CIMD

North America
Radware Inc.
575 Corporate Dr. Suite 205
Mahwah, NJ 07430
Tel 888 234 5763

International
Radware Ltd.
22 Raoul Wallenberg St.
Tel Aviv 69710, Israel
Tel 972 3 766 8666

www.radware.com

Mai, 2008

Radwares Support for SMPP Protocol

Date: Mai, 2008
Page - 2 -

SMPP Protocol
The short message peer-to-peer protocol (SMPP) is a telecommunications industry
protocol for exchanging SMS messages between SMS peer entities such as short message
service centers. It is often used to allow third parties (e.g. value-added service providers like
news organizations) to submit messages, often in bulk.
SMPP was originally designed by Aldiscon, a small Irish company that was later acquired by
Logica (now split off and known as Acision). In 1999, LogicaCMG formally handed over
SMPP to the SMS Forum
The protocol is based on pairs of request/response PDUs (protocol data units, or packets)
exchanged over OSI layer 4 (TCP session or X.25 SVC3) connections. PDUs are binary
encoded for efficiency.
The most commonly used version of SMPP is v3.3, the most widely supported standard, and
v3.4, which adds transceiver support (single connections that can send and receive
messages). Data exchange may be synchronous, where each peer must wait for a response
for each PDU being sent, and asynchronous, where multiple requests can be issued in one
go and acknowledged in a skew order by the other peer. The latest version of SMPP is v5.0.

Radwares Support for SMPP / UCP / CIMD

Clients send SMPP requests towards the AppDirector Virtual IP address. AppDirector
determines the destination port of the request and whether any specific source IP ranges are
defined. Any combination of source IP ranges and destination ports could be configured.
Using this information, AppDirector parses the request into the relevant server farm or single
server and performs destination NAT to the specific server chosen. The decision process
known as a Dispatch Method allows for several balancing distribution algorithms for the
most granular traffic distribution possible.

Dispatch Algorithms:
The following dispatch methods are available:
Cyclic
Weighted Cyclic
Fewest Number of Users Server load for specific server used across all Farms
Fewest Number of Users Server load specific to local Farm
Least Amount of Traffic Server load for specific server used across all Farms
Least Amount of Traffic Server load specific to local Farm
Response Time Health checks can be used to measure response time
Hashing
SNMP Requests SNMP values form the OS or application from the server

Sessions Modes Available for Persistency:

To achieve maximum flexibility, AppDirector allows the Client Table to work in several modes.
Company Confidential

Radwares Support for SMPP Protocol

Date: Mai, 2008
Page - 3 -

The modes are configured per AppDirector farm, during the farm configuration process.
The following Sessions Modes are available:
Entry Per Session (default)
Regular
Server Per Session
Remove on Session End
Remove Entry in Select Server

Entry Per Session

When Entry Per Session is used as the Sessions mode, AppDirector maintains Layer 3
persistency. In the Entry Per Session mode, a new entry is added to the Client Table for each
new session, which allows you to define the same server to be part of multiple farms.
In the Entry Per Session mode, clients can send requests directly to a servers IP address
and to a farms VIP address at the same time. Before sending a reply, AppDirector searches
the Client Table for an entry with the appropriate Source port. If such an entry is found,
AppDirector sends the response through the VIP address indicated in the Client Table. If no
entry is found, the response is sent directly from the servers IP address to the clients IP
address. The Entry Per Session mode uses the following parameters:
Farm Name
VIP Address
Client IP Address
Server IP Address
Source Port Used from the Client to the Server
Destination Port Used from the Client to the Server

Regular
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode, each entry is
identified by the following parameters:
Layer 4 Policy VIP Address
Client IP Address
Destination TCP/UDP Port Used from the Client to the Server

Server Per Session

In the Server Per Session mode, multiple sessions from the same client are load balanced
separately. This mode is recommended when an application represents a large number of
users by a single IP address as a client to AppDirector; for example, if many clients trying to
approach AppDirector are located behind a proxy server.

Company Confidential

Radwares Support for SMPP Protocol

Date: Mai, 2008
Page - 4 -

The Server Per Session mode identifies an entry according to the following parameters:
VIP Address
Client IP Address
Source Port used from the Client to the Server
Destination Port used from the Client to the Server

Remove on Session End

The Remove on Session End mode allows AppDirector to remove entries from the Client
Table before Aging Time expires. This mode is used to clear entries representing the TCP
sessions that were closed before the end of the Aging Time. AppDirector keeps track of the
number of users attached to each server using the Client Table. This information is important
when using the least amount of users dispatch method. AppDirector enhances server
statistics by decreasing the number of users once a FIN is detected.
The Remove on Session End mode operates in the same way as the Entry Per Session
mode, except for the following:
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN
packet between the server and the client, as the RST/FIN packets indicate that the session is
closed.
The entry is aged in five seconds and subsequently removed.

Client NAT
With the Client NAT function the AppDirector is able to hide the original source IP of the client
request for the server. The AppDirector will NAT the source IP into a prior defined IP-address
range. This feature is most often used to ensure response based routing via the AppDirector
when the return route cannot be ensured by the server infrastructure directly.

XML API
The XML based API could be used for an interaction between the AppDirector and a server or
a monitoring station. It can be used to extract information or push policy related details for
immediate use.

Conclusions
Radware offers a variety of options for load balancing the SMPP protocol using a varying
dispatch algorithms and session mode control functions. The dispatch and session mode
configuration parameters allow for customizing the load balancing solution to provide the
most efficient possible traffic flow.

Company Confidential