1.INTRODUCTION



            The Stream Control Transmission Protocol (SCTP) [1] is a new IP transport protocol, existing at an equivalent level as UDP (User Datagram Protocol) and TCP (Transmission Control Protocol),[2] which currently provide transport layer functions to all of the main Internet applications. UDP, RTP, TCP, and SCTP are currently the IETF standards-track transport-layer protocols.  Each protocol has a domain of applicability and services it provides, albeit with some overlaps.

Like TCP, SCTP provides a reliable transport service, ensuring that data is transported across the network without error and in sequence. Like TCP, SCTP is a connection-oriented mechanism, meaning that a relationship is created between the endpoints of an SCTP session prior to data being transmitted, and this relationship is maintained until all data transmission has been successfully completed.

Unlike TCP, SCTP provides a number of functions that are considered critical for signaling transport, and which at the same time can provide transport benefits to other applications requiring additional performance and reliability.

By clarifying the situations where the functionality of these protocols is applicable, this document can guide implementers and protocol designers in selecting which protocol to use.

            Special attention is given to services SCTP provides which would make a decision to use SCTP the right one.

2. Transport Protocol

            2.1 TCP service model

            TCP is a connection-oriented (a.k.a., session-oriented) transport Protocol [2].  This means that it requires both the establishment of a connection prior to the exchange of application data and a connection tear-down to release system resources after the completion of data transfer.

            TCP is currently the most widely used connection-oriented transport

            Protocol for the Internet.

            TCP provides the upper layer with the following transport services:

o             data reliability;

o             data sequence preservation; and

o             Flow and congestion control.

            2.2 SCTP service model

            SCTP is also connection-oriented and provides all the transport services that TCP provides.  Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements.  Note, for applications conscious about processing cost, there might be a difference in processing cost associated with running SCTP with only a single ordered stream and one address pair in comparison to running TCP.

            However, SCTP has some additional capabilities that TCP lacks and

This can make SCTP a better choice for some applications and environments:

o             multi-streams support:

o             multi-homing support:

o             preservation of message boundaries:

o             unordered reliable message delivery:

            2.3 UDP Service model

            UDP is connectionless.  This means that applications that use UDP do not need to perform connection establishment or tear-down.

                        As transport services to its upper layer, UDP provides only:

o             best-effort data delivery, and

o             preservation of message boundaries.

Applications that do not require a reliable transfer of more than a packet's worth of data will find UDP adequate. Some transaction-based applications fall into this category

3. SCTP Features

SCTP features can be broadly divided in two types [1]

v Core features

§ Multi-streaming

§ Multi-Homing

v Other features

§ Unicast protocol

§ Reliable transmission

§ Message oriented

§ Rate adaptive

3.1 Core Features

3.1.1 Multi-streaming

The name Stream Control Transmission Protocol is derived from the multi-streaming function provided by SCTP. This feature allows data to be partitioned into multiple streams that have the property of being delivered independently, so that message loss in any of the streams will only affect delivery within that stream, and not in other streams.

In contrast, TCP provides a single stream of data and ensures that delivery of that stream takes place with perfect sequence preservation. While this is desirable for delivery of a file or record, it causes additional delay when message loss or sequence error occurs within the network. When this happens, TCP must delay delivery of data until the correct sequencing is restored, either by receipt of an out-of-sequence message, or by retransmission of a lost message.

For a number of applications, this characteristic of strict sequence preservation is not truly necessary. In signaling, for example, it is only necessary to maintain sequencing of messages that affect the same resource (e.g., the same call, or the same channel). Other messages are only loosely correlated and can be delivered without having to maintain overall sequence integrity.

Another application having this property is delivery of web page objects, if done over a single session. It is generally not necessary to maintain sequence between the presentation of objects, and in some cases (esp. some types of graphic images) it may be possible to present parts of a single object out of sequence. Eventually the goal is to deliver all objects, however the ability to deliver objects out of sequence may result in at least better perceived performance, as parts of the web page can be displayed rather than waiting for all of the information to be received before displaying it.

SCTP accomplishes multi-streaming by creating independence between data transmission and data delivery. In particular, each DATA “chunk” (or PDU) in the protocol uses two sets of sequence numbers, a Transmission Sequence Number that governs the transmission of messages and the detection of message loss, and the Stream ID/Stream Sequence Number pair, which is used to determine the sequence of delivery of received data.

This independence of mechanisms allows the receiver to determine immediately when a gap in the transmission sequence occurs (e.g., due to message loss), and also whether or not messages received following the gap are within an affected stream or not. If a message is received within the affected stream, there will be a corresponding gap in the Stream Sequence Number, while messages from other streams will not show a gap. The receiver can therefore continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.

3.1.2Multi-Homing
The other core feature of SCTP is multi-homing, or the ability for a single SCTP endpoint to support multiple IP addresses. The benefit of multi-homing is potentially greater survivability of the session in the presence of network failures. In a conventional single-homed session, the failure of a local LAN access can isolate the end system, while failures within the core network can cause temporary unavailability of transport until the IP routing protocols can reconverge around the point of failure. Using multi-homed SCTP, redundant LANs can be used to reinforce the local access, while various options are possible in the core network to reduce the dependency of failures for different addresses. Use of addresses with different prefixes can force routing to go through different carriers, for example, while route-pinning techniques or even redundant core networks can also be used if there is control over the network 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 is chosen as the “primary” address and is used as the destination for all DATA chunks for normal transmission. Retransmitted DATA chunks use the alternate address (es) to improve the probability of reaching the remote endpoint, while continued failure to send to the primary address ultimately results in the decision to transmit all DATA chunks to the alternate until heartbeats can reestablish the reachability of the primary.

To support multi-homing, SCTP endpoints can exchange lists of addresses during initiation of the association. Each endpoint must be able to receive messages from any of the addresses associated with the remote endpoint; in practice, certain operating systems will utilize available source addresses in round robin fashion, in which case receipt of messages from different source addresses will be the normal case. A single port number is used across the entire address list at an endpoint for a specific session.

In order to reduce the potential for security problems, it is required that some response messages be sent specifically to the source address in the message that caused the response. For example, when the server receives an INIT chunk from a client to initiate an SCTP association, the server always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT.

3.2 Other Features

3.2.1 Unicast protocol

SCTP is a unicast protocol, and supports data exchange between exactly 2 endpoints, although these may be represented by multiple IP addresses.

3.2.2 Reliable Transmission

SCTP provides reliable transmission, detecting when data is discarded, reordered, duplicated or corrupted, and retransmitting damaged data as necessary. SCTP transmission is full duplex.

3.2.3 Message Oriented

SCTP is message oriented and supports framing of individual message boundaries. In comparison, TCP is stream oriented and does not preserve any implicit structure within a transmitted byte stream.

3.2.4 Rate Adaptive

SCTP is rate adaptive similar to TCP, and will scale back data transfer to the prevailing load conditions in the network. It is designed to behave cooperatively with TCP sessions attempting to use the same bandwidth.

4. SCTP packet Format

            An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data.

4.1 SCTP Common Header Field Descriptions

            4.1.1 Source port: 16 bits (unsigned integer)

            This is SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs.

            4.1.2 Destination Port Number: 16 bits (unsigned integer)

            This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application.

            4.1.3 Verification Tag: 32 bits (unsigned integer)

            The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit; the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions:

·              A packet containing an INIT chunk MUST have a zero Verification Tag.

·              A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN-ACK chunk.

·              A packet containing an ABORT chunk may have the verification tag copied from the packet which caused the ABORT to be sent.

·              An INIT chunk MUST be the only chunk in the SCTP packet carrying it.

            4.1.4 Checksum: 32 bits (unsigned integer)

            This field contains the checksum of this SCTP packet. SCTP uses the Adler-32 algorithm for calculating the checksum.

4.2 Chunk Field Descriptions

            The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet.  Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field.

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Chunk type								Chunk flags								Chunk length
Chunk data :::

(Fig 4.1: Chunk Field description)

4.2.1 Chunk type: 8 bits (unsigned integer)

Identifies the type of information contained in the Chunk data. The value of 255 is reserved for future use as an extension field.

Chunk types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Chunk type.

Chunk Type (Higher order two bits)	Description
00	Stop processing this SCTP packet and discard it, do not process any further chunks within it.
01	Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
10	Skip this chunk and continue processing.
11	Skip this chunk and continue processing, but report in an ERROR Chunk using the 'Unrecognized Chunk Type' cause of error.

(Table 4.1: Chunk Type - Higher order two bits)

The total length of a chunk MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.

Chunk type	Description
0	DATA, Payload Data.
1	INIT, Initiation.
2	INIT ACK, Initiation Acknowledgement.
3	SACK, Selective Acknowledgement.
4	HEARTBEAT, Heartbeat Request.
5	HEARTBEAT ACK, Heartbeat Acknowledgement.
6	ABORT, Abort.
7	SHUTDOWN, Shutdown.
8	SHUTDOWN ACK, Shutdown Acknowledgement.
9	ERROR, Operation Error.
10	COOKIE ECHO, State Cookie.
11	COOKIE ACK, Cookie Acknowledgement.
12	ECNE, Reserved for Explicit Congestion Notification Echo.
13	CWR, Reserved for Congestion Window Reduced.
14	SHUTDOWN COMPLETE, Shutdown Complete.
15 :: 255

(Table 4.2: Chunk type description)

4.2.2 Chunk flags. 8 bits.
The usage of these bits depends on the chunk type as given by the Chunk type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt.

4.2.3 Chunk length. 16 bits. (Unsigned integer)
This size of the chunk in bytes including the Chunk type, Chunk flags, Chunk length, and Chunk data fields. Therefore, if the Chunk value field is zero-length, the Length field will be set to 4. This field does not count any padding.

4.2.4 Chunk data. Variable length
It contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk type.

5. SCTP Multi-homing Issues

            SCTP provides transport-layer support for multi-homing. Multi-homing has the potential of providing additional robustness against network failures.  In some applications, this may be extremely important, for example, in signaling transport of PSTN signaling messages [4].

            It should be noted that SCTP multi-homing support only deals with communication between two endpoints of which one or both is assigned with multiple IP addresses on possibly multiple network interfaces. It does NOT deal with communication ends that contain multiple endpoints (i.e. clustered endpoints) that can switch over to an alternate endpoint in case of failure of the original endpoint.

            Generally, for truly fault resilient communication between two end-points; the multi-homing feature needs more than one IP network interface for each endpoint.  The number of paths used is the minimum of network interfaces used by any of the endpoints.  When an endpoint selects its source address, careful consideration must be taken. If the same source address is always used, then it is possible that the endpoint will be subject to the same single point of failure.  When the endpoint chooses a source address, it should always select the source address of the packet to correspond to the IP address of the Network interface where the packet will be emitted subject to the binding address constraint.  The binding address constraint is, put simply, that the endpoint must never choose a source address that is not part of the association i.e., the peer endpoint must recognize any source address used as being part of the association.

            The availability of the association will benefit greatly from having multiple addresses bound to the association endpoint when the endpoint is on a multi-homed host.

6. Security Considerations

6.1 Security Objectives

As a common transport protocol designed to reliably carry time-sensitive user messages, such as billing or signaling messages for telephony services, between two networked endpoints, SCTP has the following security objectives.

o availability of reliable and timely data transport services

o integrity of the user-to-user information carried by SCTP

SCTP may potentially be used in a wide variety of risk situations. It is important for operator(s) of systems running SCTP to analyze their particular situations and decide on the appropriate counter- measures.

6.2 Countering Insider Attacks

            The principles of [RFC2196] should be applied to minimize the risk of theft of information or sabotage by insiders. Such procedures include publication of security policies, control of access at the physical, software, and network levels, and separation of services.

            6.3 Protecting against Data Corruption in the  Network

            Where the risk of undetected errors in datagrams delivered by the   lower layer transport services is considered to be too great, additional integrity protection is required.  If this additional protection were provided in the application-layer, the SCTP header would remain vulnerable to deliberate integrity attacks.  While the existing SCTP mechanisms for detection of packet replays are considered sufficient for normal operation, stronger protections are   needed to protect SCTP when the operating environment contains significant risk of deliberate attacks from a sophisticated adversary.

            In order to promote software code-reuse, to avoid re-inventing the wheel, and to avoid gratuitous complexity to SCTP, the IP Authentication Header SHOULD be used when the threat environment requires stronger integrity protections, but does not require confidentiality. A widely implemented BSD Sockets API extension exists for applications to request IP security services, such as AH or ESP from an operating system kernel. Applications can use such an API to request AH whenever AH use is appropriate.

            6.4 Protecting Confidentiality

            In most cases, the risk of breach of confidentiality applies to the signaling data payload, not to the SCTP or lower-layer protocol overheads. If that is true, encryption of the SCTP user data only might be considered.  As with the supplementary checksum service, the user application MAY use user data encryption or an implementation- specific API to request that the IP Encapsulating Security Payload (ESP) be used to provide confidentiality and integrity.

   6.5 Protecting against Blind Denial of Service Attacks

            A blind attack is one where the attacker is unable to intercept or otherwise see the content of data flows passing to and from the target SCTP node.  Blind denial of service attacks may take the form of flooding, masquerade, or improper monopolization of services.

                        6.5.1 Flooding

            The objective of flooding is to cause loss of service and incorrect    behavior at target systems through resource exhaustion, interference with legitimate transactions, and exploitation of buffer-related software bugs.  Flooding may be directed either at the SCTP

node or at resources in the intervening IP Access Links or the Internet.    Where the latter entities are the target, flooding will manifest itself as loss of network services, including potentially the breach of any firewalls in place.

            In general, protection against flooding begins at the equipment design level, where it includes measures such as:

·              avoiding commitment of limited resources before determining that the request for service is legitimate

·              giving priority to completion of processing in progress over the acceptance of new work

·              identification and removal of duplicate or stale queued requests for service.

·              not responding to unexpected packets sent to non-unicast addresses.

             Network equipment should be capable of generating an alarm and log if a suspicious increase in traffic occurs.  The log should provide information such as the identity of the incoming link and source address(es) used which will help the network or SCTP system operator to take protective measures.  Procedures should be in place for the   operator to act on such alarms if a clear pattern of abuse emerges.

             The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way start-up handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association. The IP Authentication Header and Encapsulating Security

Payload might be useful in reducing the risk of certain kinds of denial of service attacks."

                        6.5.2 Blind Masquerade

                        Masquerade can be used to deny service in several ways:

·        by tying up resources at the target SCTP node to which the impersonated node has limited access.  For example, the target node may by policy permit a maximum of one SCTP association with the impersonated SCTP node.  The masquerading attacker may attempt to establish an association purporting to come from the impersonated node so that the latter cannot do so when it requires it.

·        by deliberately allowing the impersonation to be detected, thereby provoking counter-measures which cause the impersonated node to be locked out of the target SCTP node.

·        by interfering with an established association by inserting extraneous content such as a SHUTDOWN request.

                        SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Because the initial exchange is memory less, no lockout mechanism is triggered by blind masquerade attacks.  In addition, the INIT ACK containing the State Cookie is transmitted back to the IP address from which it received the INIT.  Thus the attacker would not receive the INIT ACK containing the State Cookie.  SCTP protects against insertion of extraneous packets into the flow of an established association by use of the Verification Tag. Logging of received INIT

requests and abnormalities such as    unexpected INIT ACKs might be considered as a way to detect patterns of hostile activity.  However, the potential usefulness of such logging must be weighed against the increased SCTP startup processing it implies, rendering the SCTP node more vulnerable to flooding attacks.  Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis.

                        6.5.3 Improper Monopolization of Services

            Attacks under this heading are performed openly and legitimately by the attacker.  They are directed against fellow users of the target SCTP node or of the shared resources between the attacker and the target node.  Possible attacks include the opening of a large number of associations between the attacker's node and the target, or transfer of large volumes of information within a legitimately-established association.

            Policy limits should be placed on the number of associations per   adjoining SCTP node.  SCTP user applications should be capable of detecting large volumes of illegitimate or "no-op" messages within a given association and either logging or terminating the association as a result, based on local policy.

            6.6 Protection against Fraud and Repudiation

            The objective of fraud is to obtain services without authorization and specifically without paying for them.  In order to achieve this objective, the attacker must induce the SCTP user application at the target SCTP node to provide the desired service while accepting invalid billing data or failing to collect it.  Repudiation is a related problem, since it may occur as a deliberate act of fraud or simply because the repudiating party kept inadequate records of service received.

            Potential fraudulent attacks include interception and misuse of authorizing information such as credit card numbers, blind masquerade and replay, and man-in-the middle attacks which modify the packets passing through a target SCTP association in real time.

            However, SCTP does not protect against man-in-the-middle attacks where the attacker is able to intercept and alter the packets sent and received in an association.  For example, the INIT ACK will have sufficient information sent on the wire for an adversary in the    middle to hijack an existing SCTP association.  Where a significant possibility of such attacks is seen to exist, or where possible repudiation is an issue, the use of the IPSEC AH service is recommended to ensure both the integrity and the authenticity of the SCTP packets passed.

            SCTP also provides no protection against attacks originating at or beyond the SCTP node and taking place within the context of an existing association.  Prevention of such attacks should be covered by appropriate security policies at the host site

7. Security Issues

            In this section, some relevant security issues found in the deployment of the connection-oriented transport protocols will be discussed.

             7.1 Security issues with TCP

            Some TCP implementations have been known to be vulnerable to blind denial of service attacks, i.e., attacks that had been executed by an attacker that could not see most of the traffic to or from the target host.

            The attacker would send a large number of connection establishment requests (TCP-SYN packets) to the attacked target, possibly from faked IP source addresses.  The attacked host would reply by sending SYN-ACK packets and entering SYN-received state, thereby allocating space for a TCB.  At some point the SYN-queue would fill up, (i.e., the number of connections waiting to be established would rise to a limit) and the host under attack would have to start turning down new connection establishment requests.

            TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the risk of such blind denial of service attacks.  TCP implementations can switch to using this algorithm in times when their SYN-queues are filled up while still fully conforming to the TCP specification [2].  However, use of options such as a window scale, is not possible, then.  With the SYN-cookie mechanism, a TCB is only created when the client sends back a valid ACK packet to the server, and the 3-way handshake has thus been successfully completed.

            Blind connection forgery is another potential threat to TCP.  By guessing valid sequence numbers, an attacker would be able to forge a

connection.  However, with a secure hashsum algorithm, for some of the current SYN-cookie implementations the likelihood of achieving this attack is on the order of magnitude of 1 in 2^24, i.e., the attacker would have to send 2^24 packets before obtaining one forged connection when SYN-cookies are used.

            7.2 Security issues with SCTP

            SCTP has been designed with the experiences made with TCP in mind. To make it hard for blind attackers (i.e., attackers that are not man-in-the-middle) to inject forged SCTP datagrams into existing associations, each side of an SCTP association uses a 32 bit value called "Verification Tag" to ensure that a datagram really belongs to the existing association.  So in addition to a combination of source and destination transport addresses that belong to an established association, a valid SCTP datagram must also have the correct tag to be accepted by the recipient.

            Unlike in TCP, usage of cookie in association establishment is made mandatory in SCTP. For the server, a new association is fully established after three messages (containing INIT, INIT-ACK, and COOKIE-ECHO chunks) have been exchanged.  The cookie is a variable length parameter that contains all relevant data to initialize the TCB on the server side, plus a HMAC used to secure it.  This HMAC (MD5 or SHA-1) is computed over the cookie and a secret, server-owned key.

            As specifically prescribed for SCTP implementations [1], additional resources for new associations may only be reserved in case a valid COOKIE-ECHO chunk is received by a client, and the computed HMAC for this new cookie matches that contained in the cookie.

            With SCTP the chances of an attacker being able to blindly forge a connection are even lower than in the case of TCP using SYN-cookies, since

the attacker would have to guess a correct value for the HMAC contained in the cookie, i.e., lower than 1 in 2^128 which for all practical purposes is negligible.

            It should be noted that SCTP only tries to increase the availability of a network.  SCTP does not contain any protocol mechanisms that are directly related to user message authentication, integrity and confidentiality functions.  For such features, it depends on the IPsec protocols and architecture and/or on security features of the application protocols.

            Transport Layer security (TLS) using SCTP must always use in-order streams.

            Currently the IPSEC working group is investigating the support of multi-homing by IPSEC protocols.  At the present time to use IPSEC, one must use 2 * N * M security associations if one endpoint uses N addresses and the other M addresses.

            7.3 Security Issues with both TCP and SCTP

            It is important to note that neither TCP nor SCTP protect itself from

man-in-the-middle attacks where an established session might be hijacked (assuming the attacker can see the traffic from and inject its own packets to either endpoint).

            Also, to prevent blind connection/session setup forgery, both TCP implementations supporting SYN-cookies and SCTP implementations rely on a server-known, secret key to protect the HMAC data.  It must be ensured that this key is created subject to the recommendations mentioned in [3].

            Although SCTP has been designed carefully as to avoid some of the problems that have appeared with TCP, it has as of yet not been widely

deployed.  It is therefore possible that new security issues will be identified that will have to be addressed in further revisions of [1].

8. SCTP applications.

Applications would benefit most that:

· have sufficient traffic levels to justify the overhead of association establishment and congestion and flow control measures

· require framing of reliable data streams

· transfer multiple independent message sequences that are unrelated

· need to transfer messages that do not need to be delivered in sequence

· require network layer redundancy

The transport protocol for Public Switched Telephone Network (PSTN) or loading of web pages is examples of applications that might benefit.

Applications would benefit little that:

· generate small amounts of unrelated transactions toward a destination

· require strict ordering of all data

· are oriented toward byte-stream transfer as opposed to message transfer

· do not require network-level redundancy or run on machines with only one network interface card

               File transfer is an example of an application is oriented toward byte-stream transfer and, therefore, would derive little or no benefit from framing or multi-stream capabilities. E-mail generates small amounts of unrelated transactions toward a destination.

9. References

[1] RFC2960: 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", October 2000. (http://rfc.sunsite.dk/rfc/rfc2960.html )

[2] RFC793:  Postel J., "Transmission Control Protocol", STD 7, September 1981.

(http://rfc.sunsite.dk/rfc/rfc793.html )

[3] RFC1750:  Eastlake D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", December 1994. (http://rfc.sunsite.dk/rfc/rfc1750.html )

[4] RFC2719:  Ong L., Rytina I., Garcia M., Schwarzbauer H., Coene L., Lin H., Juhasz I., Holdrege M. and C. Sharp, "Architectural Framework for Signaling Transport", October 1999. (http://rfc.sunsite.dk/rfc/rfc2719.html )

[5] RFC3257:  L. Coene, Siemens "Stream Control Transmission Protocol Applicability Statement”, April 2002. (http://rfc.sunsite.dk/rfc/rfc3257.html)

Appendix A: SCTP Terminology

This document uses certain terms and abbreviations that have a special meaning which is defined in [1], and may be confusing at first.

Active destination transport address:

A transport address on a peer endpoint which a transmitting endpoint considers available for receiving user messages.

Bundling

An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk.

Chunk

A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.

Congestion Window (cwnd)

An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement.

Cumulative TSN Ack Point

The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK.

Idle destination address

An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater.

Inactive destination transport address

An address which is considered inactive due to errors and unavailable to transport user messages.

Message Authentication Code (MAC)

An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term "MAC" has different meanings in different contexts. SCTP uses this term with the same meaning as in RFC2104.

Ordered Message

A user message that is delivered in order with respect to all previous user messages sent within the stream the message was sent on.

Outstanding TSN (at an SCTP endpoint)

A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.

Path

The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.

Primary Path

The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed.

Receiver Window (rwnd)

An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer.

SCTP association

A protocol relationship between SCTP endpoints composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.

SCTP endpoint

The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.

SCTP packet

The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks.

SCTP user application

The logical higher-layer application entity which uses the services of SCTP, also called the Upper-layer Protocol (ULP).

Slow Start Threshold (ssthresh)

An SCTP variable. This is the threshold which the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes.

Stream

A uni-directional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.

Stream Sequence Number

A 16-bit sequence number used internally by SCTP to assure sequenced delivery of the user messages within a given stream. One stream sequence number is attached to each user message.

Transmission Sequence Number (TSN)

A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.

Transport address

A Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol).

Unacknowledged TSN (at an SCTP endpoint)

A TSN (and the associated DATA chunk) which has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received.

Unordered Message

Unordered messages are "unordered" with respect to any other message, this includes both other unordered messages as well as other ordered messages. Unordered message might be delivered prior to or later than ordered messages sent on the same stream.

Verification Tag

A 32 bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association.

Appendix B: Abbreviations

The following list of abbreviations is also largely taken from RFC2960 [1].

MAC Message Authentication Code

RTO Retransmission Time-out

RTT Round-trip Time

RTTVAR Round-trip Time Variation

SCTP Stream Control Transmission Protocol

SRTT Smoothed RTT

TCB Transmission Control Block

TLV Type-Length-Value Coding Format

TSN Transmission Sequence Number

ULP Upper-layer Protocol

TO DOWN LOAD REPORT AND PPT

DOWNLOAD

SEMINARS AND PROJECTS

STREAM CONTROL TRANSMISSION PROTOCOL