|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Feb 22, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
|
|
|
|
|
|
| The charter of the SIGTRAN working group
is reported below.
|
|
|
|
The primary purpose of the Signaling Transport (SIGTRAN)
working group
will be to address the
transport of packet-based PSTN signaling over IP Networks, taking into
account functional and performance requirements of the PSTN signaling.
For interworking with PSTN, IP networks will need to transport
signaling
such as Q.931 or SS7 ISUP messages between IP nodes such as a Signaling
Gateway and Media Gateway Controller or Media Gateway.
Examples of such transport include:
|
|
| - |
Transport of signaling between a Signaling Gateway and Media
Gateway or Media Gateway Controller
|
| - |
Transport of signaling ("backhaul") from a Media Gateway to a Media
Gateway Controller
|
| - |
Transport of TCAP between a Signaling Gateway and other IP nodes
|
|
|
|
| - |
Internet dial-up remote access
|
| - |
IP telephony interworking with PSTN
|
| - |
Other services as identified
|
|
|
|
| 1. |
Architecture and Performance Requirements: The working group will
produce an informational RFC identifying functionality and
performance requirements to support signaling over IP. Signaling
messages have very stringent loss and delay requirements in the
existing telephone networks that need to be supported.
|
| 2. |
Transport: The working group will produce a standards track
proposal or proposals defining transport of signaling protocols
using SCTP, based on the requirements identified above.
|
|
These proposals will identify the method of encapsulation of different
signaling protocols. This will include differentiating between
different protocols being carried, and what components are transported,
translated or terminated at the SG. Security and resilience must be
addressed.
|
|
| Note: |
TCAP is a transaction protocol with different functions and
requirements than call control signaling. This will need to be
taken into account in its mapping to IP networks.
This work will be done in conjunction with other IETF working
groups looking at similar issues. The working group will also
ensure that good information conduits exist with groups in other
standards groups with expertise in the relevant signaling
protocols or in the network requirements for the transport of the
relevant signaling protocols.
|
|
|
The group will make use of existing IETF QoS and security technology
and
will not address creation of new QoS or security functions for IP
networks. Nor will the working group work on defining new call control
or device control protocols.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## SIGTRANwg
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
isua-04
ID Exists
(Recently Expired)
Feb 3, 2007
(140 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
SS7 ISUP-User Adaptation Layer (ISUA) |
|
This document defines a protocol for the transport of any SS7 ISUP-
User signalling (e.g, Call Control) over IP using the Stream Control
Transport Protocol [SCTP]. The protocol should be modular and
symmetric, to allow it to work in diverse architectures, such as a
Signalling Gateway and IP Signalling End-point architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
loadgrp-05
ID Exists
(Recently Expired)
Feb 3, 2007
(39 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
Load Grouping Extension for
Signalling User Adaptation Layers |
This Internet-Draft describes an extension parameter and procedure
to the Signalling User Adaptation Protocols [IUA], [M2UA], [M3UA],
[SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA], based on the Stream
Transmission Control Protocol (SCTP) [SCTP] which permits an
Application Server Processes (ASP) to indicate its placement within a
Load Group and permits an Signalling Gateway (SG) to distribute
traffic over Load Groups under Application Server Process (ASP)
control.
The described procedure provides for Override, Load-share and
Broadcast traffic mode operation within a Load Group consisting of one
or more Application Server Processes (ASPs) resulting in a mixture of
traffic modes within an Application Server (AS). The parameters and
procedures described here supplement the UA Load Selection [LOADSEL]
extension parameters and procedures for improved distribution of
traffic over ASPs and Signalling Gateway Processes (SGPs).
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
loadsel-05
ID Exists
(Recently Expired)
Feb 3, 2007
(45 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
Load Selection (LOADSEL) for
Signalling User Adaptation Layers |
|
This Internet-Draft describes Load Selection (LOADSEL) for
Signalling User Adaptation Protocols [IUA], [DUA], [V5UA], [M2UA],
[M3UA], [SUA], [GR303UA], [ISUA], [TUA], which permits an Application
Server Processes (ASP) to indicate its placement within an Application
Server and permits an Signalling Gateway (SG) to distribute traffic
over ASPs in Application Servers under Application Server Process
(ASP) control.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
m2pa-ig-01
ID Exists
(Recently Expired)
Feb 3, 2007
(9 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
SS7 MTP2-User Peer-to-Peer Adaptation Layer Implementer's Guide |
This Internet-Draft provides information for the Internet community
on clarifications and interpretations of the text of the SS7 MTP2-User
Peer-to-Peer Adaptation Layer [M2PA] based on working group comments
and experience at interoperability events. It also provides
information on specification addendum and errata -- whether of an
editorial or technical nature -- discovered to the date of this
document.
This document is intended as a companion document to the M2PA RFC
[M2PA] to be used in the implementation of M2PA to clarify the
original M2PA document.
This document updates RFC 4165 [M2PA] and text within this document
supersedes the text found in RFC 4165 [M2PA].
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
regext-04
ID Exists
(Recently Expired)
Feb 3, 2007
(33 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
Registration Extensions (REGEXT) for
Signalling User Adaptation Layers |
This memo describes Registration Extensions (REGEXT) that provides
the ability for an Application Server Process (ASP) to modify existing
Routing (Link) Keys with a Signalling Gateway (SG).
Current procedures in the SS7 Signalling User Adaptation Layers
(UAs) [M2UA], [M3UA], [SUA], [ISUA], [TUA] do not provide for the
modification of Routing (Link) Keys without deactivation of the
Application Server (AS). This causes problems in making changes to
live systems.
The extensions described in this memo permit modification of
Signalling Link membership in Application Servers for SS7 MTP2-User
Adaptation Layer [M2UA], modification of Circuit Identification Code
(CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA],
modification of Circuit Identification Code (CIC) ranges for the SS7
ISUP-User Adaptation Layer [ISUA], modificiation of Destination Local
Reference (DLR) ranges for SS7 SCCP-User Adaptation Layer [SUA], and
modification of Transaction Identifier (TID) ranges for SS7 TCAP-User
Adaptation Layer [TUA].
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
sginfo-06
ID Exists
(Recently Expired)
Feb 3, 2007
(23 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
Signalling Gateway (SG) Information (SGINFO) Support for
Signalling User Adaptation Layers |
|
This Internet-Draft describes Signalling Gateway (SG) Information
(SGINFO) for Signalling User Adaptation Protocols [M2UA], [M3UA],
[SUA], [ISUA], [TUA], which permits supporting Signalling Gateways
(SG) to convey additional Application Server (AS) support information
to Application Server Processes (ASPs) activating for AS on the SG.
This additional AS support information consists of information
pertaining to the underlying SS7 Signalling Provider that otherwise
would have to be statically configured at the Application Server
Process (ASP) or exchanged between SG and ASP using a non-IETF defined
protocol.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
bidulock-sigtran-
tua-05
ID Exists
(Recently Expired)
Feb 3, 2007
(157 p.)
[pdf(2)]
[html]
|
B. Bidulock |
|
SS7 TCAP-User Adaptation Layer (TUA) |
|
This document defines a protocol for the transport of any SS7 TCAP-
User signalling (e.g, INAP, MAP, etc.) over IP using the Stream
Control Transport Protocol [SCTP]. The protocol should be modular and
symmetric, to allow it to work in diverse architectures, such as a
Signalling Gateway and IP Signalling End-point architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
chen-sigtran-
m3ua-ext-00
ID Exists
Nov 13, 2007
(14 p.)
[pdf(2)]
[html]
|
Chen Xu
Li Xinyan
Zhang Hao
Duan Xiao Dong |
|
The proposal of extending RFC4666 for the M3UA deployment |
|
RFC 4666 defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol. Some parts of
the specification are unclear that may lead to misinterpretations
that may impair interoperability between different implementations.
RFC 4666 doesn't define the application of IPSTP-IPSEP interface. For
the signalling network management function, messages and procedures,
it needs more contributes.
This document provides clarifications and amendments to RFC 4666.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
zhang-sigtran-
m3ua-req-00
ID Exists
Feb 18, 2008
(13 p.)
[pdf(2)]
[html]
|
Zhang Hao
Chen Xu
Duan Xiao Dong
Peng jin
Zhao Yuyi |
|
The requirement of extending RFC4666 for the M3UA deployment |
RFC 4666 defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.
M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP
applications, so the network level management function isn't required.
SSNM(SS7 Signalling Network Management) messages defined in M3UA are
only used for interworking with SS7. RFC 4666 doesn't define IPSEP-
IPSTP-IPSEP application of M3UA. The signalling network management
function for this application needs to be extended.
Some parts of the specification are unclear,which may lead to
misinterpretations and may weaken interoperability.
This document provides extensions and clarifications to RFC 4666.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC2719
10/1999
(24 p.)
[html]
[pdf(2)] |
L. Ong
I. Rytina
M. Garcia
H. Schwarzbauer
L. Coene
H. Lin
I. Juhasz
M. Holdrege
C. Sharp |
SIGTRAN |
|
Framework Architecture for Signaling Transport |
|
This document defines an architecture framework and functional
requirements for transport of signaling information over IP. The
framework describes relationships between functional and physical
entities exchanging signaling information, such as Signaling Gateways
and Media Gateway Controllers. It identifies interfaces where
signaling transport may be used and the functional and performance
requirements that apply from existing Switched Circuit Network (SCN)
signaling protocols.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3094
04/2001
(106 p.)
[html]
[pdf(2)] |
D. Sprague
R. Benedyk
D. Brendes
J. Keller |
SIGTRAN |
|
Tekelec's Transport Adapter Layer Interface |
This document proposes the interfaces of a Signaling Gateway, which
provides interworking between the Switched Circuit Network (SCN) and
an IP network. Since the Gateway is the central point of signaling
information, not only does it provide transportation of signaling
from one network to another, but it can also provide additional
functions such as protocol translation, security screening, routing
information, and seamless access to Intelligent Network (IN) services
on both networks.
The Transport Adapter Layer Interface (TALI) is the proposed
interface, which provides TCAP (Transaction Capability Application
Part), ISUP (ISDN User Part), and MTP (Mail Transport Protocol)
messaging over TCP/IP. In addition, TALI provides SCCP (Signalling
Connection Control Part) Management (SCMG), MTP Primitives, dynamic
registration of circuits, and routing of call control messages based
on circuit location.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3257
04/2002
(13 p.)
[html]
[pdf(2)] |
L. Coene |
SIGTRAN |
|
Stream Control Transmission Protocol Applicability Statement |
|
This document describes the applicability of the Stream Control
Transmission Protocol (SCTP). It also contrasts SCTP with the two
dominant transport protocols, User Datagram Protocol (UDP) &
Transmission Control Protocol (TCP), and gives some guidelines for
when best to use SCTP and when not best to use SCTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3331
09/2002
(94 p.)
[html]
[pdf(2)] |
K. Morneault
R. Dantu
G. Sidebottom
B. Bidulock
J. Heitz |
SIGTRAN |
|
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer |
|
This document defines a protocol for the backhauling of Signaling
System 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages
over IP using the Stream Control Transmission Protocol (SCTP). This
protocol would be used between a Signalling Gateway (SG) and Media
Gateway Controller (MGC). It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message
Transfer Part (MTP) to provide transport. The Signalling Gateway
would act as a Signalling Link Terminal.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC3788
06/2004
(13 p.)
[html]
[pdf(2)] |
J. Loughney
M. Tuexen
J. Pastor-Balbas |
SIGTRAN |
|
Security Considerations for Signaling Transport (SIGTRAN) Protocols |
|
This document discusses how Transport Layer Security (TLS) and IPsec
can be used to secure communication for SIGTRAN protocols. The main
goal is to recommend the minimum security means that a SIGTRAN node
must implement in order to attain secured communication. The support
of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS
support is optional.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC3807
06/2004
(24 p.)
[html]
[pdf(2)] |
E. Weilandt
N. Khanchandani
S. Rao |
SIGTRAN |
|
V5.2-User Adaptation Layer (V5UA) |
This document defines a mechanism for the backhauling of V5.2
messages over IP using the Stream Control Transmission Protocol
(SCTP). This protocol may be used between a Signaling Gateway (SG)
and a Media Gateway controller (MGC). It is assumed that the SG
receives V5.2 signaling over a standard V5.2 interface.
This document builds on the ISDN User Adaptation Layer Protocol (RFC
3057). It defines all necessary extensions to the IUA Protocol
needed for the V5UA protocol implementation.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC3868
10/2004
(131 p.)
[html]
[pdf(2)] |
J. Loughney
G. Sidebottom
L. Coene
G. Verwimp
J. Keller
B. Bidulock |
SIGTRAN |
|
Signalling Connection Control Part User Adaptation Layer (SUA) |
|
This document defines a protocol for the transport of any Signalling
Connection Control Part-User signalling over IP using the Stream
Control Transmission Protocol. The protocol is designed to be
modular and symmetric, to allow it to work in diverse architectures,
such as a Signalling Gateway to IP Signalling Endpoint architecture
as well as a peer-to-peer IP Signalling Endpoint architecture.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC3873
09/2004
(46 p.)
[html]
[pdf(2)] |
J. Pastor
M. Belinchon |
SIGTRAN |
|
Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) |
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connectionless packet
network such as IP. It is designed to transport public switched
telephone network (PSTN) signaling messages over the connectionless
packet network, but is capable of broader applications.
This memo defines the Management Information Base (MIB) module which
describes the minimum set of objects needed to manage the
implementation of the SCTP.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4129
08/2005
(15 p.)
[html]
[pdf(2)] |
R. Mukundan
K. Morneault
N. Mangalpally |
SIGTRAN |
|
Digital Private Network Signaling System (DPNSS)/ Digital Access Signaling System 2 (DASS 2)
Extensions to the IUA Protocol |
|
This document defines a mechanism for backhauling Digital Private
Network Signaling System 1 (DPNSS 1) and Digital Access Signaling
System 2 (DASS 2) messages over IP by extending the ISDN User
Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1,
specified in ND1301:2001/03 (formerly BTNR 188), is used to
interconnect Private Branch Exchanges (PBX) in a private network.
DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.
This document aims to become an Appendix to IUA and to be the base
for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4165
09/2005
(53 p.)
[html]
[pdf(2)] |
T. George
B. Bidulock
R. Dantu
H. Schwarzbauer
K. Morneault |
SIGTRAN |
|
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
User Peer-to-Peer Adaptation Layer (M2PA) |
|
This document defines a protocol supporting the transport of
Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
signaling messages over Internet Protocol (IP) using the services of
the Stream Control Transmission Protocol (SCTP). This protocol would
be used between SS7 Signaling Points using the MTP Level 3 protocol.
The SS7 Signaling Points may also use standard SS7 links using the
SS7 MTP Level 2 to provide transport of MTP Level 3 signaling
messages. The protocol operates in a manner similar to MTP Level 2
so as to provide peer-to-peer communication between SS7 endpoints.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4233
01/2006
(73 p.)
[html]
[pdf(2)] |
K. Morneault
S. Rengasami
M. Kalla
G. Sidebottom |
SIGTRAN |
|
Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer |
This document defines a protocol for backhauling of Integrated
Services Digital Network (ISDN) Q.921 User messages over IP using the
Stream Control Transmission Protocol (SCTP). This protocol would be
used between a Signaling Gateway (SG) and Media Gateway Controller
(MGC). It is assumed that the SG receives ISDN signaling over a
standard ISDN interface.
This document obsoletes RFC 3057.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4666
09/2006
(124 p.)
[html]
[pdf(2)] |
K. Morneault
J. Pastor-Balbas |
SIGTRAN |
|
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA) |
This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol. Also,
provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database, or between two IP-
based applications. It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message
Transfer Part (MTP) to provide transport.
This document obsoletes RFC 3332.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC5133
12/2007
(4 p.)
[html]
[pdf(2)] |
M. Tuexen
K. Morneault |
SIGTRAN |
|
Terminal Endpoint Identifier (TEI) Query Request Number Change |
|
The Integrated Services Digital Network (ISDN) Q.921-User Adaptation
Layer (IUA) Protocol, described in RFC 4233, defines the message type
of Terminal Endpoint Identifier (TEI) Query Request messages as 5.
However, this number is already being used by the Digital Private
Network Signaling System (DPNSS)/Digital Access Signaling System 2
(DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.
This document updates RFC 4233 such that the message type of TEI
Query Request messages is 8.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
