SCTP
Tutorial
Randall
Stewart
(randall@lakerest.net)
Michael
Txen
(tuexen@=-muenster.de)
Outline
Overview
Services
provided
by
SCTP
Deployment
consideraFons
Current
developments
Timeline
of
Transport
Protocols
UDP
(RFC
768,
August
1980)
TCP
(RFC
793,
September
1981)
SCTP
(RFC
2960,
October
2000)
UDP-Lite
(RFC
3828,
July
2004)
DCCP
(RFC
4340,
March
2006)
MP-TCP
(RFC
6824,
January
2013)
Timeline
of
SCTP
RFCs
Core
Protocol
IniFal
Base
SpecicaFon
(RFC
2960,
October
2000)
Checksum
Change
(RFC
3309,
September
2002)
Errata
and
Issues
(RFC
4460,
April
2006)
Updated
Base
SpecicaFon
(RFC
4960,
September
2007)
Protocol
Extensions
ParFal
Reliability
(RFC
3758,
May
2004)
Chunk
AuthenFcaFon
(RFC
4895,
August
2007)
Address
ReconguraFon
(RFC
5061,
September
2007)
Stream
ReconguraFon
(RFC
6525,
February
2012)
API
Socket
API
(RFC
6458,
December
2011)
Protocol
Overview
ConnecFon
oriented
(SCTP
associaFon)
Supports
unicast
Same
port
number
concept
as
other
transport
protocols
Message
oriented
Supports
arbitrary
large
messages
(fragmentaFon
and
reassembly)
Supports
bundling
of
mulFple
small
messages
in
one
SCTP
packet
Flexible
ordering
and
reliability
Supports
mulFhoming
using
IPv4
and
IPv6
Packet
consists
of
a
common
header
followed
by
chunks
Extendable
AssociaFon
Setup
Four
way
handshake
Resistance
against
SYN
ooding
NegoFates
IniFal
number
of
streams
IniFal
set
of
IP
addresses
Supported
extensions
User
messages
can
already
be
transmibed
on
the
third
leg
(acer
one
RTT
i.e.
same
as
TCP)
Handles
the
case
of
both
sides
iniFaFng
the
associaFon.
Data
Transfer
TCP
friendly
congesFon
control
User
messages
are
put
into
DATA
chunks
(possibly
mulFple
in
case
of
fragmentaFon)
Each
DATA
chunk
is
idenFed
by
a
Transmission
Sequence
Number
(TSN)
Acknowledgements
(SACKs)
reporFng
CumulaFve
TSN
Gaps
(up
to
approximately
300
in
a
sack)
Duplicate
TSNs
Retransmissions
Based
on
Fmer
Based
on
gap
reports
AssociaFon
Teardown
Graceful
shutdown
Teardown
without
message
loss.
Based
on
an
exchange
of
three
messages.
Supervised
by
Fmer
No
half
close
state
is
allowed
Non-graceful
shutdown
Possibly
message
loss
Uses
a
single
message
Service:
PreservaFon
of
Message
Boundaries
Most
applicaFon
protocols
are
message
based
Simplies
applicaFon
protocols
and
its
implementaFon
Awareness
of
message
boundaries
makes
opFmal
handling
at
the
transport
layer
/
applicaFon
layer
boundary
possible
But
special
abenFon
is
needed
for
supporFng
arbitrary
large
messages
Service:
ParFal
Reliability
Allows
to
avoid
spending
resources
on
user
messages
not
being
relevant
anymore
for
the
receiver.
The
sender
can
abandon
user
messages
base
on
criteria
called
PR-SCTP
policy
PR-SCTP
policies
are
implemented
on
the
sender
side
and
does
not
require
negoFaFon.
Examples
of
PR-SCTP
policies:
LifeFme
Number
of
retransmissions
Priority
with
respect
to
buering
Service:
ParFal
Ordering
An
SCTP
associaFon
provides
up
to
2^16
uni-
direcFonal
streams
in
each
direcFon.
The
applicaFon
is
free
to
send
a
message
on
a
stream
of
its
choice.
Minimizes
head
of
line
blocking,
because
message
ordering
is
only
preserved
within
each
stream.
In
addiFon,
messages
can
be
marked
for
unordered
delivery.
The
stream
reconguraFon
extension
(RFC
6525)
allows
to
Add
streams
during
the
lifeFme
of
an
associaFon
Reset
streams
(i.e.
start
over
at
stream
sequence
0)
Service:
Network
Fault
Tolerance
Each
end-point
can
have
mulFple
IP-addresses
Each
path
is
conFnuously
supervised
Primary
path
is
used
for
iniFal
transmission
of
user
data
In
case
of
a
failure,
another
(working)
address
is
used
The
Address
ReconguraFon
extension
(RFC
5061)
allows
Add
and
delete
IP-addresses
during
the
lifeFme
of
an
associaFon
Select
the
local
and
remote
primary
path
Currently
being
specied:
loadsharing
Security
SCTP
over
IPSec
Specied
in
RFC
3554,
July
2003
MulFhoming
improvements
for
IPSec
Not
implemented
(as
far
as
the
authors
know)
TLS
over
SCTP
Specied
in
RFC
3436,
December
2002
Doesnt
provide
all
services
(no
PR-SCTP,
only
ordered
delivery)
Doesnt
scale
well
and
cant
be
implemented
directly
in
OpenSSL,
however
can
be
build
as
part
of
the
applicaFon
DTLS
over
SCTP
Specied
in
RFC
6083,
September
2010
Provides
almost
all
services
provided
by
SCTP
and
its
extensions
Implemented
in
OpenSSL
1.0.1
Usage
SIGTRAN:
Telephony
signaling
networks
RSerPool
Diameter
IPFIX
Forces
RTCWeb
RTCWeb
Transport
layer
for
data
channels
Encapsulated
in
DTLS
running
on
top
of
UDP
using
ICE/STUN/TURN
for
NAT
traversal
Usage
of
mulFple
streams
ordered
/
unordered
delivery
parFal
reliability
stream
reconguraFon
ImplementaFons
Provided
by
OS
vendor
for
FreeBSD
Linux
Solaris
The
FreeBSD
has
been
ported
to
support
Mac
OS
X
as
a
network
kernel
extension
(NKE)
Windows
as
a
kernel
driver
Windows,
Linux,
FreeBSD,
MacOS
X
as
a
userland
stack
(included
in
Firefox)
Commercial
implementaFons
for
various
operaFng
systems
ImplementaFons
are
interoperable
as
shown
in
nine
interoperability
tests.
Socket
API
(RFC
6458)
Two
programming
models:
One
to
one
Style
API
One
to
many
Style
API
Several
socket
opFons
allowing
ne-tuning
of
parameters
NoFcaFons
(events
that
happen
on
the
transport
connecFon)
AddiFonal
cmsgs
for
sendmsg()/recvmsg()
AddiFonal
funcFons
for
supporFng
mulFple
IP
addresses
per
end-point
sending
and
receiving
user
messages
TransiFon
of
sockets
between
programming
models
Mostly
supported
by
FreeBSD,
Linux
and
Solaris
allowing
users
to
write
portable
programs
NAT
Traversal
Legacy
NATs:
UDP
encapsulaFon,
allows
UDP
port
numbers
to
be
modied
by
middle-boxes
Requires
support
in
the
SCTP
end-hosts
Doesnt
require
special
support
in
the
middle-boxes
SCTP
aware
NATs:
SCTP
port
numbers
are
not
modied
by
middle-boxes
Requires
support
from
the
middle-boxes
and
the
end-
hosts,
however
no
communicaFon
between
middle-
boxes
is
required
Ongoing
SCTP-related
Work
in
TSVWG
UDP
tunneling
(in
IESG
discussion)
SCTP
aware
NATs
ECN
support
Interleaving
of
user
messages
Loadsharing
OpFmizaFons
(sack
immediately
and
others)
Conclusion
SCTP
provides
a
variety
of
exible
services
Network
fault
tolerance
ParFal
reliability
ParFal
ordering
Interoperable
implementaFons
are
available
Middleboxes
need
to
be
taken
into
account
