You are on page 1of 39

SCTP Overview

John Loughney
NRC/COM Helsinki
April 4th, 2000

NOKIA John A. Loughney 3 April 2000

Introduction
Based on NRC IP Based 3G Protocols
SCTP
S=
C=
T=
P=

Simple (maybe Stream )


Control
Transmission
Protocol

SIGTRAN = Signaling Transport


IETF reference implementation should be ready this week.

NOKIA John A. Loughney 3 April 2000

Why?
IP is 'everywhere' but it an 'old' protocol (RFC 793, September
1981)
TCP has acknowledged deficiencies.
Head-of-line blocking
Vulnerable to attacks
Poor support for multihoming.
New, demanding applications & services are IP based.
IP Telephony
Streaming Audio & Video
3G
Advancing Hardware Design
Bandwidth, bandwidth, bandwidth ...

NOKIA John A. Loughney 3 April 2000

SCTP Goals
SCTP is designed to transport both PSTN signaling messages and
provide general transport solution.
SCTP is an kernel-level datagram transfer protocol operating over
IP offering:

acknowledged error-free non-duplicated transfer of user data


data segmentation to conform to discovered path MTU size,
sequenced delivery of user datagrams within multiple streams, with an
option for order-of-arrival delivery of individual messages
optional multiplexing of user messages into SCTP datagrams, subject to
MTU size restrictions
network-level fault tolerance through supporting of multi-homing at
either or both ends of an association.

Appropriate congestion avoidance behavior.


Resistance to flooding and masquerade attacks.

NOKIA John A. Loughney 3 April 2000

Work So Far
Architectural Framework For Signaling Transport document
RFC 2719
SCTP - Simple Control Transmission Protocol draft
draft submitted - draft-ietf-sigtran-sctp07.txt
SCCP user adaptation layer: used by TCAP, RANAP, etc.
Draft submitted - draft-loughney-sigtran-sua00.txt
MTP level 3 user adaptation layer: used by ISUP and SCCP.
Draft submitted - draft-ietf-sigtran-m3ua02.txt
MTP level 2 user adaptation layer: used by MTP level 3
draft submitted - draft-ietf-sigtran-m2ua-03.txt
Q.921 User adaptation layer: used by q931/DSS1
draft submitted - draft-ietf-sigtran-iua-01.txt
NOKIA John A. Loughney 3 April 2000

Functional Description of SCTP


_____________
|
|
| Association |
|
|
|
startup
|
..|
|
|
and
|
|
|
|
takedown |
..|
|
|
|
|
|
|
|
..|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|______________

NOKIA John A. Loughney 3 April 2000

____________________
| Sequenced delivery |
|
within streams
|
|____________________|
____________________________
|
User Data Segmentation |
|____________________________|
____________________________
|
Acknowledgement
|
|
and
|
|
Congestion Avoidance
|
|____________________________|
____________________________
|
Chunk Multiplex
|
|____________________________|
________________________________
|
Message Validation
|
|________________________________|
________________________________
|
Path Management
|
|________________________________|

SCTP Association
_____________
| SCTP User |
| Application |
|-------------|
|
SCTP
|
| Transport |
|
Service
|
|-------------|
|
|One or more
| IP Network |IP address
|
Service
|appearances
|_____________|

---\/
/\
----

_____________
| SCTP User |
|Application |
|-------------|
|
SCTP
|
| Transport |
|
Service
|
|-------------|
One or more|
|
IP address| IP Network |
appearances|
Service
|
|_____________|

SCTP Node A |<-------- Network transport ------->| SCTP Node B

* Usage of multiple port / address pairs


is implementation specific.

NOKIA John A. Loughney 3 April 2000

Data Transfer
+--------------------------+
|
User Messages
|
+--------------------------+
SCTP user
^ |
==================|==|=================================
| v (1)
+------------------+
+--------------------+
| SCTP DATA Chunks |
|SCTP Control Chunks |
+------------------+
+--------------------+
^ |
^ |
| v (2)
| v (2)
+--------------------------+
|
SCTP datagrams
|
+--------------------------+
SCTP
^ |
===========================|==|========================
| v
IP
(1) SCTP sender will segment user messages larger than the current path MTU into multiple data chunks., when
converting user messages into Data chunks . The segmented message will normally be reassembled from data chunks
before delivery to the user by the SCTP receiver.
(2) Multiple data and control chunks may be multiplexed by the sender into a single SCTP datagram for transmission, as
long as the final size of the datagram does not exceed the current path MTU. The receiver will de-multiplex the datagram
back into the original chunks.
NOKIA John A. Loughney 3 April 2000

Example

Endpoint A
Endpoint Z
{app sets association with Z}
(build TCB)
INIT [INIT Tag=Tag_A
& other info] --------\
(Start T1-init timer)
\
(Enter COOKIE-WAIT state)
\---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A,
/
INIT Tag=Tag_Z,
(Cancel T1-init timer) <-----/
Cookie_Z, & other info]
(destroy temp TCB)
COOKIE [Cookie_Z] -----------\
(Start T1-init timer)
\
(Enter COOKIE-SENT state)
\---> (build TCB enter ESTABLISHED state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=init TSN_A
Strm=0,Seq=1 & user data]-\
(Start T3-rxt timer)
\
\--->
/---- SACK [TSN ACK=init TSN_A,Frag=0]
(Cancel T3-rxt timer)
<------/
{app sends 2 datagrams;strm 0}
/---- DATA
/
[TSN=init TSN_Z
<--/
Strm=0,Seq=1 & user data 1]
/---- DATA
SACK [TSN ACK=init TSN_Z,
[TSN=init TSN_Z + 1,
Frag=0]
---------\/
<------/\
Strm=0,Seq=2 & user data 2]
\--->
NOKIA John A. Loughney 3 April 2000

TCP Drawbacks
TCP provides reliable data transfer with strict order-oftransmission delivery. Some applications need only reliable
transfer, while others need only partial ordering of the data. In
both of these cases the head-of-line blocking offered by TCP
causes unnecessary delay.
TCP stream support is often an inconvenience. Applications must
add their own record marking to delineate their messages, and
must make explicit use of the push facility to ensure that a
complete message is transferred in a reasonable time.
The limited scope of TCP sockets complicates the task of
providing highly-available data transfer capability using multihomed hosts.
TCP is relatively vulnerable to denial of service attacks, such as
SYN attacks.
NOKIA John A. Loughney 3 April 2000

Differences between TCP & SCTP


SCTP is connection-oriented in nature, but the SCTP association
is a broader concept than the TCP connection.
The term "stream" is used in SCTP to refer to a sequence of user
messages. This is in contrast to its usage in TCP, where it refers to
a sequence of bytes.

NOKIA John A. Loughney 3 April 2000

Congestion Control (1/3)


The congestion control algorithms used by SCTP are based on RFC
2581 "TCP Congestion Control".
SCTP congestion control is always applied to the entire
association, and NOT to individual streams.
The Selective Acknowledgment function (SACK) is designed into
SCTP, rather than an enhancement that is added to the protocol
later as is the case for TCP. SCTP SACK carries the same semantic
meaning with that of TCP SACK.
Multi-homing in SCTP, may lead differing data paths between the
two points, thus a separate set of congestion control parameters
for each of the paths.

NOKIA John A. Loughney 3 April 2000

Congestion Control (2/3)


Congestion control variables similar to TCP:
Receiver advertised window size (rwnd, in octets), which is set
by the receiver based on its available buffer space for
incoming packets.
Congestion control window (cwnd, in octets), which is
adjusted by the sender based on observed network conditions.
Slow-start threshold (ssthresh, in octets), which is used by the
sender to distinguish slow start and congestion avoidance
phases.
SCTP also requires one additional control variable,
partial_bytes_acked, which is used during congestion avoidance
phase to facilitate cwnd adjustment.
Unlike TCP, an SCTP sender MUST keep a set of these control
variables for EACH destination address of its peer (when its peer
is multi-homed).
NOKIA John A. Loughney 3 April 2000

Congestion Control (3/3)


A straightforward implementation Fast Retransmission on Gap
Reports, requires that the sender keeps a counter for each TSN
hole first reported by a SACK; the counter keeps track of whether
3 subsequent SACKs have reported the same hole.
TCP-like fast-recovery is achieved automatically, because cwnd in
SCTP indirectly bounds the number of outstanding TSN's, with no
adjustment to the congestion control window size.

NOKIA John A. Loughney 3 April 2000

SS7 over IP Architecture


******
SS7 ******* SS7 ************ IP
*******
*SEP *--------* STP *------*
SG
*-------*ISEP *
******
*******
************
*******
+-----+
|S7AP |
+-----+
|Adap.|
|layer|
+-----+
|MTP |
|
|
|
|
+-----+

+-----+
|MTP |
|
|
|
|
+-----+
SEP
STP
SG
ISEP
S7AP

NOKIA John A. Loughney 3 April 2000

+---------+
| Adap. |
| layer |
+---------+
|MTP |SCTP|
|
+----+
|
| IP |
+---------+

= Signaling End Point


= Signaling Transfer Point
= Signaling Gateway
= IP Signaling Endpoint
= SS7 Application protocol

+-----+
|S7AP |
+-----+
|Adap.|
|adap |
+-----+
|SCTP |
+-----+
| IP |
+-----+

SIGTRAN in 3GPP
3GPP Rel 99 Packet Architecture
RANAP (Iu interface)
RNSAP (Iur interface)
3GPP Rel 00 - All IP architecture
MAP over 'SIGTRAN'
CAP over 'SIGTRAN'
R-SGW
T-SGW

NOKIA John A. Loughney 3 April 2000

Open Issues
Bounded transfer delay -> No Changes.
Inadequate congestion control. -> No Changes.
On failover, ability to not do slow start on failover link
Load balancing in SCTP. -> No Changes.
SCTP support of load balancing in the ULP.
Host names -> Slight Change in Draft.
Modified TSN windowing calculation. -> Slight Change in Draft.
Cancel chunk operation -> Slight change & future study.
Per-stream rwnd -> Future Study.
Support of source address selection, IP source routing and persource/Destination address pair congestion control. -> Future
Study.
Adding / deleting addresses in an association. -> Future Study.
NOKIA John A. Loughney 3 April 2000

Uses of SCTP?
Already specified for carrying SS7 protocols in 3GPP.
RANAP, RSNAP
MAP/TCAP, CAP/TCAP
HTTP
AAA
SIP
MEGACO protocol
BICC (Bearer Independent Call Control)

NOKIA John A. Loughney 3 April 2000

Effects on Other Protocols


IKE (Internet Key Exchange) needs to be modified to more fully
support multihoming.
SCTP implementation may use TCP-like socket calls, to more
easily allow integration of existing protocols.

NOKIA John A. Loughney 3 April 2000

Areas to Study
Performance studies and simulations.
Applying existing TCP optimizations to SCTP.
SCTP over wireless devices.
Creative uses of multihoming.
Fair queuing when assigning TSNs to different streams.

NOKIA John A. Loughney 3 April 2000

MTP-3 User Adaptation Layer


John A. Loughney
Nokia Research Center

NOKIA John A. Loughney 3 April 2000

ISUP Transport
********
SS7
*****************
IP
********
* SEP *---------*
SG
*--------* ASP *
********
*****************
********
+------+
+------+
| ISUP |
(NIF)
| ISUP |
+------+
+------+-+------+
+------+
| MTP3 |
| MTP3 | | M3UA |
| M3UA |
+------|
+------+ +------+
+------+
| MTP2 |
| MTP2 | | SCTP |
| SCTP |
+------+
+------+ +------+
+------+
| L1 |
| L1 | | IP |
| IP |
+------+
+------+ +------+
+------+
|_______________|
|______________|
SEP - SS7 Signaling End Point
SCTP - Simple Common Transport Protocol
NIF Nodal Interworking Function

NOKIA John A. Loughney 3 April 2000

Major Terminology
Application Server (AS) - A logical entity serving a specific
Routing Key.
Application Server Process (ASP) - An Application Server Process
serves as an active or standby process of an Application Server
(e.g., part of a distributed virtual switch or database element).
Routing Key: At the SG, the Routing Key describes a set of SS7
parameter/parameter-ranges that uniquely defines the range of
signaling traffic configured to be handled by a particular
Application Server.
Routing Context from the perspective of an ASP, the Routing
Context uniquely identifies the range of traffic associated with a
particular Application Server, which the ASP is configured to
receive from the SG.

NOKIA John A. Loughney 3 April 2000

SCCP Transport
********
SS7
*****************
IP
********
* SEP *---------*
*--------*
*
* or *
*
SG
*
* ASP *
* STP *
*
*
*
*
********
*****************
********
+------+
+---------------+
+------+
| SCCP |
|
SCCP
|
| SCCP |
+------+
+------+-+------+
+------+
| MTP3 |
| MTP3 | | M3UA |
| M3UA |
+------|
+------+ +------+
+------+
| MTP2 |
| MTP2 | | SCTP |
| SCTP |
+------+
+------+ +------+
+------+
| L1 |
| L1 | | IP |
| IP |
+------+
+------+ +------+
+------+
|_______________|
|______________|
STP - SS7 Signaling Transfer Point

NOKIA John A. Loughney 3 April 2000

Example (1/2)
********
**************
*
*_________________________________________* ******** * Host1
*
*
_________* * ASP1 * *
* SG1 *
SCTP Associations
|
* ******** *
*
*_______________________
|
* ******** *
*
*
|
|
* * ASP2 * *
*
*
|
|
* ******** *
*
*
|
|
* ******** *
*
*
|
|
* * ASP3 * *
********
|
|
* ******** *
|
|
*
.
*
********
|
|
*
.
*
*
*_______________________________|
*
*
*
*
|
* ******** *
* SG2 *
SCTP Associations |
* * ASPn * *
*
*____________
|
* ******** *
*
*
|
|
**************
*
*
|
|
**************
*
*
|
|_________________* ******** * Host2
*
*
|____________________________* * ASP1 * *
********
* ******** *
* ******** *
* * ASP2 * *
* ******** *
* ******** *
* * ASP3 * *
* ******** *
*
.
*
*
.
*
*
*
* ******** *
* * ASPn * *
* ******** *
**************
.
.
.
NOKIA John A. Loughney 3 April 2000

Example (2/2)
+--------+
|
|
+------------+ SG 1 +--------------+
+-------+
|
| "STP" |
|
---| SEP +---+
+--------+
+---/
\
|
or |
| ASPs
|
| STP +---+
+--------+
+---\
/
+-------+
|
|
|
|
---+------------+ SG 2 +--------------+
| "STP" |
+--------+

NOKIA John A. Loughney 3 April 2000

Messages
Transfer Messages

Data

0101

SS7 Signaling Network Management (SSNM) Messages

Destination
Destination
Destination
SS7 Network
Destination

Unavailable (DUNA)
Available (DAVA)
State Audit (DAUD)
Congestion State (SCON)
User Part Unavailable (DUPU)

0201
0202
0203
0204
0205

Application Server Process Maintenance (ASPM) messages

ASP Up
ASP Down
Heartbeat
ASP Active
ASP Inactive

0301
0302
0303
0401
0402

Management (MGMT) Messages

Error
Notify

NOKIA John A. Loughney 3 April 2000

0000
0001

Basic Introduction
Removed explicit SCN protocol id & protocol ID
Cleaned-up SG configuration terminology
Expanded to include n+k redundancy, load-sharing
Better description of fail-over operation
Added ability for ASP to route SS7 traffic across redundant SGs
Added point code lists in SSNM messaging
Made SSNM DAUD (audit) more flexible
Added state change notification SG-ASPs in AS to allow better
coordination.
User cases expanded
Added optional M3UA-level heartbeat
NOKIA John A. Loughney 3 April 2000

Current Issues
Impact of future registration protocol Component
Implementation-dependent parameters or messages (agreed, to
be added)
New SS7 Network unavailable message (agreed, to be added)
Nodal inter-working function still confusing.
More use cases (agreed, to be added)
Timer provisional values required.
ASP graceful shutdown required
Provide consistent use of MUST, SHALL, MAY

NOKIA John A. Loughney 3 April 2000

New Issues
Add case of SG sending UPU into SS7 when all ASPs in SPMC are
unavailable.
Use of TCP
IP to IP M3UA.
Specify explicit data recovery from a failed SCTP association (use
like SS7 changeover?)
SCON from ASP to SG to indicate ASP nodal congestion?

NOKIA John A. Loughney 3 April 2000

SCCP User Adaptation Layer


Update from the 47th IETF Meeting: Adelaide,
Australia
draft-loughney-sigtran-sua-00.txt
John A. Loughney

NOKIA John A. Loughney 3 April 2000

Why
SCCP-users can run over IP.
There are existing, proprietary solutions (i.e. - TCAP over
IP).
All IP 3G Networks are currently in development, which
use application protocols over SCCP, but IP for transport.
Point-to-point and via Signaling Gateways.
Simplifies the protocol stack.

NOKIA John A. Loughney 3 April 2000

How
Keep SCCP-User lower interface intact.
Allow protocol options.
Connection-less & connection oriented, etc.
Transfer SCCP-User messages over SCTP/IP.
CAP/TCAP, MAP/TCAP, RANAP, etc.
Allow flexible protocol & architectural implementation.
Support for distributed IP-based signaling nodes.
Inter-work with legacy SS7 networks.

NOKIA John A. Loughney 3 April 2000

General Architecture Protocol Stack


********
SS7
***************
IP
********
* SEP *---------*
*--------*
*
* or *
*
SG
*
* ASP *
* STP *
*
*
*
*
********
***************
********
+------+
+------+
| AP |
| AP |
+------+
+------+------+
+------+
| SCCP |
| SCCP | SUA |
| SUA |
+------+
+------+------+
+------+
| MTP3 |
| MTP3 |
|
|
|
+------|
+------+ SCTP |
| SCTP |
| MTP2 |
| MTP2 |
|
|
|
+------+
+------+------+
+------+
| L1 |
| L1 | IP |
| IP |
+------+
+------+------+
+------+
|
|
|
|
+----------------+
+-------------+
NOKIA John A. Loughney 3 April 2000

General Architecture Example


Signaling
Gateway

AS1

SCTP Associations

AS3
ASP1
ASP2

ASP1
ASP3

SS7
Network

ASP2

AS2
ASP1

AS4
ASP1

ASP2
ASP2

Note: The Signaling Gateway may be realized as a cluster.


Application Servers may be distributed as well.
NOKIA John A. Loughney 3 April 2000

All-IP Architecture Protocol Stack


********
IP
********
*
*--------*
*
* AS *
* AS *
*(ASP) *
*(ASP) *
********
********
+------+
+------+
| AP |
| AP |
+------+
+------+
| SUA |
| SUA |
+------+
+------+
| SCTP |
| SCTP |
+------+
+------+
| IP |
| IP |
+------+
+------+
|
|
+---------------+

NOKIA John A. Loughney 3 April 2000

All-IP Architecture Example


AS1

SCTP Associations

AS3

ASP1

ASP1

ASP2

ASP2
ASP3

AS2
ASP1

AS4
ASP1

ASP2
ASP2
ASP3

NOKIA John A. Loughney 3 April 2000

Messages
Data Transfer Messages
Data Transfer (DATRA)

Data Acknowledge (DAACK)

Connection Messages
connection request (CONRE)
release request (RELRE)
reset confirm (RESCO)

connection acknowledge (CONAK)


release complete (RELCO)
reset request (RESRE)

Application Server Process Maintenance (ASPM) Messages


ASP Up (ASPUP)
ASP Active (ASPAC)
ASP Takeover (ASPTO)
No Active ASP (NAASP)

ASP Down (ASPDN)


ASP Inactive (ASPIA)
Notify (NTFY)

SUA Management Messages


Error (ERR)
Stream Configuration (SCO)

Audit (AUD)
Stream Configuration Acknowledge (SCA)

SS7 Signaling Network Management (SSNM) Messages


Destination Unavailable (DUNA)
Destination Available (DAVA)
Destination State Audit (DAUD)
SS7 Network Congestion State (SCON)
Destination User Part Unavailable (DUPU)

Other
Vendor-Specific Message (VEND)
NOKIA John A. Loughney 3 April 2000

To Do
Improve all-IP architecture.
Administrative resources for AS.
Avoid dual client & server ASP.
Avoid association setup collision
Specify in a more detailed way which protocols features
are mandatory and those that are optional.
Add more use cases & examples.
Rework management messages.
Application Server Process Maintenance Messages.
SS7 Management Messages
Approve draft for WG status

NOKIA John A. Loughney 3 April 2000

You might also like