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 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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
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
required.
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
information.
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
included.
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,
Melbourne,
Victoria 3000,
Australia
ian.rytina@ericsson.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 "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet Draft expires in 6 months from February 1999.
Rytina Informational [Page 5]
INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt