
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by <NAME>
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[conference]{IEEEtran}
% Add the compsoc option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% <NAME>'s ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
\usepackage{cite}
% cite.sty was written by <NAME>
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by <NAME> and <NAME>. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by <NAME> which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by <NAME> and <NAME>.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by <NAME>) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by <NAME>:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% <NAME>'s and <NAME>'s array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is <NAME>'s extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is <NAME>'s eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by <NAME>. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by <NAME>, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/


\usepackage{verbatim}

% *** FLOAT PACKAGES ***
%
\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% <NAME> and <NAME>. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by <NAME>. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
\usepackage{url}
% url.sty was written by <NAME>. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.



\usepackage{listings}

% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{SCTP: What is it, and how to use it?}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
\author{\IEEEauthorblockN{Randall~Stewart}
        \IEEEauthorblockA{Cisco Systems Inc.\\
                          4875~Forest Drive\\
                          Suite~200\\
                          Columbia, SC~29206\\
                          USA\\
                          Email: <EMAIL>}
\and
    \IEEEauthorblockN{Michael~T\"uxen}
    \IEEEauthorblockA{M\"unster University of Applied Sciences\\
                      Department of Electrical Engineering\\
                      and Computer Science\\
                      Stegerwaldstr.~39\\
                      D-48565 Steinfurt\\
                      Germany\\
                      Email: <EMAIL>}
\and
    \IEEEauthorblockN{Peter~Lei}
    \IEEEauthorblockA{Cisco Systems Inc.\\
                      8735~West Higgins Road\\
                      Suite~300\\
                      Chicago, IL~60631\\
                      USA\\
                      Email: <EMAIL>}
}
% \and
% \IEEEauthorblockN{<NAME>}
% \IEEEauthorblockA{Twentieth Century Fox\\
% Springfield, USA\\
% Email: <EMAIL>

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{<NAME>\IEEEauthorrefmark{1},
%<NAME>\IEEEauthorrefmark{2},
%<NAME>\IEEEauthorrefmark{3}, 
%<NAME>\IEEEauthorrefmark{3} and
%<NAME>\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: <EMAIL>}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath
Stream Control Transmission Protocol~(SCTP) is a new transport protocol incorporated into  FreeBSD~7.0. It was first standardized by the Internet Engineering Task Force~(IETF)
in October of 2000 in~RFC~2960 and later updated by~RFC~4960.
SCTP is a message oriented protocol providing  reliable end to end communication
between two peers in an IP network.  
So, why would one want to use SCTP instead of just using TCP or UDP?

This paper will try to answer that question by detailing
services provided by SCTP, and illustrating how SCTP can be easily used
with the socket API.
\end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract.
% This preserves the distinction between vectors and scalars. However,
% if the conference you are submitting to favors bold math in the abstract,
% then you can use LaTeX's standard command \boldmath at the very start
% of the abstract to achieve this. Many IEEE journals/conferences frown on
% math in the abstract anyway.

% no keywords




% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
%\IEEEpeerreviewmaketitle



\section{Introduction}
% no \IEEEPARstart
Stream Control Transmission Protocol (SCTP)~\cite{rfc4960} is a reliable, message oriented
transport protocol that provides new services and features for IP communication.
For the past twenty years, reliable communication service has been provided by TCP~\cite{rfc793}, and unreliable service has been provided by UDP~\cite{rfc768}.
So, what has brought about the addition of a third protocol to the IP suite of protocols? Many of the features found in TCP and UDP can also be found in SCTP.
See TABLE~\ref{features} for a comprehensive comparison of the features. 

\begin{table}
\begin{center}
\begin{tabular}{|l|r|r|r|}
\hline
Service/Features               & SCTP & TCP & UDP \\\hline
\hline
Message-Oriented               & yes  & no  & yes \\\hline 
Byte-Oriented                  & no   & yes & no  \\\hline
Connection-Oriented            & yes  & yes & no  \\\hline
Full Duplex                    & yes  & yes & yes \\\hline
Reliable data transfer         & yes  & yes & no  \\\hline
Partially-Reliable data transfer & opt  & no  & no  \\\hline
Ordered data delivery          & yes  & yes & no  \\\hline
Unordered delivery             & yes  & no  & yes \\\hline
Flow control                   & yes  & yes & no  \\\hline
Congestion Control             & yes  & yes & no  \\\hline
ECN Capable                    & yes  & yes & no  \\\hline
Selective Acknowledgments      & yes  & opt & no  \\\hline
Path MTU discovery             & yes  & yes & no  \\\hline
Application PDU fragmentation  & yes  & yes & no  \\\hline
Application PDU bundling       & yes  & yes & no  \\\hline
Multistreaming                 & yes  & no  & no  \\\hline
Multihoming                    & yes  & no  & no  \\\hline
Dynamic Multihoming            & opt  & no  & no  \\\hline
SYN flooding attack prevention & yes  & no  & n/a \\\hline
Allows half-closed state       & no   & yes & n/a \\\hline
Reach-ability check            & yes  & opt & no  \\\hline
Pseudo-header for checksum     & no   & yes & yes \\\hline
Time wait state                & no   & yes & n/a \\\hline
Authentication                 & opt  & opt & no  \\\hline
CRC based checksum             & yes  & no  & no  \\\hline
\end{tabular}
\end{center}
\caption{Feature List \label{features}}
\end{table}
As you can see, SCTP overlaps and adds to the list
of features that an application developer can draw upon.  The rest of this document will be laid
out as follows: In Section II we will compare and contrast the feature sets of SCTP, TCP and UDP.
In Section III we will provide an overview of the socket API used with SCTP. In Section IV we will
get into some of the details for using the SCTP socket API. In Section V we will close
with a brief review and a few conclusions.

\section{A comparison of features}
SCTP, like TCP, provides a connection oriented, full duplex, reliable data communication path. 
Many of the standard features you will find in TCP (congestion control, flow control, etc.)
can also be found in SCTP. However, unlike TCP, SCTP provides a transport of messages, not just
bytes. In this section we will go through the unique and strikingly different
features found in SCTP. For features that are the same (e.g. congestion control in TCP versus
SCTP) we will not comment and allow the reader to research the feature
in TCP (if interested) since SCTP and TCP will react in the same way.

\subsection{Ordering options}
\label{hol}
One of the two most striking features of SCTP is ``multi-streaming.'' When you hear
this term, what is being referred to in reality is the ordering options that SCTP provides.
The term is also where the ``stream'' in SCTP's name comes from.

In a classic TCP connection, you have no choices in the ordering and presentation of your
data to your peer. All bytes transmitted are delivered in strict transmission order. In many
instances this is exactly what an application wants. Consider for a moment a set of
transactions to a banking system from a client application. If a transfer of
money is first sent, followed by a sizable withdrawal from that account, we would not want
these two requests reversed in order; absolute order is important. 

Now consider that same set of transactions with multiple users involved. A withdrawal or
deposit for customer A is unimportant with respect to customer B (assuming the transactions
are not between customers A and B).  Thus, if the transactions
being sent over the connection pertain to multiple users, ordering between the
separate transactions is not important. In fact, strict ordering can actually cause
an undesirable additional delay in processing in the presence of network loss.
When such a delay happens, it is termed Head of Line (HOL) blocking.
But how exactly does this occur?

\begin{figure}
\includegraphics{lostpacket}
\caption{A lost packet}
\label{lost}
\end{figure}

Let us consider a TCP connection as shown in Fig~\ref{lost}. 
The sender, EA, sends Packets P1, P2 and P3. Note that to TCP the data
in each packet is dependent on what is in its send queue at the time TCP decides
to send the data.  No message boundaries are implied by the packets. In this
transfer, we have the unfortunate occurrence of a lost packet: P1 is lost. P2 and P3
arrive safely, but since the data has not \emph{all} arrived in order, they are held by the TCP stack
awaiting the retransmission of P1. This will usually happen within one second or so
depending on TCP's retransmission algorithms and timers for the connection's network path.

Now what has happened is that any data in P1 has caused an HOL condition for data
held within P2 and P3. In some cases, as we have stated, this may be very desirable.
However in many instances, the information in P2 or P3 is not related to P1 (as we also
described above). This can cause delays in processing of information that may
be undesirable or unacceptable to the application.

SCTP's streams were designed to deal with this very problem and provide a
method for applications to have finer grain control of what gets blocked by
the SCTP stack when such a packet loss occurs. When an application sends
data, it can specify a stream number to be used. There are up to 65,535 streams in an
SCTP association\footnote{The use of the term association is common for SCTP and
represents a similar concept to a TCP connection.}
(the exact number is negotiated at association startup).
When a message is sent in Stream N, a loss of data  that does not have
any Stream N data does not cause delays in delivery. In other words, when data arrives
in a given stream (N) it is only held for reordering if other data is missing for that same stream.
For example, let us assume that P1 contains a message for stream 11, P2 contains a message for stream 2 and 
P3 contains a message for stream 6. Only messages in stream 11 would be blocked by
the loss of P1 so both the payloads of P2 and P3 would not be held but delivered 
immediately upon arrival\footnote{This assumes, of course, that no other losses have occurred.}.
Streams allow an application to do selective ordering of messages. 

SCTP also provides another ordering constraint that mimics UDP (i.e. none). An application
is allowed to send a message as ``unordered'' on a per message basis. When an application sends in this
fashion, it is specifying that the data has \emph{no} order with respect to any other
data sent previously. An unordered message is placed into the delivery queue (often
times termed a socket buffer) immediately upon arrival. 

The combination of streams and unordered data provide powerful tools an application
can use to provide fine grain control over the delivery of data upon arrival at
the peer endpoint SCTP stack. Many applications in today's Internet can gain
improved performance in the face of network loss by using these features.

\subsection{Multihoming}
\label{multi}
The second of the two key features of SCTP is multihoming. A host that
is multihomed has more than one point of attachment to the network.
In a traditional TCP connection, one IP address and one port are chosen at each end to 
send and receive packets with. The two IP addresses and ports selected represent
the four tuple identification of the TCP connection (IP-A + Port-A, IP-Z + Port-Z).

In SCTP, an association is composed of two ``sets'' of IP addresses and two ports. This
means that if two hosts are multihomed, all of their IP addresses can be involved
in sending and receiving data. In instances of lost packets, SCTP will often select
one of the alternate addresses to send data to. This provides a form of network 
resilience in the face of network loss and outages. Consider Fig~\ref{mhomeloss}(a).
The network connection to EZ via IP3 has failed, and EA sends two packets P1 and P2 using
IP3 as the destination. Naturally the data will be lost, since there is an ``airgap''
between the network and the host. Later, when EA's SCTP stack detects the loss (via timeout)
the retransmission would take the alternate path, as shown in Fig~\ref{mhomeloss}(b). This gives
the application additional redundancy. When you combine this with the ability to fine tune
the retransmission timers (including the minimum and maximum values) an 
application can improve both its availability and how quickly it will recover from
network errors.

An additional feature that many SCTP stacks offer is the ability to dynamically 
reconfigure the IP address set that makes up the association ~\cite{rfc5061}. This
provides the ability for an association to survive an address renumbering or take
advantage of a hot-pluggable network interface without restarting the 
association. Again, this unique feature provides yet again more support 
to an application attempting to minimize down time.

Lastly, it is important to note that SCTP's address sets allow any mix of IPv4 and IPv6
addresses at each endpoint.  That is, an SCTP association may use both IPv4 and IPv6 addresses,
providing additional network path diversity.
\begin{figure}
\includegraphics{multihome}
\caption{Packet loss in a multi-homed scenario}
\label{mhomeloss}
\end{figure}


\subsection{Partial Reliability}
\label{prsctp}
Partial Reliability, as the name implies, allows SCTP to control the 
amount of reliability an application wants on a per message granularity.
Consider a video game sending character position updates every 400 milliseconds.
If data is lost and not retransmitted within that time period (400~ms), then
retransmitting the character position makes no sense since a new
updated one would already be en-queued. With the addition of \cite{rfc3758}, SCTP
gained the ability to specify how long a message is ``good" for.  The initial
RFC allows the user to specify a ``time to live'' for each message. The 
sender makes a decision based on this ``time to live'' as to when to stop retransmitting and
skip over the data. 

The actual mechanism to skip over the data is separate from the
methodology used to determine when to skip over data. This means that
a sender can have many different ``profiles'' for skipping data and the
receiver does not need to have the same ``profile''.

Currently the authors are aware of three profiles commonly implemented:
\begin{itemize}
  \item Time based reliability
  \item Buffer based reliability
  \item Number of retransmissions
\end{itemize}
The time based profile follows RFC3758 in that the sender specifies
the number of milliseconds before the message should be skipped.  As
many retransmissions that are possible will be made in the time allowed.
For example, if the application sends the data with a 9,000 millisecond
reliability, the message will be retransmitted several times\footnote{The exact
number of times is based on factors such as the minimum and maximum RTO.} if loss occurs.

Another reliability profile is buffer based. In this form, the user specifies the maximum
number of bytes of data that are allowed to be on queue. If the size of the queue 
specified is reached, then the oldest data (marked in this manner) is looked to be
skipped so that the new data can be added to the queue of outgoing data.

The number of retransmissions profile allows an application to specify how many
times the data will be retransmitted. So, for example, if the application specified
zero times no retransmissions would be made\footnote{This is similar to UDP
except that this profile assures that at least one transmission occurs, whereas
UDP makes no such assurance}.

In all cases, no matter which profile is used, fully reliable and partially reliable
data may be mixed. In effect, a single stream may have both reliable and
partially reliable data en-queued on it. This also has ramifications to the 
buffer based method in that if the entire association is filled with 
fully reliable data, then the new send itself will be the one subject
to ``skipping.''

\subsection{Message boundaries}
\label{mbound}
Message boundary preservation is a small incremental feature added to
SCTP that many developers will be happy to see. When you think of
an interaction between two applications, rarely do they exchange a ``stream of bytes''.
Rather, they send, receive, and act upon messages. In a TCP connection, each
message must be framed in some way as any read of a buffer may return
parts of two separate messages. The application needs to provide application
layer code that parses the message based on the way the messages
were framed by the sender. 

With SCTP, messages are never merged together upon reading. As long
as a large enough buffer is provided for reading, each read returns a 
single message. Each send is considered to be a message in itself\footnote{Note that
there are mechanisms to explicitly avoid this premise, but the default behavior is such
that every send is a message}. As a consequence, the application does not need to
track by sender nor receiver where the message boundaries are.

Note that message boundary preservation does have impact on how
messages are transmitted. SCTP is capable of bundling multiple messages
together and even splitting a large message over multiple Protocol Data Units (PDUs).
How the bundling or splitting occurs is often driven by the size of the 
messages the user is sending and the Path Maximum Transport Unit (PMTU).


\subsection{Security}
\label{secure}

Security is a topic of  some importance since a transport protocol that is subject
to easy attack is not acceptable in today's often hostile Internet. SCTP has several
unique features that help strengthen its security to blind attacks, and an optional
extension \cite{rfc4895} that provides even more capabilities.

Every SCTP association starts with a four way handshake. This four
way handshake includes a signed cookie that the passive server side
sends to the active initiating client. The server holds no state, and thus
is not subject to the SYN flooding attack. 

In the first two packets during the setup exchange, a 32-bit random value is
supplied by both endpoints. This 32-bit random nonce serves as a verification
tag (vtag).  All packets sent must include the vtag supplied by the peer during
setup of the association, in order to be accepted by the receiving SCTP stack.
This means that a blind attacker must generate 2 billion guess (on average) in
order to say inject an ``ABORT'' chunk to tear down the association. 

The authentication option RFC4895\cite{rfc4895} adds the ability for any
chunk to be required to be signed in such a way so that the receiver can know
without doubt that the source was indeed the expected sender. Even applications that
decide not to use shared keys can still gain some measure of security assuming
that the first two packets that setup an association are not intercepted by a
man in the middle.

Note that even though SCTP uses a four way handshake, this does not
cause delay in getting the first data messages to the receiver. In fact,
due to the way most TCP stack socket API's work, SCTP usually can get
the first data chunk to its peer one half of a round trip quicker than TCP.

\subsection{Other differences}
\label{miscdiff}

There are a few other differences worth noting in any comparison of
IP transports. One of the obvious differences is the checksum. In both
UDP and TCP, a summation is used of all bits in the message. The summation
is done as a simple addition of all bytes in the message including a
pseudo-header. The pseudo-header is selected parts of the IP
header to help detect when a router misdirects a packet. For SCTP,
a Cyclic Redundancy Check is used (CRC32c). A CRC is much stronger
than a checksum and provides much better protection against
bit errors and packet damage done by routers and other network
devices. 

The pseudo-header mentioned above is not needed in SCTP. The reason
is the vtag discussed earlier. The pseudo-header, as noted, is used to
detect misrouted packets in the checksum. For SCTP, the 32-bit random
nonce provides this same protection without the need to embed a
hidden field in the packets checksum.

Another consequence of the use of a vtag is the absence of 
the timed-wait state in the protocol state machine. In TCP, for
some period of time after an endpoint shuts down, the TCP stack
prevents the port from being bound. This period of time is called
the ``timed-wait'' period and normally last for about two minutes. 
The purpose of this ``timed-wait'' is to allow lingering packets with
the same four-tuple to drain from the network. In SCTP, the vtag,
protects us from this same situation as long as vtags themselves are
reused in a ``timed-wait'' manner.  As long as a different vtags are used, the same
port may be immediately re-used for a new association to the same
peer endpoint.

SCTP also includes a required heartbeat mechanism for path
management. In contrast, TCP has an optional keep-alive mechanism
which must be explicitly enabled by the application. 

One other striking difference between TCP and SCTP is the absence
of the half closed state. In a TCP connection, one side is allowed to
inform the peer that it will send no more data but will continue to accept
data from the peer. This state is known as half closed. SCTP does not
allow this behavior. If a user closes one side, then the connection will
shutdown.

\subsection{A word about optional features}
\label{options}
In the preceding sections, we have mentioned several optional
features. You might wonder which of them should I expect from
my implementation. It is the authors' opinion that a complete 
SCTP implementation should include:
\begin{enumerate}
 \item  RFC4960 (basic SCTP)
 \item  RFC3758 (partial reliability)
 \item  RFC4895 (authentication)
 \item  RFC5061 (dynamic addresses)
\end{enumerate}

There are other drafts and extensions that are currently being
reviewed by the IETF, but those will truly be optional in our
opinion. The ones listed above, however, though optional, we
consider quite necessary for a full featured SCTP stack.

\section{Socket API overview}
Now that we have discussed some of the features and function of SCTP, let us
talk about how you can use this powerful new protocol. As with TCP and UDP, the socket
API is the most common method of accessing and using SCTP. Before diving deeper
into the details of SCTP's socket API we will first get an overview of some of the
basic elements and choices that an application writer will have when using
SCTP.

\subsection{Models}
First and foremost, when we go to use SCTP, is that we now have two choices.
The SCTP socket API provides two models: the one-to-one model and the
one-to-many model.

The one-to-one model is based on a one-to-one relationship between the socket and
an SCTP association (not taking the listening sockets into account). This is similar to
a standard TCP socket.
For the one-to-many model, there is a one-to-many relationship between the socket
and the SCTP associations. This is similar to using unconnected UDP sockets.

The one-to-one model is basically a ``TCP'' compatibility model. This model
works the same exact way that the standard TCP socket API model works.
A server will typically call \texttt{socket()}, \texttt{bind()}, and \texttt{listen()}. Then after
the initial setup will sit in a loop calling \texttt{accept()} to gain new connections.
Each new connection is a new socket descriptor on which the new connection is
available to send and receive data on. The application must track each individual socket
descriptor for each connection setup.  The client will call \texttt{socket()} followed
by a call to \texttt{connect()} to the address of the server. 

The major advantage to this model is that a simple change to 
existing TCP code will allow that code to work with SCTP. To access this model, a user
calls \texttt{socket(int domain,  int type, int proto)}
with type set to \texttt{SOCK\_STREAM} and proto set to \texttt{IPPROTO\_SCTP}. 
Note that the domain argument is generally how you choose between IPv6 
and IPv4 (\texttt{PF\_INET6} and \texttt{PF\_INET}).

The one-to-many model is designed as a peer-to-peer type model.
In this model, both sides generally call \texttt{socket()} followed by \texttt {listen()}.
Then, when they wish to exchange information
with a peer, they call \texttt{sendto()} or \texttt{recvfom()} (or any of the extended send or
receive calls, see section \ref{adv}). Note that the one single socket will have multiple
associations underneath it. Only one socket descriptor is ever used
in this model, calling \texttt{accept()} will return an error.
One of the advantages to this model is the ability to send data on the third leg
of the four way handshake\footnote{Note that some implementations do allow this with
the one-to-one model at the expense of breaking TCP compatibility.}.
Another advantage is that an application does not really need to track association state.
In order to be truly free of association state, however, the application is recommended
to turn on the \texttt{AUTO\_CLOSE} socket option that will automatically close associations
that are idle for long periods. 

Accessing the one-to-many model is done by calling the \texttt{socket()} system call specifying the type as
\texttt{SOCK\_SEQPACKET} and the proto as \texttt{IPPROTO\_SCTP}.

\subsection{Notifications}

While developing the socket API for SCTP, it became quickly obvious
that the transport stack itself would often have useful things to tell the application 
(if the application is interested). The existing socket API had no method
for the transport to easily communicate events that were happening
within the transport. To deal with this, the socket API for SCTP allows an
application to subscribe to event ``notifications''. The subscription is
done by setting one of the SCTP socket options. Once one or more events are
turned on, and when the SCTP stack has one of those events to tell the application,
it sends an event notification message to the application up the normal data 
path with the flags field set to \texttt{MSG\_NOTIFICATION}. That is, it multiplexes 
the event notification messages with peer user messages.  When a user application
subscribes to these events, it is in effect acknowledging to the SCTP stack that it
(the application) understands it must look at the flags field before interpreting
a message, since it is possible it is not a message from a peer but from the transport
itself.

There are currently eight types of notifications. They are:
\begin{itemize}
 \item  Association events - the starting and closing of new associations
 \item  Address events - information about peer addresses, failures, additions, deletions, confirmations.
 \item  Send Failures - When a send fails, the data is returned with an error if you subscribe to this event.
 \item  Peer Error - If the peer sends an error message the stack would pass the TLV up the stack in this notification.
 \item  Shutdown events - Indications that a peer has closed or shutdown an association.
 \item  Partial delivery events - this notification will indicate issues that may occur in the partial delivery api.
 \item  Adaptation layer event - this notification holds a adaptation indication.
 \item  Authentication event - Various authentication events (such as new keys activated) would be signaled by this notification.
 \end{itemize}

Often applications will not be interested in a number of these notification. Two of the most
useful notifications for the one-to-many model are the Association and Shutdown events. Within
these events is an association identification often called \texttt{assoc\_id}. This id identifies a specific
association within the one-to-many socket. It can also be used with some of the extended
socket API calls used for sending messages (instead of using a socket address). 
Many of the socket options used with SCTP will take the \texttt{assoc\_id} as an argument to
identify which specific association to change  or gather settings on, instead of the whole 
socket descriptor.

We will discuss notifications in more detail in the next section.

\subsection{Extended calls}

All of the existing socket API calls will work with SCTP seamlessly to
provide most of all of the functions needed. However, there are limitations for a few
corner cases in either the utility or in the ease of use of many of the common API calls.
For example, the existing socket API does not adequately address the following cases:

\begin{itemize}
 \item  For binding addresses, you can have one or all addresses.
 \item  For connecting to a peer, you can connect to one and only one address.
 \item  For sending or receiving, getting access to the stream information is rather awkward.
\end{itemize}

To solve these problems, there are extensions to the socket API to add additional capabilities
as well as make some existing features easier to use.  New ``system calls'' have been added 
specifically for SCTP. Note that a new system call may be no more than a utility library
routine that eases access to a specific feature. 

We will discuss each of the extended socket API calls as well as other features such
as notifications and socket options in \ref{adv}.


\section{Socket API - details}
\label{adv}
Now that you have a general idea of the advantages of SCTP, you are probably
wondering how you access these features. This section will try to highlight and provide
a rough overview of the way a user can best interact with SCTP.

\subsection{Notifications}

As mentioned earlier SCTP can provide information to the user via
notifications. Notifications are received in the data path i.e. by \texttt{recvmsg()} or \texttt{sctp\_recvmsg()}. You could in theory use \texttt{recvfrom()} or \texttt{recv()} but then you would have no way of knowing if
the message was a notification from SCTP or a real peer message.  All notifications are disabled by default, so
an application must set a socket option (\texttt{SCTP\_EVENTS}) to turn on one or more notifications. Once you 
enable a notification, you are making an implicit pledge to the SCTP stack that you will not use \texttt{recvfrom()} or \texttt{recv()}.
If you violate that pledge, you will most likely be confused by messages arriving from both the peer application as well as the SCTP stack.

The \texttt{SCTP\_EVENTS} socket option takes has input a structure as shown
in Fig. \ref{fig:events}. Note that each \texttt{uint8\_t} field
is interpreted as a boolean, where a zero value turns off the 
notification and a non-zero value turns on the notification.
\begin{figure}
\verbatiminput{event.h}
\caption{The SCTP Event Subscription structure}
\label{fig:events}
\end{figure}

The careful reader will notice two distinctions. There is an extra event
for FreeBSD (found in the \#ifdefs), and there is a ``notification" that was 
not listed previously, \texttt{sctp\_data\_io\_event}. The data\_io event is not really a 
notification, but the ability to receive extra information as ancillary data with the receive calls.
The extra information tells you the stream number as well as other
ancillary data. If you wish to receive this information you must enable
the ``event'' just like you would for a notification. 

Note when the \texttt{sctp\_data\_io\_event} event is enabled you will receive the \texttt{sctp\_sndrcvinfo}
structure with every 
\texttt{recvmsg()} or \texttt{sctp\_recvmsg()} call. You cannot receive
this information with the \texttt{recv()} or \texttt{recvfrom()} calls. In the
\texttt{sctp\_recvmsg()} call, the \texttt{sctp\_sndrcvinfo}  structure is an
argument passed in the call. For the \texttt{recvmsg()} call, the user will
need to parse ancillary data for type \texttt{SCTP\_SNDRCV}. 
The \texttt{sctp\_sndrcvinfo} is shown in Fig.~\ref{fig:sndrcv}.
\begin{figure}
\verbatiminput{sndrcv.h}
\caption{The SCTP sndrcvinfo}
\label{fig:sndrcv}
\end{figure}

Each notification, as mentioned, provides you with a specific structure. 
We will examine two of the notifications and leave the rest
as an exercise for the reader. \cite{socketdraft} and \cite{stevensapi} may
also be helpful.

\begin{figure}
\verbatiminput{assoc.h}
\caption{Association notification}
\label{fig:assocnotify}
\end{figure}

One of the most common notifications an application will be interested in is
the association events notification. This notification tells you about changes in
associations, including the arrival of new associations.  Refer to Figure \ref{fig:assocnotify} for the full structure.
Some notable fields from this structure are \texttt{sac\_type}, \texttt{sac\_flags},
and \texttt{sac\_length}. Every notification begins with these type, flags and length fields. 
This allows the receiver to cast the structure to a base notification structure and then
examine the type to know exactly which notification has arrived.
In this particular notification, an application may be interested in
\texttt{sac\_outbound\_streams} and \texttt{sac\_inbound\_streams}, which tells
the user how many streams were negotiated (note this may not be the number expected by
the application and the two values are not necessarily equal). Another useful field is the
\texttt{sac\_assoc\_id}.
As indicated earlier, this field uniquely identifies this association and can actually be used as a destination
when using the advanced SCTP API send calls.

Another notification often subscribed to can be found in Figure \ref{fig:paddr}.
This notification arrives when some event has occurred concerning one of the peer's
addresses. The \texttt{spc\_state} field will reflect what happened with the address.
Possible address events include:

\begin{itemize}
 \item  It was added~(\texttt{SCTP\_ADDR\_ADDED}).
 \item  It was deleted~(\texttt{SCTP\_ADDR\_REMOVED}).
 \item  It is now reachable~(\texttt{SCTP\_ADDR\_AVAILABLE}).
 \item  It~is~now~un-reachable~(\texttt{SCTP\_ADDR\_UNREACHABLE}).
\end{itemize}

For fault tolerant applications, tracking the states of the peer's addresses
may well be an essential job.

\begin{figure}
\verbatiminput{paddr.h}
\caption{Address change notification}
\label{fig:paddr}
\end{figure}

\subsection{Extended system calls}
SCTP provides some additional system calls:
\begin{itemize}
 \item  \texttt{sctp\_recvmsg(int sd, void *msg, size\_t len, struct sockaddr *from, socklen\_t *fromlen, struct sctp\_sndrcvinfo *sinfo, int *flags)}
 \item  \texttt{sctp\_sendmsg(int s, void *msg, size\_t len, struct sockaddr *to, socklen\_t tolen, uint32\_t ppid, uint32\_t flags, uint16\_t stream, uint32\_t timetolive, uint32\_t context)}
 \item  \texttt{sctp\_send(int sd, void *msg, size\_t len, struct sctp\_sndrcvinfo *sinfo, int flags)}
 \item  \texttt{sctp\_bindx(int sd, struct sockaddr *addrs, int addrcnt, int type)}
 \item  \texttt{sctp\_connectx(int sd, struct sockaddr *addrs, int addrcnt, sctp\_assoc\_t *assoc\_id)}
 \item  \texttt{sctp\_sendx(int sd, void *msg, size\_t len, struct sockaddr *addrs, int addrcnt, struct sctp\_sndrcvinfo *, int flags)}
 \item  \texttt{sctp\_sendmsgx(int s, void *msg, size\_t len, struct sockaddr *to, int addrcnt, socklen\_t tolen, uint32\_t ppid, uint32\_t flags, uint16\_t stream, uint32\_t timetolive, uint32\_t context)}
\end{itemize}
The first three essentially provide some convenience functions to the user. Their functionality can be provided by
using equivalent  \texttt{sendmsg()} and \texttt{recvmsg()} calls with the appropriate handling of the required ancillary data.

The last four functions
are necessary to make the support of multihoming possible. \texttt{sctp\_bindx()} makes it
possible to bind an arbitrary set of local addresses to a socket, rather than the ``all or none"
that \texttt{bind()} provides. \texttt{sctp\_connectx()},
\texttt{sctp\_sendx()} and \texttt{sctp\_sendx()} make it possible to use multiple known addresses
of the peer already \emph{during} the association setup. Without these functions,
multihoming would only be available after the association has been completely established.

\subsection{Socket Options}

SCTP provides a large set of socket options as shown in TABLE~\ref{sockopt}, and some FreeBSD
specific extensions as shown in TABLE~\ref{bsdsockopt}.
This is due to the fact that SCTP allows a lot of protocol parameters to be controlled by the
user. Also, some protocol extensions, like the SCTP-AUTH \cite{rfc4895} extension, use socket options to
control the feature (e.g. controls hash algorithms, keys, chunks to authenticate, etc.). 
The usage of a few of these options are described in the examples in the
next section. For a detailed description, see~\cite{socketdraft}.

\begin{table}[h]
\begin{center}
\begin{tabular}{|l|r|l|}
\hline
Option                          & R-W & Description              \\\hline
\hline
SCTP\_RTOINFO                   & rw  & RTO min/max              \\\hline
SCTP\_ASSOCINFO                 & rw  & Association parameters   \\\hline
SCTP\_INITMSG                   & rw  & Setup options            \\\hline
SCTP\_NODELAY                   & rw  & Nagle algorithm          \\\hline
SCTP\_AUTOCLOSE                 & rw  & Automatic closing        \\\hline
SCTP\_SET\_PEER\_PRIMARY\_ADDR  & rw  & Remote primary           \\\hline
SCTP\_PRIMARY\_ADDR             & rw  & Local primary            \\\hline
SCTP\_ADAPTATION\_LAYER         & rw  & AI indication            \\\hline
SCTP\_DISABLE\_FRAGMENTS        & rw  & Fragmentation            \\\hline
SCTP\_PEER\_ADDR\_PARAM         & rw  & Misc parameters          \\\hline
SCTP\_DEFAULT\_SEND\_PARAMS     & rw  & Default sendrcvinfo      \\\hline
SCTP\_EVENTS                    & rw  & Notifications            \\\hline
SCTP\_I\_WANT\_MAPPED\_V4\_ADDR & rw  & Mapped v4 addresses      \\\hline
SCTP\_MAXSEG                    & rw  & Fragmentation point      \\\hline
SCTP\_DELAYED\_SACK             & rw  & Delayed sack             \\\hline
SCTP\_FRAGMENT\_INTERLEAVE      & rw  & Receive interleave       \\\hline
SCTP\_PARTIAL\_DELIVERY\_POINT  & rw  & receive PD point         \\\hline
SCTP\_AUTH\_CHUNK               & w   & Add Auth Chunk           \\\hline
SCTP\_AUTH\_KEY                 & w   & Add Auth key             \\\hline
SCTP\_HMAC\_IDENT               & rw  & hmac algo                \\\hline
SCTP\_AUTH\_ACTIVE\_KEY         & rw  & Active key               \\\hline
SCTP\_AUTH\_DELETE\_KEY         & w   & Delete key               \\\hline
SCTP\_USE\_EXT\_RCVINFO         & rw  & Extended sndrcvinfo      \\\hline
SCTP\_AUTO\_ASCONF              & rw  & Automatic IP add/del     \\\hline
SCTP\_MAXBURST                  & rw  & Microburst control       \\\hline
SCTP\_CONTEXT                   & rw  & Default context          \\\hline
SCTP\_EXPLICIT\_EOR             & rw  & Explicit EOR             \\\hline
SCTP\_STATUS                    & r   & Assoc status             \\\hline
SCTP\_GET\_PEER\_ADDR\_INFO     & r   & Info on dest             \\\hline
SCTP\_PEER\_AUTH\_CHUNKS        & r   & Peer requires auth       \\\hline
SCTP\_LOCAL\_AUTH\_CHUNKS       & r   & Local requires auth      \\\hline
SCTP\_GET\_ASSOC\_NUMBER        & r   & Number of assocs         \\\hline
SCTP\_GET\_ASSOC\_ID\_LIST      & r   & Assoc ids                \\\hline
\end{tabular}
\end{center}
\caption{SCTP Socket Options\label{sockopt}}
\end{table}

\begin{table}[h]
\begin{center}
\begin{tabular}{|l|r|l|}
\hline
Option                      & R-W & Description   \\\hline
\hline
SCTP\_RESET\_STREAMS        & w   & Stream reset  \\\hline
SCTP\_SET\_DEBUG\_LEVEL     & rw  & Debug output  \\\hline
SCTP\_CMT\_ON\_OFF          & rw  & CMT on/off    \\\hline
SCTP\_CMT\_USE\_DAC         & rw  & DAC with CMT  \\\hline
SCTP\_PLUGGABLE\_CC         & rw  & Set CC        \\\hline
SCTP\_GET\_SNDBUF\_USE      & r   & Send space    \\\hline
SCTP\_GET\_NONCE\_VALUES    & r   & Vtag pair     \\\hline
SCTP\_SET\_DYNAMIC\_PRIMARY & w   & Global primary\\\hline
SCTP\_GET\_PACKET\_LOG      & r   & Packet log    \\\hline
SCTP\_VRF\_ID               & rw  & Default VRF   \\\hline
SCTP\_ADD\_VRF\_ID          & w   & Add a VRF     \\\hline
SCTP\_GET\_VRF\_IDS         & r   & Get VRF IDs   \\\hline
SCTP\_GET\_ASOC\_VRF        & r   & Assoc VRF ID  \\\hline
SCTP\_DEL\_VRF\_ID          & w   & Delete VRF ID \\\hline
\end{tabular}
\end{center}
\caption{SCTP FreeBSD Specific Socket Options\label{bsdsockopt}}
\end{table}


\subsection{Some Examples}

In this section, we will provide example code for a simple client
which sends a number of messages to a server, and a server which
just discards all received messages. The client will use the one-to-one
model and the server will use the one-to-many model. Of course,
despite using different programming models, the client and server can
still communicate properly.

\begin{figure*}[h]
\lstset{numbers=left, frame=single, basicstyle=\small\ttfamily}
\lstinputlisting{discard_server.c}
\caption{Discard server using the one-to-many model.}
\label{fig:discard-server}
\end{figure*}

Let us first consider the server in Figure~\ref{fig:discard-server}.
In line~22, a one-to-many style socket is created. A method of enabling
all notifications is shown in lines~25--27. Then in lines~31--38,
the socket is bound to the IPv4 wildcard address and the well known port
for the discard service. To allow the kernel to accept SCTP
associations on the discard port, the socket is put into listening
mode in line~41. 
The reception of messages and notifications is handled by the
infinite loop in lines~45--62. \texttt{sctp\_recvmsg()} is used in 
line~51 to read event notifications or peer user messages, after initializing
several variables in lines~46--49. If a notification is received,
only a simple message is printed. For a received user message, the
length, source address and port number, stream identifier and
payload protocol identifier is printed. It should be noted that
this simple program does not check if the notification or message
was completely received by checking for the \texttt{MSG\_EOR} flag.
In line 64, the socket would be closed, but this line will never be
executed.

The second example is a simple client shown in~Figure~\ref{fig:discard-client},
which sends a number of messages of the same length to a discard server.

\begin{figure*}[h]
\lstset{numbers=left, frame=single, basicstyle=\small\ttfamily}
\lstinputlisting{discard_client.c}
\caption{Discard client using the one-to-one model.}
\label{fig:discard-client}
\end{figure*}

In line~27, a one-to-one style socket is created. In lines 31--36, the
number of outgoing streams to be requested during association setup
is set to 2048. Then the association is established in line~48. Since 
the number of incoming and outgoing streams is negotiated during the
association setup, the number of streams is retrieved in lines 50--54
via a socket option. Then all messages are sent via a \texttt{sctp\_sendmsg()}
call in lines~57--60. A given payload protocol identifier is used, and the
stream number to send with is used in a round robin fashion. In line~65, the
association teardown procedure is started by closing the socket.

\section{Conclusion}
This paper describes the features provided by SCTP and gives
a glimpse into the many ways an application can control and
configure it. SCTP has been designed to be flexible and
yet provide reasonable defaults for applications that do
not wish to dig into the deep details of controlling the
transport. For applications that need more control, SCTP
provides a wide host of socket options and a multitude of
ordering options. 

In general, SCTP can be used any place TCP can be used
and gives the application greater flexibility. No longer
does the application need to frame messages, the transport
does that for you. No longer does the application need
to worry about connection state (when using the one-to-
many socket model). SCTP may also be used in cases where
one might consider UDP, assuming a full featured implementation
of SCTP including Partial Reliability. 

The authors encourage you to go and explore SCTP as it will
become addictive.

Happy SCTPing.

%\section*{Acknowledgment}
%
%
%The authors would like to thank...
%

\begin{thebibliography}{9}
\bibitem{rfc768}
  J.~Postel,
  ``User Datagram Protocol'',
  \textit{RFC~768},
  August~1980.
\bibitem{rfc793}
  J.~Postel,
  ``Transmission Control Protocol'',
  \textit{RFC~793},
  September~1981.
\bibitem{rfc3758}
  M.~T\"uxen~et~al.,
  ``Stream Control Transmission Protocol Partial Reliability Extension'',
  \textit{RFC~3758},
  May~2004.
\bibitem{rfc4960}
  R.~Stewart,
  ``Stream Control Transmission Protocol'',
  \textit{RFC~4960},
  September~2007.
\bibitem{rfc4895}  
  R.~Stewart~et~al.,
  ``Authenticated Chunks for the Stream Control Transmission Protocol'',
  \textit{RFC~4895},
  August~2007.
\bibitem{rfc5061}
  R.~Stewart~et~al.,
  ``Stream Control Transmission Protocol Dynamic Address Reconfiguration'',
  \textit{RFC~5061},
  September~2007.
\bibitem{socketdraft}
  R.~Stewart~et~al,
  ``Socket API Extensions for Stream Control Transmission Protocol (SCTP)'',
  \textit{draft-ietf-tsvwg-sctpsocket-16.txt}, work~in~progress.
\bibitem{stevensapi}
  R.~Stevens~et~al.,
  ``UNIX Network Programming Volume 1 Third Edition''', <NAME>, 2004.
\end{thebibliography}

% that's all folks
\end{document}


