SCTP Overview

NOKIA John A. Loughney 3 April 2000

SCTP Overview

John Loughney

NRC/COM Helsinki

April 4th, 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

* Usage of multiple port / address pairsis implementation specific.

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


Data Transfer+--------------------------+| User Messages |+--------------------------+

SCTP user ^ |==================|==|=================================

| v (1)+------------------+ +--------------------+| SCTP DATA Chunks | |SCTP Control Chunks |+------------------+ +--------------------+

^ | ^ || v (2) | v (2)

+--------------------------+| SCTP datagrams |+--------------------------+

SCTP ^ |===========================|==|========================

| vIP

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


/---- DATA/ [TSN=init TSN_Z + 1,

<------/ Strm=0,Seq=2 & user data 2]

ExampleEndpoint 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)

DATA [TSN=init TSN_AStrm=0,Seq=1 & user data]-\

(Start T3-rxt timer) \\--->/---- SACK [TSN ACK=init TSN_A,Frag=0]

(Cancel T3-rxt timer) <------/

SACK [TSN ACK=init TSN_Z,Frag=0] ---------\

\\--->

{app sends 2 datagrams;strm 0}/---- DATA/ [TSN=init TSN_Z

<--/ Strm=0,Seq=1 & user data 1]

{app sends 1st user data; strm 0}


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 usermessages. 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 parametersfor 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 PointSTP = Signaling Transfer PointSG = Signaling GatewayISEP = IP Signaling EndpointS7AP = 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 LayerJohn 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 PointSCTP - Simple Common Transport ProtocolNIF – 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 LayerUpdate from the 47th IETF Meeting: Adelaide,

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

AS3

ASP3

ASP1

ASP2

AS4ASP1

ASP2

SignalingGateway

AS1

AS2ASP1

ASP2

ASP2

ASP1

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

SS7Network

SCTP Associations


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

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

| |+---------------+


All-IP Architecture Example

AS3

ASP3

ASP1

ASP2

AS4ASP1

ASP2

AS1

ASP2

ASP1

AS2

ASP3

ASP1

ASP2

SCTP Associations


Messages• Data Transfer Messages

Data Transfer (DATRA) Data Acknowledge (DAACK)

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

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

• SUA Management MessagesError (ERR) Audit (AUD)Stream Configuration (SCO) Stream Configuration Acknowledge (SCA)

• SS7 Signaling Network Management (SSNM) MessagesDestination Unavailable (DUNA) Destination Available (DAVA)Destination State Audit (DAUD) SS7 Network Congestion State (SCON)Destination User Part Unavailable (DUPU)

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

Documents

SCTP Overview