One document matched: draft-ietf-sigtran-common-transport-00.txt
Framework for SIGTRAN Common Transport Protocol
<draft-ietf-sigtran-common-transport-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 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
document.
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).
(*1)
|| || || || ||
+------------------+ +------------------------------------+
| |--| Adaptation Modules (ADAL1....ADALn)|
| | +------------------------------------+
| | ||(*2)
| | +------------------------------------+
| |--| Sequencing Sublayer |
| Layer Control | +------------------------------------+
| and | ||
| Layer Management | +------------------------------------+
| |--| Reliability Sublayer |
| | +------------------------------------+
| | ||
| | +------------------------------------+
| |--| Link Sublayer |
+------------------+ +------------------------------------+
||(*3)
+------------------------------------+
| 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.
(*1)
|| || || || ||
+------------------+ +------------------------------------+
| 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
errors.
(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
actions.
(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
Transport
<draft-ietf-sigtran-framework-arch-02.txt>, June 1999, work in progress.
[2] R. Stewart, Q. Xie, et al :- Multi-Network Datagram Transmission
Protocol
<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
progress.
[4] G. Sidebottom, L. Ong, I. Rytina :- SS7 ISUP Tunneling
<draft-ietf-sigtran-itun-00.txt>, June 1999, work in progress.
Acknowledgements
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
"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 June 1999.
| PAFTECH AB 2003-2026 | 2026-04-24 11:10:35 |