As per Relevance of the word transport, we have this rfc below:
Network Working Group L.
Request for Comments: 3286 Ciena
Category: Informational J.
Nortel
May 2002
An Introduction to the Stream Control Transmission Protocol (SCTP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document provides a high level introduction to the
supported by the Stream Control Transmission Protocol (SCTP). It
intended as a guide for potential users of SCTP as a general
transport protocol
1.
The Stream Control Transmission Protocol (SCTP) is a new IP
protocol, existing at an equivalent level with UDP (User
Protocol) and TCP (Transmission Control Protocol), which
transport layer functions to many Internet applications. SCTP
been approved by the IETF as a Proposed Standard [1]. The
check algorithm has since been modified [2]. Future changes
updates will be reflected in the IETF RFC index
Like TCP, SCTP provides a reliable transport service, ensuring
data is transported across the network without error and in sequence
Like TCP, SCTP is a session-oriented mechanism, meaning that
relationship is created between the endpoints of an SCTP
prior to data being transmitted, and this relationship is
until all data transmission has been successfully completed
Unlike TCP, SCTP provides a number of functions that are critical
telephony signaling transport, and at the same time can
benefit other applications needing transport with
performance and reliability. The original framework for the
definition is described in [3].
Ong & Yoakum Informational [Page 1]
RFC 3286 SCTP Overview May 2002
2. Basic SCTP
SCTP is a unicast protocol, and supports data exchange
exactly 2 endpoints, although these may be represented by multiple
addresses
SCTP provides reliable transmission, detecting when data
discarded, reordered, duplicated or corrupted, and
damaged data as necessary. SCTP transmission is full duplex
SCTP is message oriented and supports framing of individual
boundaries. In comparison, TCP is byte oriented and does
preserve any implicit structure within a transmitted byte
without enhancement
SCTP is rate adaptive similar to TCP, and will scale back
transfer to the prevailing load conditions in the network. It
designed to behave cooperatively with TCP sessions attempting to
the same bandwidth
3. SCTP Multi-Streaming
The name Stream Control Transmission Protocol is derived from
multi-streaming function provided by SCTP. This feature allows
to be partitioned into multiple streams that have the property
independently sequenced delivery, so that message loss in any
stream will only initially affect delivery within that stream,
not delivery in other streams
In contrast, TCP assumes a single stream of data and ensures
delivery of that stream takes place with byte sequence preservation
While this is desirable for delivery of a file or record, it
additional delay when message loss or sequence error occurs
the network. When this happens, TCP must delay delivery of
until the correct sequencing is restored, either by receipt of
out-of-sequence message, or by retransmission of a lost message
For a number of applications, the characteristic of strict
preservation is not truly necessary. In telephony signaling, it
only necessary to maintain sequencing of messages that affect
same resource (e.g., the same call, or the same channel).
messages are only loosely correlated and can be delivered
having to maintain overall sequence integrity
Another example of possible use of multi-streaming is the delivery
multimedia documents, such as a web page, when done over a
session. Since multimedia documents consist of objects of
sizes and types, multi-streaming allows transport of these
Ong & Yoakum Informational [Page 2]
RFC 3286 SCTP Overview May 2002
to be partially ordered rather than strictly ordered, and may
in improved user perception of transport
At the same time, transport is done within a single SCTP association
so that all streams are subjected to a common flow and
control mechanism, reducing the overhead required at the
level
SCTP accomplishes multi-streaming by creating independence
data transmission and data delivery. In particular, each
DATA "chunk" in the protocol uses two sets of sequence numbers,
Transmission Sequence Number that governs the transmission
messages and the detection of message loss, and the Stream ID/
Sequence Number pair, which is used to determine the sequence
delivery of received data
This independence of mechanisms allows the receiver to
immediately when a gap in the transmission sequence occurs (e.g.,
to message loss), and also whether or not messages received
the gap are within an affected stream. If a message is
within the affected stream, there will be a corresponding gap in
Stream Sequence Number, while messages from other streams will
show a gap. The receiver can therefore continue to deliver
to the unaffected streams while buffering messages in the
stream until retransmission occurs
4. SCTP Multi-Homing
Another core feature of SCTP is multi-homing, or the ability for
single SCTP endpoint to support multiple IP addresses. The
of multi-homing is potentially greater survivability of the
in the presence of network failures. In a conventional single-
session, the failure of a local LAN access can isolate the
system, while failures within the core network can cause
unavailability of transport until the IP routing protocols
reconverge around the point of failure. Using multi-homed SCTP
redundant LANs can be used to reinforce the local access,
various options are possible in the core network to reduce
dependency of failures for different addresses. Use of
with different prefixes can force routing to go through
carriers, for example, route-pinning techniques or even
core networks can also be used if there is control over the
architecture and protocols
In its current form, SCTP does not do load sharing, that is, multi
homing is used for redundancy purposes only. A single address
chosen as the "primary" address and is used as the destination
all DATA chunks for normal transmission. Retransmitted DATA
Ong & Yoakum Informational [Page 3]
RFC 3286 SCTP Overview May 2002
use the alternate address(es) to improve the probability of
the remote endpoint, while continued failure to send to the
address ultimately results in the decision to transmit all
chunks to the alternate until heartbeats can reestablish
reachability of the primary
To support multi-homing, SCTP endpoints exchange lists of
during initiation of the association. Each endpoint must be able
receive messages from any of the addresses associated with the
endpoint; in practice, certain operating systems may
available source addresses in round robin fashion, in which
receipt of messages from different source addresses will be
normal case. A single port number is used across the entire
list at an endpoint for a specific session
In order to reduce the potential for security issues, it is
that some response messages be sent specifically to the
address in the message that caused the response. For example,
the server receives an INIT chunk from a client to initiate an
association, the server always sends the response INIT ACK chunk
the source address that was in the IP header of the INIT
5. Features of the SCTP Initiation
The SCTP Initiation Procedure relies on a 4-message sequence,
DATA can be included on the 3rd and 4th messages of the sequence,
these messages are sent when the association has already
validated. A "cookie" mechanism has been incorporated into
sequence to guard against some types of denial of service attacks
5.1 Cookie
The "cookie" mechanism guards specifically against a blind
generating INIT chunks to try to overload the resources of an
server by causing it to use up memory and resources handling new
requests. Rather than allocating memory for a Transmission
Block (TCB), the server instead creates a Cookie parameter with
TCB information, together with a valid lifetime and a signature
authentication, and sends this back in the INIT ACK. Since the
ACK always goes back to the source address of the INIT, the
attacker will not get the Cookie. A valid SCTP client will get
Cookie and return it in the COOKIE ECHO chunk, where the SCTP
can validate the Cookie and use it to rebuild the TCB. Since
server creates the Cookie, only it needs to know the format
secret key, this is not exchanged with the client
Ong & Yoakum Informational [Page 4]
RFC 3286 SCTP Overview May 2002
Otherwise, the SCTP Initiation Procedure follows many
conventions, so that the endpoints exchange receiver windows,
sequence numbers, etc. In addition to this, the endpoints
exchange address lists as discussed above, and also mutually
the number of streams to be opened on each side
5.2 INIT Collision
Multi-homing adds to the potential that messages will be received
of sequence or with different address pairs. This is a
concern during initiation of the association, where
procedures for resolving the collision of messages, you may
end up with multiple parallel associations between the
endpoints. To avoid this, SCTP incorporates a number of
to resolve parallel initiation attempts into a single association
6. SCTP DATA Exchange
DATA chunk exchange in SCTP follows TCP's Selective ACK procedure
Receipt of DATA chunks is acknowledged by sending SACK chunks,
indicate not only the cumulative Transmission Sequence Number (TSN
range received, but also any non-cumulative TSNs, implying gaps
the received TSN sequence. Following TCP procedures, SACKs are
using the "delayed ack" method, normally one SACK per every
received packet, but with an upper limit on the delay between
and an increase to once per received packet when there are
detected
Flow and Congestion Control follow TCP algorithms. The
receive window indicates buffer occupancy at the receiver, while
per-path congestion window is maintained to manage the packets
flight. Slow start, Congestion avoidance, Fast recovery and
retransmit are incorporated into the procedures as described in
2581, with the one change being that the endpoints must manage
conversion between bytes sent and received and TSNs sent
received, since TSN is per chunk rather than per byte
The application can specify a lifetime for data to be transmitted,
that if the lifetime has expired and the data has not yet
transmitted, it can be discarded (e.g., time-sensitive
messages). If the data has been transmitted, it must continue to
delivered to avoid creating a hole in the TSN sequence
Ong & Yoakum Informational [Page 5]
RFC 3286 SCTP Overview May 2002
7. SCTP Shutdown
SCTP Shutdown uses a 3-message procedure to allow graceful shutdown
where each endpoint has confirmation of the DATA chunks received
the remote endpoint prior to completion of the shutdown. An
procedure is also provided for error cases when an immediate
must take place
Note that SCTP does not support the function of a "half-open
connection as can occur in TCP, when one side indicates that it
no more data to send, but the other side can continue to send
indefinitely. SCTP assumes that once the shutdown procedure begins
both sides will stop sending new data across the association,
only need to clear up acknowledgements of previously sent data
8. SCTP Message
The SCTP Message includes a common header plus one or more chunks
which can be control or data. The common header has source
destination port numbers to allow multiplexing of different
associations at the same address, a 32-bit verification tag
guards against insertion of an out-of-date or false message into
SCTP association, and a 32-bit checksum (this has been modified
use the CRC-32c polynomial [2]) for error detection
Each chunk includes chunk type, flag field, length and value
Control chunks incorporate different flags and parameters
on the chunk type. DATA chunks in particular incorporate flags
control of segmentation and reassembly, and parameters for the TSN
Stream ID and Stream Sequence Number, and a Payload
Identifier
The Payload Protocol ID has been included for future flexibility.
is envisioned that the functions of protocol identification and
number multiplexing will not be as closely linked in the future
they are in current usage. Payload Protocol ID will allow
protocol being carried by SCTP to be identified independent of
port numbers being used
The SCTP message format naturally allows support of bundling
multiple DATA and control chunks in a single message, to
transport efficiency. Use of bundling is controllable by
application, so that bundling of initial transmission can
prohibited. Bundling will naturally occur on retransmission of
chunks, to further reduce any chance of congestion
Ong & Yoakum Informational [Page 6]
RFC 3286 SCTP Overview May 2002
9. Error
9.1
Retransmission of DATA chunks occurs from either (a) timeout of
retransmission timer; or (b) receipt of SACKs indicating the
chunk has not been received. To reduce the potential for congestion
the rate of retransmission of DATA chunks is limited.
retransmission timeout (RTO) is adjusted based on estimates of
round trip delay and backs off exponentially as message
increases
In an active association with fairly constant DATA transmission
SACKs are more likely to cause retransmission than the timeout.
reduce the chance of an unnecessary retransmission, a 4 SACK rule
used, so that retransmission only occurs on receipt of the 4th
that indicates that the chunk is missing. This is intended to
retransmits due to normal occurrences such as packets received out
sequence
9.2 Path
A count is maintained of the number of retransmissions to
particular destination address without successful acknowledgement
When this count exceeds a configured maximum, the address is
inactive, notification is given to the application, and the
begins to use an alternate address for the sending of DATA chunks
Also, Heartbeat chunks are sent periodically to all idle
(i.e., alternate addresses), and a counter is maintained on
number of Heartbeats sent to an inactive destination without
of a corresponding Heartbeat Ack. When this counter exceeds
configured maximum, that destination address is also
inactive
Heartbeats continue to be sent to inactive destination
until an Ack is received, at which point the address can be
active again. The rate of sending Heartbeats is tied to the
estimation plus an additional delay parameter that allows
traffic to be tailored according to the needs of the
application
9.3 Endpoint
A count is maintained across all destination addresses on the
of retransmits or Heartbeats sent to the remote endpoint without
successful Ack. When this exceeds a configured maximum, the
is declared unreachable, and the SCTP association is closed
Ong & Yoakum Informational [Page 7]
RFC 3286 SCTP Overview May 2002
10.
The specification includes a model of the primitives
between the application and the SCTP layer, intended as
material rather than a formal API statement. A socket-based API
being defined to simplify migration of TCP or UDP applications to
use of SCTP
11. Security
In addition to the verification tag and cookie mechanisms,
specifies the use of IPSec if strong security and
protection is required. The SCTP specification does not
define any new security protocols or procedures
Extensions to IPSec are under discussion to reduce the
required to support multi-homing. Also, work is in progress on
use of Transport Layer Security (TLS) over SCTP [4].
12.
The SCTP format allows new chunk types, flags and parameter fields
be defined as extensions to the protocol. Any extensions must
based on standard agreements within the IETF, as no vendor-
extensions are supported in the protocol
Chunk Type values are organized into four ranges to allow
to be made with a pre-defined procedure for responding if a new
Type is not recognized at the remote endpoint. Responses include
whole packet discard; packet discard with reporting; ignoring
chunk; ignoring with reporting. Similar pre-defined responses
specified for unrecognized Parameter Type values
Chunk Parameter Type values are in principle independent ranges
each Chunk Type. In practice, the values defined in the
specification have been coordinated so that a particular
type will have the same Chunk Parameter Type value across all
Types. Further experience will determine if this alignment needs
be maintained or formalized
Ong & Yoakum Informational [Page 8]
RFC 3286 SCTP Overview May 2002
13. Informative
[1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work
Progress
[3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "
Architecture for Signaling Transport", RFC 2719, October 1999.
[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work
Progress
14. Authors'
Lyndon
Ciena
10480 Ridgeview
Cupertino, CA 95014
EMail: lyong@ciena.
John
Emerging
Nortel
EMail: yoakum@nortelnetworks.
Ong & Yoakum Informational [Page 9]
RFC 3286 SCTP Overview May 2002
15. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Ong & Yoakum Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
