Internet Engineering Task Force
INTERNET-DRAFT                                                   Author
Transport Working Group                                      Ian Rytina
Category: Informational                                        Ericsson
February  1999
Expires: August 1999

            Framework for Generic Common Signaling Transport Protocol
                < draft-rytina-sigtran-generic-framework-00.txt >

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section&nbsp;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 possible generic framework for the Sigtran protocol.
The intention is to define a framework for Sigtran which allows for all SCN
protocols to be added as extensions to the base Sigtran protocol, without
affecting the protocol itself. This will help progress the work in Sigtran,
so that certain "key" SCN protocols could be defined in the first stage of
the Working Group, and additional ones added at a later date, if and when

Rytina                          Informational                       [Page 1]

INTERNET-DRAFT        draft-rytina-sigtran-generic-framework-v00.txt

1. Introduction

1.1 Overview

This document outlines a possible generic framework for the Sigtran protocol.
The intention is to define a framework for Sigtran which allows for all SCN
protocols to be added as extensions to the base Sigtran protocol, without
affecting the protocol itself. This will mean that that certain "key" SCN
protocols could be defined in the first stage of the Working Group, and
additional ones added at a later date, if and when required.

1.2 Terminology

The following general term is used in this document:

Common Transport Protocol (CTP):

This is a generic term used to describe the protocol developed by Sigtran.
It is assumed to be an addition to the underlying transport protocol (TCP/UDP)
to provide the performance required by the carried SCN protocol - for example
CTP may be a protocol running over TCP or UDP. 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 CTP 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  Generic Structure

The difficulty with a working group that is defining a generic protocol to
carry other protocols is that the set of protocols which are to be supported is
potentially very large. Since there are many SCN protocols, each with different
requirements, this is a task that extremely difficult and is likely to delay
the work.

A concept of a generic structure for the protocol is being proposed in order
to put a framework in place so that a subset of "key" protocols can be worked
on, while not precluding future work on other protocols.

Essentially, the idea behind the generic structure is that all SCN protocols
have some common basic requirements for transport, and some can be further
broken down into groups of similar protocols.

Rytina                          Informational                       [Page 2]

INTERNET-DRAFT        draft-rytina-sigtran-generic-framework-v00.txt

Figure 1 outlines the ideas behind a generic protocol structure for Sigtran.
The structure consists of three types of module, arranged in a 1:n:m basis.

                              |              |
                              |   Module A   |
                              |(Generic Part)|
                              |              |
         |                    |                         |
+--------|--------+   +-------|---------+       +-------|---------+
|                 |   |                 |. . . .|                 |
|   Module B1     |   |   Module B2     |       |   Module Bn     |
|(Service Level 1)|   |(Service Level 2)|. . . .|(Service Level n)|
|                 |   |                 |       |                 |
+-------|---------+   +-------|---------+. . . .+-------|---------+
        |                     |                         |
  +-----+-------+       +-----+-------+           +-----+-------+
  |     |       |       |     |       |           |     |       |
+-|-+ +-|-+   +-|-+   +-|-+ +-|-+   +-|-+       +-|-+ +-|-+   +-|-+
|C11| |C12|. .|C1m|   |C21| |C22|. .|C2m|. . . .|Cn1| |Cn2|. .|Cnm|
+---+ +---+   +---+   +---+ +---+   +---+       +---+ +---+   +---+

                 Figure 1: Protocol Framework Modules

The three modules can be described as follows :-

Module A :

This is the main Sigtran module, which specifies the base parts of CTP,
valid for all SCN protocols being transported.

The information carried could be, for example, SCN protocol identification
indicator, input/output signaling addresses, message length, multiplexed
message information, and message sequence number.

There may also be a need for a "message type indicator", if it is decided
that management messages are required for CTP (e.g. heartbeat, keepalive)
to distinguish between those messages that are carrying the SCN native
protocols and the CTP management messages.

Module B :

These are the modules describing each different "Service Level". Different
SCN protocols may have different functional and performance requirements,
but some could be grouped together into different functional/performance
service levels.

Rytina                          Informational                       [Page 3]

INTERNET-DRAFT        draft-rytina-sigtran-generic-framework-v00.txt

For example, possible different service levels could be (this is not intended
to be a definitive list) :-

            SL1    SS7 applications on MTP3 (ISUP, SCCP)
            SL2    DSS1 applications (Q.931)
            SL3    Applications on SCCP (i.e. TCAP)
            SL4    Applications on TCAP (MAP, INAP, IS-41, etc.)
            SL5    Applications on MTP2 (MTP3)
            SLn . . . . . . . . . . . . . . . . . .

Example information that could be contained in a Module B is whether TCP or
UDP is used, retransmission timers for UDP, plus other relevant transport

In some cases, it may also be possible to encapsulate different protocols in
the same IP packet, provided that the service levels of these protocols are
the same.

Module C :

These are the actual protocol modules, one for each of the protocols being
defined to be carried by CTP, e.g. ANSI ISUP, ITU MTP3, etc., etc.

Each module C would specify its own SCN protocol identification indicator
(as described in module A), plus the service level (module B) being used by
that specific protocol. Other information such as functions to be supported
by the protocol, and possible interwork with other protocols may also be

2.2  Protocol Development

The advantage of this system is that a common CTP can be defined, without
the need to consider every protocol.

One RFC could be written to describe the generic parts and framework of CTP
(module A) and the different service level parts (modules B). This would be
the main output of the Working Group.

Internet Drafts could be submitted for each individual protocol (modules C),
as required. These could be converted to individual RFCs per module C, or if
this involves too much administration, be converted into a single RFC, which
is designed to be easily extensible.

3. Acknowledgements

The author would like to thank Lyndon Ong, Christian Groves and Mark Hollis for
their valuable input.

Rytina                          Informational                       [Page 4]

INTERNET-DRAFT        draft-rytina-sigtran-generic-framework-v00.txt

4. References

[1] L.Ong, I.Rytina :- Architectural Framework for Signaling Transport
<draft-sigtran-framework-arch-00.txt>, February 1999, work in progress.

Author's Address

Ian Rytina,
Ericsson Australia,
37/360 Elizabeth Street,
Victoria 3000,

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  "AS IS"

This Internet Draft expires in 6 months from February 1999.

Rytina                          Informational                       [Page 5]

INTERNET-DRAFT        draft-rytina-sigtran-generic-framework-v00.txt