SCTP Overview

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= Simple (maybe Stream …)
•C= Control
•T= Transmission
•P= Protocol
• SIGTRAN = Signaling Transport
• IETF reference implementation should be ready this week.


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 ...


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.


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


Functional Description of SCTP
_____________ ____________________
| | | Sequenced delivery |
| Association | | within streams |
| | |____________________|
| startup |
..| | ____________________________
| and | | User Data Segmentation |
| | |____________________________|
| takedown |
..| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
..| | |____________________________|
| |
| | ____________________________
| | | Chunk Multiplex |
| | |____________________________|
| |
| | ________________________________
| | | Message Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|______________ |________________________________|


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 |<-------- Network transport ------->| SCTP Node B

* Usage of multiple port / address pairs
is implementation specific.


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.

Endpoint A
Example 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]
SACK [TSN ACK=init TSN_Z, /---- DATA
Frag=0] ---------/ [TSN=init TSN_Z + 1,
<------/ Strm=0,Seq=2 & user data 2]
--->

TCP Drawbacks
• TCP provides reliable data transfer with strict order-of-
transmission 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 multi-
homed hosts.
• TCP is relatively vulnerable to denial of service attacks, such as
SYN attacks.


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.


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.


• 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).

• 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.


SS7 over IP Architecture
****** SS7 ******* SS7 ************ IP *******
*SEP *--------* STP *------* SG *-------*ISEP *
****** ******* ************ *******

+-----+ +-----+
|S7AP | |S7AP |
+-----+ +---------+ +-----+
|Adap.| | Adap. | |Adap.|
|layer| | layer | |adap |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SCTP| |SCTP |
| | | | | +----+ +-----+
| | | | | | IP | | IP |
+-----+ +-----+ +---------+ +-----+
SEP = Signaling End Point
STP = Signaling Transfer Point
SG = Signaling Gateway
ISEP = IP Signaling Endpoint
S7AP = SS7 Application protocol


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


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 per-
source/Destination address pair congestion control. -> Future
Study.
• Adding / deleting addresses in an association. -> Future Study.

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)


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.


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.


MTP-3 User Adaptation Layer
John A. Loughney
Nokia Research Center


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


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.


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


Example (1/2)
******** **************
* *_________________________________________* ******** * Host1
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * ******** *
* * | | * * ASP2 * *
* * | | * ******** *
* * | | * ******** *
* * | | * * ASP3 * *
******** | | * ******** *
| | * . *
******** | | * . *
* *_______________________________| * *
* * | * ******** *
* SG2 * SCTP Associations | * * ASPn * *
* *____________ | * ******** *
* * | | **************
* * | | **************
* * | |_________________* ******** * Host2
* * |____________________________* * ASP1 * *
******** * ******** *
* ******** *
* * ASP2 * *
* ******** *
* ******** *
* * ASP3 * *
* ******** *
* . *
* . *
* *
* ******** *
* * ASPn * *
* ******** *
**************
.
.
.

Example (2/2)

+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | | "STP" | | ----
| SEP +---+ +--------+ +---/

| or | | ASPs
|
| STP +---+ +--------+ +---
/
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+


Messages
• Transfer Messages
• Data 0101

• SS7 Signaling Network Management (SSNM) Messages
• Destination Unavailable (DUNA) 0201
• Destination Available (DAVA) 0202
• Destination State Audit (DAUD) 0203
• SS7 Network Congestion State (SCON) 0204
• Destination User Part Unavailable (DUPU) 0205

• Application Server Process Maintenance (ASPM) messages
• ASP Up 0301
• ASP Down 0302
• Heartbeat 0303
• ASP Active 0401
• ASP Inactive 0402

• Management (MGMT) Messages
• Error 0000
• Notify 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


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 …


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?


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


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.


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.


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 |
+------+ +------+------+ +------+
| | | |
+----------------+ +-------------+

General Architecture Example

Signaling SCTP Associations AS3
Gateway ASP1

AS1 ASP2
ASP1
ASP3
SS7 ASP2
Network
AS2
AS4
ASP1
ASP1
ASP2
ASP2

Note: The Signaling Gateway may be realized as a cluster.
Application Servers may be distributed as well.

All-IP Architecture Protocol Stack
******** IP ********
* *--------* *
* AS * * AS *
*(ASP) * *(ASP) *
******** ********

+------+ +------+
| AP | | AP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+---------------+


All-IP Architecture Example
AS1 SCTP Associations AS3
ASP1 ASP1

ASP2 ASP2

ASP3

AS2
AS4
ASP1
ASP1
ASP2
ASP2
ASP3


Messages
• Data Transfer Messages
Data Transfer (DATRA) Data Acknowledge (DAACK)

• Connection Messages
connection request (CONRE) connection acknowledge (CONAK)
release request (RELRE) release complete (RELCO)
reset confirm (RESCO) reset request (RESRE)

• Application Server Process Maintenance (ASPM) Messages
ASP Up (ASPUP) ASP Down (ASPDN)
ASP Active (ASPAC) ASP Inactive (ASPIA)
ASP Takeover (ASPTO) Notify (NTFY)
No Active ASP (NAASP)

• SUA Management Messages
Error (ERR) Audit (AUD)
Stream Configuration (SCO) 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)


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


SCTP Overview

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SCTP Overview

Similar a SCTP Overview (20)

Más de John Loughney

Más de John Loughney (20)

SCTP Overview