Probando SCTP en linux debian= proyecto lksctp

Como sabran sctp es la implementacion del protocolo de la capa de transporte usado en sigtran (asi se implementa en forma practica, aunque pudieramos hacer un despliegue sigtran sobre udp), sctp posee algunas ventajassobre su primo tcp:

• Reliability mechanisms—TCP provides both reliable data transfer, through acknowledgments mechanism, and strict order of transmission delivery of data, through sequencing mechanism. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases the head-of-line blocking caused by TCP adds unnecessary delay.

• Real-time issues—The abovementioned acknowledgement mechanism (which added the unnecessary delay) makes the TCP inappropriate for real-time applications.

• TCP sockets—The limited scope of TCP sockets complicates the task of providing highly available data transfer capability using multi-homed hosts.

• Security issues—TCP is relatively vulnerable to denial-of-service attacks.

Se supone que por diseñosctp no adolece de estas debilidades.

Es posible en linux probar este protocolo: (proyecto lksctp)

http://lksctp.sourceforge.net/index.html

http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm

Linux Kernel SCTP (LKSCTP)

The LKSCTP implementation of SCTP runs in kernel space. For our tests, we used Linux kernel 2.5.65 and lksctp-2_5_65-0_6_8.

Detailed information on LKSCTP can be found on the Web site of the LKSCTP project. According to Randall Stewart (co-author of SCTP), the version of LKSCTP that we tested is not completely compliant with RFC 2960 and the current Implementer’s Guide, and is not optimized for performance. The latter was confirmed by Jon Grimm, from the LKSCTP project.

Loading the SCTP modules is done with: /sbin/modprobe -a sctp

Otras implementaciones de SCTP disponibles:

Linux Linux
(http:// (http://sourceforge sourceforge.net/projects/ .net/projects/lksctp lksctp/) /)

FreeBSD/ FreeBSD/NetBSD NetBSD/ /OpenBSD OpenBSD
(http://www. (http://www.sctp sctp.org) .org)

Solaris Solaris
(http://playground.sun.com/ (http://playground.sun.com/sctp sctp/) /)

libss7 en asterisk

svn co http://svn.digium.com/svn/zaptel/branches/1.4 zaptel-1.4`
`cd zaptel-1.4`
`make; make install`

`svn co http://svn.digium.com/svn/libss7/trunk libss7-trunk`
`cd libss7-trunk`
`make; make install`

`svn co http://svn.digium.com/svn/asterisk/trunk asterisk-trunk`
`cd asterisk-trunk`
`./configure; make; make install;`

CONFIGURATION:
In zaptel.conf, your signalling channel(s) should be a “dchan” and your
bearers should be set as “bchan”.

In the asterisk-ss7 branch, there is a sample zapata.conf that is
installed which contains sample configuration for setting up an E1 link.

In brief, here is a simple ss7 linkset setup:

signalling = ss7
ss7type = itu ; or ansi if you are using an ANSI link

linkset = 1 ; Pick a number for your linkset identifier in
; zapata.conf

pointcode = 28 ; The decimal form of your point code. If you
; are using an
; ANSI linkset, you can use the xxx-xxx-xxx
notation for
; specifying your linkset pointcode.
adjpointcode = 2 ; The point code of the switch adjacent to your
; linkset

defaultdpc = 3 ; The point code of the switch you want to send
; your ISUP
; traffic to. A lot of the time, this is the
; same as your
; adjpointcode.

; Now we configure our Bearer channels (CICs)

cicbeginswith = 1 ; Number to start counting the CICs from. So if
; Zap/1 to Zap/15 are CICs 1-15, you would set
; this to 1 before you
; declare channel=1-15

channel=1-15 ; Use Zap/1-15 and assign them to CICs 1-15

cicbeginswith = 17 ; Now for Zap/17 to Zap/31, they are CICs 17-31
; so we initialize
; cicbeginswith to 17 before we declare those
; channels

channel = 17-31 ; This assigns CICs 17-31 to channels 17-31

signchan = 16 ; This is where you declare which Zap channel is
; your signalling
; channel. In our case it is Zap/16. You can
; add redundant
; signalling channels by adding additional
; sigchan= lines.

; If we want an alternate redundant signalling channel add this

sigchan = 48 ; This would put two signalling channels
in our ; linkset, one at Zap/16 and one at Zap/48 which
; both would be used to send/receive
; ISUP traffic.

; End of zapata.conf

This is how a basic linkset is setup. For more detailed zapata.conf SS7
config information as well as other options available for that file, see
the default zapata.conf that comes with the samples in asterisk. If you
would like, you can do a `make samples` in your asterisk-trunk directory
and it will install a sample zapata.conf for you that contains more
information about SS7 setup.

Sobre sigtran

Sigtran is the name given to an Internet Engineering Task Force (IETF) working group that produced specifications for a family of protocols that provide reliable datagram service and user layer adaptations for SS7 and ISDN communications protocols. SIGTRAN is logically an extension of the SS7 protocol family. It supports the same application and call management paradigms as SS7 but uses an IP transport called Stream Control Transmission Protocol (SCTP) as its underlying transport vehicle. Indeed, the most significant protocol defined by the SIGTRAN group was SCTP, which is used to carry PSTN signaling over IP.

The SIGTRAN group was significantly influenced by telecommunications engineers intent on using the new protocols for adapting VoIP networks to the PSTN with special regard to signaling applications. Recently, SCTP is finding applications beyond its original purpose wherever reliable datagram service is desired.

The SIGTRAN family of protocols includes:

• ISDN User Adaptation (IUA)
• MTP2 User Peer-to-Peer Adaptation Layer (M2PA)
• MTP2 User Adaptation Layer (M2UA)
• MTP3 User Adaptation Layer (M3UA)
• Stream Control Transmission Protocol (SCTP)
• SCCP User Adaptation (SUA)
• V5 User Adaptation (V5UA)

For more information on SIGTRAN, refer to RFC 2719: Architectural Framework for Signaling Transport.

RFC 2719 also defines the concept of a Signaling Gateway (SG), which converts CCS messages from SS7 to SIGTRAN. Implemented in a variety of network elements including softswitches and Edge STPs, the SG function can provide significant value to existing common channel signaling networks, leveraging investments associated with SS7 and delivering the cost/performance values associated with IP transport.

Revisar:

http://www.iec.org/online/tutorials/ss7_over/index.html

Why is SCTP needed given TCP and UDP are widely available?

http://www.isoc.org/briefings/017/index.shtml

http://www.sigtran.ss7box.com/

http://www.protocols.com/pbook/sigtran.htm

M3UA [MTP-3 User Adaptation Layer/ RFC 3332] is a SIGTRAN protocol. It transports SS7 MTP-3 user signalling over IP using SCTP. It is used in normal Signalling Gateway, Softswitch type of distributed environment.

https://sourceforge.net/projects/m3ua/

OpenSS7, SCTP and SIGTRAN

OpenSS7 is an opensource development project to provide robust and GPL’ed SS7 stack for Linux and other UNiX operation systems.

Perhaps we should have called it LinuxSS7, or SS7-For-The-Common-Man, or SS7-For-The-Rest-Of-Us, but we’re kinda attached to the name OpenSS7 as this is an opensource project.

Project Purpose

The purpose of the OpenSS7 project is to attempt to address the following impediments to the widespread use of SS7 both inside and outside the carrier community: Expense, Complexity, Collaboration, Certification, Core Competency and Expertise.

Project Background

Lists and describes some of the significant turning points in the OpenSS7 Project. These are just the highlights.

Project Mandate

Mandate of the OpenSS7 Project: build an SS7 stack.

Project Scope

Lists and describes what components are considered within the scope of the project and which are not.

Project Objectives

Lists and describes the specific objectives of the OpensSS7 Project.

What’s New in This Release:

· The SCTP, STREAMS, and ISDN components were updated.

http://www.openss7.org

Major features since the last public release are as follows:

- Support build on openSUSE 10.2.
- Support build on Fedora 7 with 2.6.21 kernel.
- Support build on CentOS 5.0 (RHEL5).
- Support build on Ubuntu 7.04.
- Updated to gettext 0.16.1.
- Supports build on Fedora Core 6.
- Support for recent distributions and tool chains.

Asterisk utiliza este desarrollo de stack sigtran (SS7) para la comunicacion PSTN (de ser necesario).

Poryectos relacionados:

Stream Control Transmission Protocol (SCTP) is a reliable, message-oriented, multihomed transport protocol. Developed by the IETF SIGTRAN working group to transport SS7 over IP, it is now the third general-purpose transport developed by the IETF.

http://www.sctp.org/

http://www.sctp.org/implementations.html

http://www.sctp.de/

http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/
(SCTP for beginners)

http://sourceforge.net/projects/lksctp
(linux kernel sctp)

SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It offers acknowledged error-free non-duplicated transfer of datagrams (messages). Detection of data corruption, loss of data and duplication of data is achieved by using checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss or corruption of data. Originally, SCTP was designed to provide a general-purpose transport protocol for message-oriented applications, as is needed for the transportation of signalling data. It has been designed by the IETF SIGTRAN working group, which has released the SCTP standard draft document ( RFC2960 ) in October 2000. Its design includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. The decisive difference to TCP is multhoming and the concept of several streams within a connection (which will be referred to as association in the rest of these documents). Where in TCP a stream is referred to as a sequence of bytes, an SCTP stream represents a sequence of messages (and these may be very short or long). SCTP can be used as the transport protocol for applications where monitoring and detection of loss of session is required. For such applications, the SCTP path/session failure detection mechanisms, especially the heartbeat, will actively monitor the connectivity of the session. An SCTP association generally looks like this, so the services of SCTP are naturally at the same layer as TCP or UDP services: Diagram showing the concept of an SCTP association _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A || SCTP Node B GSM/UMTS: RANAP, BSSAP and RNSAP over Sigtran User/Application level Protocols : : MTP lvl3 TCAP SCCP,ISUP | | | | +-----------------------+ - - +------+ - +------+ - +-------+ |User Adaptation modules| | MTP | | SCCP | | MTP 3 | +-----------------------+ | lvl2 | |------| |-------| | SCTP | | | | MTP 3| | MTP 2 | +-----------------------+ |- - - | |------| |-------| | IP Transport | | MTP | | MTP 2| | MTP 1 | +-----------------------+ | lvl1 | |------| | | | | | | MTP 1| | | Network Layer (IP) | | | | | | (a) (b) (c) (d) Figure 2.4.1: equivalence of adaptation layer to replaced layer (b) User adaptation layer = MTP lvl2 user adaptation layer (M2UA) (c) " " " = SCCP user adapatation layer (SUA) (d) " " " = MTP lvl3 User adaptation layer (M3UA) BSSAP/RANAP/RNSAP SCCP MTP3 M3UA MTP3-B MTP2 SCTP SAAL MTP1 IP ATM Stack TDM Stack IP Stack ATM