Internet Engineering Task Force David Sanchez
INTERNET DRAFT Ericsson
January 15, 1999 Miguel A. Garcia
Expires July 15, 1999 Ericsson
<draft-sanchez-garcia-SSTP-v1r0-00.txt>
A Simple SCCP Tunneling Protocol (SSTP)
David Sanchez
Miguel A. Garcia
Version 1.0 draft
January 14, 1999
Status of this document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast)
Abstract
This document describes SSTP (Simple SCCP Tunneling Protocol), a
protocol architecture that provides the support of SCCP and TCAP user
applications over an IP network. The purpose of SSTP is to provide a
standard tunneling protocol to convey SCCP messages over an IP based
network. Address mapping from PSTN signalling to IP is not in the scope
of this draft. Therefore SSTP only deals with IP addresses. TCP or UDP
is used for SCCP class 0 messages. TCP is used for SCCP class 1, 2 or 3.
SSTP provides seamless connection between nodes implementing SSTP and
classical SS7 nodes by means of an SSTP gateway. The design of SSTP is
oriented to fulfill the requirements of TCAP user applications running
on a WAN.
Table of Contents
1. Introduction
2. Scope
3. Network architecture
4. SSTP functionality
4.1. SSTP primitives and parameters
4.1.1. SSTP primitives
4.1.2. SSTP primitive parameters
4.2. Messages in the SSTP architecture
5. Procedures
5.1. Start/Restart
5.2. Supervision
5.3 Network configuration errors
6. Further Studies
7. Acronyms
8. References
9. Authors
1. Introduction
TCAP is currently used extensively by applications to exchange
user sensitive signalling information via the reliable SS7 network.
TCAP only uses the connectionless service of SCCP. To mention some
examples of applications we found INAP (Intelligent Network
Application Part) in IN systems, MAP (Mobile Application Part) in
GSM or IS-41 in AMPS systems.
The applications on top of TCAP take advantage of the international
support of SS7 system in many countries. The layer that acts as a
glue by providing addressing capabilities over different SS7 networks
is SCCP.
There are some applications that do not use TCAP, but SCCP
instead. For instance, the BSSAP (Base Station System Application
Protocol).
IP is a widely used transport protocol, with a big range of products
available. Comparing with the OSI model, IP/UDP/TCP covers network
functions up to the layer 4. in the SS7 model, the MTP and the SCCP
layers conform up to the level 3. Therefore interactions between these
two systems focus on that level of the protocol stack.
The SCCP addressing functionality is needed to provide interconnection
to existing SS7 networks. It also provides network management features
to control the resources of the SS7 network(s) such congestion control
or TCAP user unavailability indications. Both SCCP addressing and SCCP
management functions are considered to be essential for a solution that
provides SS7 over IP signalling transport for WAN applications.
2. Scope
The scope of this document is to describe a protocol architecture that
provides the support of TCAP and SCCP user applications over an IP
network. The network would be typically a WAN, were some network
parameters like traffic load, congestion, availability or network
failures cannot be controlled as in a LAN.
This document describes the adaptation functionality of the signalling
gateway that provides seamless connectivity between the SS7 over IP
network and the classical SS7 network. This involves support SCCP
class 0, 1, 2 and 3 services.
To easy the modelling of the protocol and to facilitate alignment with
the modelling principles of ITU, this draft uses primitives to define
the interactions between SSTP and SCCP. Nevertheless implementations are
not required to fulfill the set of primitives described here.
SCCP uses GTs and PCs to address other SS7 nodes, while IP uses IP
addresses. Although there is a need for mapping between SCCP and IP
addresses, it is outside the scope of this draft to solve the mapping.
Therefore SSTP only deals with IP addresses.
SSTP does not deal with segmentation of SCCP messages. In order to
take advantage of the long message capabilities of the IP network
(compared to narrow-band MTP3 which has a maximum length of 272
octets), it is recommended to use of the LUDT messages as described in
reference [2]. LUDT messages supports a maximum length of 3952 octets.
3. Network architecture
SSTP provides adaptation function between SCCP and the IP family
protocols. In the IP network the communications between SS7 nodes are
end to end, which means that no Signalling Point Relay functionality
is implemented in the IP routers. It also provides mapping of
functionality between ICMP and the SCCP management functionality.
Figure 1 shows the protocol architecture proposed by SSTP.
+------+------+
| | APP. |
| APP. |------+
| | TCAP |
+------+------+
| SCCP |
+-------------+
| SSTP |
+-------------+
| TCP/UDP | +--------+
+-------------+ | APP. |
| IP |----+ +--------+
+-------------+ | +-----------------+ | TCAP |
| | SCCP | +--------+
| +--------+--------+ | SCCP |
| | SSTP | | +--------+
| +--------+ |--------| MTP |
| | TCP/UDP| MTP | +--------+
| +--------+ |
+----| IP | |
| +--------+--------+
+------+------+ |
| | APP. | |
| APP. |------+ |
| | TCAP | |
+------+------+ |
| SCCP | |
+-------------+ |
| SSTP | |
+-------------+ |
| TCP/UDP | |
+-------------+ |
| IP |----+
+-------------+
Figure 1. Network architecture using SSTP
4. SSTP functionality
SSTP performs the functions in order to provide adaptation between
SCCP and the network functions provided by the IP network. Among others,
SSTP provides the following functionality:
- Peer to peer: SSTP establishes a peer to peer communication
channel between two SCCP over IP nodes. SSTP nodes are listening to
the SCCP over IP port.
- Encapsulation of SS7 messages: SSTP provides a standard way to
encapsulate SCCP messages into IP packets, so that interworking
between different vendors is guaranteed.
- Use of transport protocols: SSTP uses both TCP and UDP as
transport protocols on top of IP. UDP is used for SCCP class 0
messages (unsequenced). TCP is used for SCCP classes 1, 2 and 3.
TCP can be used for class 0 as well.
- Connection supervision: An SSTP node monitors the communication
channel previously established with other SSTP nodes.
- Start/restart: SSTP provides automatic restablishment of the
communication channel with other SSTP nodes upon a start/restart.
- Network control: SSTP uses ICMP to control the IP network. It uses
Echo/Echo Reply and Destination Unreachable messages from ICMP in
order to detect failures in remote SS7 over IP nodes. SSTP informs
SCCP about failures in the network.
The functionality is provided by the next primitives and parameters.
4.1. SSTP primitives and parameters
4.1.1. SSTP primitives
SSTP provides a very similar interface towards SCCP as MTP does. This is
in order to provide the information needed by SCCP in order to perform
the required functionality.
The primitives and the parameters associated to them are shown in
figure 2.
The Request primitives flow from SCCP to SSTP, whilst the Indication
primitives flow from SSTP to SCCP.
+-----------------------------+------------------------+
| Primitive | Parameter |
+=============================+========================+
| SSTP-TRANSFER-Request | Destination IP address |
| | Destination IP port |
| | Protocol Class |
| | SLS |
| | SIO |
| | Data |
+-----------------------------+------------------------+
| SSTP-TRANSFER-Indication | Source IP address |
| | Source IP port |
| | SLS |
| | SIO |
| | Data |
+-----------------------------+------------------------+
| SSTP-NOTICE-Indication | Source IP address |
| | Source IP port |
| | Error Code |
| | SLS |
| | SIO |
| | Data |
+-----------------------------+------------------------+
| SSTP-PAUSE-Indication | Affected IP address |
+-----------------------------+------------------------+
| SSTP-RESUME-Indication | Affected IP address |
+-----------------------------+------------------------+
| SSTP-STATUS-Indication | Affected IP address |
| | Error Code |
+-----------------------------+------------------------+
Figure 2. SSTP primitives and parameters
4.1.1.1 SSTP-TRANSFER-Request
This primitive is used by SCCP to request from SSTP the transfer of
an SCCP message to a destination node.
4.1.1.2 SSTP-TRANSFER-Indication
This primitive is used by SSTP to indicate the reception of an SCCP
message from another SCCP node.
4.1.1.3 SSTP-NOTICE-Indication
This primitive is used by SSTP to indicate an error reported when
a message was sent through the IP network. Thus, this primitive is
issued as an error answer to a previous SSTP-TRANSFER-Request.
Delivery errors occur upon connection broken, node failure, IP network
configuration errors or similar situations. These type of errors are
reported to SSTP in the ICMP Destination Unreachable message. SSTP issues
then this primitive when receiving ICMP Destination Unreachable message
with the error reported by the IP network encoded in the Error Code
parameter with the values specified in Figure 4.
The SLS and SIO are the same parameters sent in a previous
SSTP-TRANSFER-Request primitive. However, the Data parameter may
contain a partial copy (not a complete one) of the Data sent in the
SSTP-TRANSFER-Request primitive.
The SCCP is responsible to take the proper actions (i.e. in the SS7
signalling gateway generate a return message or in the end SSTP node
generate an N-NOTICE-Indication primitive) upon the reception of this
primitive.
The Source IP address and Source IP port are those where the error
message was generated.
4.1.1.4 SSTP-PAUSE-Indication
This primitive is used by SSTP to indicate to SCCP the inability of
sending any SCCP message to the indicated node. The SSTP layer
generates as a result of remote host errors detected by the SSTP
supervision mechanisms as explained in section 5.2.
4.1.1.5 SSTP-RESUME-Indication
This primitive is used by SSTP to indicate to SCCP the availability of
sending again SCCP messages to the indicated node. The SSTP layer
generates this indication when the remote SCCP over IP node starts to
answer again to the ICMP Echo messages as explained in section 5.2.
Once the local SSTP reports that the remote IP & ICMP layers are
working again, it is the responsibility of SCCP to check the
availability of the peer SCCP layer.
The primitive is also issued when the local IP layer restart is
completed. If the IP transmission layer has been temporarily
unavailable due to a failure in the local hardware or software, SSTP
detects when it is available again and indicates this to SCCP by means
of this primitive. The value of the Affected IP address and Cause
parameters are left to the implementation (these values are not
specified in [3]), but in case of using an existing SCCP layer, it
would be desirable that the values provided by SSTP are the same as the
values used by the implementation of the existing SCCP layer.
4.1.1.6 SSTP-STATUS-Indication
This primitive is used by SSTP to indicate to SCCP some special events:
- Remote SCCP layer unavailability: If the remote SSTP layer receives a
message for SCCP, but SCCP is not working or attached to the remote
SSTP, then the remote SSTP generates an ICMP Destination Unreachable
message back, with the code set to value 12 (host unreachable for
this type of service). The local SSTP receiving such an ICMP message
reports the error to the local SCCP by means of this primitive.
- Remote SCCP congestion
4.1.2 SSTP primitive parameters
4.1.2.1 Source IP address
The Source IP address is used to indicate the node that originates the
message. This parameter is sent in the primitives:
- SSTP-TRANSFER-Indication
- SSTP-NOTICE-Indication
4.1.2.2 Source IP port
The Source IP port is used to indicate to SCCP the port that
originates the message. This parameter is sent in the primitives:
- SSTP-TRANSFER-Indication
- SSTP-NOTICE-Indication
4.1.2.3 Destination IP address
The Destination IP address is used to indicate the destination node for
a message or TCP connection. This parameter is sent in the primitives:
- SSTP-TRANSFER-Request
4.1.2.4 Affected IP address
The affected IP address is used to indicate the node affected by some
abnormal event. This parameter is sent in the following primitives:
- SSTP-PAUSE-Indication (SSTP to SCCP): The affected IP address
indicates the unavailability of the node SCCP over IP node, and that,
SCCP must not send any message to that node through the SSTP layer.
- SSTP-RESUME-Indication (SSTP to SCCP): The affected IP address
indicates the availability of a previously unavailable SCCP over IP
node. SCCP can resume to send messages to that node through the SSTP
layer.
- SSTP-STATUS-Indication (SSTP to SCCP): The affected IP address
indicates the IP node where the reported error applies.
4.1.2.5 Destination IP port
The Destination IP port is used to indicate the SSTP application in the
destination node. The port number reserved for SCCP over IP is 14001.
The Destination IP Port parameter is sent in the primitive:
- SSTP-TRANSFER-Request
4.1.2.6 Protocol Class
SSTP uses the value of Protocol Class received from SCCP to decide the
layer where the message is sent (UDP or TCP). If class 0 is used, then
SSTP may use either TCP or UDP as transport protocol (this is
implementation dependant). If class 1, 2 or 3 is used, then SSTP shall
use TCP as transport protocol.
The Protocol Class parameter is sent in the primitive:
- SSTP-TRANSFER-Request
4.1.2.7 SLS (Signalling Link Selection)
The Signalling Link Selection is encapsulated into the SLS octet and
transparently transmitted over the IP network.
The SLS octet contains 4 spare bits and the actual SLS value:
+------+------+
| DCBA | DCBA |
+------+------+
|Spare | SLS |
+------+------+-----> First bit transmitted
Figure 3. SLS octect
The SLS octet is sent in the following primitives:
- SSTP-TRANSFER-Request
- SSTP-TRANSFER-Indication
- SSTP-NOTICE-Indication
4.1.2.8 SIO (Service Indication Octet)
The SIO consists of:
- Service Indicator
- Subservice field, which consists on
- Network Indicator
- Spare bits (or message priority)
The SIO is sent in the following primitives:
- SSTP-TRANSFER-Request
- SSTP-TRANSFER-Indication
- SSTP-NOTICE-Indication
SCCP uses the SIO to indicate the MTP user (Service Indicator which
in this case will indicate SCCP) and network indicator. The SIO also
contains two spare bits, used for the message priority in the United
States networks.
The SIO is transparently transmitted over the IP network.
4.1.2.9 Data
This is the SCCP message to be sent to the remote node. The message is
composed of:
1) Message type code
2) Mandatory fixed part
3) Mandatory variable part
4) Optional variable part
These fields are described in reference [2] and in chapter 3 in
reference [4].
The Data is sent in the following primitives:
- SSTP-TRANSFER-Request
- SSTP-TRANSFER-Indication
- SSTP-NOTICE-Indication
4.1.2.10 Error code
This parameter carries the error code generated by the IP network
when a message was not properly delivered.
This parameter is used in the primitives:
- SSTP-NOTICE-Indication
- SSTP-STATUS-Indication
In most cases the primitive that includes the Error Code parameter is
sent as result of an ICMP Destination unreachable message. The values
of Error Code and its mapping to the ICMP Destination unreachable
code is described in the following table:
+-----------------+--------+---------------------+------+-----------+
| Error Code | Err. C.| ICMP Destination | ICMP | Primitive |
| | value | unreachable code | value| |
+=================+========+=====================+======+===========+
| Network failure | 0 | Network unreachable | 0 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Host failure | 1 | Host unreachable | 1 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| IP SW failure | 2 | Protocol unreachable| 2 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| SSTP failure | 3 | Port unreachable | 3 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Unqualified | 4 | Fragmentation needed| 4 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Unqualified | 4 | Source route failed | 5 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| IP network | 5 | Destination network | | |
| address error | | unknown | 6 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| IP host address | 6 | Destination network | | |
| error | | unknown | 7 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Config. error | 7 | Source host isolated| 8 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| | | Communication with | | |
| | | destination network| | |
| Administrative | | administratively | | |
| network barring| 8 | prohibited | 9 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| | | Communication with | | |
| | | destination network| | |
| Administrative | | administratively | | |
| host barring | 9 | prohibited | 10 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Remote SCCP net | | Network unreachable | | |
| unavailable | 10 | for type of service| 11 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Remote SCCP host| | Host unreachable | |Status-Ind |
| unavaliable | 11 | for type of service| 12 |Notice-Ind |
+-----------------+--------+---------------------+------+-----------+
| Network | | | | |
| congestion | 12 | | |Notice-Ind |
+=================+========+=====================+======+===========+
Figure 4. Mapping of Destination Unreachable codes to Error Codes
4.2. Messages in the SSTP architecture
SSTP provides encapsulation of the SCCP message in an IP datagram. If
SCCP class 0 is used, SSTP uses UDP or TCP to transmit the SCCP message
to the destination node. If SCCP class 1, 2 or 3 is used, SSTP uses an
existing TCP connection to the destination node to transmit the SCCP
message.
Figure 5 shows that the SCCP messages are encapsulated as a UDP/TCP
datagram.
+-------------+----------------+---+---+-------------------------+
| IP header | UDP/TCP header |SIO|SLS| SCCP message |
+-------------+----------------+---+---+-------------------------+
Figure 5. SSTP encapsulation
5. Procedures
5.1 Start/Restart
Whenever a node is started up or restarted, the server process is
launched. The server process is accepting TCP connections or UDP
packets and it is listening to the SCCP over IP reserved port
number, 14001. If a new TCP connection or UDP packet is received
by the SSTP layer, SSTP issues asynchronously the primitive
SSTP-RESUME-Indication to SCCP and aborts any ongoing supervision
process to the remote node that originated the message.
Once SSTP is listening to the reserved port, it starts in paralel
a supervision process with all the remote SSTP nodes defined.
If the remote SSTP node has defined no TCP connection to be
established (only UDP will be used), when the supervision process
detects that the remote SSTP node is available, SSTP issues
the primitive SSTP-RESUME-Indication to SCCP.
If SSTP has to establish a TCP connection with the remote SSTP node,
when the supervision process detects that the remote SSTP node is
available, SSTP requests a TCP connection to the SSTP node. When
the connection is established, SSTP issues the primitive
SSTP-RESUME-Indication to SCCP.
5.2 Supervision
SSTP performs monitoring of the communications with other SSTP nodes.
This implies supervision of TCP connections (if class 0, 1, 2 or 3 is
supported) and supervision of the status of remote hosts (if class 0
with support of UDP is used). This supervision is performed using
the services of ICMP Echo and Echo Reply messages. The supervision
procedure consists on the periodic polling of remote hosts by sending
ICMP Echo messages. The periodicity T1 of the polling is not specified.
Each TCP connection is supervised by SSTP. In case no messages are
sent for a certain period of time, ICMP Echo is sent to the remote
node, waiting to receive an Echo Reply message. If the Echo Reply
message is not received within a specific period of time T2, SSTP
considers that the TCP connection is broken. SSTP starts then the
supervision process is started.
SSTP also uses the supervision process upon start/restart (see section
5.1), to check that all remote nodes are available before UDP messages
are sent or TCP connections are established.
SSTP may also use the supervision process to monitor the status of
remote SSTP nodes that have no TCP connection established with the
local SSTP.
The supervision process is also started by SSTP upon reception of an
ICMP Destination Unreachable message from ICMP indicating net
unreachable or host unreachable.
If a number of Echo Reply message is not received within a specific
period of time T3, the communication is supposed to be broken, and
this is indicated to SCCP by means of the primitive SSTP-PAUSE-
Indication. The supervision process continues until an ICMP Echo
Reply message is received from the remote host. The recovery of the
remote host is indicated to SCCP by means of the primitive
SSTP-RESUME-Indication. In supervision process may also be aborted
(see section 5.1) in which case no primitive is sent to SCCP.
5.3 Network configuration errors
Errors on local or remote configurations of the IP network are
reported to SSTP by means of ICMP messages. Besides the standard
procedures of error reporting to SCCP explained above, the network
administrator shall be informed upon reception the ICMP messages
that report configuration failures in order to take actions to solve
the problem.
6. Further Studies
The further studies for following issues are needed:
- Provision of automatic rerouting upon IP network failure.
- Provision of forced rerouting and controlled rerouting in IP networks.
- Provision of enhanced error reporting procedures in IP networks.
- Study the introduction of enhanced routing algorithms like OSPF.
- Congestion control mechanism.
- Provision of remote SSTP monitoring mechanism.
7. Acronyms
AMPS - Advanced Mobile Telephone Service
BSSAP - Base Station System Application Part
GSM - Global System for Mobile Communication
GT - Global Title
ICMP - Internet Control Message Protocol
IN - Intelligent Network
INAP - Intelligent Network Application Part
IP - Internet Protocol
LAN - Local Area Network
MAP - Mobile application Part
MTP - Message Transfer Part
OSPF - Open Shortest Path First
PC - Point Code
SCCP - Signalling Connection Control Part
SS7 - Signalling System No. 7
SSTP - Simple SCCP Tunneling Protocol
TCAP - Transaction Capabilities Application Part
UDP - User Datagram Protocol
WAN - Wide Area Network
8. References
[1] ITU-T Recommendation Q.711: "Functional Description of the
Signalling Connection Control Part"
[2] ITU-T Recommendation Q.713: "Signalling Connection Control Part
formats and codes"
[3] ITU-T Recommendation Q.714: "Signalling Connection Control Part
procedures"
[4] ANSI T1.112-1996 "Signalling System Number 7 - Signalling
Connection Control Part (SCCP)"
[5] Postel, J.B. 1980, "Transmission Control Protocol", RFC 793
[6] Postel, J.B. 1980, "User Datagram Protocol", RFC 768
[7] Postel, J.B. 1981, "Internet Control Message Protocol" RFC 792
[8] Branden, R. 1989, "Requirements for Internet Hosts --
Communication Layers" RFC 1122
9. Authors
David Sanchez Miguel A. Garcia
Ericsson Ericsson
Retama 1 Retama 7
Madrid, Spain 28045 Madrid, Spain 28045
Tel: +34 91 339 3027 Tel: +34 91 339 2985
Email: emedasa@madrid.ericsson.se Email: Miguel.A.Garcia@ericsson.com