[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force
INTERNET-DRAFT                                                  Authors
Transport Working Group                            Ian Rytina, Ericsson
Category: Informational                     Lyndon Ong, Nortel Networks
June 1999
Expires: January 2000

            Framework for SIGTRAN Common Transport Protocol

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.  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."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at


This document outlines a framework for the Sigtran protocol that
consists of a modular, extensible structure with a common reliable
transport protocol used for all signaling transport. This structure
initially allows for narrowband SCN signalling protocols to be
transported over an IP network in order to support TDM to IP
interworking of voice and data services, and allows the protocol to
be extended for future use as required.

The reliable transport protocol addresses a set of requirements for
signaling transport which include persistent associations, reliable
data transport and sequence preservation (within a control stream).
These requirements imply a TCP-like protocol, with added functions
to support:
-- elimination of head-of-line blocking
-- rapid detection of session failure
-- failover to backup session or port
-- improved transport delay characteristics suited to signaling.

The functional characteristics for the signaling common transport
protocol are described in greater detail in the document, and these
are compared with TCP characteristics.

1. Introduction

1.1 Overview

This document outlines a framework for the Sigtran protocol. The
framework provides a modular structure using a common reliable
transport protocol for transport needs, and allowing definition
of adaptation modules for different SCN control protocols to be
added as extensions, without affecting the transport protocol itself.
This will allow progress to be made initially on a set of "key" SCN
protocols for the first stage of Sigtran activities, and adaptation
modules supporting additional protocols to be added at a later date,
as required.

1.2 Terminology

The following general term is used in this document:

Signaling Common Transport Protocol :

This is a generic term used to describe the protocol used to transport
SCN signaling protocols over IP. It is assumed to have a modular
structure that uses UDP for underlying transport functions, but adds
functions such as reliability, sequenced delivery, etc., as needed
for SCN signaling transport (see also [1]).

1.3  Scope

Signaling transport focuses on transparent transport of SCN signaling
protocols over IP networks. The signaling transport protocol will be
defined in such a way as to support encapsulation and carriage of a
variety of application and call control protocols. For more information
refer to [1].

It is the intention that the signaling transport protocol be designed
in an open manner so that it can be integrated with multimedia
frameworks such as H.323 and SIP, to provide transport of SCN
protocols in such systems.

2. Protocol Framework Architecture

2.1 Signaling Transport Components

The basic architecture, as defined in [1], is as in Figure 1 :-

                       SCN Protocols
                        |    |    |
             |      SCN Adaptation modules    |
             |  Common Signaling Transport    |
             |     Standard IP Transport      |
                      Network Layer (IP)

       Figure 1: Signaling Transport Components

The three components of Signaling Transport are :-

1) adaptation modules that support specific primitives, e.g.
   management indications, required by a particular SCN signaling
   application protocol.
2) a Signaling Common Transport Protocol that supports a common set
   of reliable transport functions for signaling transport.
3) a standard IP transport protocol (TCP/UDP) provided by the operating
   system. In some network scenarios, it has been recognised that TCP
   can provide limited (but sufficient) reliable transport
   functionality for signaling, and this is discussed later in this

In order to provide a generic modular structure, the architecture can
be further decomposed to allow full optionality according to the SCN
protocol being transported. This architecture is outlined in Figure
2a (for UDP) and Figure 2b (for TCP).

                         ||     ||     ||      ||      ||
+------------------+  +------------------------------------+
|                  |--| Adaptation Modules (ADAL1....ADALn)|
|                  |  +------------------------------------+
|                  |                    ||(*2)
|                  |  +------------------------------------+
|                  |--|         Sequencing Sublayer        |
|  Layer Control   |  +------------------------------------+
|       and        |                    ||
| Layer Management |  +------------------------------------+
|                  |--|        Reliability Sublayer        |
|                  |  +------------------------------------+
|                  |                    ||
|                  |  +------------------------------------+
|                  |--|             Link Sublayer          |
+------------------+  +------------------------------------+
                      |                 UDP                |

|| = Data
|  = Management

                 Figure 2a: Signaling Transport Sublayers
                              (Underlying Transport Protocol is UDP)

Published (open) interfaces are :-
(*1)   SCN primitives. Initially, MTP3-user, MTP2-user, Q.921-user.
(*2)   Common Signaling Transport Protocol upper primitives.
(*3)   UDP upper primitives.

                         ||     ||     ||      ||      ||
+------------------+  +------------------------------------+
| Layer Control    |--| Adaptation Modules (ADAL1....ADALn)|
|       and        |  +------------------------------------+
| Layer Management |                   ||
+------------------+                   ||(*4)
                      |                TCP                 |

|| = Data
|  = Management

                 Figure 2b: Signaling Transport Sublayers
                              (Underlying Transport Protocol is TCP)

TCP provides the sequencing, reliability and link sublayers, hence
these sublayers are null. The published (open) interfaces are :-
(*1)   SCN primitives.
(*4)   TCP upper primitives.

2.2 Definition of Sublayer Functionality

The function of the sublayers described in Figures 2a and 2b can be
defined as follows :-

- Link, Reliability, Sequencing sublayers are the Signaling
  Common Transport Protocol. These sublayers are not exposed to
  external view, and are only used to model the functions
  of the Signaling Common Transport Protocol. These sublayers
  will be empty/null, according to whether the underlying transport
  is UDP or TCP. The protocol will be based on MDTP [2].

- The Adaptation Modules (ADAL1....ADALn) make up the sublayer
  that describes the functions expected by a particular SCN
  signaling protocol. For example, one such function could be the
  mapping of different SCN primitives to the Signaling Common
  Transport Protocol primitives (and vice versa).
  In order to meet the extensibility requirement for transporting
  existing and future SCN signaling protocols [1] the structure of this
  sublayer must be made generic, and easily extensible. Two current
  examples of adaptation modules are the Backhaul Manager [3] and SS7
  ISUP Tunneling [4].

2.3 Peer-to-Peer Relationship

The relationship between two peer entities is described in Figure 3.

            ||   ||   ||   ||             ||   ||   ||   ||
+-------+ +--------------------+       +--------------------+ +-------+
|       |-| Adaptation Modules |<=====>| Adaptation Modules |-|       |
|       | +--------------------+       +--------------------+ |       |
|       |          ||                            ||           |       |
|       | +--------------------+       +--------------------+ |       |
| Layer |-|    Sequencing SL   |<=====>|    Sequencing SL   |-| Layer |
|Control| +--------------------+       +--------------------+ |Control|
|   &   |          ||                            ||           |   &   |
| Mgmnt | +--------------------+       +--------------------+ | Mgmnt |
|       |-|   Reliability SL   |<=====>|   Reliability SL   |-|       |
|       | +--------------------+       +--------------------+ |       |
|       |          ||                            ||           |       |
|       | +--------------------+       +--------------------+ |       |
|       |-|      Link SL       |<=====>|        Link SL     |-|       |
+-------+ +--------------------+       +--------------------+ +-------+
                   ||                            ||
          +--------------------+       +--------------------+
          |      TCP/UDP       |       |       TCP/UDP      |
          +--------------------+       +--------------------+
                   ||                            ||
          |                Network Layer (IP)               |

|| = Data
|  = Management

                Figure 3: Peer-to-Peer Relationship

3. Generic Protocol Framework

3.1  Generic Protocol Structure

The set of SCN control protocols which are to be supported is
potentially very large. Since there are many SCN protocols, each with
different requirements, this is best addressed by a modular framework
which allows addition of modules to support SCN protocols not addressed
in the initial specification.

The advantage of the architecture described in Section 2 is that it
assumes that all SCN protocols have similar transport requirements, so
that the only protocol specific considerations are in the adaptation
modules. One proposal is that an adaptation module document (RFC) is
written for each SCN protocol. (To be decided)

Initial work will be carried out on mapping the MTP3-user, the
MTP2-user and the Q.921-user primitives to the upper primitives of the
Signaling Common Transport Protocol [2].

3.2 Registration aspects

TBD, possibly required to register with IANA for Protocol Identifier,
and Port Numbers.

4. Signaling Common Transport Protocol

This section documents the reasoning behind the need to use a transport
protocol that has similar functionality to TCP (i.e. link, reliability
and sequencing) but also suggesting added functions that are specific
for signaling transport but are not provided by current TCP.

4.1 Requirements for Signaling Transport

Based on the architecture for signaling transport [1], it can be
determined that transport of SCN control protocols will have the
following requirements:

(a) Persistent Associations

    The applications identified in [1] require transport of
    signaling messages multiplexed from many different interactions
    (e.g., many different calls). As a result, the transport
    association should be persistent, and setup of the association
    is small relative to the duration of the association.

(b) Reliable Transport

    The performance requirements identified in [1] require that
    the transport protocol carries data reliably and with minimal

(c) Time-Dependent Transport

    The nature of signaling adds some time-dependency to transport
    requirements: signaling messages that are delayed in transport
    are in most cases no longer useful, because the associated
    SCN protocol or the user will time out and take alternative

(d) Availability

    Since multiplexed signaling affects a large number of users
    (for example, a single 56 Kbps SS7 link may support signaling
    for 50,000 individual calls per hour), availability of signaling
    transport must be high, often implemented through use of
    redundancy of devices and ports.

4.2 Functions Comparable to TCP

A number of the functions for signaling transport can be met by
use of TCP for transport, especially:

- persistent associations
- reliable transport
- sequence preservation

4.3 Functions Beyond Current TCP

Signaling transport ideally would support a number of functions
that are not provided by current TCP:

- no head-of-line blocking, i.e. multiple streams
- multilink failover for added reliability
- keep-alive function for active rapid failure detection
- message verses byte sequence numbering
- tighter timer control (than standard TCP implementations)
- greater fan out (than standard TCP implementations)

4.4 TCP for Reliable Transport

It is possible to use TCP for reliable transport, however, certain
features will not be provided as identified in the previous section.
Also, certain features of TCP may need to be turned off in order to
avoid interference with signaling transport requirements. Some of these,
for example, are :-
- use of the Nagle algorithm (adds delay)
- tbd

4.5 Security

Since signaling affects a large number of users and carries potentially
sensitive information, security is extremely important. SCN protocols
are protected by running over private links, and care should be taken
to continue this practice when running over IP. When the Signaling
Common Transport Protocol is used over a shared IP network, such as
the Internet, IPsec protocols (RFC2401, RFC2411) should be used to
secure the data and to protect the header of the IP packet.

5. Functions of Target Signaling Common Transport Protocol

The following basic functions are provided by the target Signaling
Common Transport Protocol :-

- Initialization of transport association
  - Synchronization of association state
  - Synchronization of sequence numbering
- Reliable Data Transfer
  - Forward and backward sequence numbering
  - Timers for transmission and acknowledgement
  - Notification of out-of-sequence
  - Retransmission of lost messages
- Support of multiple control streams
  - Separate sequence control and delivery of each stream
  - Request to open new streams
- Congestion control
  - Window flow control
  - Congestion avoidance based on on TCP methods, e.g. using
    retransmission backoff, window reduction, etc.
- Detection of session failure by active means, e.g. heartbeat
- Termination of association

6. References

[1] L.Ong, I.Rytina, et al :- Architectural Framework for Signaling
<draft-ietf-sigtran-framework-arch-02.txt>, June 1999, work in progress.

[2] R. Stewart, Q. Xie, et al :- Multi-Network Datagram Transmission
<draft-ietf-sigtran-mdtp-06.txt>, June 1999, work in progress.

[3] D. Auerbach, D. Berg, K, Morneault :- Signaling Backhaul Protocol
<draft-ietf-sigtran-signaling-backhaul-00.txt>, February 1999, work in

[4] G. Sidebottom, L. Ong, I. Rytina :- SS7 ISUP Tunneling
<draft-ietf-sigtran-itun-00.txt>, June 1999, work in progress.


Credit for the basic architecture diagram should be given to Tom
Taylor for supplying the original decomposition.
The authors would also like to thank M. Holdridge, C. Sharp and
G. Sidebottom for their valuable comments and suggestions.

Authors' Addresses

Ian Rytina,                       Lyndon Ong
Ericsson Australia,               Nortel Networks
37/360 Elizabeth Street,          4401 Great America Parkway
Melbourne, Victoria 3000          Santa Clara, CA 95054
Australia                         USA
ian.rytina@ericsson.com           long@nortelnetworks.com

Full Copyright Statement

Copyright (C) The Internet Society (1998).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.

However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

This Internet Draft expires in 6 months from June 1999.