INTERNET DRAFT Michael McGrew
Date: November 1998 Lucent Technologies Inc.
Expires: May 1999
Transport SS7 Signalling Over IP
<draft-mcgrew-tss7s-00.txt>
Status of this Memo
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 proposes the transport of SS7 signalling messages
over IP in a way that utilizes the existing SS7 network (MTP and
SCCP) layers to ensure 'carrier class' service as expected by
existing users of SS7. The transport of SS7 user information
could use TCP connections or UDP. The SS7 signalling messages
would include ISUP or SCCP or, if the network services are not
needed, could include only TCAP. Work should begin to define the
necessary adaptation layers to make these transport methods
possible.
Table of Contents
1.0 Purpose and Scope
2.0 Overview
3.0 Discussion
4.0 Proposals
4.1 Emulate MTP Transport
4.2 Point-to-Point Transport
5.0 Conclusion and Recommendations
6.0 Acronyms
7.0 MTP Transfer Primitives
8.0 References
9.0 Author
1.0 Purpose and Scope
This paper addresses the need to transport over an IP network SS7
signalling between any two network elements which have an SS7
protocol stack at Message Transfer Part (MTP) Level 3 and/or
above. In architectures that have been discussed for transport
SS7 signalling over IP, a common thread is that the end user
protocols need to understand SS7. The motivation is that SS7 users
need the interface with IP to give them more flexibility to
communicate with a more widely distributed SS7 user community of
the future. Some SS7 users might not have the SS7 protocol stack,
but instead rely on transport over IP. Other SS7 network nodes
will already be on the standard SS7 network and have a full SS7
protocol stack, but have a need to communicate with the nodes that
have only IP-based access. When the latter is deployed on SS7
Signalling Transfer Points (STPs), they can act as gateways to
open up access to the SS7 nodes on the large installed base of SS7
networks that should need to have no knowledge of the IP network
interconnection. All nodes such as Service Switching Point (SSP)
nodes and Service Control Point (SCP) database nodes would be
included in this new community.
There will be many SS7 user needs, and this contribution describes
a limited set of solutions that can be applied comprehensively to
meet those various needs. This contribution describes interfaces
or "adaptation layers", or protocol layers that allow the SS7
transport to take place, that incorporate the needs of these
various nodes. It proposes that work begin to define what details
are needed in these adaptation layers, to adapt the SS7 protocol
being transported to the underlying UDP/TCP/IP transport.
2.0 Overview
This general view of "SS7 transport over IP" considers that SS7
user protocols residing on various network nodes need to maintain
their existing peer-to-peer relationship when they communicate.
SS7 user information maintained in its original form can be
transported over IP and facilitate this communication between
nodes on a SS7 network, on an IP network or both. A goal is to
provide reliable "carrier class" transport of the pure SS7 user
information.
This document assumes that transport over IP would be based on the
Transmission Control Protocol (TCP) suite that is already defined
and includes:
* UDP (User Datagram Protocol) -- Connectionless Packet Delivery
Service which provides efficient but unverified message delivery.
* TCP connections -- Reliable Stream Transport Service which is a
connection-oriented data delivery service. When used in a sub-
network for SS7, would need to be permanently maintained because
SS7 nodes are permanent (not fleeting) members of the network
community, and reliable service would have to avoid the delay and
uncertainty of opening a TCP connection when it is needed. TCP
failure detection may take substantial amounts of time.
An adaptation layer between MTP Level 3 users and the TCP/IP
transport service) needs to provide:
* Encapsulation/unencapsulation (to provide MTP transport of MSUs
without application processing)
* Mapping between SS7 point codes and IP addresses for transfer in
both directions between the two networks. As will be seen in the
proposals, anIP address might be used in different ways, to
identify an emulated SS7 signalling link or to identify the entire
SS7 node.
* Interfaces to the MTP users above and underlying TCP/IP or
UDP/IP transport below.
* Other functionality to conform with the SS7 transport
characteristics such as performance, reliable in-sequence delivery
and signalling network management.
The SS7 networks have MTP transfer capabilities and performance
requirements. These same capabilities will need to be provided
when interfacing with the adaptation layer and transporting over
UDP/TCP/IP. The MTP transfer primitives are summarized section 7
and performance objectives are included in the references.
In this contribution, "transport" may be regarded as
"encapsulation" and not "interworking". "Interworking" implies
that there is a mapping between the functions performed by the two
protocols. There is no intention to provide such a mapping in this
proposal. Transport encapsulation occurs when a common protocol
has interfaces to two transport protocols, e.g., in this case,
* SS7 MTP users over MTP-3 or over a adaptation layer that
emulates MTP-3.
* MTP-3 over MTP-2 or over a adaptation layer that emulates
MTP-2.
The transport of SS7 can be accomplished using UDP or TCP
connections over IP. Either can be considered and each places
unique requirements on the adaptation layer. Then there are
different ways to fit the adaptation layer(s) into the SS7 network
stack as well.
2.1 Scope and Limitations
To limit the scope of this proposal, capabilities that are not
included are:
* Do not redefine traditional SS7 STP gateway functionality such
as screening
* Do not define interworking between different protocols
* Do not include interworking between different versions of the
same protocols
* Do not include SCCP functionality
* Assuming that a traditional switch may be decomposed into a
signalling gateway and a media gateway, do not attempt to include
protocols to accommodate unique requirements between those
elements.
These capabilities may be useful in a gateway between an SS7
network and an IP sub-network which is used to transport SS7
signalling, but they are not included because they are outside the
scope of this contribution.
In general, IP transport proposed here will allow nodes without
the full SS7 signalling resources to:
* provide ISUP connection control and interface with ISUP switches
* gain access to services that are part of the Intelligent Network
capabilities in traditional SS7 voice networks
* inter-operate between circuit networks and Voice-over-IP
networks.
3.0 Discussion
Following is a list of steps to provide transport of SS7 over IP:
1. Encapsulate the SS7 information in an envelope. SS7 information
may be, e.g., ISDN User Part (ISUP), Signalling Connection Control
Part
(SCCP), probably but not necessarily the Message Transfer Part
(MTP), or possibly Transaction Capabilities Application Part
(TCAP) directly ("directly" meaning without the MTP/SCCP layers --
normally in SS7, TCAP is over SCCP, a user of the MTP).
2. Provide the necessary protocol to transport this envelope over
TCP/IP. This protocol is being called an "adaptation layer".
3. Provide the necessary modifications, if necessary to the
existing protocols as required to fit the new protocol into their
existing protocol stacks.
4. Remember in the design that this protocol is a peer-to-peer
communication layer and does not look inside the envelope or
change the contents of the envelope. Only the SS7 processing
nodes can do that, using procedures that are already defined.
5. Be sure to consider not only the protocol communication itself
but also the performance, delay, message loss, in-sequence
delivery, etc. characteristics that provide the SS7 "carrier
class" equivalent service that the SS7 users expect. [A variation
of this is to consider if there are any special users (e.g., SS7's
TCAP simple query/response) which do not require the SS7 "carrier
class" service. To accommodate the special needs of these users,
there could be compromises of the service (e.g., permitting longer
delays or not requiring in-sequence delivery).]
3.1 Network Examples
First, consider an SS7 network adjacent to a sub-network that
incorporates IP as a transport service. Assume because the end
users are SS7, the protocol data unit being transferred is ISUP,
SCCP or TCAP. Four types of nodes may be defined:
1. SS7 network Signalling Transfer Point (full MTP capabilities
are required)
2. SS7 network Signalling End Points (because there is no STP
function, the MTP transfer function and many of the signalling
network management functions of MTP Level 3 are not needed)
3. IP network Signalling Transfer Point with full MTP Level 3 (the
network diagram would look like SS7 within the IP network)
4. IP network Signalling End Points without STP function, possibly
without MTP Level 3, might have only above MTP-3, SCCP as needed.
This type of node depends on point-to-point communication among
other nodes of the same type and, therefore, does not require the
SS7 MTP routing label. Any node of this type may have specific
functionality (applications) e.g.,:
* SCP - Service Control Point (implies SCCP layer and database
application)
* SEP - Signalling End Point (implies ISUP)
* SSP - Service Switching Point (implies ISUP and SCCP layer).
In any case, for the purpose of this transport, the end users are
the existing users of the SS7 MTP, i.e., ISUP and SCCP/TCAP.
Mate STPs are redundant SS7 network nodes, each with a unique
signalling point code but also load sharing capability. In North
America, STPs are capable of sharing a common signalling point
code for access to identical SCCP functionality that is usually
distributed between the two STPs. Similarly, duplicate SS7
interfaces or nodes having identical functionality, such as mate
STPs, should be able to share a signalling point code in the IP
environment.
The specific services of TCP (e.g., TCP connections or UDP
datagrams) are discussed later and depend on the needs of the
specific adaptation layer being defined. The adaptation layers
under the existing SS7 layer and over TCP/IP each have unique
needs as will be discussed for each case. Also, this document
assumes that the addition of the adaptation layer is intended to
minimize the impact on existing SS7 and TCP/IP protocols.
4.0 Proposals
The following describes two approaches to providing SS7 transport
over TCP/IP, namely to emulate reliable MTP network transport and
to provide reliable point-to-point transport.
4.1 Emulate MTP Transport
Figure 1 shows a complete SS7 protocol stack with two data link
layers (MTP-2 and SAAL) as already defined and two new possible
data link layers as could be defined over IP to emulate reliable
MTP level 3 transport.
1. SUAL: Signalling UDP/IP Adaptation Layer (the services required
of TCP would be UDP datagrams). To provide SS7 quality, UDP
transport can be enhanced by providing error monitoring,
retransmission and guaranteed in-sequence delivery. (Note that
Real Time Protocol (RTP) provides many of these services.)
2. SCAL: Signalling TCP Connection/IP Adaptation Layer (the
services required of TCP would TCP connections over IP). In this
case, the TCP already provides reliable transport, but is not
message-based, and could be used to establish a network of point-
to-point connections. Failure detection would have to be faster
than usually associated with TCP connections.
Figure 1
Adaptation of SS7 and IP network supporting transport of SS7 MTP
interface
USERS OF SS7
------------------------------------------------
| |
+---------+ +------------------------------+
| TC USER/| | ISDN-UP |
| TCAP | | ISDN-UP |
+---------+ +------------+ |
| | | |
+------------------------+ +-----------------+
| SCCP | |
+------------------------+ |
| |
+----------------------------------------------+
| MTP-3 (B-MTP-3) |
+----------------------------------------------+
| | | |
+-------+ +------+ +---------+ +---------+
| MTP-2 | | SAAL | | SUAL | | SCAL |
+-------+ +------+ +---------+ +---------+
| | | |
+-------+ +------+ +---------+ +---------+
| MTP-1 | | ATM | | UDP/TCP | | TCP |
+-------+ +------+ +---------+ +---------+
| |
+----------------------+
| IP |
+----------------------+
Both of the examples in Figure 1 require the "full" MTP-3
implementation at each SS7 network node (for SEP or STP as
appropriate). Both of these methods communicate with standard SS7
MTP-3, including the newer version over ATM. Both of these
methods have the advantage that they provide transparent transport
for all MTP users.
4.2 Point-to-Point Transport
Figure 2 shows the SS7 protocol stack without the MTP Level 3
layer because the SS7 users need only communicate point-to-point,
without the benefit of SS7 MTP networking. This implementation
would not require the full MTP-3 at each SS7 network node, e.g.,
because the nodes have no MTP Level 2 signalling links. Consider
two variations of this approach:
1. No MTP-3 routing label is provided because no SS7 point codes
need to be involved in the communication. All communication is
point-to-point using the IP address of the node interface. If the
MTP-3 routing label were omitted, communication with the
"standard" SS7 nodes would be excluded.
2. An MTP-3 routing label is provided by the adaptation layer,
thus enabling compatibility with other nodes. Any node
implementing these interfaces can communicate with any other
similar node in either the SS7 or IP network. The network can be a
mix of these. The MTP Level 3 routing label can be present, even
though full MTP functionality is lacking. This variation then
merely distinguishes Figure 2 from Figure 1.
If there is a network failure, the adaptation layer must rapidly
detect the problem and provide any desired backup to provide SS7
"carrier class" service.
Figure 2
Adaptation of SS7 network and IP network supporting transport of
SS7 user's interface
USERS OF SS7
------------------------------------------------
| |
+---------+ +------------------------------+
| TC USER/| | ISDN-UP |
| TCAP | | ISDN-UP |
+---------+ +------------+ |
| | | | |
| +------------------+ +-----------------+
| | SCCP | |
| +------------------+ |
| | |
+----------------------------------------------+
| SPIAL |
+----------------------------------------------+
|
+----------+
| TCP |
+----------+
|
+----------+
| IP |
+----------+
Adaptation Layer: SPIAL = Signalling Point-to-Point IP Adaptation
Layer
For transfer of TCAP over IP, two interfaces are shhown. If the
services of the SCCP layer are needed, e.g., are used by a peer
user at one end of a signalling relation, then the TCAP interfaces
with the SCCP layer, which then has an interface with the SPIAP
adaptation layer. If a point-to-point signalling relation does
not require the SCCP layer, then a direct interface from TCAP to
SPIAP could be possible.
UDP could also be used with this method, but it is not considered
in this contribution only because there is not a comparable
transport method for SS7 over ATM, as there is in the datalink
case.
Three user interfaces are shown and each could each generate
unique requirements on the adaptation layer. For example, it is
possible for transactions to be simple query/responses, not
requiring the message sequencing that is assumed for all SS7
users. This contribution assumes that no distinction should be
made among different SS7 user requirements at this time, and the
objective should be to develop one common adaptation layer that
meets all these users' needs, consistent with an objective of
providing SS7 "carrier class" performance and reliability.
4.3 Comparison
Many comparisons are possible, but as an introduction, here are
major ones:
* One set of solutions (Section 4.1) create a datalink layer so
the full MTP level 3 routing and signalling network management is
available for the network communication. This would use an IP
address for each datalink.
* The other set of solutions (Section 4.2) is for point-to-point
communication and does not have the intermediate network
management. This would require an IP address for the virtual SS7
signalling point code. Any network management can be provided in
the adaptation layer.
* Adaptation layers that depend on TCP connection service have the
advantage of reliable delivery already provided. However, they
also have the overhead of TCP connections, which might be
considerable to support a large network and tweaking to improve
the failure response time would only increase the overhead.
5.0 Conclusion and Recommendations
Three adaptation layers are described here:
1. Signalling UDP/IP Adaptation Layer
2. Signalling TCP Connection/IP Adaptation Layer
(It is probably sufficient to define only #1 or #2)
3. Signalling Point-to-point Adaptation Layer
Because any of the adaptation layers may have applicability in
particular situations, work should be started to define them.
Each solution needs to evaluate the services of the underlying
TCP connections or UDP datagrams to ensure that the solution is
viable.
6.0 Acronyms
ATM Asynchronous Transfer Mode
BISDN Broadband ISDN
BMTP Broadband MTP
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
MTP Message Transfer Part
RTP Real Time Protocol
SAAL Signalling ATM Adaptation Layer
SCCP Signalling Connection Control Part
SCP Service Control Point
SEP Signalling End Point
SSP Service Switching Point
SS7 Signalling System No. 7
STP Signalling Transfer Point
TCAP Transaction Capabilities Application Part
TCP Transmission Control Protocol
UDP User Datagram Protocol
7.0 SS7 MTP Transfer Primitives
The SS7 networks have MTP transfer capabilities:
* primitives MTP Pause/Resume/Congestion
* congestion level
* Point Code
* MTP Transfer
* Originating Point Code
* Destination Point Code
* load sharing parameter (Signaling Link Selection)
* Message based, 4k bytes/message, including MTP Level 3 header
The requirements imposed on the MTP include undetected errors,
message loss, messages out-of-sequence or duplicated, failure
response time and MSU transfer time.
Relevant Standards for evaluating the needs and performance of MTP
transport over IP include are given in the references and are
based on the E series documents that are the basis for the
performance, Quality of Service, Dependability of Service, etc.,
of the SS7 series.
8.0 References
[1] ITU-T Recommendation Q.700, "Introduction To ITU-T Signalling
System No. 7"
[2] ITU-T Recommendation Q.701-Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[3] ITU-T Recommendation Q.706, "Signalling System No. 7 (SS7) -
Message Transfer Part Signalling Performance"
[3] ITU-T Recommendation Q.709, "Hypothetical Signalling Reference
Connection"
[4] ITU-T Recommendation Q.711-Q.714, "Signalling System No. 7
(SS7) - SignalingConnection Control Part (SCCP)"
[5] ITU-T Recommendation Q.761-Q.764, "Signalling System No. 7
(SS7) - Integrated Services Digital Network User Part (ISUP)"
[6] ITU-T Recommendation Q.766, "Performance Objectives in the
ISDN Application"
[7] ITU-T Recommendation Q.771-775, "Signalling System No. 7 (SS7)
- TransactionCapabilities Application Part (TCAP)"
9.0 Author
Michael A. McGrew
Lucent Technologies, Inc.
6200 East Broad Street
Columbus, Ohio 43213 USA
Tel: +1-614-860-3585
Email: mmcgrew@lucent.com
INTERNET DRAFT
Transport SS7 Signalling Over IP
<draft-mcgrew-tss7s-00.txt>
Date: November 1998
Expires: May 1999