WDIFF

draft-ietf-sigtran-mdtp-06.txt --> draft-ietf-sigtran-sctp-00.txt

INTERNET-DRAFT Q. Xie
Motorola
K. Morneau Morneault
C. Sharp
Cisco
H. J. Schwarzbauer
Siemens
T. Taylor
Nortel Networks
I. Rytina
Ericsson
M. Kalla
Telcordia
L. Zhang
UCLA

expires in six months June 25,1999

MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL
<draft-ietf-sigtran-mdtp-06.txt> September 23,1999

Simple Control Transmission Protocol
<draft-ietf-sigtran-sctp-00.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This Internet Draft discusses a new protocol, namely document describes the Multi-network
Datagram Simple Control Transmission Protocol (MDTP), that is intended
(SCTP). SCTP was designed to provide
fault-tolerant reliable data transfer between communicating entities transport PSTN signalling messages over
IP networks [1].

MDTP networks, but is capable of broader application.

SCTP is proposed as an application-level datagram transfer protocol that is designed operating on
top of an unreliable datagram service such as UDP. It offers the
following services to
support redundant networks and transparent fault management. MDTP also
provides timing control and configuration flexibilities its users:

-- acknowledged error-free non-duplicated transfer of user data
-- application-level segmentation to meet conform to discovered MTU size
-- sequenced delivery of user datagrams within multiple streams,
with an option for order-of-arrival delivery of individual
datagrams
-- optional multiplexing of user datagrams into SCTP datagrams,
subject to MTU size restrictions
-- enhanced reliability through support of multi-homing at either or
both ends of the
stringent timing requirements often found in telephony signaling
protocols. association.

The motivation design of developing MDTP is SCTP includes appropriate congestion avoidance behaviour
and resistance to support
Internet-based high reliability applications such as signaling flooding and
call control for Internet telephony. masquerade attacks.

Stewart, et al [Page 1]

Internet Draft Multi-network Datagram Simple Control Transmission Protocol June September 1999

TABLE OF CONTENTS

1. Introduction.......................................................3 Introduction
1.1 Terminology......................................................3 Motivation
1.2 Design Requirements Architectural View of MDTP......................................4 SCTP
1.3 Interface to MDTP................................................5 Functional View of SCTP
1.3.1 Association Startup and Takedown
1.3.2 Sequenced Delivery within Streams
1.3.3 User Data Segmentation
1.3.4 Acknowledgement and Congestion Avoidance
1.3.5 Chunk Multiplex
1.3.6 Path Management
1.3.7 Message Validation
1.4 Recapitulation of Key Terms
1.5. Abbreviations
2. MDTP SCTP Datagram Format...............................................5 Format
2.1 MDTP SCTP Common Header Field Descriptions............................6 Descriptions
2.2 MDTP Control Chunk Field Descriptions
2.2.1 INIT/INIT ACK Parameter Part Definitions..........................7 Format
2.2.1.1 Vendor-Specific Extensions (0xFFFE)
2.3 MDTP SCTP Chunk Definitions
2.3.1 Initiation (INIT)
2.3.1.1 Optional or Variable Length Parameters
2.3.2 Initiation Acknowledgement (INIT ACK)
2.3.3 Selective Acknowledgement (SACK)
2.3.4 Heartbeat Request (HEARTBEAT)
2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK)
2.3.6 Abort Association (ABORT)
2.3.7 Shutdown Association (SHUTDOWN)
2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK)
2.3.9 Operation Error (ERROR)
2.3.10 Encryption Cookie (COOKIE)
2.3.11 Cookie Acknowledgment (COOKIE ACK)
2.3.12 Payload Data Part Definitions......................................11 (DATA)
2.3.13 Vendor-Specific Chunk
2.4 Bundling
3. Endpoint SCTP Association Initialization...............................12
3.1 Initiation Message and Tag Lock.................................12
3.1.1 Passing Initiation State Diagram
4. Association Initialization
4.1 Normal Establishment of an Association
4.1.1 Handle Stream Parameters ................................12
3.2 Tag Unlock and TSN Initialization...............................13
3.3 Datagram
4.1.2 Handle Address Parameters
4.1.3 Generating Responder Cookie
4.1.4 Cookie Processing during Tag Lock ............................14
3.4
4.1.5 Cookie Authentication
4.1.6 An Example of Normal Association Initialization .......................14
3.5 Establishment
4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK
4.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-SENT State
4.2.2 Handle Duplicate INIT in Other Initiation Issues.........................................15
3.5.1 States
4.2.3 Handle Duplicate INIT ACK
4.2.4 Handle Duplicate COOKIE
4.2.5 Handle Duplicate COOKIE-ACK
4.2.6 Handle Stale COOKIE Error
4.3 Other Initialization Issues
4.3.1 Selection of Tag Value......................................15
3.5.2 Value
4.3.2 Initiation from behind a NAT................................15
3.5.3 Initialization Collision....................................16
3.5.4 Association Re-initialization...............................16
4. Transfer NAT
5. User Datagram............................................16
4.1 Data Transfer
5.1 Transmission of DATA Chunks
5.2 Acknowledgment of Reception of DATA Chunks
5.3 Timer Management Rules..........................................17
4.1.1 T3-send Rules
5.3.1 T3-rxt Timer Adjustment with RTT...........................18
4.2 Multihoming Rotation............................................18
4.2.1 Remote Multihoming Rotation.................................18
4.2.2 Local Multihoming Rotation..................................19
4.3 RTT
5.4 Multi-homed SCTP Endpoints
5.5 Stream Identifier and Sequence Number..........................................19
4.4 Number
5.6 Ordered and Un-ordered Delivery.................................19
4.5 Delivery
5.7 Report Missing Datagrams........................................20
4.6 Gaps in Received DATA TSNs
5.8 TSN Range Check
5.9 CRC-16 Utilization
5.10 Segmentation
5.11 Bundling
5.12 Retransmission
5.12.1 Basic Retransmission Rules
5.12.2 Retransmit on TSN .............................................21
4.7 Advisory Ack Request............................................21
4.8 CRC utilization.................................................21
5 Congestion Controls...............................................22
5.1 Send with Window Control........................................22
5.1.1 Window Length Adjustment....................................23
5.2 Send T3-rxt Timer Expiration
5.12.3 T3-rxt Timer Back-off at Re-transmission..........................24
6. Network Management................................................25
6.1 Failure Detection in Redundant Networks.........................25 Congestion Control
6.1 SCTP Differences from TCP Congestion Control
6.2 RTT Measurement.................................................26 SCTP Slow-Start and Congestion Avoidance
6.2.1 Slow-Start
6.2.2 Congestion Avoidance
6.2.3 Congestion Control
6.2.4 Fast Retransmit on Gap Reports
6.3 Network Heart Beat .............................................26 Path MTU Discovery
6.4 Discussion
7. Fault Management
7.1 Endpoint Failure Detection
7.2 Path Failure Detection
7.3 Path Heartbeat
7.4 Verification Tag
7.5 RTT/RTO Measurement
8. Termination of Association........................................27
7.1 Graceful Shutdown Association
8.1 Close of an Association.............................28
8. Stream Operations.................................................29
8.1 Stream Initiation...............................................29 Association
8.2 Stream Termination..............................................29
8.3 Other Issues with Stream Operations.............................30 Shutdown of an Association
9. Interface with Upper Layer........................................30 Layer
9.1 ULP-to-SCTP
9.2 SCTP-to-ULP
9.3 Interfaces to Layer Management
9.3.1 LM-to-SCTP
9.3.2 SCTP-to-LM
10. Security Considerations
10.1 Security Objectives
10.2 SCTP Responses To Potential Threats
10.2.1 Countering Insider Attacks
10.2.2 Protecting against Data Corruption in the Network
10.2.3 Protecting Confidentiality
10.2.4 Protecting against Blind Denial of Service Attacks
10.2.4.1 Flooding
10.2.4.2 Masquerade
10.2.4.3 Improper Monopolization of Services
10.3 Protection against Fraud and Repudiation
11. IANA Consideration
12. Suggested MDTP SCTP Timer and Protocol Parameter Values................34
11. Abbreviations.....................................................34
12. Acknowledgments...................................................34 Values
13. Authors' Addresses................................................34 Acknowledgments
14. References........................................................35

Stewart, et al [Page 2]

Internet Draft Multi-network Datagram Transmission Protocol June 1999 Authors' Addresses
15. References

1. Introduction

This Internet Draft discusses a new protocol, namely section explains the Multi-network
Datagram reasoning behind the development of the
Simple Control Transmission Protocol (MDTP). The intention of developing
MDTP is (SCTP), the services it offers,
and the basic concepts needed to provide a fault-tolerant, real-time understand the detailed description
of the protocol.

1.1 Motivation

TCP [RFC 793, "Transmission Control Protocol", Jon Postel ed.,
September 1981] has performed immense service as the primary means of
reliable data transfer
mechanism between communicating endpoints over in IP networks [1].

MDTP is proposed as networks. However, an application-level increasing number
of recent applications have found TCP too limiting, and have
incorporated their own reliable data transfer protocol that is designed on top of UDP
[RFC 768, "User Datagram Protocol", Jon Postel, August 1980]. The
limitations which users have wished to
support redundant networks bypass relate both to the
intrinsic nature of TCP and transparent fault management. MDTP also to its typical implementation.

Intrinsic limitations:

-- TCP provides timing control both reliable data transfer and configuration flexibilities to meet strict order-
of-arrival delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be
satisfied with partial ordering of the
stringent timing requirements often found in telephony signaling
protocols. data. In both of these
cases the head-of-line blocking offered by TCP causes
unnecessary delay.

-- The motivation stream-oriented nature of developing MDTP TCP is often an inconvenience.
Applications must add their own record marking to support
Internet-based high reliability applications such as signaling delineate
their messages, and
call control for Internet telephony.

MDTP is also designed must make explicit use of the push facility
to be scalable ensure that a complete message is transferred in order to support different
signaling transport requirements for different interfaces to a
telephony network.

For example, the transportation
reasonable time.

-- The limited scope of signaling protocols such as ISDN
PRI may not require redundant networks, and hence only a subset TCP sockets complicates the task of
MDTP will need
providing highly-available data transfer capability using
multi-homed hosts.

Limitations due to be implemented. On implementation:

-- TCP is generally implemented at the other hand, redundant
networks operating system level.
Kernel limitations may be mandated when transporting SS7 signaling messages
amongst different components in a carrier-grade telephony core
network. In such cases, constrain the transparent support for redundant
networks, load sharing, and fault management defined in MDTP become
essential.

Many maximum allowable number
of the fundamental concepts simultaneous TCP connections to a number far below that have made
required for certain applications.

-- TCP such implementations do not generally allow the application
to control the timers which determine how quickly a useful
protocol connection
failure is discovered. Some applications are reused in MDTP, and some more critically
dependent than others on timely initiation of the advantages recovery from
such failures.

Transport of UDP are
also merged into PSTN signalling across the design.

1.1 Terminology

The following terms IP network is an application
for which all of these limitations of TCP are defined and used in relevant. While this document:

- Redundant networks:

An endpoint
application directly motivated the development of SCTP, other
applications may be able to transmit or receive on more than one IP
address/UDP port. RFC 1122 refers find SCTP a good match to this their requirements.

1.2 Architectural View of SCTP

SCTP is viewed as multi-homing. This
constitutes a redundant local network (for MDTP) relative to the
endpoint. MDTP makes no attempt to assure routing diversity within
the Internet connecting two endpoints. Each endpoint attempts to
send to its peer endpoint using all layer between the IP addresses SCTP user application ("SCTP
user" for short) and UDP ports
its peer has open (within an unreliable end-to-end datagram service such as
UDP. The basic service offered by SCTP is the constraints reliable transfer of any application
specified restrictions). The choice
user datagrams between peer SCTP users. It performs this service
within the context of which local socket to send
upon is an implementation detail (it is possible only one socket is
available and bound to all association between two SCTP Hosts. Chapter 9
of this document sketches the local networks to API which the machine is
connected). The O/S also will play a role in the multi-homing/redundancy.
MDTP attempts a best effort should exist at spreading the traffic across a

Stewart, et al [Page 3]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

destination's available interfaces. It is assumed by MDTP that boundary
between the
network (if fault tolerance SCTP and the SCTP user layers.

SCTP is desired) connection-oriented in nature, but the SCTP association is engineered for diversity
and MDTP's best effort will play only a small role in that diversity.

- Endpoint:

Representation of
broader concept than the logical point where MDTP datagrams can be sent
to or received from. Moreover, an MDTP TCP connection. SCTP provides the means for
each SCTP endpoint shall be defined as to provide the other during association startup
with a set list of IP address/port combinations in order to support redundant
networks. For example, an transport addresses (e.g. address/UDP port
combinations) through which that endpoint on a multi-homed host connected
with N IP networks can be represented as:

[IP addr1/port1,
...
IP addrN/portN]

where reached and from
which it will originate messages. The association spans transfers
over all of the port numbers or IP addresses may not be unique, but their possible source/destination combinations shall which may be guaranteed unique by
generated from the underneath IP
networks.

- Association:

Representation of an ongoing logical communication channel between
two MDTP endpoints.

- Sub-layering:

Conceptually MDTP is subdivided into two sub-layers, as shown below:

+--------------------------+ endpoint lists.

This Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| Unreliable |One or more ---- One or more| Unreliable |
| Datagram |port/address \/ port/address| Datagram |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|

SCTP Host A |<-------- Network transport ------->| SCTP Host B

Figure 1: An SCTP Association

It is introduced possible to achieve a clear separation between:
1) have multiple associations active between the reliable same
pair of SCTP Hosts.

1.3 Functional View of SCTP

The SCTP transport on service can be decomposed into a per association basis, number of
functions. These are depicted in Figure 2 and
2) the in-sequence delivery on a per stream basis to avoid blocking
between independent streams.

- Reliability Sub-layer:

This Sub-layer copes only with functions to guarantee explained in the
remainder of this section.

SCTP User Application

..-----------------------------------------------------
.. _____________ ____________________
| | | Sequenced delivery |
| Association | | within streams |
| | |____________________|
| startup |
..| | ____________________________
| and | | User Data Segmentation |
| | |____________________________|
| takedown |
..| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
..| | |____________________________|
| |
| | ____________________________
| | | Chunk Multiplex |
| | |____________________________|
| |
| | ________________________________
| | | Path Management |
| | |________________________________|
| |
| | ________________________________
| | | Message Validation |
|______________ |________________________________|

Figure 2: Functional View of a datagram at its peer. At this sub-layer there
is no subdivision into different streams.

- Transmission Sequence Number (TSN):

A TSN is assigned to every datagram sent that transports user
data. The TSN the SCTP Transport Service

1.3.1 Association Startup and Takedown

An association is used initiated by a request from the peer Reliability Sub-layer to detect any
missing or duplicate SCTP user data. The TSN is processed by (see the
Reliability Sub-layer only. Its value and presence is not known by
description of the Sequencing Sub-layer

- Sequencing Sub-layer

This sub-layer copes only with ordered delivery ASSOCIATE primitive in Chapter 9). The startup
sequence is described in chapter 4 of datagrams
belonging to a certain stream. this document. It is based designed to
be resistant to flooding and masquerade attacks.

SCTP provides for graceful takedown of an active association on
request from the fact that
the Reliability Sub-layer has ensured SCTP user. See the guaranteed delivery description of datagrams.

- Stream:

Defined the TERMINATE
primitive in chapter 9. SCTP also allows ungraceful takedown, either
on request from the user (ABORT primitive) or as a unidirectional logical sub-channel within result of an existing
association (see the example below).

Each stream shall be identified by a stream ID that is unique error
condition detected within the association and with regard to SCTP layer. Chapter 8 describes both the endpoint that opens
graceful and the stream.

Endpoint "A" Endpoint "Z"

------- association -------
|===========================|
Stream ID | |
0 ----------------------------> |
1 ----------------------------> |
2 ----------------------------> |
| | Stream ID
| <---------------------------- 0
| <---------------------------- 1
| <---------------------------- 2
| <---------------------------- 3
| |
|===========================|
------- -------

Datagrams sent through ungraceful takedown procedures.

1.3.2 Sequenced Delivery within Streams

The term "stream" is used in SCTP to refer to a stream shall be reliably transmitted and
delivered independent sequence of datagrams. This is
in contrast to datagrams from other streams.

As an implementation consideration, both its usage in TCP, where it refers to a sequence of bytes.

The SCTP user can specify at association startup time the sender and receiver
sides may need number of
streams to dedicate resources, e.g., data queues, for each
existing stream.

- Stream Sequence Number (SSN):

A Stream Sequence Number be supported by the association. This number is negotiated
with the remote end (see section 4.1.1). User datagrams are associated
with every datagram
having stream numbers (SEND, RECEIVE primitives, Chapter 9). Internally,
SCTP assigns a TSN. The SSN is valid only within the stream where the sequence number to each datagram belongs to. The SSN is processed passed to it by
the Sequencing
Sub-layer on SCTP user. On the receiving side, SCTP ensures that datagrams are
delivered to the SCTP user in sequence within a per given stream. However,
while one stream basis.

Stream 0xffff is reserved and shall not be used. Stream 0x0 is
open per default upon initiating an association and is not to may be
terminated.

- Sequence-number Attack:

As defined in RFC 1948 [10].

- CRC Usage Policy:

The minimum level of data integrity is provided using blocked waiting for the checksum next in-sequence user
datagram, delivery from other streams may proceed.

SCTP provides a mechanism of for bypassing the underlying transport protocol. It is therefore
required that sequenced delivery
service. Datagrams sent using this mechanism is always enabled when transferring
MDTP datagrams.

In order are delivered to meet higher data integrity, the SCTP
user as required for transporting
of certain SCN signaling protocols, an additional 16 bit CRC value soon as they are received.

1.3.3 User Data Segmentation

SCTP can optionally be carried in an MDTP datagram.

See ITU-T Recommendation Q.703 [11] for details of how segment user datagrams to calculate ensure that the SCTP datagram
passed to the lower layer conforms to the path MTU. Segments are
reassembled into complete datagrams before being passed to the SCTP
user.

1.3.4 Acknowledgement and Congestion Avoidance

SCTP assigns a 16 bit CRC.

1.2 Design Requirements Transmission Sequence Number (TSN) to each user data
segment or unsegmented datagram. The TSN is independent of MDTP any
sequence number assigned at the stream level. The following receiving end
acknowledges all TSNs received, even if there are some of gaps in the design requirements of MDTP
sequence. In this way, reliable delivery is kept functionally separate
from sequenced delivery.

The Acknowledgement and Congestion Avoidance function is responsible
for message retransmission when timely acknowledgement has not been
received. Message retransmission is conditioned by congestion
avoidance procedures similar to
make MDTP capable those used for TCP.

See Chapters 5 and 6 for a detailed description of supporting real-time call control environments
that may employ redundant networks:

A) High communication fan-out: an endpoint may need to be in
simultaneous communication the protocol
procedures associated with hundreds or thousands of endpoints
performing various call processing functions. These endpoints may
be codec converters, SS7 to IP translation applications, or, this function.

1.3.5 Chunk Multiplex

As described in Chapter 2, the
case of mobile networks, data selector and combiner applications.

B) Stringent timer control: an endpoint needs SCTP datagram as delivered to have the lower
layer consists of a very fine common header followed by one or more chunks. Each
chunk may contain either user data or SCTP control over information. The
SCTP user has the timing for delivering option to request "bundling", or multiplexing of
more than one user datagram into a single SCTP datagram. The timing
should be easily adjusted depending on chunk
multiplex function of SCTP is responsible for assembly of the message type complete
SCTP datagram and its disassembly at the
destination. For example, after a few seconds receiving end.

1.3.6 Path Management

The sending SCTP user is able to manipulate the set of non-delivery transport
addresses used as destinations for SCTP datagrams, through the
call which
primitives described in Chapter 9. The SCTP path management function
chooses the message is about may not exist anymore.

Stewart, et al [Page 4]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

C) Support multiple network paths: an endpoint communicating with a peer
should be able to take advantage of destination transport address for each outgoing datagram
based on the multiple network paths SCTP user's instructions and
multi-homing in a transparent way. Therefore, the protocol must
be able to take advantage currently perceived
reachability status of local multi-homed hosts and remote
multi-homed hosts to provide resilient data delivery. This means
that the application or upper layer protocols need not to be involved
in the network fault management. Instead, when network failure occurs
MDTP should be able to automatically transmit out-bound datagrams to an
alternate eligible destination network interface (if one exists) without
intervention from the application.

D) Reliable transport: datagrams might be lost or discarded while
traveling in the IP network towards the destination. set.

The protocol
must handle path management function monitors reachability through heartbeat
messages where other message traffic is inadequate to provide this
information, and advises the re-transmission SCTP user when reachability of lost messages in an autonomous
way without any intervention from far-
end transport address changes. The path management function is also
responsible for reporting the upper layer. Also, sometimes
datagrams may arrive in duplicate copies, in such cases MDTP must
be able eligible set of local transport
addresses to detect and remove the duplicates automatically.

E) Support both ordered and unordered delivery: MDTP must support
both ordered far end during association startup, and unordered delivery. In for reporting
the case of ordered
delivery, transport addresses returned from the receiver shall detect out-of-order datagrams and
re-order them before dispatching them far end to the upper layer. In the
unordered case, received datagrams shall be dispatched without any
effort SCTP user.

At association start-up, a primary destination transport address is
defined for each SCTP endpoint, and is used for normal sending of re-ordering.

F) Support stream sequencing: on SCTP
datagrams.

On the demand of receiving end, the upper layer
protocols or applications, MDTP should be able to support sequenced
delivery with regard to each individual stream, i.e., path management is responsible for verifying
the delay caused
by existence of a valid SCTP association to which the loss inbound SCTP
datagram belongs before passing it for further processing.

1.3.7 Message Validation

The common SCTP header includes a validation tag and retransmission an optional
CRC field. A validation tag value is chosen by each end of the
association during association startup. Messages received without the
validation tag value expected by the receiver are discarded, as a datagram should
protection against blind masquerade attacks and against stale
datagrams from a previous association.

The CRC may optionally be isolated set by the sender, to
only provide
additional protection against data corruption in the stream network beyond
that provided by lower layers (e.g. the UDP checksum).

1.4 Recapitulation of Key Terms

The language used to which describe SCTP has been introduced in the datagram belongs.
previous sections. This is particularly
important in some call control applications, where section provides a loss consolidated list of a
message should only affect the call whom the message belongs to.

1.3 Interface to MDTP
key terms and their definitions.

SCTP user application (SCTP user): The logical higher-layer
application programs or upper layer protocols entity which uses the services of SCTP.

User datagram (user message): the unit of data delivery across the interface with MDTP
through a set
between SCTP and its user.

User data: the content of primitives (see section 9).

Towards user datagrams.

SCTP user data: the IP networks, content of SCTP user datagrams.

SCTP datagram: the unit of data delivery across the interface
between SCTP and the unreliable datagram service (e.g. UDP) which
it is assumed that UDP using. An SCTP datagram includes the common SCTP header, possible SCTP
control chunks, and user data encapsulated within SCTP DATA chunks.

SCTP host: a physical unit within which SCTP is used running.

Transport address: an address which serves as a source or
destination for the unreliable datagram transport layer. No special interfaces or changes are assumed within
UDP or at service used by
SCTP. In IP networks, a transport address is defined by the UDP/MDTP interface. MDTP maintains its own queuing
combination of an IP address and
endpoint association. When MDTP runs on a router or on UDP port number.

SCTP endpoint: a
gateway-enabled logical entity, comprising a set of eligible
transport addresses at an SCTP host, it which SCTP datagrams will place no special constraints on be
sent to and received from. Note, a transport address can only be
included in one unique SCTP endpoint, i.e., it is NOT allowed to
have the
lower layer protocol implementations other same SCTP transport address appear in more than those described one
endpoints.

SCTP association: a protocol relationship between SCTP endpoints in
two SCTP hosts, comprising the
Router Requirements SCTP endpoint at each host and Host Requirements RFCs.

2. MDTP Datagram Format

A MDTP datagram consists
protocol state information including verification tags and the
currently active set of Transmission Sequence Numbers (TSNs).

Chunk: a common unit of information within an SCTP datagram, consisting of
a chunk header and possibly a control
parameter part, chunk-specific content.

Transmission Sequence Number (TSN): a 32-bit sequence number used
internally by SCTP. One TSN is attached to each chunk containing
user data part, or both.

Stewart, et al [Page 5]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

MDTP Datagram Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-16/MDTP Protocol Identifier | Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Reserved |C| Data Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Control Parameter Part /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Data Part /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: Message Type to permit the receiving SCTP endpoint to acknowledge its
receipt and Data Size detect duplicate deliveries.

Stream: a uni-directional logical channel established between SCTP
user peers, within which all user datagrams are delivered in
sequence except for those submitted to the common header MUST be
transmitted in network byte-order. unordered delivery service.
Note: when both the control part and data part are present The relationship between stream numbers in an MDTP
datagram, opposite directions is
strictly a matter of how the control part MUST be processed first.

2.1 MDTP Common Header Field Descriptions

CRC-16/MDTP Protocol Identifier: 28 bits

When applications use them. It is the C Bit is NOT set, this field shall contain the 28 bit
MDTP Protocol Identifier with a fixed value
responsiblity of 0xf787307. The
receiver shall verify this Protocol Identifier before it
consider the received datagram application to create these correlations if it
is desirable.

Stream sequence number: a valid MDTP datagram.

When 16-bit sequence number used internally by
SCTP to assure sequenced delivery of the C Bit datagrams within a given
stream. One stream sequence number is set, attached to each user
datagram.

Bundling: an optional multiplexing operation, whereby more than one
user datagram may be carried in the most significant 16 bits of this
field shall contain same SCTP datagram. Each user
datagram occupies its own DATA chunk.

Outstanding TSN (at an SCTP endpoint): a CRC-16 value, and the other 12 bits shall
be filled with '0' TSN (and associated DATA
chunk) which have been sent by the sender and ignored endpoint but for which it has not
yet received an acknowledgement.

Unacknowledged TSN (at an SCTP endpoint): a TSN (and associated DATA
chunk) which have been received by the receiver, as
illustrated below:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-16 |0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version: 4 bits

This field represents endpoint but for which an
acknowledgement has not yet been sent.

Flight Size (fsize): An SCTP protocol variable indicating the version total
number of the MDTP protocol,
and shall currently outstanding TSNs.

[Editors Note: may need to enhance flight size to be set specific to 0x3.

Message Type: 8 bits

When the value is non-zero, this shall indicate the type
a destination transport address ]

Receiver Window (rwnd): The most recently advertised receiver
window, in number of
control message present user DATA chunks (i.e., TSNs). This gives an
indication of the space available in the current MDTP datagram. A value receiver inbound buffer.

Congestion Window (cwnd): An SCTP variable that limits the number of
0x0 indicates
user DATA chunks (i.e., TSNs) a sender can send into the control part network
before receiving an acknowledgment on a particular destination Transport
address.

Slow Start Threshold (ssthresh): An SCTP variable. This is NOT present in the current
datagram.

Stewart, et al [Page 6]

Internet Draft Multi-network Datagram
threshold which the endpoint will use to determine whether to
perform slow start or congestion avoidance on a particular destination
Transport address.

Transmission Protocol June 1999

The value Control Block (TCB): an internal data structure
created by an SCTP host for each of Message Type is defined as its existing SCTP associations
to maintain and manage the follows:

0x0 - indicating control part is NOT present

0x1 - Initiation
0x2 - Initiation Ack
0x3 - Extended Data Ack
0x4 - Advisory Ack Request
0x5 - Window-up
0x6 - Window-up Ack
0x7 - RTT-request
0x8 - RTT-ack
0x9 - Abort
0xa - Graceful Shutdown
0xb association.

1.5. Abbreviations

NAT - Graceful Shutdown Ack
0xc Network Address Translation

MD5 - Stream Initiation
0xd MD5 Message-Digest Algorithm (RFC 1321)

RTT - Stream Initiation Ack
0x10 Round Trip Time

SCTP - Stream Initiation Nack
0xe Simple Control Transmission Protocol

TCB - Stream Termination
0xf Transmission Control Block

TSN - Stream Termination Ack

0x11 to 0xff Transport Sequence Number

ULP - reserved and MUST NOT be used

Reserved: 7 bits

These bits are reserved for future use. The sender shall always
set these bits to '0', and the receiver shall ignore there
values.

C Bit: 1 bit

The CRC flag to indicate whether a CRC-16 value or the MDTP
protocol identifier Upper Layer Protocol

2. SCTP Datagram Format

An SCTP datagram is present in the header, as described
above.

Data Size: 16 bits

This value represents, in number of octets, the size composed of the a common header and chunks. A chunk
contains either control information or user
data present in the Data Part of the current datagram. If the
Data Part data.

The SCTP datagram format is not present in the current datagram, it MUST be set
to 0x0. This implies that no Data Part with zero size user data
shall be allowed.

2.2 MDTP Control Parameter Part Definitions

This section defines whether a control parameter part is present for
each message type, and its format if a control parameter part is
present.

Note: integers in the control parameter part MUST be transmitted in
network byte-order.

2.2.1 Initiation (0x1) and Initiation Ack (0x2):

The parameter field of the Initiation and Initiation Ack messages
shall carry two initiation Tags, the maximal window length of the
sender, the sender's T2-Receive timer value in microseconds, the
number of pre-open outbound streams (P), the number of maximal
inbound streams (M), and the sender's local network
information. The network information informs the receiver the
addresses that may be the source of datagrams for this association
and are valid addresses that the receiver can use as a destination
address. Note that the endpoint MAY be multi-homed.

Stewart, et al [Page 7]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

The following defines the parameter format for carrying N IPv4
Network addresses (other network address formats can be carried by
setting the size and type fields accordingly): shown below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Value 1 (Seen) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Value 2 (Send) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Window Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My T2-Recv Timer value in microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Pre-open Streams (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Max Streams (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Networks = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of address=8 | Type of Address=2 Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network 1 Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port # 1 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Size of address=8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type of Address=2 Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address of Network N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port # N | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If there is any implementation-specific data needed to

Multiple chunks can be
exchanged at multiplexed into one UDP SCTP datagram up to the setup of MTU
size except for the association, INIT, INIT ACK, and SHUTDOWN ACK chunks. These
chunks MUST not be multiplexed with any other chunk in a datagram.

If an user data message doesn't fit into one SCTP datagram it should can be appended
segmented into multiple chunks using the procedure defined in Section 5.10.

When determining when to segment, the end of SCTP implementation MUST take
into account the above data structure. SCTP datagram header as well as the DATA chunk
header. The format implementation MAY also take account of the
implementation-specific data should follow "Size/Type/Data Field"
format as defined above. In case an endpoint does not support the
implementation-specific data received, it shall ignore space required
for a SACK chunk.

When multiplexing Control chunks with DATA chunks, Control chunks MUST
be placed first in the
additional fields.

2.2.2 Extended Data Ack (0x3): datagram on transmit.

The parameter field contains 0 or more segment reports and receiver MUST process the
highest consecutive TSN received.

Stewart, et al [Page 8]

Internet Draft Multi-network Datagram Transmission Protocol June 1999 chunks in the order they appear within
the message.

2.1 SCTP Common Header Field Descriptions

SCTP Common Header Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Segments = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment #1 Start TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment #1 End TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment #N Start TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers | Segment #N End TSN Reserved |C| CRC-16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest Consecutive TSN Seen Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For example, assume

Version: 4 bits, u_int

This field represents the receiver has version number of the following datagrams newly
arrived at SCTP protocol,
and MUST be set to '0011'.

Verification Tag: 32 bit u_int

The receiver of this datagram uses the time when it decides Verification Tag to send an Extended Data Ack,

----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
---------- identify
the control parameter part of association. On transmit, the Extended Data Ack shall value of this Verification Tag MUST
be
constructed as follows:

--------------------------------
| number set to the value of seg = 2 |
--------------------------------
| seg #1 start = 17 |
--------------------------------
| seg #1 end = 17 |
--------------------------------
| seg #2 start = 14 |
--------------------------------
| seg #2 end = 15 |
--------------------------------
| highest consecutive TSN = 12 |
--------------------------------

Note: when multiple segments are reported in the Initiate Tag received from the peer
endpoint during the association initialization.

For datagrams carrying the INIT chunk, the transmitter MUST set the
Verification Tag to all 0's. If the receiver receives a single Extended
Data Ack, datagram
with an all-zeros Verification Tag field, it checks the order of Chunk ID
immediately following the segments in common header. If the Extended Data Ack Chunk Type is not specified.

2.2.3 Advisory Ack Request (0x4):

No parameter field.

2.2.4 Window-up (0x5):

No parameter field.

2.2.5 Window-up Ack (0x6):

Same as that of Extended Data Ack.

2.2.6 RTT-request (0x7)
INIT or SHUTDOWN ACK, the receiver MUST drop the datagram.

For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter
SHOULD set the Verification Tag to the Initiate Tag received from
the peer endpoint during the association initialization, if known
otherwise the Verification Tag MUST be set to all 0's.

Reserved:

Reserved bits MUST be set to 0 on transmit and RTT-ack (0x8):

The parameter should be ignored
on receipt.

C: 1 bit (Octet 2, Bit 8)

When the C-bit is set to 1, the CRC-16 field shall contain contains the time value that CRC-16
(defined below).

When the C-bit is set to 0, the CRC-16 field is not used for
RTT calculation (see section 6.2), and optionally an
acknowledgment Seen value.

0 1 2 3
0 1 2 MUST be
set to 0.

CRC-16: (Octets 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 or TSN Seen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.7 Abort (0x9): & 4)

When the C Bit is set to 1, this field MUST contain a CRC-16.
The Abort message shall carry CRC-16 used is defined in Section 4.2 of ITU Recommendation
Q.703.

Section 5.9 defines the initiation Tag use of CRC-16 in SCTP.

Note: When the
destination endpoint C bit is set to 0, an implementation MAY use the fixed
value 0x30000000 as a measure of security.

Stewart, et al [Page 9]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

2.2.8 Graceful Shutdown (0xa): sanity check on an inbound datagram. If the
first long integer is not the fixed value the datagram MAY be
discarded with no further processing.

2.2 Chunk Field Descriptions

The destination endpoint initiation Tag shall figure below illustrates the field format for the chunks to be carried as
transmitted in the SCTP datagram. Each chunk is formatted with a
measure of security. Chunk
ID field, a Chunk-specific flag field, a Length field and a value
field.

2.2.9 Graceful Shutdown Ack (0xb):

No parameter field.

2.2.10 Stream Initiation (0xc):

The parameter
\ \
/ Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk ID: 8 bits, u_int

This field shall contain identifies the initiation Tag type of information contained in the
destination endpoint (see section 3.1) and the Stream Identifier.
Also, there shall be chunk
value field. It takes a "Size of Stream Info" and "Stream
Information" fields that may contain value from 0x00 to 0xFD. The value of 0xFE
is reserved for vendor-specific extensions. The value of 0xFF is
reserved for future use as an opaque user data structure
specific extension field. Procedures for
extending this field are defined in Section 2.3.13??

The values of Chunk ID are defined as follows:

ID Value Chunk Type
----- ----------
00000000 - Payload Data (DATA)
00000001 - Initiation (INIT)
00000010 - Initiation Acknowledgment (INIT ACK)
00000011 - Selective Acknowledgment (SACK)
00000100 - Heartbeat Request (HEARTBEAT)
00000101 - Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110 - Abort (ABORT)
00000111 - Shutdown (SHUTDOWN)
00001000 - Shutdown Acknowledgment (SHUTDOWN ACK)
00001001 - Operation Error (ERROR)
00001010 - COOKIE
00001011 - COOKIE ACK
00001100 to 11111101 - reserved for future IETF usage
11111110 - Vendor-specific chunk extensions
11111111 - IETF-defined Chunk Extension

Chunk Flags: 8 bits

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

Chunk Length: 16 bits (u_int)

This value represents the stream being opened. size of the chunk in octets including the
Chunk ID, Flags, Length and Value fields. Therefore, if the Value
field is zero-length, the Length field will be set to 0x0004. The "Stream Information"
Length field should does not include any padding.

Chunk Value: Variable

The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field
is dependent on the Chunk ID. The Chunk Value field MUST be
aligned on 32-bit boundaries. If the length of the
chunk does not align on 32-bit boundaries, it is padded at the end
with '0's to 32 bit word boundary before
transmission. all zero octets.

2.2.1 INIT/INIT ACK Parameter Format

The optional and variable-length parameters contained in the INIT and
INIT ACK are defined in a Type-Length-Value format as shown below. The
actual parameters are defined in the specific chunk section.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Init-Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved (set to 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type | Size of Stream Info = N Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ Stream Information (N octets) \
/ Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.11 Stream Initiation Ack (0xd):

Type: 16 bit u_int

The parameter Type field shall contain is a 16 bit identifier of the Stream Identifier.

Stewart, et al [Page 10]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

0 1 2 3
0 1 2 type of parameter. It
takes a value of 0x0000 to 0xFFFD. The value of 0xFFFE is reserved
for vendor-specific extensions. The value of 0xFFFF is reserved for
IETF-defined extensions. The usage of the specific parameter types
is defined in Section 2.3.13??.

The parameters defined in this document are:

Parameter ID Parameter Name
------------ -----------
0x0000 - 0x0004 Reserved for use by IETF
0x0005 IPv4 Address/Port
0x0006 IPv6 Address/Port
0x0007 Cookie
0x0008 Unrecognized Parameters
0x0009 Cookie Preservative
0x000A - 0xFFFD Reserved for use by IETF
0xFFFE Vendor-specific Extensions
0xFFFF IETF extensions

Length: 16 bit u_int

The Length field contains the length of the of the Type, Length and
Value fields for this parameter. Thus, a parameter with a zero-
length Value field would have a Length field of 0x0004. The Length
does not include any padding octets.

Value: variable-length.

The Value is dependent on the value of the Type field. The value
field MUST be aligned on 32-bit boundaries. If the value field is
not aligned on 32-bit boundaries it is padded at the end with all
zero octets. The value field must be an integer number of octets.

The sequence of parameters within an INIT or INIT ACK may be
processed in any order. For example, a receiver of a INIT ACK may
need to scan through the chunk looking for all the address types, to
locate the address to which the INIT was sent, so that the receiver
may find the correct Transmission Control Block (TCB).

2.2.1.1 Vendor-Specific Extensions (0xFFFE)

Since Vendor-Specific Extensions are a special case, they are described
here.

This parameter value is available to allow vendors to support their
own extended parameters not defined by the IETF. It MUST not affect
the operation of SCTP.

Endpoints not equipped to interpret the vendor-specific information
sent by a remote endpoint MUST ignore it (although it may be reported).
Endpoints that do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.

A summary of the Vendor-Specific Extension format is shown below.
The fields are transmitted from left to right.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier Type | Reserved (set to 0) Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.12 Stream Initiation Nack (0x10):

Same
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 16 bit u_int

0xFFFE for Vendor-Specific.

Length: 16 bit u_int

>= 8

Vendor-Id: 32 bit u_int

The high-order octet is 0 and the low-order 3 octets are the
SMI Network Management Private Enterprise Code of the Vendor
in network byte order, as that defined in the Assigned Numbers (RFC
1700).

Value: Variable length

The Value field is one or more octets. The actual format of Stream Initiation Ack.

2.2.13 Stream Termination (0xe): the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished
octets.

The parameter codification of the range of allowed usage of this field shall contain is
outside the initiation Tag scope of this specification.

It SHOULD be encoded as a sequence of vendor type / vendor length
/ value (see
section 3.1) and fields, as follows. The parameter field is
dependent on the Stream Identification vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
method follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Init-Tag Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier Vendor-Id | Reserved (set to 0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VS-Type | VS-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.14 Stream Termination Ack (0xf):

Same as that
/ VS-Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VS-Type: 16 bit u_int

This field identifies the parameter included in the VS-Value field.
It is assigned by the vendor.

VS-Length: 16 bit u_int

This field is the length of Stream Initiation Ack. the vendor-specific parameter and
Includes the VS-Type, VS-Length and VS-Value (if included) fields.

VS-Value: Variable Length

This field contains the parameter identified by the VS-Type field.
It's meaning is identified by the vendor.

2.3 MDTP Data Part SCTP Chunk Definitions

The following

This section defines the format shall of the different chunk types.

Note: integers in the chunk MUST be transmitted in network octet-order.

2.3.1 Initiation (INIT) (00000001)

This chunk is used for MDTP datagram Data Part: to initiate a SCTP association between
two endpoints. The format of the INIT message is shown below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN Seen Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN Send Receive Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S Number of Outbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number n of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: TSN Seen, TSN Send, Stream Identifier, and Sequence Number

The INIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only be transmitted included once in network byte-order. the INIT chunk.

Parameter Optional/Mandatory
--------- ------------------
Initiate Tag Mandatory
Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Seen: Mandatory
IPv4 Address/Port (Note 1) Optional
IPv6 Address/Port (Note 1) Optional
Cookie Preservative Optional

Note 1: The INIT/INIT ACK chunks may contain multiple addresses that
may be IPv4 and/or IPv6 in any combination.

Vendor-specific parameters MUST be appended to the end of the above
INIT chunk. The format of the vendor-specific parameters MUST follow
the Type-Length-value format of other parameters as defined above.
In case an endpoint does not support the vendor-specific data received,
it MUST ignore the additional fields.

Initiate Tag: 32 bits bit u_int

The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP datagram that the responding end
transmits within this association.

The value of this tag must be selected from the range of 0x1 to
0xffffffff, and should be randomized as defined in RFC 1750 [11].
The value of 0x00000000 is reserved for the Verification Tag field of
datagrams carrying INIT chunks (or the exceptional case where a
SHUTDOWN ACK must be retransmitted after the TCP as been deleted).

Receive Window Credit (rwnd): 32 bit u_int

If non-zero, this field defines the maximum number of TSNs the
receiving end is allowed to have outstanding (i.e. sent
and not acknowledged). If set to zero, the default is applied.
The suggested default is 20.

Number of Outbound Streams (OS): 32 bit u_int

Defines the number of outbound streams the sender of this INIT chunk
wishes to create in this association. The value of 0 MUST NOT be
used.

Number of Inbound Streams (MIS) : 32 bit u_int

Defines the maximum number of streams the sender of this INIT
chunk allows the peer end to create in this association. The value 0
MUST NOT be used.

Initial TSN (I-TSN) : 32 bit u_int

Defines the initial TSN that the sender will use. This field MAY be
set to the value of the Initiate Tag field.

2.3.1.1 Optional or Variable Length Parameters

The following parameters follow the Type-Length-Value format. The IP
Address Fields MUST come after the fixed-length fields.

Any extensions MUST come after the IP address fields.

IPv4 Address/Port

This parameter contains an IPv4 address/port for use as a destination
transport address by the receiver.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Address: 32bit u_int

Contains an IPv4 address of this endpoint. It is binary encoded.

Port Number: 16 bit u_int

Contains the UDP port number which the sender of this INIT wants
to use for this address.

Padding: 16 bits

This field is set to 0x00 on transmit and ignored on receive.

IPv6 Address/Port:

This parameter contains an IPv6 address/port for use as a destination
transport address by the receiver.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Address: 128 bit u_int

Contains an IPv6 address of the sender of this message. It is binary encoded.

Port Number: 16 bit u_int

Contains the UDP port number which the sender of this INIT wants
to use for this address.

Padding: 16 bits

This field is set to 0x00 on transmit and ignored on receive.

The values passed in the IPv4 and IPv6 Address/Port parameters
indicate to the other end of the association which transport addresses
this end will support for the association being initiated.
Within the association, any one of these addresses may appear in the
source address field of a datagram sent from this (the initiating) end,
and may be used as a destination of a datagram sent from the
other (the responding) end.

Note that an endpoint MAY be multi-homed. A multi-homed endpoint may
have access to different types of network, thus more than one
address type may be present in one INIT chunk, i.e., IPv4 and IPv6
addresses are allowed in the same INIT messge.

More than one IP Address parameter can be included in an INIT chunk.

If the INIT contains a least one IP Address parameter, then only the
transport addresses provided within the INIT may be used as
destinations by the responding end. If the INIT does not contain any
IP Address parameters, the responding end MUST use the source
address associated with the received SCTP datagram as its sole
destination address for the session.

Cookie Preservative

This parameter contains a request by the sender for a longer
lifespan on a cookie.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Life Time (ALT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Additional Life Time (ALT): 32bit u_int

This parameter indicates to the receiver the need for a cookie that
expires in a longer period of time. It is normally added to the INIT
when the responder has reported receiving of a Stale COOKIE chunk.
The ALT field is filled in with the number of microseconds that the sender
would like the cookie to be valid for. It is optional for the receiver
to extend the lifespan of a cookie based upon its local security
requirements.

2.3.2 Initiation Acknowledgement (INIT ACK) (00000010):

The INIT ACK chunk is used to acknowledge the initiation of a SCTP
association.

The parameter part of INIT ACK is formatted the same as the INIT
chunk. It uses two extra parameters: The Responder Cookie and the
Unrecognized Parameter:

The format of the INIT ACK message is shown below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The INIT ACK contains the following parameters:
Parameter Optional/Mandatory
--------- ------------------
Initiate Tag Mandatory
Receiver Window Credit Mandatory
Receiver Maximum Datagram Size Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN (Note 2) Mandatory
Responder Cookie Mandatory
IPv4 Address (Note 1) Optional
IPv6 Address (Note 1) Optional
Unrecognized Parameters Optional

Note 1: The INIT/INIT ACK chunks may contain multiple addresses that
may be IPv4 and/or IPv6 in any combination.

The Responder Cookie and Unrecognized Parameters use the Type-Length-
Value format and are defined below. The other fields are defined the
same as in the INIT message.

Responder Cookie: variable size, depending on Size of Cookie

This field MUST contain all the necessary state and parameter
information required for the sender of this INIT ACK to create the
association, along with an MD5 digital signature (128-bit). See
Section 4.1.3 for details on Cookie definition. The Cookie MUST be
padded with '0' to the next 32-bit word boundary; otherwise, the
format of the Cookie is implementation-specific.

Unrecognized Parameters: Variable Size.

This parameter is returned to the originator of the INIT message if
the receiver does not recognize one or more parameters in the INIT
chunk. This parameter field will contain the unrecognized
parameters copied from the INIT message complete with TLV.

2.3.3 Selective Acknowledgement (SACK) (00000011):

This chunk is sent to the remote endpoint to acknowledge received DATA
chunks and to inform the remote endpoint of gaps in the received
subsequences of DATA chunks as represented by their TSNs.

The SACK MUST contain the Highest Consecutive TSN ACK and Rcv
Window Credit (rwnd) parameters. By definition, the value of the
Highest Consecutive TSN ACK parameter is the last TSN received at the
time the Selective ACK is sent, before a break in the sequence of
received TSNs occurs; the next TSN value following this one has not
yet been received at the reporting end. This parameter therefore
acknowledges receipt of all TSNs up to and including the value given.

The Selective ACK also contains zero or more fragment reports. Each
fragment report acknowledges a subsequence of TSNs received following
a break in the sequence of received TSNs. By definition, all TSNs
acknowledged by fragment reports are higher than the value of the
Highest Consecutive TSN ACK.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest Consecutive TSN ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv Window Credit (rwnd) | Number of Fragments = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment #1 Start | Fragment #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment #N Start | Fragment #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to all zeros on transmit and ignored on receipt.

Highest Consecutive TSN ACK: 32 bit u_int

This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. Therefore, it must be lower than the
Start TSN of the first fragment, if present.

Receive Window Credit (rwnd): 16 bit u_int

Number of Fragments: 16 bit u_int

Indicates the number of TSN fragments included in this Selective ACK.

Fragments:

These fields contain the ack fragments. They are repeated for each
fragment up to the number of fragments defined in the Number of
Fragments field. All DATA chunks with TSNs between the (Highest
Consecutive TSN + Fragment Start) and (Highest Consecutive TSN +
Fragment End) of each fragment are assumed to have been received
correctly.

Fragment Start: 16 bit u_int

Indicates the Start offset TSN for this fragment. To calculate the
actual TSN number the Highest Consecutive TSN is added to this
offset number to yield the TSN. This calculated TSN identifies
the first TSN in this fragment that has been received.

Fragment End: 16 bit u_int

Indicates the End offset TSN for this fragment. To calculate the
actual TSN number the Highest Consecutive TSN is added to this
offset number to yield the TSN. This calculated TSN identifies
the TSN of the last DATA chunk received in this fragment.

For example, assume the receiver has the following datagrams newly
arrived at the time when it decides to send a Selective ACK,

then, the parameter part of the Selective ACK MUST be constructed as
follows:

+---------------+--------------+
| Highest Consecutive TSN = 12 |
----------------+---------------
| rwnd = 0 |num of frag=2 |
----------------+---------------
|frag #1 strt=2 |frag #1 end=3 |
----------------+---------------
|frag #2 strt=5 |frag #2 end=5 |
--------------------------------

2.3.4 Heartbeat Request (HEARTBEAT) (00000100):

An endpoint should send this chunk to its peer endpoint of the
current association to probe the reachability of a particular
destination transport address defined in the present association.

The parameter fields MUST contain the time values.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 1 (sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 2 (usec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Time Value 1: 32 bit u_int
Time Value 2: 32 bit u_int

The Time Values contain a time value meaningful only to the
sender. Time Value 1 is in units of seconds and Time Value 2 is in
units of microseconds. Their value should be set to the current
time at which this Heartbeat Request is sent.

IMPLEMENTATION NOTE: For most systems the value is normally
set by doing a system call to get the current time.

2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK) (00000101):

An endpoint should send this chunk to its peer endpoint as a
response to a Heartbeat Request (see Section 7.3).

The parameter field MUST contain the time values.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 1 (sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 2 (usec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Time Value 1: 32 bit u_int
Time Value 2: 32 bit u_int

The values of these two field SHALL be copied from the time values
contained in the Heartbeat Request to which this Heartbeat
acknowledgement is responding.

2.3.6 Abort Association (ABORT) (00000110):

The ABORT chunk is sent to the peer of an association to terminate the
association. The Abort chunk has no parameters.

If an endpoint receives an INIT or INIT ACK missing a mandatory
parameter, it MUST send an ABORT message to its peer. It SHOULD
include a Operational Error chunk with the Abort chunk to specify
the reason.

If an endpoint receives an ABORT with a format error or for an
association that doesn't exist, it drops the chunk and ignores it.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:
Set to zero on transmit and ignored on receipt.

2.3.7 SHUTDOWN (00000111):

An endpoint in an association MUST use this chunk to initiate a
graceful termination of the association with its peer. This chunk has
the following format.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest Consecutive TSN ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Highest Consecutive TSN ACK: 32 bit u_int

This parameter contains the TSN of the last chunk received in
sequence before any gaps.

2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK) (00001000):

This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
chunk at the completion of the shutdown process, see Section 8.2 for
details.

The SHUTDOWN ACK chunk has no parameters.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Note: if the endpoint that receives the SHUTDOWN message does not have
a TCB or tag for the sender of the SHUTDOWN, the receiver SHALL still
respond. In such cases, the receiver SHALL send back a stand-alone
SHUTDOWN ACK chunk in an SCTP datagram with the Verification Tag field
of the common header filled with all '0's.

2.3.9 Operation Error (ERROR) (00001001):

This chunk is sent to the other endpoint in the association to
notify certain error conditions. It has the following parameters:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause-Specific Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Length:

Set to the length of the chunk.

Cause Code: 16 bit u_int

Defines the type of error conditions which triggered this ERROR
chunk.

Cause-specific Information: depends on Length field

Currently SCTP defines the following error causes:

Cause of error
---------------
Invalid Stream Identifier

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cause of error
---------------
Missing Mandatory Parameter

Each missing mandatory parameter ID should be specified in the
message.

Cause of error
--------------
Stale Cookie Error.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of staleness in microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The sender of the stale cookie error may choose to place how long
past expiration the cookie is. It does this by placing in the
'Measure of staleness' variable the difference, in microseconds,
between the current time and the time the cookie expired. If a
implementation does not wish to provide this information it should
set 'Measure of staleness' to 0.

2.3.10 Encryption Cookie (COOKIE) (00001010):

This chunk is used only during the initialization of an association.
It is sent by the initiator of an association to its peer to complete
the initialization process. This chunk MUST precede any DATA chunk
sent within the association, but MAY be bundled with one or more DATA
chunks in the same datagram.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0|Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

Set to zero on transmit and ignored on receipt.

Cookie: variable size, (matching the size in the Cookie parameter
received in the INIT ACK from the responder)

This field must contain the exact cookie received in a previous INIT
ACK.

2.3.11 Cookie Acknowledgment (COOKIE ACK) (00001011):

This chunk is used only during the initialization of an association.
It is used to acknowledge the receipt of a COOKIE chunk. This chunk
MUST precede any DATA chunk sent within the association, but MAY be
bundled with one or more DATA chunks in the same datagram.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:
Set to zero on transmit and ignored on receipt.

2.3.12 Payload Data (DATA) (00000000):

The following format MUST be used for the DATA chunk:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: the TSN, stream identifier, and sequence number MUST be
transmitted in network byte order.

Reserved bits should be set to '0'.

B bit: 1 bit
The (B)eginning segment bit is a one bit field set to 1 on the
first segment derived from a SCTP user message and set to 0 for all
other segments from the same SCTP user message.

E bit: 1 bit
The (E)nding segment bit is a one bit field set to 1 on the last
segment and set to 0 for all other segments.

An unsegmented message has both the B and E bits set to 1.
Both B and E bits set to 0 indicates a continued segment of a SCTP
user message.

B/E Bits and their Definitions

B E Description
============================================================
| 1 0 | First piece of a segmented SCTP user message. |
+----------------------------------------------------------+
| 0 0 | Continued piece of a segmented message |
+----------------------------------------------------------+
| 0 1 | Last piece of a segmented SCTP user message. |
+----------------------------------------------------------+
| 1 1 | Unsegmented Message |
============================================================

Length: 16 bits (16 bit u_int)

This field indicates the length of the DATA chunk in octets. It
includes the Type field, the Reserved field, the B/E bits, the Length
field, the Stream Identifier, the Stream Sequence Number and the User
Data fields. It does not include any padding.

TSN : 32 bits (32 bit u_int)

This value represents the TSN for this DATA chunk.

Stream Identifier S: 16 bit u_int

Identifies the stream to which the following user data belongs.

Sequence Number n: 16 bit u_int

This value presents the sequence number of the following user
data within the stream S.

Sequence number 0x0 indicates that the following user data MUST
be treated as unordered, and MUST be dispatched to the upper
layer by the receiver without any attempt of re-ordering.

For ordered datagram, the sequence number MUST wrap around to 0x1
after 0xffff.

User Data: variable length

This is the payload user data. The implementation MUST
pad the end of the data to a 32 bit boundary with 0 octets. Any
padding should NOT be included in the length field.

2.3.13 Vendor-Specific Chunk (0xFE)

Since Vendor-Specific Chunks are a special case, they are described
here.

This Chunk type is available to allow vendors to support their own
extended data formats not defined by the IETF. It MUST not
affect the operation of SCTP.

Endpoints not equipped to interpret the vendor-specific chunk sent by
a remote endpoint MUST ignore it. Endpoints that do not receive
desired vendor specific information SHOULD make an attempt to operate
without it, although they may do so (and report they are doing so) in
a degraded mode.

A summary of the Vendor-Specific Chunk format is shown below.
The fields are transmitted from left to right.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 8 bit u_int

0xFE for Vendor-Specific.

Flags: 8 bit u_int

Vendor specific flags.

Length: 16 bit u_int

>= 8

Vendor-Id: 32 bit u_int

The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the Assigned Numbers (RFC 1700).

Value: Variable length

The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished
octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

2.4 Bundling

Multiple chunks can be bundled into one SCTP datagram. Partial chunks
MUST NOT be placed in a datagram.

The transmitter MUST transmit DATA chunks within a datagram in
increasing order of TSN. Control messages MUST be placed at the
beginning of a datagram.

The receiver MUST process the chunks in order in the datagram. The
receiver uses the chunk length field to determine the end of a chunk
and beginning of the next chunk taking account of the fact that all
chunks end on a thirty-two-bit word boundary. If the receiver detects
a partial chunk, it should drop the chunk.

3. SCTP Association State Diagram

During the lifetime of an SCTP association, the SCTP endpoints
progress from one state to another in response to various events. The
events that may potentially advance an endpoint's state include:

o SCTP user primitive calls, e.g., [open], [shutdown], [abort],

o reception of INIT, COOKIE, ABORT, SHUTDOWN, etc. control
chunks, or

o some timeout events.

The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that some
of the error conditions are not shown in the state diagram. Full
description of all special cases should be found in the text.

Note, chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE chunk type vs.
Cookie parameter.

----- -------- (frm any state)
/ \ / rcv ABORT [abort]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT.ACK ---| CLOSED |
+---------+
/ \ [open]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid COOKIE | v
(1) ---------------- | +------------+
create TCB | | COOKIE_WAIT| (2)
snd COOKIE.ACK | +------------+
| |
| | rcv INIT.ACK
| | -----------------
| | snd COOKIE
| | stop init timer
| | strt cookie timer
| v
| +------------+
| | COOKIE_SENT| (3)
| +------------+
| |
| | rcv COOKIE.ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+

(from any state except CLOSED)
|
|
/--------+--------\
[shutdown] / \
----------------- | |
check outstanding | |
data chunks | |
v |
+---------+ |
(4) |SHUTDOWN | | rcv SHUTDOWN
|PENDING | | ----------------
+---------+ | x
| |
No more outstanding | |
------------------- | |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(5) |SHUTDOWN | | SHUTDOWN | (5)
|SENT | | RECEIVED |
+---------+ +-----------+
| |
rcv SHUTDOWN.ACK | | x
------------------- | |-----------------
stop shutdown timer | | retransmit missing DATA
delete TCB | | send SHUTDOWN.ACK
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+

Note:

(1) If the received COOKIE is invalid (i.e., failed to pass the
authentication check), the receiver MUST silently discard the
datagram. Or, if the received COOKIE is expired (see Section
4.1.5), the receiver SHALL send an ERROR chunk back. In
either case, the receiver SHALL stay in the closed state.

(2) If the init timer expires, the endpoint SHALL retransmit INIT
and re-start the init timer without changing state. This SHALL be
repeated up to 'Max.Init.Retransmit' times. After that, the
endpoint SHALL abort the initialization process and report the
error to SCTP user.

(3) If the cookie timer expires, the endpoint SHALL retransmit
COOKIE and re-start the cookie timer without changing
state. This SHALL be repeated up to 'Max.Init.Retransmit'
times. After that, the endpoint SHALL abort the initialization
process and report the error to SCTP user.

(4) In SHUTDOWN-SENT state the endpoint SHALL acknowledge any received
DATA chunks without delay

(5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new
send request from its SCTP user.

4. Association Initialization

Before the first data transmission can take place from one SCTP
endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must
complete an initialization process in order to set up an SCTP
association between them.

The SCTP user at an endpoint SHOULD use the ASSOCIATE primitive to
initialize an SCTP association to another SCTP endpoint.

IMPLEMENTATION NOTE: an association may be implicitly opened,
without an associate primitive being invoked, by the initiating
endpoint's sending of the first user data to the destination
endpoint. The initiating SCTP will assume default values for all
mandatory and optional parameters for the INIT/INIT ACK.

Once the association is established, unidirectional streams will be
open for data transfer on both ends (see Section 4.1.1).

A cookie mechanism is employed during the initialization to provide
protection against security attacks. The cookie mechanism uses a
four-way handshaking, but the last two legs of which are allowed to
carry user data for fast setup.

4.1 Normal Establishment of an Association

The initialization process consists of the following steps (assuming
that SCTP endpoint "A" tries to set up an association with SCTP
endpoint "Z" and "Z" accepts the new association):

A) "A" shall first send an INIT message to "Z". In the INIT, "A" must
provide its security tag "Tag_A" in the Initiate Tag field. Tag_A
shall be a random number in the range of 0x1 to 0xffffffff (see
4.3.1 for Tag value selection). After sending the INIT, "A" enters
the COOKIE-WAIT state.

B) "Z" shall respond immediately with an INIT ACK message. In the
message, besides filling in other parameters, "Z" must set the
Verification Tag field to Tag_A, and also provide its own security
tag "Tag_Z" in the Initiate Tag field.

Moreover, "Z" shall generate and send along with the INIT ACK a
responder cookie. See Section 4.1.3 for responder cookie
generation.

Note: after sending out INIT ACK with the cookie, "Z" should not
allocate any resources, nor keep any states for the new
association. Otherwise, "Z" will be vulnerable to resource attacks.

C) Upon reception of the INIT ACK from "Z", "A" shall leave COOKIE-WAIT
state and enter the COOKIE-SENT state. "A" now sends the cookie
received in the INIT ACK message in a cookie chunk. The cookie
chunk can be bundled with any pending DATA chunks, but it MUST
be the first chunk in the datagram.

D) Upon reception of the COOKIE chunk, Endpoint "Z" will reply with
a COOKIE-ACK chunk after building a TCB and marking itself to
the established state. A COOKIE-ACK chunk may also be combined with
any pending DATA chunks (and/or SACK chunks), but the COOKIE-ACK chunk
must be the first chunk in the datagram.

IMPLEMENTATION NOTE: a implementation may choose to send the
communication up primitive to the SCTP user upon reception
of a valid cookie.

E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
COOKIE-SENT state to the ESTABLISHED state, stopping its INIT
timer.

IMPLEMENTATION NOTE: a implementation may choose to send the
communication up primitive to the SCTP user upon reception
of a the COOKIE ACK.

Note: no DATA chunk shall be carried in the INIT or INIT ACK message.

Note: if an endpoint receives an INIT, INIT ACK, or COOKIE chunk but
decides not to establish the new association due to lack of resources,
etc., it shall respond to the chunk with an ABORT chunk. The
Verification Tag field of the common header must be set to equal the
Initiate Tag value of the peer.

Note: After the reception of the first data chunk in an association
the receiver MUST immediately respond with a SACK to acknowledge
the data chunk, subsequent acknowledgements should be done as
described in section 5.2.

Note: When a SCTP endpoint sends a INIT or INIT ACK it MUST include
all of its transport addresses in the parameter section. This is
because it may NOT be possible to control the "sending" address that
a receiver of a SCTP datagram sees. A receiver thus MUST know every
address that may be a source address for a peer SCTP endpoint, this
assures that the inbound SCTP datagram can be matched to the proper
association.

4.1.1 Handle Stream Parameters

In the INIT and INIT ACK messages, the sender of the message shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximal inbound streams (MIS) it will
accept from the other endpoint.

After receiving these stream configuration information from the other
side, each endpoint shall perform the following check: if the
peer's MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants to
configure, the endpoint MUST either settle with MIS outbound streams,
or abort the association and report to its upper layer the resources
shortage at its peer.

After the association is initialized, the valid outbound stream
identifier range for either endpoint shall be 0 to
min(local OS, remote MIS)-1.

4.1.2 Handle Address Parameters

During the association initialization, an endpoint shall use the
following rules to discover and collect the destination transport
address(es) to its peer.

On reception of an INIT or INIT ACK message, the receiver shall record
any transport addresses specified as parameters in the INIT or INIT
ACK message, and use only these addresses as destination transport
addresses when sending subsequent datagrams to its peer. If NO
destination transport addresses are specified in the INIT or INIT ACK
message, then the source address from which the message arrived should
be used as the destination transport address for all datagrams.

4.1.3 Generating Responder Cookie

When sending an INIT ACK as a response to an INIT message, the sender
of INIT ACK should create a responder cookie and send it as part of
the INIT ACK. Inside this responder cookie, the sender should include
a security signature, a time stamp on when the cookie is created, and
the lifespan of the cookie, along with all the information necessary
for it to establish the association.

The following steps SHOULD be taken to generate the cookie:

1) create an association TCB using information from both the received
INIT and the outgoing INIT ACK messages,

2) in the TCB, set the creation time to the current time of day, and
the lifespan to the protocol parameter 'Valid.cookie.life',

3) attach a private security key to the TCB and generate a 128-bit MD5
signature from the key/TCB combination (see [15] for details on
MD5), and

4) generate the responder cookie by combining the TCB and the
resultant MD5 signature.

After sending the INIT ACK with the cookie, the sender SHOULD delete
the TCB and any other local resource related to the new association,
so as to prevent resource attacks.

The private key should be a cryptographic quality random number with
a sufficient length. Discussion in RFC-1750 can be helpful in
selection of the key.

4.1.4 Cookie Processing

When a cookie is received from its peer in an INIT ACK message, the
receiver of the INIT ACK MUST immediately send a COOKIE chunk to its
peer and MAY piggy-back any pending DATA chunks on the outbound
cookie chunk. The sender should also start a timer, and retransmit
the cookie chunk until a COOKIE ACK is received or the endpoint
is marked unreachable (see section 5.12 for retransmission details).

4.1.5 Cookie Authentication

When an endpoint receives a COOKIE chunk from another endpoint with
which it has no association, it shall take the following actions:

1) compute an MD5 signature using the TCB data carried in the cookie
along with the receiver's private security key,

2) authenticate the cookie by comparing the computed MD5 signature
against the one carried in the cookie. If this comparison fails,
the datagram, including the COOKIE and the attached user data,
should be silently discarded,

3) compare the creation time stamp in the cookie to the current local
time, if the elapsed time is longer than the lifespan carried in
the cookie, then the datagram, including the COOKIE and the
attached user data, SHOULD be discarded and the endpoint MUST
transmit a stale cookie operational error to the sending endpoint,

4) if the cookie is valid, create an association to the sender of the
COOKIE message with the information in the TCB data carried in the
COOKIE, and enter the ESTABLISHED state,

5) acknowledge any DATA chunk in the datagram following the rules
defined in Section 5.2, and,

6) send a COOKIE ACK chunk to the sender acknowledging reception of
the cookie. The COOKIE ACK MAY be piggybacked with any DATA chunk or
SACK chunk (if a DATA chunk is present in the received datagram a
SACK MUST be sent in the acknowledgement).

Note that if a COOKIE is received from an endpoint with which the
receiver of the COOKIE has an existing association, the proceedures in
section 4.2 should be followed.

4.1.6 An Example of Normal Association Establishment

In the following example, "A" initiates the association and then sends
a user datagram to "Z", then "Z" sends two user datagrams to "A"
later:

Endpoint A Endpoint Z

{app sets association with Z}
INIT [INIT Tag=Tag_A
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)

/--- INIT ACK [Veri Tag=Tag_A,
/ INIT Tag=Tag_Z,
(Cancel T1-init timer, <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE[ Cookie_Z] -----------\
(Start T1-init timer) \
(Enter COOKIE-SENT state) \---> (build TCB enter established state)

/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter established state)
...
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rxt timer) \
\->

/----- SACK [TSN ACK=init TSN_A,Frag=0]
(Cancel T3-rxt timer) <------/
...
...
{app sends 2 datagrams;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN ACK=init TSN_Z, /---- DATA
Frag=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>

Note that If T1-init timer expires at "A" after the INIT or COOKIE
chunks are sent, the same INIT or cookie chunk with the same Initiate
Tag (i.e., Tag_A) or cookie shall be retransmitted and the timer
restarted. This shall be repeated Max.Init.Retransmit times before "A"
considers "Z" unreachable and reports the failure to its upper layer.

4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK

At any time during the life of an association (in one of the possible
states) between an endpoint and its peer, one of the setup chunks
may be received from the peer, the receiver shall process such
a duplicate has described in this section.

The following scenarios can cause duplicated chunks:

A) The peer has crashed without being detected, and re-started itself
and sent out a new Chunk trying to restore the association,

B) Both sides are trying to initialize the association at about the
same time,

C) The chunk is a staled datagram that was used to establish
the present association or a past association which is no longer in
existence, or

D) The chunk is a false message generated by an attacker.

In case A), the endpoint shall reset the present association and set a
new association with its peer. Case B) is unique and is discussed in
Section 4.2.1. However, in cases C) and D), the endpoint must retain
the present association.

The rules in the following sections shall be applied in order to
identify and correctly handle these cases.

4.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-SENT State

This usually indicates an initialization collision.

In such a case, each of the two side shall respond to the other side
with an INIT ACK, with the Verification Tag field of the common header
set to the tag value received from the INIT message, and the Initiate
Tag field set to its own tag value (the same tag used in the INIT
message sent out by itself). Each responder shall also generate a
cookie with the INIT ACK.

After that, no other actions shall be taken by either side, i.e., the
endpoint shall not change its state, and the T1-init timer shall be
let running. The normal procedures for handling cookies will
resolve the duplicate INITs to a single association.

4.2.2 Handle Duplicate INIT in Other States

Upon reception of the duplicated INIT, the receiver shall follow
the normal procedures for handling a INIT message, i.e. generate
a INIT ACK with a cookie.

In the outbound INIT ACK, the Verification Tag field of the common
header shall be set to the peer tag value (from the INIT message), and
the Initiate Tag field set to its own tag value (unchanged from the
existing association). A cookie should also be included generated
with the current time and a updated TCB based upon the INIT message.
And no further actions shall be taken.

4.2.3 Handle Duplicate INIT ACK

If an INIT ACK is received by an endpoint in any state
other than the COOKIE-WAIT state, the endpoint should discard
the INIT ACK message. A duplicate INIT ACK usually indicates the
processing of a old INIT or duplicated INIT message.

4.2.4 Handle Duplicate Cookie

When a duplicated COOKIE chunk is received in any state for an
existing association the following rules shall be applied:

1) compute an MD5 signature using the TCB data carried in the cookie
along with the receiver's private security key,

3) compare the timestamp in the cookie to the current time, if
the cookie is older than the lifespan carried in the cookie,
the datagram, including the COOKIE and the attached user data,
should be discarded and the endpoint MUST transmit a piggy-backed acknowledgment, indicating the reception
of datagrams up stale cookie
error to this TSN.

TSN Send: 32 bits

This value represents the TSN sending endpoint only if the Verification tags of the user data carried
cookie's TCB does NOT match the current tag values in this
datagram.

Stewart, et al [Page 11]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

Stream Identifier S: 16 bits

Identify the stream association
(this is case C or D above).

4) If the cookie proves to which be valid, unpack the following user date belongs.

Sequence Number n: 16 bits

This value presents TCB into a
temporary TCB.

5) If the sequence number of Verification Tags in the following user
data within Temporary TCB matches the stream.

Sequence number 0x0 indicates that
Verification Tags in the following user data shall existing TCB, the cookie is a
duplicate cookie. A cookie ack should be treated as unordered, and shall sent to the peer
endpoint but NO update should be dispatched made to the upper
layer by existing
TCB.

6) If the receiver without any attempt of re-ordering.

User Data: variable length

This the local Verification Tag in the temporary TCB
does not match the local Verification Tag in the existing
TCB, then the cookie is a old stale cookie and does
not correspond to the payload user data. existing association (case C above).
The size of the user data shall datagram should be specified silently discarded.

7) If the Peers Verification Tag in the Data Size field. The implementation may
optionally have some '0' padded at temporary TCB does not
match the end Peers Verification Tag in the existing TCB
then a restart of User Data field.

3. Endpoint Association Initialization

Before the first data transmission can take place from one peer has occurred (case A above) and the
endpoint
("A") should report the restart and respond with a COOKIE-ACK
message; Updating the Verification Tag, starting sequence
number, and network information of its peer from the temporary
TCB to another endpoint ("Z"), the two endpoints must complete an
initialization process in order existing TCB. After which the temporary TCB may be discarded.

IMPLEMENTATION NOTE: It is a implementation decision on how
to set up an association between them. handle any pending datagrams. The upper layer implementation may explicitly request MDTP elect
to initialize an
association either A) send all messages up to an endpoint, or implicitly open the association by
sending its upper layer with the first datagram
restart report, or B) automatically requeue any datagrams
pending, marking all to that endpoint on stream 0.

Once the association is established, stream 0 is automatically opened unsent state and ready for datagram transmission assigning
new TSN's at the time of initial transmit based upon the
updated starting sequence number (as defined in both directions. Moreover, if
there are section 5.5).

4.2.5 Handle Duplicate COOKIE-ACK.

At any pre-open streams specified by either side, they shall
also be opened and ready for transmission from that side.

Other streams must state other than COOKIE-Sent a endpoint may receive a
duplicated COOKIE-ACK chunk. If so, the chunk should be explicitly opened before data transmission can
occur. silently
discarded.

4.2.6 Handle Stale COOKIE Error

A tag-and-lock mechanism must be employed during the initialization
in order to guard against security attacks as well as erroneous
datagrams.

3.1 Initiation Message and Tag Lock

The initialization process consists stale cookie error indicates one of the following steps (assuming a number of possible events:

A) that MDTP endpoint "A" tries the association failed to set up completely setup before the
cookie issued by the sender was processed.

B) an old cookie was processed after setup completed.

C) an old cookie is received from someone that the receiver is
not interested in having a association with MDTP and the ABORT
message was lost.

When processing a stale cookie a endpoint "Z"):

A) "A" shall should first send examine
if an Initiation message to "Z", with Tag Seen
field set to 0x0 and Tag Send field set to Tag_A, where Tag_A shall association is in the process of being setup, i.e. the
association is in the COOKIE-SENT state. In all cases if
the association is NOT in the COOKIE-SENT state, the stale
cookie message should be a random number silently discarded.

If the association is in the range COOKIE-SENT state, the endpoint
may elect one of 0x80000000 three alternatives.

1) Send a new INIT message to 0xffffffff (see
3.1.4 for Tag value selection), and enter the Tag-lock mode.

B) "Z" shall respond immediately with an Initiation Ack message, with
Seen set endpoint, to Tag_A generate
a new cookie and Send set to Tag_Z (same range as Tag_A), re-attempt the setup procedure.

2) Discard the TCB and
enter report to the Tag-lock-new mode.

Stewart, et al [Page 12]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

At this point, "Z" is ready upper layer the
inability to send user datagrams setup the association.

3) Send a new INIT message to "A" in stream
0. And upon the reception endpoint, adding a
cookie preservative requesting a time extentsion
on the life of the above Initiation Ack cookie. When calculating the
time extension, a implementation SHOULD use
Round Trip Time (RTT) information generated from "Z", "A"
also becomes ready to send user datagrams to "Z" in stream 0.

Note: user data in other streams can not be sent until
the
respective streams are opened.

C) "Z" shall leave Tag-lock-new mode original COOKIE <-> Stale COOKIE timing and enter Tag-lock mode only if
should add no more than 1,000,000 microseconds
beyond the RTT. Long cookie lives will make a
user datagram has been sent out endpoint
more subject to a replay attack.

4.3 Other Initialization Issues

4.3.1 Selection of Tag Value

Initiate Tag values should be selected from "Z" the range of 0x1 to "A".

Note:
0xffffffff. It is very important that the Tag value be randomized to guard
help protect against "man in the middle" attacks, an and "sequence number" attacks.
It is suggested that RFC 1750 [9] be used for the Tag randomization.

Moreover, the tag value used by either endpoint in a given association
MUST never be changed during the lifetime of the association. However,
a new tag value MUST be used each time the endpoint
should impose a limit on tears-down and
then re-establishes the number of associations allowed association to be
in the Tag-lock-new mode; whenever this limit same peer.

4.3.2 Initiation from behind a NAT

When a NAT is reached, any
further association Initiations received by present between two endpoints, the endpoint shall be
silently discarded. Also, that is
behind the NAT, i.e., one that does not have a timer publicly available
network address, shall take one of the following options:

A) Indicate that only one address can be used on each association
that is by including no transport
addresses in the Tag-lock-new state; at INIT message (Section 2.3.1.1). This will make the expiration of
endpoint that timer, receives this Initiation message to consider the sender
as only having that association shall one address. This method can be shutdown by used for a dynamic
NAT, but any multi-homing configuration at the endpoint by sending an
Abort to the peer of that association.

Note: no user data shall is behind
the NAT will not be carried visible to its peer, and thus not be taken
advantage of.

B) Indicate all of its networks in both the Initiation by specifying all
the actual IP addresses and
Initiation Ack messages, i.e. ports that the Data Size field in NAT will substitute for the
endpoint. This method requires that the MDTP common
header must be set to 0x0.

Note: if an endpoint receives an Initiation but decides not to
establish behind the new association due to lack NAT must
have pre-knowledge of resources, etc.,
it shall respond to the Initiation with an Abort message.

3.1.1 Passing Initiation Parameters

In addition to all the Tags, both side must exchange their local network
information, maximal window length, IP addresses and ports that the sender's T2-Receive timer
value NAT will
assign.

5. User Data Transfer

User data is transferred in microseconds, number SCTP DATA Chunks. The format of pre-open outbound streams (P), SCTP data
chunks is defined in Section 2.3.12.

For transmission efficiency, SCTP defines mechanisms for bundling of
small user messages and
number segmentation of maximal inbound streams (M), large user messages.

The bundling and segmentation mechanisms, as defined in the Initiation Sections 5.10
and
Initiation Ack messages. And 5.11, are optional to implement by the data sender, but they MUST
be implemented by the data receiver, i.e., a SCTP receiver shall process MUST be
prepared to to receive and store
these initiation parameters. process bundled or segmented data.

5.1 Transmission of DATA Chunks

The maximal window length from the peer will following general rules SHALL be used to validate applied by the
TSN range sender for
transmission and/or retransmission of outbound DATA chunks:

A) At any given time, the received datagrams (see section 4.6).

The sender's T2-receive timer will be used sender MUST NOT have more than
min(cwnd, rwnd) DATA chunks outstanding.

B) When the time comes for the sender to adjust transmit, before sending
new DATA chunks, the T3-send timer sender MUST first transmit any outstanding
DATA chunks which are marked for retransmission (see section 4.1.1). Section 5.12
for more on retransmission).

C) Then, the sender can send out up to N new DATA chunks, where
N = min(cwnd, rwnd) - fsize. The number of maximal inbound streams (M) sender shall indicate then update its
fsize.

Note: if the maximal
number of concurrent streams window is full (i.e., N is less than or equal to zero),
the sender will may still accept send requests from its peer
(excluding stream 0). The sender will reject any new Stream Initiation
request from its peer if this number is reached, unless upper layer, but
SHALL transmit no more DATA chunks until some or all of the
currently open streams
outstanding DATA chunks are closed first by acknowledged and its fsize decremented.

In all cases, if a transmission or retransmission of a DATA chunk is
made, the peer.

The sender shall use start the number of pre-open outbound streams (P) to
indicate retransmission timer (T3-rxt) if it
is not currently running. For retransmissions, the T3-rxt timer value
must be adjusted according to its peer that, the timer back-off rules defined in addition
Section 5.12.3.

Note: If rwnd is set to the stream 0, the and all pending DATA chunks are acknowledged,
a sender
wants is allowed to have that many more streams (from stream send 1 new DATA chunk to stream P)
implicitly opened from the sender's side at the onset of the
association. This allows probe the receiver to allocate and initialize
necessary resources for
changes to rwnd.

5.2 Acknowledgment on Reception of DATA Chunks

The SCTP receiver MUST always acknowledge the additional P inbound streams.

However, if the sender's P is greater than, or equal to, the
receiver's M, SCTP sender about the
reception of each DATA chunk.

The guidelines on delayed acknowledgment algorithm specified in
Section 4.2 of RFC 2581 [14] SHOULD be followed. In particular, a SCTP
receiver shall replace the sender's P with M, MUST NOT excessively delay acknowledgments. Specifically, an
acknowledgement SHOULD be generated for at least every second datagram
received, and
then only pre-open M inbound streams (from stream 1 to stream M). At
the same time, the sender also must either settle with M, instead SHOULD be generated within 200 ms of
P, pre-open outbound streams, or abort the association and report arrival of any
unacknowledged datagram.

IMPLEMENTATION NOTE: the
resources shortage.

3.2 Tag Unlock and TSN Initialization

The first user datagram transmitted by "A" maximal delay for generating an
acknowledgement may need to "Z" shall have be configurable by the TSN
Seen value set to Tag_Z SCTP user,
either statically or dynamically, in order to meet the Data Part (see 2.3).

Similarly, specific
timing requirement of the first user datagram transmitted by "Z" to "A" shall
have signaling protocol being carried.

Acknowledgments MUST be sent in SACK control chunks. A SACK chunk can
acknowledge the TSN Seen value set to Tag_A.

The reception of this first datagram with user data and with multiple DATA chunks, see Section 2.3.3
for SACK chunk format. In particular, the
correct Tag value in SCTP receiver MUST fill the
Highest Consecutive TSN Seen ACK field from its peer shall unlock to indicate the
Tag highest consecutive
TSN number it has received, and cause the endpoint to leave any received segments beyond the Tag-lock or Tag-lock-new mode.
highest consecutive TSN SHALL also be reported.

The receiver shall immediately send back an Extended Data Ack to
acknowledge following example illustrates the reception use of this first user datagram.

The TSN Send value carried in this first datagram delayed acknowledgments:

Endpoint A Endpoint Z

{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rxt timer)

DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
/------- SACK [TSN ACK=8,Frag=0]
(cancel T3-rxt timer) <-----/
...
...

DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rxt timer)
...
{App sends 1 message; strm 1}
(bundle SACK with user data shall DATA)
/----- SACK [TSN Ack=9,Seg=0] \
/ DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rxt timer) <------/ (Start T3-rxt timer)
(ack delayed)
...
(send ack)
SACK [TSN ACK=6,Seg=0] --------------> (cancel T3-rxt timer)

5.3 Timer Management Rules

Unless otherwise stated, the following rules SHALL be used to establish manage
the initial TSN of this peer, i.e., timers during normal DATA chunk transfer:

A) When a DATA chunk is sent out, the SCTP sender of
this datagram.

To strengthen the security, this initial TSN shall be randomly
selected from start
a T3-rxt timer if no T3-rxt timer is currently running.

Note, if there are any unacknowledged DATA chunks (e.g., due to
delayed ack), the range between 0x1 sender should create a SACK and 0x7fffffff by the sender, by
means such as those suggested in RFC 1750 [9].

Note: When an endpoint receives the first user datagram that causes bundle it
to leave the with
the Tag-lock or Tag-lock-new mode, it shall immediately
send an Extended Data Ack to acknowledge outbound DATA chunk, as long as the reception size of this user
datagram and shall NOT start a T2-recv timer. For all the subsequent
user resultant SCTP
datagram receptions, does not exceed the receiver shall follow current MTU.

B) When the normal T3-rxt timer
rules.

Stewart, et al [Page 13]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

3.3 Datagram Processing during Tag Lock

In Tag-lock or Tag-lock-new mode, an endpoint shall silently discard
any user datagrams from expires, the peer endpoint that does not carry sender shall follow the
correct Tag value.

However, if there is a control part present rules
described in a discarded user
datagram, Section 5.12 for retransmissions.

The value of the endpoint T3-rxt timer shall always process the
control part even be adjusted every time when the data part is being discarded.

If another Initiation from "A" it
is received by "Z" after "Z" sent out
its Initiation Ack, "Z" shall respond to this second Initiation by
re-sending started with the Initiation Ack latest RTT measures. See Section 5.12.3 for
details.

C) When all outstanding DATA chunks are acknowledged, the T3-rxt
timer shall be stopped if it is still running.

D) When the Tag Send field of this second
Initiation data sender has the same value as T3-rxt timer running and receives a
partial acknowledgment (one that of acknowledges at least one but not
all outstanding DATA chunks), if the original Initiation.
Otherwise, "Z" Consecutive TSN ACK is moved
forward, the sender shall respond by sending an Initiation of its own, with
Tag Send field set to Tag_Z, so as to elicit an Initiation Ack from
"A".

3.4 An Example of Association Initialization

In restart the T3-rxt timer; otherwise T3-rxt
timer shall continue running.

The following example, "A" initiates example shows the association first and then
sends a user datagram to "Z", then "Z" sends two user datagrams
sometimes later: use of various timer rules (assuming
the receiver uses delayed acks).

Endpoint A Endpoint Z

{app sets association with Z}
Initiation
[Tag Seen=0,Tag Send=Tag_A
& net addr info] --------\
(Start T1-init timer) \
(Enter Tag_A-lock mode) \---->Initiation Ack
[Tag Seen=Tag_A,Tag Send=Tag_Z
/---- & net addr info]
/ (Enter Tag_Z-lock-new mode)
(Cancel T1-init timer)<-------/

{app
{App sends 1st user data; 2 messages; strm 0}
U-Data
[Seen=Tag_Z,Send=init TSN-A
Strm=0,Seq=1,
& user data] -------\
(Start T3-send timer) \
\---->(Leave Tag_Z-lock-new mode)
------Ext
Data Ack
/ [Seg=0,TSN Seen=init TSN-A]
(Cancel T3-send [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rxt timer) <-----/
..

Stewart, et al [Page 14]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

..
{app
{App sends 2 datagrams;strm 0}
/---- U-data 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN ACK=7,Frag=0] \
\ / [Seen=Tag_A,Send=init TSN-Z
(Leave Tag_A-lock mode) <----/ Strm=0,Seq=1,
Ext Data Ack & user data 1]
[Seg=0,TSN Seen=init TSN-Z] /---- U-data
--------\ DATA [TSN=6,Strm=1,Seq=2]
\ / [Seen=init TSN-A,
\/ Send=init TSN-Z +1, (Start T2-receive timer)<---/\ Strm=0,Seq=1, & user data 2] T3-rxt timer)
\
\------>

If T1-init timer expires at "A" after
/ \
(Re-start T3-rxt timer) <------/ \--> (ack delayed)
(ack delayed)
...
{send ack}
SACK [TSN ACK=6,Frag=0] --------------> (Cancel T3-rxt timer)
..
(send ack)
(Cancel T3-rxt timer) <-------------- SACK [TSN ACK=8,Frag=0]

5.3.1 T3-rxt Timer Adjustment with RTT

The sender shall keep track of the Initiation latest RTT measurement for the
destination transport address of its peer (or addresses if the peer is sent,
multi-homed).

Procedures for obtaining RTT measurements are defined in Section 7.5.

Every time when a new DATA chunk is sent for the same
Initiation message with first time (i.e.,
not a retransmission), the same Tag_A value following procedure shall be retransmitted applied to
determine the T3-rxt timer value:

1. TL3-value = 'TL3-default'

2. T3-rxt = TL3-value + network-RTT

where, 'TL3-default' is a protocol parameter configurable by the
sender, and the network-RTT is the current RTT measurement of the
destination transport address this transmission is to take place.

However, if the previous T3-rxt timer expired and is being re-started
for a retransmission, the timer restarted. This back-off rules defined in Section 5.12
shall be repeated Max.Init.Retransmit times
before "A" considers "Z" unreachable and optionally reports used instead.

5.4 Multi-homed SCTP Endpoints

An SCTP endpoint is considered multi-homed if there are more than one
transport addresses that can be used as a destination address to reach
that endpoint.

Moreover, at the
failure.

3.5 Other Initiation Issues

3.5.1 Selection sender side, one of Tag Value

Tag values should the multiple destination
addresses of the multi-homed receiver endpoint shall be selected from as
the range primary destination transport address by the UPL (see Section 9
for details).

At association initiation, the initial primary destination transport
addresses are:

- for the sender of 0x80000000 to
0xffffffff. It is very important that the Tag value be randomized to
guard against "man in INIT message, the middle" and "sequence number" attacks. It is
suggested transport address that RFC 1750 [9] the INIT
is sent on. This may be used changed upon reception of the destination transport
adress list in the INIT ACK message.

- for the Tag randomization.

3.5.2 Initiation sender of the INTI ACK message, any valid transport address
obtained from behind a NAT the INIT message.

When a NAT is present between two endpoints, the endpoint that SCTP sender is
behind transmitting to the NAT, i.e., one that does not have a publicly available
network address, shall multi-homed receiver, by
default the transmission SHOULD always take one of place on the following options:

A) Indicate that it has only one network by setting primary
transport address, unless the 'Number of
networks' field in SCTP user explicitly specifies the Initiation message destination
transport address to use.

If possible, acknowledgements SHOULD be transmitted to 0. This will make the
endpoint that receives same
destination transport address from which the acknowledged DATA or
control chunks were received (Note: when acknowledging multiple DATA
chunks in a single SACK, this Initiation message may not be possible).

Some of the destination transport addresses may become inactive due to consider
either the occurrance of certain error conditions or adjustments from
SCTP user.

In the case where the primary destination transport address becomes
inactive, or the SCTP user tries to explicitly send to an inactive
destination transport address, the SCTP sender
as only having that one address. should either send the
chunk to an alternate active destination transport address, or to
report an error. This method can be used for is implementation specific.

Also, when the SCTP receiver is multi-homed, an SCTP sender SHOULD
always try to retransmit a dynamic
NAT, but any multi-homing configuration at chunk to an active destination transport
address that is different from the endpoint original destination address used
to transmit that chunk.

5.5 Stream Identifier and Sequence Number

Every DATA chunk MUST carry a valid stream identifier. If a DATA chunk
with an invalid stream identifier is behind received, the NAT will not be visible receiver shall
respond immediately with an ERROR message with cause set to its peer, Invalid
Stream Identifier (see Section 2.3.9) and thus not discard the DATA chunk.

For ordered DATA chunks, a non-zero stream sequence number MUST be taken
advantage of.

B) Indicate all of its networks
carried.

The stream sequence number in the Initiation by specifying all the actual IP addresses streams shall start from 1 when
the association is established. Also, when the stream sequence number
reaches the value 0xffff the next sequence number shall be set to 1.

Stream sequence number '0' has special meanings, see Section 5.6
below.

5.6 Ordered and ports that Un-ordered Delivery

Normally, the NAT will substitute for SCTP receiver shall ensure the
endpoint. This method requires that DATA chunks within any
given stream be delivered to the endpoint behind upper layer according to the NAT must
have pre-knowledge order of all
their stream sequence number. If there are DATA chunks arriving out of
order of their stream sequence number, the IP addresses and ports that receiver MUST hold the NAT will
assign.

Stewart, et al [Page 15]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

3.5.3 Initialization Collision

If two endpoints attempt to initialize
received DATA chunks from delivery until they are re-ordered.

However, an association with each other
at about SCTP sender can set the same instance, a collision will occur. As stream sequence number of a result, each
side will receive an Initiation datagram from DATA
chunk to '0', to indicate that no ordered delivery is required on that
particular DATA chunk within the other side after it
transmitted its own. stream.

In such a this case, both sides shall send an
Initiation Ack datagram to the other side using receiver must bypass the procedure
described above.

3.5.4 Association Re-initialization

An endpoint shall be allowed to re-initialize an established
association with ordering mechanism and
immediately delivery the other endpoint.

Once an endpoint has left data to the Tag-lock or Tag-lock-new mode of upper layer (after re-assembly if
the
previous association initialization process, it shall treat any new
Initiation message from its peer as a re-initialization event.

During a re-initialization, both endpoint shall follow data is segmented by the same
procedure as defined sender)..

This provides an effective way to transmit "out-of-band" data in section 3.1. And any
given stream. Also, a new Init-Tag must stream can be used as an "un-ordered" stream by
simply setting the endpoint that receives the Initiation message, if it has already
left the previous Tag-lock or Tag-lock-new mode.

Association re-initialization affects ongoing transmission and
their resources. The receiver stream sequence number of the new Initiation each outbound DATA chunk
to 0.

IMPLEMENTATION NOTE: An implementation, when sending an un-ordered
DATA chunk, may need choose to
perform garbage-collection on its resources, including:

A) automatically terminating all existing streams within place the current
association and releasing DATA chunk in an outbound
datagram at the resources,

B) cancelling any running timers,

C) removing all outstanding datagrams head of the current association
from its retransmission queue, and

D) optionally, notifying the upper layer about outbound transmission queue if
possible.

5.7 Report Gaps in Received DATA TSNs

Upon the re-initialization.

4. Transfer User Datagram

The receiver reception of a user datagram new DATA chunk, an SCTP receiver shall always acknowledge the reception
to examine
the sender continuity of the datagram. Normally, delayed acknowledgment shall
be used. The delay shall be controlled by a T2-receive timer.

At TSNs received. If the expiration of T2-receive timer, if there is out-bound user data, receiver detects that gaps
exist in the ack should received DATA chunk sequence, an SACK with fragment
reports shall be piggy-backed sent back immediately.

Based on the data part of segment reports from the out-bound user
datagram, occupying SACK, the TSN Seen field data sender can
calculate the missing DATA chunks and make decisions on whether to
retransmit them (see section 2.3). Otherwise, a
stand-alone Extended Data Ack shall Section 5.12 for details).

Multiple gaps can be used to carry reported in one single SACK (see Section 2.3.3).

Note that when the
acknowledgment.

When Extended Data Ack data sender is used, multi-homed, the sender shall fill SCTP receiver
SHOULD always try to send the Highest
Consecutive TSN Seen field SACK to indicate the highest TSN Send number it
has received same network from where the peer. Any received segments must
last DATA chunk was received.

Upon the reception of the SACK, the data sender SHALL remove all DATA
chunks which have been acknowledged by the SACK. The data sender MUST
also be treat all the DATA chunks which fall into the gaps between the
fragments reported (see sections 2.2.2 and 4.5). by the SACK as "missing". The number of "missing"
reports for each outstanding DATA chunk MUST be recorded by the data
sender in order to make retransmission decision, see Section 6.2.4
for details.

The following example illustrates both stand-alone and piggy-backed
acknowledgments: shows the use of SACK to report a gap.

Endpoint A Endpoint Z
{App sends 3 messages in strm 0}
U-Data
[Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer)
(Start T3-send timer)

U-Data
[Seen=5,Send=8,Strm=0,Seq=4]-------->

Stewart, et al [Page 16]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

U-Data
[Seen=5,Send=9,Strm=0,Seq=5]-------->
...
{Timer T2 expires}
/--------- Extended Data Ack
/ [Seg=0,Seen=9]
(cancel T3-send timer) <----/
...
...
{App sends 1 message; messages; strm 0}
U-Data
[Seen=5,Send=10,Strm=0,Seq=6]-------> (Start T2-receive timer)
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-send timer)
...
{App sends 1 message; strm 1}
(cancel T2-receive T3-rxt timer)
/------ U-Data
/ [Seen=10,Send=6,Strm=1,Seq=2]

DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)

DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN ACK=6,Frag=1,
/ (Start T3-send timer)
(cancel T3-send timer) <------/
(Start T2-receive timer)
..
{Timer T2 Expires}
Extended Data Ack
[Seg=0,Seen=6]----------------------> (cancel T3-send timer)

4.1 Timer Management Rules Strt=2,End=2]
<-----/
(remove 6 and 8 from out-queue,
and strike 7 as "1" missing report)

Note: in order to keep the size of the outbound SCTP datagram not to
exceed the current path MTU, the maximal number of fragments that can
be reported within a single SACK chunk is limited. When a single SACK
can not cover all the fragments needed to be reported due to the MTU
limitation, the endpoint SHALL send only one SACK, reporting the
fragments from the lowest to highest TSNs, within the size limit set
by the MTU, and leave the remaining highested TSN fragment numbers unacknowledged.

5.8 TSN Range Check

The SCTP receiver must check the range of the TSN in each received
DATA chunk. The algorithm is outlined as follow:

Assume that the following rules shall be used to manage highest TSN received from the timers during
normal datagram transfer, unless otherwise stated for some special
cases:

A) When a user datagram data sender is received, T and the endpoint shall start a
T2-receive timer if no T2-receive timer
current LOCAL Receiver Window Credit is lrwnd (that is currently running. Upon the expiration of rwnd last
advertised by the T2-receive timer, receiver to the endpoint data sender). When the next DATA
chunk arrives from the data sender, the receiver MUST discard the DATA
chunk if the TSN carried in the DATA chunk is greater than T + lrwnd
(calculation shall
acknowledge wrap around at 0xffffffff to 0x1). The receiver
shall also immediately send a SACK to the sender all data sender.

Note: the un-acked user datagrams it has highest TSN received is not necessarily the highest
consecutive TSN received.

B) When a user datagram They becomes the same only when there is sent out, no
gap in the received TSN sequence space.

5.9 CRC-16 Utilization

When sending endpoint shall start a T3-send timer if no T3-send timer is currently running.

If datagram, the T2-receive timer is running, sender can choose to strengthen the endpoint shall first stop data
integrity of the T2 timer, piggy-back an ack (or Extended Data Ack) onto transmission by including the CRC-16 value calculated
on the
out-bound datagram, and then start a T3-send timer.

If as described below.

After the T3-send timer expires, datagram is constructed (containing the endpoint shall follow SCTP common header
and one or more control or DATA chunks), the rules
described sender shall:

1) fill in 4.6 for possible re-transmission of the un-acked
datagrams.

Moreover, whenever proper Version number and Verification Tag in the T3-send timer is started
common header,

2) set the RTT estimate
last calculated for that remote network address should be added C Bit to '1' and fill the 16 bit CRC-16 field with '0',

3) calculate the base T3-send timer CRC-16 value (see sections 6.2 of the whole datagram, including the
SCTP common header and 6.3 for RTT).

Stewart, et al [Page 17]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

C) When all outstanding datagrams are acknowledged, the T3-send timer chunks,

It shall be stopped if one is still running.

D) If an endpoint has a T3-send timer running and receives a partial
acknowledgment (one that acknowledges some of the outstanding
datagrams), the endpoint shall restart ones complement of the T3-send timer.

The following example shows sum (modulo 2) of:
a) the use remainder of various timers.

Endpoint A Endpoint Z
{App sends x k (x 15 + x 14 + x 13 + x 12 + x 11 + x 10 +
x 9 + x 8 + x 7 + x 6 + x 5 + x 4 + x 3 + x 2 messages; strm 0}
U-Data
[Seen=5,Send=7,Strm=0,Seq=3] ---------> (Start T2-receive timer)
(Start T3-send timer)

U-Data {App sends 1 message; strm 1}
[Seen=5,Send=8,Strm=0,Seq=4] -\ /-- (cancel T2-receive timer)
\ / U-Data
\ / [Seen=7,Send=6,Strm=1,Seq=2]
\ (Start T3-send timer)
/ \
(Re-start T3-send timer) <-------/ \
(Start T2-receive timer) \
... -> (Start T2-receive timer)
...
{T2-receive timer expires}
Extended Data Ack
[Seg=0,Seen=6] -----------------------> (Cancel T3-send timer)
..
{T2-receive timer expires}
(Cancel T3-send timer) <---------------- Extended Data Ack
[Seg=0,Seen=8]

4.1.1 T3-send Timer Adjustment with RTT

The sender shall keep track of the latest RTT measurement for the
destination IP address (or addresses if + x + 1) divided
(modulo 2) by the remote host generator polynomial x 16 + x 12 + x 5 + 1,
where k is
multi-homed) of its peer. Three procedures for obtaining RTT
measurements are defined in sections 4.7, 6.2, and 6.3,
respectively. And the calculation number of RTT should follow the method
described bits in [4].

Every time when a new datagram is sent for the first time (i.e., SCTP frame not
for re-transmission), including
the following procedure shall be applied to
determine CRC-16 bits, and
b) the T3-send timer value:

1. TL3-value = 'TL3-default'

2. if TL3-value <= Receiver's T2-Recv + highest-RTT,
TL3-value = TL3-value remainder of the division (modulo 2) by the generator
polynomial x 16 + highest-RTT
end-if

3. T3-send = TL3-value x 12 + network-RTT

where, 'TL3-default' is a protocol parameter configurable x 5 + 1, of the product of x 16 by the
endpoint, receiver's T2-Recv timer
content of the frame not including the CRC-16 bits.

4) put the resultant value is known during into the
association initiation (see section 3.1.1), CRC-16 field, and leave the rest of
the highest-RTT bits unchanged.

When a datagram is received, the
current highest RTT measurement across all receiver MUST first check the destination IP
addresses available for transmission, and, C
Bit. If the network-RTT C Bit is set, the
current RTT measurement of receiver SHALL:

1) store the destination IP address this
transmission is to take place (see section 4.2.1 for received CRC-16 value aside,

2) replace the determining 16 bits of destination IP address).

However, if the previous T3-send timer expired CRC-16 with '0' and is being re-started
for calculate a re-transmission, CRC-16
value of the timer back-off rules defined in section 5.2
shall be used instead.

4.2 Multihoming Rotation

4.2.1 Remote Multihoming Rotation

When an endpoint whole received datagram,

3) verify that the calculated CRC-16 value is transmitting to a remote multi-homed endpoint, the
transmitting endpoint shall rotate between destination IP addresses.
Every time same as the application transmits a datagram, MDTP received
CRC-16 value, If not, the receiver MUST keep track
of treat the remote IP address datagram as an
invalid SCTP datagram.

If the C Bit is not set, the receiver MUST NOT perform the above
CRC-16 check.

The default procedure of handling invalid SCTP datagrams is to which it sent
silently discard them.

5.10 Segmentation

Segmentation SHALL be performed by the datagram in data sender if the MDTP

Stewart, et al [Page 18]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

protocol variable 'last.sent.intf'. MDTP should rotate each send in user message
to be sent has a
round robin fashion amongst all available destination IP addresses on large size that causes the outbound SCTP datagram
size exceeding the remote multi-homed host and should update current MTU.

IMPLEMENTATION NOTE: if segmentation is not support by the protocol variable
'last.sent.intf' to indicate which destination IP address it last
used.

If possible, acks sender,
an error should be transmitted reported to the same IP address from
which sender's SCTP user if the acked messages were received. When acknowledging multiple
messages, this may not data to be possible. In
sent has a size exceeding the latter case, MDTP SHOULD
rotate current MTU. In such cases the transmission of acknowledgments Send
primitive discussed in Section 9.1 would need to all remote IP addresses.

The MDTP implementation MUST allow return an application error
to override this
rotation by specifying the destination IP address to which to send a
datagram. The implementation must also provide an interface to add
and remove upper layer.

Segmentation takes the following steps:

1) the data sender SHALL break the large user message into a remote IP address from rotation eligibility.

4.2.2 Local Multihoming Rotation

As discussed in section 3.3.4 series of RFC 1122, an endpoint MAY rotate
transmitted messages amongst all local network interfaces by
specifying
DATA chunks, each with a total size smaller than the local IP address and UDP port or it may allow current MTU
minus the
networking protocol to decide which local IP address (and network
interface) to use to transmit SCTP common header size (i.e., 8 octets),

2) the data sender MUST then assign, in sequence, a datagram..

If possible, acks should be transmitted from separate TSN to
each of the same IP address over
which DATA chunks in the acked messages were received. When acknowledging multiple
messages, this may not be possible. In series,

3) the latter case, MDTP SHOULD
rotate data sender MUST also set the transmission B/E bits of acknowledgments from all configured IP
address/port pairs.

4.3 Stream Sequence Number

The datagram stream sequence number shall always be set to 1 when the
stream is opened.

Also, when first DATA chunk
in the stream sequence number reaches series to '10', the value 0xffff B/E bits of the
next sequence number shall be set last DATA chunk in the
series to 1. Sequence number '0' has
special meaning (see section 4.4) '01', and shall not be used the B/E bits of all other DATA chunks in normal
sequence number rotation..

4.4 Ordered and Un-ordered Delivery

Normally, the
series to '00'.

The data receiver MUST recognize the segmented DATA chunks, by
examining the B/E bits in each of the received DATA chunks, and queue
the segmented DATA chunks for re-assembly. Then, it shall ensure pass the
re-assembled user datagrams within any
given stream be delivered to the upper layer according message to the order of
their specific stream sequence number. If there are datagram arrived out of
order for re-ordering and
final dispatching.

5.11 Bundling

An SCTP sender achieves bundling by simply including multiple DATA
chunks in one outbound SCTP datagram, see Section 2 for details. Note
that the total size of their stream sequence number, the receiver must hold resultant SCTP datagram, including the
received datagrams from delivery until they are re-ordered.

However, a SCTP
common header, MUST be less or equal to the current MTU.

5.12 Retransmission

5.12.1 Basic Retransmission Rules

The SCTP data sender can set SHALL follow these rules for retransmit:

A) The data sender should only retransmit up to 'Max.retrans.at.once'
DATA chunks marked for retransmission in one send opportunity. Any
remaining DATA chunks marked for retransmission should be left for
the stream sequence number of a user
datagram next send opportunity.

[Editors note: fsize may need to 0, change to indicate that no ordering shall be performed on that
datagram within that stream. Upon total-fsize]

B) Retransmissions does not change the reception count of outstanding DATA
chunks, i.e., the datagram, fsize will not increase on retransmissions.

C) If the

Stewart, et al [Page 19]

Internet Draft Multi-network Datagram Transmission Protocol June 1999 data receiver must by-pass is multi-homed, a retransmission should be
sent to an alternate active destination transport address which
should be different from the ordering mechanism one the original transmission took
place.

The state of each destination transport address (active or
inactive) should be maintained and immediately delivery
the datagram to updated by the upper layer.

This provides an effective way to transmit "out-of-band" data sender,
using the failure detection (see Section 7.2) and heartbeat
mechanisms (see Section 7.3).

Note: fast retransmit on gap reports is discussed in any
given stream. Also, a stream can be used Section 6.2.4 as an "un-ordered" stream by
simply setting the stream sequence number
part of each out-bound user
datagram to 0.

4.5 Report Missing Datagrams

MDTP uses a receiver-based retransmission policy, where the sender
attempts congestion control.

5.12.2 Retransmit on T3-rxt Timer Expiration

When the T3-rxt timer expires, in addition to elicit from the receiver information on congestion control
adjustments defined in 6.2.3, the missing
datagrams before data sender SHALL take the following
steps:

1) mark the outstanding DATA chunk for retransmission. If a receiver detects holes in there are
more than one outstanding DATA chunks, the received user datagram sequence (by
examining sender should mark both
the oldest and newest ones (in terms of their TSN Send numbers), an Extended Data Ack with segment reports order) for
retransmission;

2) immediately start retransmitting using the rules described in
Section 5.12.1, and;

3) start the T3-rxt timer after retransmission, if it is not
currently running.

5.12.3 T3-rxt Timer Back-off

When the T3-rxt timer is started or re-started for retransmission,
the following timer back-off rules shall be sent back applied to inform determine the sender so that
value of the sender can
calculate new timer:

1. TL3-value = TL3-value * 2

2. T3-rxt = TL3-value + network-RTT

where, TL3-value is the protocol variable which keeps the previous
T3-rxt timer base value, and re-transmit the missing datagrams.

Multiple segments can network-RTT is the current RTT
measurement of the destination transport address the retransmission is
to be indicated in one single Extended Data Ack
(see sent to.

Note: the T3-rxt timer base value shall be restored to its default
value 'TL3-default' when an ack is received from the peer endpoint.

6. Congestion control

[ Editors Notes.. this section 2.2.2).

If there is outbound user data, the endpoint shall piggy-back the
Extended Data Ack with the user data in the same MDTP datagram, still being reworked and may
have some changes ]

Congestion control is one of the TSN Seen field basic functions in the data part shall not SCTP protocol.
It is likely that adequate resources will be used, i.e., the
sender shall set the field allocated to 0x0 and SCTP
traffic to assure prompt delivery of time-critical SCTP data, thus it
would be unlikely, during normal operations, that SCTP transmissions
encounter severe congestion condition. However SCTP must prepare itself
for adverse operational conditions, which can develop upon partial
network failures or unexpected traffic surge. In such situations SCTP
must follow correct congestion control steps to recover from congestion
quickly in order to get data delivered as soon as possible. In the receiver shall ignore it.
absence of network congestion, these preventive congestion control
algorithms will show no impact on the protocol performance.

The following example shows congestion control algorithms used by SCTP are based on RFC 2581,
"TCP Congestion Control". This section describes how the algorithms
defined in RFC 2581 are adopted for use of segment report in an Extended
Data Ack.

Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
U-Data
[Seen=3,Send=6,Strm=0,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer)

U-Data
[Seen=3,Send=7,Strm=0,Seq=3]-----X (lost)

U-Data
[Seen=3,Send=8,Strm=0,Seq=4]-------> (A seg detected SCTP. We first list
differences in data)
..
{T2-receive timer expires}
/------ Extended Data Ack
/ [Seg=1,Strt=8,End=8,Seen=6]
(Prepare retransmission) <----/

In this example, when "Z" receives protocol designs between TCP and SCTP, and then describe
SCTP's congestion control scheme. The description will use the third datagram same
terminology as in TCP congestion control whenever appropriate.

6.1 SCTP Differences from "A" it
realizes that a gap exists TCP Congestion control

Different from TCP, SCTP controls data transmission in the received data. At the expiration unit of
T2-receive timer, "Z" sends an Extended Data Ack with a segment report
to "A" to indicate the missing datagram.

Stewart, et al [Page 20]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

When the peer endpoint is multi-homed, the Extended Data Ack should be
sent out to
DATA chunks instead of byte count. Thus the destination IP address specified flow control and congestion
control windows in SCTP are measured and adjusted in the MDTP protocol
variable 'last.good.intf'. The value number of 'last.good.intf'
DATA chunks.

Another difference is always
updated to point that Selective Acknowledgment function (SACK) is
designed into SCTP, rather than an enhancement that is added to the source IP address from which
protocol later as the last datagram case for TCP. SCTP SACK carries different
semantic meanings from that of TCP SACK. TCP considers the peer endpoint arrived.

4.6 Range Check on TSN

For security reasons, information
carried in the receiver must check SACK as advisory information only. In SCTP, any DATA
chunk that has been acknowledged by SACK, including DATA that arrived
at the range receiving end out of order, are considered having been delivered
to the TSN
Send value in each received user datagrams.

Assume that destination application, and the highest TSN received from a peer sender is T and free to discard the maximal
window length
local copy. Thus the value of cwnd controls the same peer number of outstanding
DATA chunks; it is W (exchanged during association
initiation, see section 3.1). When not the next user datagram arrives from
this peer, upper bound between the receiver shall silently discard highest acknowledged
sequence number and the datagram if latest DATA chunk that can be sent within the TSN
Send value carried in
congestion window, as the datagram case in TCP. SCTP SACK leads to different
implementations of fast-retransmit and fast-recovery from that of TCP.

The biggest difference between SCTP and TCP, however, is greater multi-homing.
SCTP is designed to establish robust communication associations between
two end points each of which may be reachable by more than T+W (calculation
rounds up at 0x7fffffff one transport
address. Potentially different addresses may lead to 0x1).

4.7 Advisory Ack Request

An endpoint distinguished data
paths between the two points, thus ideally one may use Advisory Ack Requests to improve bandwidth
utilization, in combination need a separate set
of the window congestion control (see section 5.1).

Advisory Ack Request shall always be piggy-backed on an outbound user
datagram.

The endpoint should send an Advisory Ack Request to its peer when:

A) it reaches half parameters for each of the paths. Given SCTP is
the first transport protocol whose design specifically takes multihoming
issue into consideration, however, there is no experience at this point
regarding the use of its window length multiple addresses, or the likelyhood of each
address pair representing a separate path. To proceed with caution, we
make the sending following assumptions:

o the sender does not change the use of source address often, if at
all.
o the
current user datagram, or

B) it detects that sender always uses the next send will reach same destination address until being
instructed by the full window length
with upper layer otherwise.
o the sending sender keeps a separate congestion control parameter set for each
of the current user datagram.

After destination addresses. The parameters should decay if the receiver detects
address is not used for a long enough time period.
o For each of the Advisory Ack Request in destination addresses, do slow-start upon the first
transmission to that address.

6.2 SCTP Slow-Start and Congestion Avoidance

The slow start and congestion avoidance algorithms MUST be used by a
SCTP sender to control
part the amount of outstanding data being injected
into the datagram, it should handle network. The congestion control in SCTP is employed in regard
to the association, not to an individual stream. In some situations it with
may be beneficial for a SCTP sender to be more conservative than the
algorithms allow, however a SCTP sender MUST NOT be more aggressive than
the following rules:

A) The receiver may choose algorithms allow.

Like TCP, an SCTP sender uses the following three control variables to ignore
regulate its transmission rate.

o Receiver advertised window size (rwnd), which is set by the peer's Advisory Ack Request
receiver based on its available buffer space for any reasons, such as flow control, etc, and move incoming packets.
o Congestion control window (cwnd), which is adjusted by the sender
based on observed network conditions.
o Slow-start threshold (ssthresh), which is also used by the sender to
process
distinguish congestion control and congestion avoidance phases.
o Flight size (fsize), an SCTP sender variable that indicates the total
number of outstanding DATA chunks.

SCTP also requires one additional control variable, cwnd2, which is used
during congestion avoidance phase to facilitate cwnd adjustment.

6.2.1 Slow-Start

Beginning data part.

B) If transmission into a network with unknown conditions
requires SCTP to probe the receiver chooses network to respond, it should, determine the available capacity.
The slow start algorithm is used for this purpose at the end beginning of
processing a
transfer, or after repairing loss detected by the data part, immediately send an Extended Data Ack retransmission timer.

o The initial value of cwnd MUST be less than or equal to acknowledge all the un-acked datagrams (including the one it
just processed), and cancel its T2-receive timer if one is still
running. 2 (DATA chunks).
o The following diagram shows an example initial value of using Advisory Ack Request:

Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
U-Data
[Seen=5,Send=7,Strm=0,Seq=3]-------------> (Start T2-recv timer)
(Start T3-send timer)

U-Data
[Seen=5,Send=8,Strm=0,Seq=4]----------->

{detects window half full, use Advisory Ack Req}
Adv Ack Request/U-data
[Seen=5,Send=9,Strm=0,Seq=5]------\
\
\----> (cancel T2-receive timer)
<---------------- Extended Data Ack
[Seg=0,Seen=9]

An endpoint sending an Advisory Ack Request may also ssthresh MAY be arbitrarily high (for example,
some implementations use this request
for its RTT calculation. The sending endpoint may note the time mark
when sending size of the datagram with receiver advertised window).
o Whenever cwnd is greater than zero, the Advisory Ack Request. sender is allowed to send cwnd
number of DATA chunks.
o When cwnd is less than or equal to ssthresh, cwnd is incremented by
the
peer endpoint responds number of chunks acknowledged in each SACK received (piggy-backed
or stand-alone SACKs).

Note: a piggy-backed SACK is one that is bundled with a DATA chunk.

6.2.2 Congestion Avoidance

Whenever cwnd is increased to be equal or greater than ssthresh, cwnd
should be incremented by 1 per RTT. In practice an Extended Data Ack, the sender of implementation can
achieve this goal in the
Advisory Ack Request may use following way:

o cwnd2 is initialized to 0.
o Whenever cwnd is equal or greater than ssthresh, upon each SACK
arrival, increase cwnd2 by the time mark number of the arriving Extend Data
Ack chunks acknowledged in that
SACK.
o When cwnd2 is equal or greater than cwnd, increase cwnd by 1, and
reset cwnd2 to (cwnd2 - cwnd).

6.2.3 Congestion Control

Upon detection of packet losses from SACK, the stored time mark sender should do the
following:

ssthresh = max(fsize/2, 2)
cwnd = ssthresh/2

Basically, a packet loss causes cwnd to calculate be cut in half.

When the RTT as defined T3-timer expires, SCTP should perform slow start by setting
cwnd = 1, which assures that no more than one DATA chunk will be in
[4]. However,
flight until the sender of receives acknowledgment for successful
delivery.

6.2.4 Fast Retransmit on Gap Reports

In the Advisory Ack Request shall abandon absence of data losses, a SCTP receiver performs delayed
acknowledgment. However whenever a receiver notices a hole in the
RTT calculation if more datagrams are sent to its peer and no Extended
Data Ack is received.

Stewart, et al [Page 21]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

4.8 CRC-16 Utilization

When
arriving TSN sequence, it should start sending a datagram, SACK for every
packet arrival.

At the sender can choose to strengthen the data
integrity
of end, whenever the transmission by including sender notices a CRC-16 value of hole in a SACK, it
should wait for 3 further SACKs before taking action. If the datagram.

After 3
subsequent SACKs report the datagram is constructed, same TSN(s) missing, the sender shall:

1) set the C Bit to '1' and fill mark the 28 bit CRC-16/MDTP Protocol
Identifier field with '0', DATA chunk(s) for retransmission,
2) adjust its ssthresh and the 4 bit Version field cwnd according to the
current MDTP version number (binary 0011).

2) calculate a CRC-16 value of the whole datagram, including the
MDTP common header, the Control Parameter Part formula described in
this section.
3) Restart T3-rxt timer if present, it is running, and
the Data Part if present,

3) put the resultant CRC-16 value into the most significant 16 bits
4) start retransmission procedure, as described in Section 5.12.2.

A straightforward implementation of the CRC-16/MDTP Protocol Identifier, and leave the rest of above requires that the
bits unchanged.

When sender
keeps a datagram is received, the receiver must counter for each TSN hole first check reported by a SACK; the C
Bit. If
counter keeps track of whether 3 subsequent SACKs have reported the C Bit is set,
same hole.

Because cwnd in SCTP bounds the receiver shall:

1) store number of outstanding TSN's,
the received CRC-16 value (the most significant 16 bits effect of TCP fast-recovery is achieved automatically with no
adjustment to the control window size.

6.3 Path MTU Discovery

[Editor's Note: text to be provided by Vern]

6.4 Discussion

There is one important difference between the first word of SCTP congestion control,
as described above, and TCP congestion control. In the datagram),

2) replace latter the 16 bit CRC-16/MDTP Protocol Identifier field with '0'
and calculate
control behavior is measured in unit of packets. That is, upon slow
start, a CRC-16 TCP connection doubles cwnd value of the whole received datagram,

3) verify that per RTT as measured by the calculated CRC-16
number of packets. In SCTP, cwnd value is the same doubled per RTT as measured
by the
received CRC-16 value, and

4) handle number of DATA chunks. Similarly, during congestion avoidance,
in the datagram as an invalid MDTP datagram if absence of packet losses a TCP connection increases cwnd by one
data packet per RTT, while a SCTP association increases cwnd by one DATA
chunk per RTT.

Ideally, congestion control should be performed by controlling the CRC-16
values mismatch .

If
number of outstanding packets. However because the C Bit DATA chunk size is a
variable, there does not set, the receiver shall check the MDTP Protocol
Identifier instead, seem a simple and handle reliable way to translate "one
datagram" to a suitable number of chunks. Although the datagram SCTP congestion
control design, as an invalid MDTP
datagram if described in this section, represents a simple
starting point, it may have potential negative impact on the check fails.

The default procedure application
performance depending on the relative sizes of handling invalid MDTP datagrams DATA chunks and packet
MTU. For example, if the MTU is to
silently discard them. 5 Congestion Controls

Several different mechanisms shall be used jointly to achieve
congestion control in MDTP. These mechanisms are always used in regard
to times of the association, not a individual stream.

5.1 Send with Window Control

The sending endpoint shall use average DATA chunk size,
it would take 5 times longer for a transmission window SCTP association to open up its cwnd
to control the
number same size of outstanding datagrams, i.e., datagrams that have been sent,
but yet to be acknowledged. The length of a TCP connection. During a slow start
congestion recovery, limiting the window transmission to cwnd DATA chunks may
lead to sending half-full packets, even when more application data is defined as
waiting to be transmitted.

We suggest that the
maximal number of outstanding datagrams current design be discussed, and revised if deemed
necessary.

7. Fault Management

7.1 Endpoint Failure Detection

The data sender shall keep a sending endpoint can
allow. This length is adjusted dynamically, depending counter on the current total number of successful transmissions as well as
consecutive retransmissions to its peer (including retransmissions to
ALL the number destination transport addresses of lost
datagrams or retransmissions.

When the number peer if it is multi-homed).

If the value of outstanding datagrams reaches this counter exceeds the current window
length, limit defined in the protocol
parameter 'Max.Retransmits', the data sender shall consider the peer
endpoint unreachable and shall still accept send requests from its stop transmitting any more data to
it. In addition, the data sender shall report the failure to the upper
layer, but shall transmit no more datagrams until some or and optionally report back all of the outstanding datagrams are acknowledged. remaining
in its outbound queue.

The endpoint may also elect
to queue only counter shall be reset each time a specified number of datagram when the window is full.
When this maximal number of queued datagrams is reached the endpoint
shall return an error to its upper layer.

Moreover, when the window length is reached, the next send request received from the upper layer will trigger a Window-up message to be
transmitted. Upon receiving this Window-up the receiver must respond
with a Window-up Ack, as illustrated by
peer endpoint.

7.2 Path Failure Detection

When the following example
(assuming current window length is 3):

Stewart, et al [Page 22]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

Endpoint A Endpoint Z
{App sends 3 messages, strm 0}
U-Data
[Seen=5,Send=7,Strm=0,Seq=3]--------> (Start T2-receive timer)
(Start T3-send timer)

U-Data
[Seen=5,Send=8,Strm=0,Seq=4]-------->

U-Data
[Seen=5,Send=9,Strm=0,Seq=5]-------->

{App sends a new message, strm 1}
(queue new message and send Win-up)
Window-up ---------------> (cancel T2-recv timer)
/---- Window-up Ack
/ [Seg=0,Seen=9]
(Cancel T3-send timer) <--------/
U-Data
[Seen=5,Send=10,Strm=1,Seq=2]-------> (Start T2-receive timer)
(Start T3-send timer)

In remote endpoint is multi-homed, the above example, after data sender should keep a
'retrans.count' counter for each of the transmission destination transport addresses of
the first three
datagrams, "A" reached its window length. The next message from remote endpoint.

This count should be incremented each time the
user triggered a Window-up that data sender retransmits
an outstanding datagram which was originally sent to "Z". The Window-up shall
contain no user data. In response, "Z" cancelled timer T2 the destination
transport address.

When the value in 'retrans.count' exceeds half of the value of the
protocol parameter 'Max.Retransmits', the data sender should mark the
corresponding destination transport address as inactive, and
immediately sent a Window-up Ack. The arrival of this Window-up Ack
effectively resolved all notification
may optionally be sent to the upper layer.

When an outstanding datagrams at "A", thus
allowing "A" datagram is acknowledged, the data sender should
clear the 'retrans.count' counter of the destination transport address to send out
which the next datagram.

5.1.1 Window Length Adjustment

The window length shall datagram was sent. In the case of a retransmitted datagram
(due to time-out or SACK) the destination transport address last
sent to should be initially set used to 2, and determine which 'retrans.count' to clear.

7.3 Path Heartbeat

By default, an SCTP endpoint shall then monitor the reachability of the
idle destination transport address(es) of its peer by sending
HEARTBEAT messages periodically to the destination transport
address(es).

A destination transport address should be
dynamically adjusted based on considered idle if no
datagram loss has been sent to it for a certain period of time, no matter
if it is marked active and acknowledgment.

If the current window length inactive.

IMPLEMENTATION NOTE: When multiple idle destination transport
addresses exist, it is less than or equal recommended that the endpoint sends heartbeat
messages on a Round-Robin basis, with priority given to active idle
destination transport addresses.

The upper layer can optionally initiate the following functions:

A) disable heartbeat on a given association,
B) re-enable heart beat on a given association, and,
C) request an on-demand heartbeat on a given association.

The endpoint should keep a 'heartbeat.sent.count' counter for each
destination transport address to 4, every time
when record the number of consecutive outstanding datagrams HEARTBEAT
messages sent to that destination transport address yet not
acknowledged in a
single ack upon.

When the value of this counter reaches the protocol parameter
'Max.HeartBeat.Misses', the endpoint should also mark that destination
address as inactive if it is equal not so marked. The endpoint may also
optionally report to or greater than half the current window length, upper layer the sender's window length shall be raised by 1, until it reaches
'Max.Outstanding.dg' (which un-reachablility of the
transport address.

The sender of the HEARTBEAT message should be a user configurable parameter).

If include in the message the
current window length is greater than 4, every time when the number message is sent out.

The receiver of consecutive outstanding datagrams acknowledged in the HEARTBEAT should immediately respond with a single ack is
equal to or greater than 4,
HEARTBEAT ACK that contains the sender's window length shall be raised
by 1, until it reaches 'Max.Outstanding.dg'.

In time value copied out from the following circumstances,
received HEARTBEAT message.

Upon the sender's window length shall be
decreased. However, when receipt of the window length reaches 2 it shall not be
decreased any further.

Firstly, if HEARTBEAT ACK, the sender receives a stand-alone Extended Data Ack with a
Seen TSN that equals of the HEARTBEAT
should clear the 'heartbeat.sent.count' of the destination transport
address to which the highest consecutive acked TSN, HEARTBEAT was sent, and mark the sender
should consider this destination
transport address as a duplicate ack and lower its window size
by 4. active if it is not so marked. The peer endpoint may
also optionally report reception gaps which may correspond to
multiple datagram losses (indicated by an Extended Data Ack or

Stewart, et al [Page 23]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

Window-up Ack). If between 1 to 3 datagrams are lost, the window
length shall be decreased by 1. If between 4 to 7 datagrams are lost, upper layer the window length shall be decreased by 2. If 8 or more datagrams are
lost, reachablility of the
transport address. It also should perform an RTT measurement for that
destination transport address using the window length shall be decreased by 4.

Any time a Window-up Ack value carried in the
HEARTBEAT ACK message.

The suggested interval for heart beat interval is received 4000 ms, and may be
dynamically adjusted by an endpoint, as a response to
a previous Window-up it sent, adding the endpoint shall decrease its window
by 1 current RTT measurement if it is
available.

7.4 Verification Tag

Except for INIT, the window has not advanced from sender of any SCTP datagram MUST include the time at which
destination endpoint's Tag in the
Window-up was sent out.

Also, if a timeout forces a retransmission Verification Tag field of the sender's window length
shall be reduced to half
message. In the case of its currently value.

The following table summarizes these rules:

-----------------------------------------------------------------
duplicate ack received by INIT, the sender | Adjust down by 4
-----------------------------------------------------------------
8 or more datagrams lost | Adjust down by 4
-----------------------------------------------------------------
4 to 7 datagrams lost | Adjust down by 2
-----------------------------------------------------------------
1 should set the Verification
Tag to 3 datagrams lost | Adjust down by 1
-----------------------------------------------------------------
Timeout forced retransmission | Adjust down by 1/2 of 0.

When sending a SHUTDOWN ACK message, the
| current window.
-----------------------------------------------------------------
Window-up Ack received and sender is allowed to either
to use the | Adjust down by 1
window has not advanced. |
-----------------------------------------------------------------
4 or more consecutive datagrams | Adjust up by 1
acknowledged (window length > 4) |
-----------------------------------------------------------------
1/2 Window length destination endpoint's Tag or more acked | Adjust up by 1
(window length <=4) |
-----------------------------------------------------------------

5.2 Send Timer Back-off at Re-transmission

Whenever a T3-send timer expires, the endpoint shall re-transmit fill the
un-acked Verification Tag
field with 0.

When receiving an SCTP datagram (except for INIT and SHUTDOWN ACK),
the receiver MUST ensure that has the highest TSN Send value and re-start in the
T3-send timer, unless:

A) If Verification Tag field
of the current window length is reached, a Window-up received message shall
be sent out (see section 5.1), or

B) matches its own Tag. If the current window length is values do not reached and there is still user
data pending for transmission, a new datagram with user data shall
be sent out and T3-send timer shall be restarted.

When the T3-send timer is re-started at a retransmission,
match, the
following back-off rules receiver shall be applied to determine the value of
the new timer:

1. TL3-value = TL3-value * 2

2. T3-send = TL3-value + network-RTT

where, TL3-value is the protocol variable keeping silently discard the previous and
current T3-send timer base value, datagram and the network-RTT is the current
RTT measurement shall NOT
process it.

The receiver of a SHUTDOWN ACK message shall accept the destination IP address message if the re-transmission
Verification Tag field is filled with correct Tag or 0x0.

7.5 RTT/RTO Measurement

[Editor's Note: text to be sent to.

Note: the T3-send timer base value shall added]

8. Termination of Association

All existing associations should be restored to its default
value 'TL3-default' terminated when a datagram is received from the peer
endpoint.

The total number of consecutive re-transmissions to all destination IP
addresses in an endpoint exits
from service. An association shall can be recorded. If this value exceeds
the limit defined in 'Max.Retransmit', the sending terminated by either close or
shutdown.

8.1 Close of an Association

When an endpoint decides to close down an association, it shall
consider send
an ABORT message to its peer endpoint.

No acknowledgment is required for ABORT message. When the peer
endpoint unreachable and shall stop transmitting any
more data to it. The sending endpoint MAY receives the Abort, after checking the Verification Tag,
the peer shall remove the association from its record, and shall
report the failure termination to the its upper layer, including layer.

8.2 Shutdown of an Association

An endpoint in an association may decide to gracefully shutdown the
association. This will guarantee that all outstanding datagrams in its out-bound buffer which
have not been acknowledged. Whenever a datagram is received from a
peer endpoint
the total number peer of retransmissions shall be cleared.

Stewart, et al [Page 24]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

6. Network Management

6.1 Failure Detection in Redundant Networks

When the peer endpoint is multi-homed, shutdown initiator be delivered before the re-transmission of association
terminates.

The initiator shall send a
datagram should be attempted SHUTDOWN message to the destination IP address specified
in the MDTP protocol variable 'last.good.intf'. The value peer of
'last.good.intf' is always updated to point to the source IP address
from which
association, and shall include the last datagram from the peer endpoint arrived.

The number of highest consecutive T3-send timeout events is also recorded in
a variable 'retran.count' for each destination IP address. This count
should be incremented when a T3-send time-out event occurs for that
destination IP address. Every time a datagram is TSN it has
received from a the peer
endpoint, in the receiving endpoint 'Highest Consecutive TSN ACK' field. It
shall reset to 0 the 'retran.count'
corresponding to then start the source IP address .

If T2-shutdown timer and enter the value in 'retran.count' exceeds half of Shutdown-SENT
state (if the value of timer expires, the
protocol parameter 'Max.Retransmit', initiator must re-send the destination IP address shall
be reported to SHUTDOWN
with the upper layer as out-of-service and shall be removed updated last TSN received from eligibility for rotation. When re-transmitting a datagram, the
re-transmission should use 'last.good.intf' as its peer). The sender of the preferred
destination IP address to which to re-transmit, unless 'last.good.intf'
points
SHUTDOWN message may also optionally include a SACK to indicate
any gaps by bundling both the destination IP address on which the original T3-send
time-out event occurred.

In SACK and SHUTDOWN message together.

Note the event that sender of a datagram is received from an IP address that has
been reported as out-of-service, shutdown should limit the 'retran.count' shall be cleared
as specified above, number of retransmissions
of the destination IP address shall be reported as
in-service shutdown message to the upper layer, and protocol parameter 'Max.Retransmits'.
If Max.Retransmits is exceeded the destination IP address shall be
considered valid for rotation.

Stewart, et al [Page 25]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

6.2 RTT Measurement

On occasions an endpoint of an association should destroy the TCB
and may need report the endpoint has unreachable to perform an RTT
measurement of the network (or one upper layer.

Upon the reception of the redundant networks) between
itself and its peer.

RTT-request SHUTDOWN, the peer shall enter the
Shutdown-received state, and RTT-ack messages shall be used to perform verify, by checking the RTT
measurement. In TSN ACK
field of the messages, two 32 bit long opaque integers message, that all its outstanding datagrams have been
received by the initiator.

If there are used still outstanding datagrams left, the peer shall mark
them for retransmission and start the retransmit procedure as defined
in Section 5.12.

While in Shutdown-SENT state, the control parameter field initiator shall immediately respond
to carry each inbound user datagram from the time value.

At peer with a SACK and restart
the request of its upper layer, an endpoint T2-shutdown timer.

If there is no more outstanding datagrams, the peer shall initiate an RTT
measurement by sending an RTT-request (to send a specific network if
redundant networks exist). The sender shall also place in Time value 1
SHUTDOWN ACK and Time value 2 the value then remove all record of the current time mark. association.

Upon the reception receipt of the SHUTDOWN ACK, the initiator shall stop the
T2-shutdown timer and remove all record of the association.

Note: that it should be the responsibility of this RTT-request message, the recipient shall
immediately respond with a RTT-ack initiator to assure
that all the sender (over the same
network outstanding datagrams on which its side have been resolved
before it initiates the RTT-request arrives shutdown procedure.

Note: an endpoint shall reject any new data request from its upper
layer if the recipient it is
multi-homed), with Shutdown-SENT or Shutdown-RECEIVED state until completion
of the time mark carried sequence.

Note: if an endpoint is in the original RTT-request
copied into a Shutdown-SENT state and receives an INIT
message from its own Time value fields.

Upon peer, it should discard the reception of this reply, INIT message and
retransmit the shutdown message. The sender shall use of the time mark INIT should respond
with a stand-alone SHUTDOWN ACK in an SCTP datagram with the reply RTT-ack
Verification Tag field of its common header set to calculate 0, and let the RTT (to
normal T1-init timer cause the specific destination
IP address if redundant networks exist) as defined in [4].

Endpoint A Endpoint Z
{RTT - Request Now=x.y}
RTT-request
[Time-value1=x,
Time-value2=y,
Seen=81] ----------------------->
/------- RTT-ack
/ [Time-value1=x,
/ Time-value2=y,
/ Seen=3]
(Endpoint A uses <----------/
x.y INIT message to calculate RTT)

6.3 Network Heart Beat

At be retransmitted and
thus restart the request of its upper layer, an endpoint association.

9. Interface with Upper Layer

The Upper Layer Protocols (ULP) shall enable heart beat request for services by passing
primitives to a specific peer with which it has an established association. SCTP and shall receive notifications from SCTP for
various events.

The RTT-request message defined primitives and notifications described in this section 2.2 shall should be
used as a guideline for implementing SCTP. The following functional
description of ULP interface primitives is, at best, fictional. We
must warn readers that different SCTP implementations may have
different ULP interfaces. However, all SCTPs must provide a certain
minimum set of services to guarantee that all SCTP implementations can
support the same protocol hierarchy. This section specifies the
functional interfaces required of all SCTP implementations.

Sections 9.1 and 9.2 model interface between SCTP and the Upper Layer
Protocols. Section 9.3 models interfaces to a Layer Management entity.
The Layer Management functions could be used implemented as part of the heart beat while the RTT-ack shall be used
upper layer itself or as the heart beat
response.

After having heart beat enabled, the endpoint shall transmit a heart
beat to that specific peer and start separate entity.

9.1 ULP-to-SCTP

The following sections functionally characterize a T5-heartBeat timer. ULP/SCTP interface.
The peer
shall immediately respond notation used is similar to the heart beat in the same manner as the
RTT measurement most procedure described or function calls in section 6.2. This response, as
well as the new RTT measurement, shall be stored by the endpoint.

Stewart, et al [Page 26]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

When the T5-heartBeat timer expires,
high level languages.

The ULP primitives described below specify the endpoint shall first check if basic functions the previous heart beat has been responded
SCTP must perform to (on the same network it
was sent in the case support inter-process communication. Individual
implementations must define their own exact format, and may provide
combinations or subsets of multi-homed hosts). If not, the destination IP basic functions in single calls.

A) Initialize

Format: INITIALIZE ([local port], or [eligible transport address list])
-> local SCTP instance name

This primitive allows SCTP to which the last heart beat was sent shall have the
'retran.count' incremented and checked following the rules described
in section 6.1. Then, the endpoint shall send another heart beat initialize its internal data structures
and
re-start the T5-heartBeat timer.

In the case where one or both allocate necessary resources for setting up its operation
environment. Note that once SCTP is initialized, ULP can communicate
directly with other endpoints are multi-homed, the sending
of Heart beats shall follow the network rotation rules outlined in
section 4.2.

If, before without re-invoking this primitive.

A local SCTP instance name will be returned to the expiration of T5-heartBeat timer, a datagram is
received ULP by the endpoint, the T5-heartBeat timer shall be stopped and
restarted.

The suggested interval for T5-heartBeat timer is 4000 ms, and SCTP.

Mandatory attributes:

None.

Optional attributes:

The following types of attributes may be
dynamically adjusted by adding passed along with
the current RTT measurement primitive:

o local port - UDP port number, if ULP wants it is
available.

7. Termination of Association

Before an endpoint terminates itself, it shall send an Abort message to each be specified;

o eliglible transport address list - A list of its peer endpoints in eliglible transport
addresses that the local SCTP endpoint should bind. By default
all existing associations. The Abort
shall transport interface cards should be sent without requiring an acknowledgment from used by the local SCTP
host if no list is given.

B) Associate

Format: ASSOCIATE(local SCTP instance name, destination addr info,
stream count [,eligible transport address list] [,timer info])
-> association id [,destination net list] [,outbound stream count]

This primitive allows the upper layer to initiate an association to a
specific peer endpoint. However, the sender of the Abort message MUST fill in the
peer's Init-Tag.

When the The peer endpoint receives the Abort, after verifying the Tag,
the peer shall remove the sender from its record, and optionally
report the termination be specified by one of
the sender to its upper layer. However if
the Tag sent with transport addresses which define the Abort message is incorrect, endpoint (see section 1.1).
If the peer must
silently discard local SCTP instance has not been initialized, the Abort message.

The following shows ASSOCIATE is
considered an example of the termination of Endpoint A:

Endpoint A
{App indicates termination}
Abort
[Tag-X] --------------------------------> to Endpoint X

Abort
[Tag-Y] --------------------------------> to Endpoint Y

Abort
[Tag-Z] --------------------------------> to Endpoint Z

Stewart, et al [Page 27]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

7.1 Graceful Shutdown error. The set of an Association

An endpoint in an association may decide to "graceful shutdown" the
association without completely closing it down. With graceful
shutdown, both endpoints shall remove any record and pending datagrams
associated with the association. Further communications between transport addresses specified in the
two endpoints can be resumed by going through a re-initialization
procedure (see section 3.5.4).

A Graceful Shutdown message
"eligible transport address list" shall be sent used has valid destinations
when sending to the peer endpoint endpoint. If this parameter is not specified,
the associate command will consider all of the
association, and transport addresses
returned by the peer shall send back an acknowledgment. Note
that it shall be INIT ACK message has valid.

An association id, which is a local handle to the responsibility SCTP association,
will be returned on successful establishment of the endpoint that sends the
Graceful Shutdown message association.
If SCTP is not able to assure that all open an SCTP association with the outstanding datagrams
from its side have been resolved before it initiates peer endpoint,
an error is returned.

Implementor's Note: If ASSOCIATE primitive is implemented as a blocking
function call, the graceful
shutdown procedure.

In ASSOCIATE primitive can return association parameters
in addition to the Graceful Shutdown message, association id upon successful establishment. If ASSOCIATE
primitive is implemented as a non-blocking call, only the sender association id
shall indicate be returned and association parameters shall be passed using the
highest TSN Seen it has received from
COMMUNICATION UP notification.

The association parameters shall include the peer, destination addresses of the
peer as well as the
Init-Tag outbound stream count.
One of the peer.

Upon transport address from the reception set of the Graceful Shutdown, the peer shall first
verify that Tag value contained in the Graceful Shutdown message is
valid. If the Tag is invalid, the message must destination addresses will
be silently discarded. used as default primary destination address for sending datagrams to this
peer. The peer then shall verify, returned "destination net list" can be used by checking the Seen numbers from ULP to
override the
Graceful Shutdown message, that all default primary destination transport address or to force sending a
datagram on a specific network.

Mandatory attributes:

o local SCTP instance name - obtained from the out-bound datagrams have
reached initialize operation.

o destination addr info - specified as one of the destination. Otherwise, transport addresses
of the peer shall re-transmit all
lost datagrams.

After sending the Graceful Shutdown, if the endpoint receives any new
user datagram it shall immediately respond with an Extended Data Ack
and re-start its T3-send timer.

The peer shall send a Graceful Shutdown Ack when all which the outstanding
datagrams are acknowledged, then start a T4-shutdown timer. The
endpoint, after receiving association is to be established.

o stream count - the Graceful Shutdown Ack, must also
validate number of streams the Tag value contained in ULP would like to open at the message. If it does not match
beginning of the Tag value association.

Optional attributes:

o eligible transport address list - a list of transport addresses
that unlocked the association, endpoint is allowed to use for sending datagrams to the message should be
silently discarded.

The following sequence shows an example
peer. By default, all transport addresses of Graceful Shutdown:

Endpoint A Endpoint X
{App indicates graceful shutdown}
Graceful Shutdown
[Tag-X, Seen=10] ---------------------> (all datagrams resolved)
(start T3-send timer) /-------- Graceful Shutdown Ack
/ [Tag-A]
/ (start T4-shutdown timer)
(cancel T3-send timer) <------/ ...
(clean-up the association) (T4-shutdown expires)
(clean-up peer are
available.

o timer info - Timer selection and its operation syntax -- to indicate
to SCTP an alternative timer the association)

Stewart, et al [Page 28]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

Both endpoints shall reject any new data request from their upper layers
while SCTP should use for its operation.

C) Terminate

Format: TERMINATE(association id)
-> result

Gracefully terminates an association. Any locally queued datagrams will
be delivered to the graceful shutdown procedure is in progress.

8. Stream Operations

8.1 Stream Initiation

An MDTP peer. The association between will be terminated only after
the two endpoints must peer acknowledges all the messages sent.
A success code will be established
before any stream operation.

Except for returned on successful termination of the global stream (i.e, stream 0) and
association. If attempting to terminate the pre-opened
streams (see section 3.1.1), association results in a stream
failure, an error code shall be initiated (opened) by returned.

Mandatory attributes:

o association id - local handle to the sender before SCTP association

Optional attributes:

None.

D) Abort

Format: ABORT(association id)
-> result

Ungracefully terminates an association. Any locally queued datagrams can will
be passed in that stream. When a
stream discarded and an ABORT message is no longer used, it shall be terminated (closed) by the
endpoint that opened sent to the stream. Moreover, both sides peer.
A success code will be returned on successful abortion of the
association. If attempting to abort the association results in a
failure, an error code shall be able to initiate or terminate streams
independently. Streams are unidirectional.

The sender initiates a stream by sending a Stream Initiation. In
addition returned.

Mandatory attributes:

o association id - local handle to specifying the Stream Identifier, SCTP association

Optional attributes:

None.

E) Send

Format: SEND(association id, buffer address, byte count
[,context] [,stream id] [,life time] [,destination transport address]
[,un-order flag] [,no-bundle flag] )

This is the sender must set main method to send datagrams via SCTP.

Mandatory attributes:

o association id - local handle to the
Init-Tag field of SCTP association

o buffer address - the Stream Initiation location where the payload to be transmitted is
stored;

o byte count - The size of the Tag value payload in number of octets;

Optional attributes:

o context - optional information that will be carried in the peer
endpoint.

The sender shall also attach
sending failure notification to the stream-specific data ULP if any (usually
provided by the upper layer), with transportation of
this datagram fails.

o stream id - to indicate which stream to send the Stream Initiation. Otherwise, data on. If not
specified, stream 0 will be used.

o life time - specifies the Size life time of Stream Info field shall the message. The message will not
be set sent by SCTP after the life time expires. This parameter can be used
to 0x0.

After sending out avoid efforts to transmit stale datagrams. SCTP notifies the Stream Initiation, ULP, if
the sender shall start a
T6-streamInit timer. If this timer expires, datagram cannot be initiated to transport (i.e. sent to the sender shall
re-transmit destination
via SCTP's send primitive) within the Stream Initiation. The value and adjustment rules life time variable.

o destination transport address - specified as one of
T6-streamInit timer is the same as that destination
transport addresses of the T3-send timer (see
sections 4.1.1 and 5.2).

Upon peer endpoint to which this message
should be sent. Whenever possible, SCTP should use this destination
transport address for sending the reception datagram, instead of the Stream Initiation, the peer must first
verify current
primary destination transport address.

o un-order flag - this flag, if present, indicates that the correct Tag value is carried in the Init-Tag field of user
would like the Stream Initiation. The peer must silently discard data delivered in an un-ordered fashion to the Stream
Initiation if
remote peer.

o no-bundle flag - Instructs SCTP not to bundle the tag value user data with
other outbound DATA chunks. Note: SCTP may still bundle even when
this flag is found incorrect.

Then, the peer shall respond immediately present, when faced with either a Stream
Initiation Ack if it chooses to establish network congestion.

F) Set Primary

Format: SETPRIMARY(association id, destination transport address)
-> result

Instructs the requested stream, or a
Stream Initiation Nack if it chooses local SCTP to reject use the request for reasons
such specified destination transport
address as lack of resources. primary destination address for sending datagrams.

The arrival result of the Stream Initiation Ack or Nack attempting this operation shall cause be returned. If the
sender to cancel its T6-streamInit timer.

The following example shows
specified destination transport address is not present in the opening of stream 5 by "A":

Endpoint A Endpoint Z
{App Initiates stream 5}
Stream Initiation
[Tag=Tag-Z,Strm=5] -------------\
(Start T6-streamInit timer) \
\------>
(Cancel T6-streamInit timer) <----------------- Stream Initiation Ack
[Strm=5]

8.2 Stream Termination

An endpoint
"destination transport address list" returned earlier in an associate
command or communication up notification, an error shall be allowed returned.

Mandatory attributes:

o association id - local handle to terminate any the SCTP association

o destination transport address - specified as one of the streams it
opened, by sending a Stream Termination to its peer. However,
stream 0 is not allowed to be terminated, and if an endpoint receives a
termination message for stream 0 it must silently discard transport
addresses of the message.

The same Tag verification process and timer rules peer endpoint, which should be used as primary
address for stream
initiation sending datagrams. This overrides the current primary
address information maintained by the local SCTP endpoint.

G) Receive

Format: RECEIVE(association id, buffer address, buffer size [,stream id])
-> byte count [,transport address] [,stream id]

This primitive shall be applied read the first datagram in the SCTP in-queue to stream termination.

Stewart, et al [Page 29]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

The peer shall immediately send a Stream Termination Ack
ULP, if there is one available, in response to the Stream Termination. specified buffer. The following example shows the termination size of stream 5 by "A":

Endpoint A Endpoint Z
{App closes stream 5}
Stream Termination
[Tag=Tag-Z,Strm=5] ---------------\
(Start T6-streamInit timer) \
\------>
(Cancel T6-streamInit timer) <------------------ Stream Termination Ack
[Strm=5]

Received datagrams associated with a terminated stream shall
the datagram read, in octets, will be
silently discarded. returned. It is up to may, depending on the endpoint to assure that all
outstanding user datagrams in
specific implementation, also return other information such as the stream are acknowledged before
sender's address, the stream termination.

8.3 Other Issues with Stream Operations

When an association id on which it is re-initialized (see section 3.5.4), all existing
streams within that association will be automatically terminated.

The receiver shall silently discard any received, whether there
are more datagrams associated with a
stream which has not yet been opened or has already been terminated.

9. Interface with Upper Layer

The upper layer protocols (ULP) shall request for services by passing
primitives to MDTP and shall receive notifications from MDTP available for
various events.

The primitives and notifications described in retrieval, etc. Depending upon the
implementation, if this section should be
used as a guideline for implementing MDTP.

A) Init.MDTP primitive

This primitive allows MDTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Note that once MDTP is initialized, ULP can communicate
directly with any other endpoints without re-invoking invoked when no datagram is available
the implementation should return an indication of this primitive. condition or should
block the invoking process until data does become available.

Mandatory attributes:

None.

Optional attributes:

The following types

o association id - local handle to the SCTP association

o buffer address - the memory location indicated by the ULP to store
the received datagram.

o buffer size - the maximum size of attributes may data to be passed along with
the primitive:

Stewart, et al [Page 30]

Internet Draft Multi-network Datagram Transmission Protocol June 1999 received, in octets.

Optional attributes:

o Timer selection and its operation syntax -- stream id - to indicate which stream to MDTP
an alternative timer receive the MDTP should use for its operation.
o Initial MDTP operation mode; data on.

o IP port number, if ULP wants it to be specified;

B) Init.Association stream sequence number - the stream sequence number assigned.

H) Status

Format: STATUS(association id) -> status data

This primitive allows shall return a data block containing the upper layer following
information:
receive window size,
send window size,
connection state,
number of buffers awaiting acknowledgement,
number of buffers pending receipt,
primary destination address,
round trip time on primary destination address,
retransmission time out value on primary destination address,
other destination addresses,
round trip times on other destination addresses.

Mandatory attributes:

o association id - local handle to initiate an the SCTP association

Optional attributes:

None.

I) Change Heartbeat

Format: CHANGEHEARTBEAT(association id, new state)
-> result

Instructs the local SCTP to a
specific peer endpoint. enable or disable heart beat on the
specified association.

The peer endpoint result of attempting this operation shall be specified by one of
the IP address/port pairs which define the endpoint (see section 1.1). returned.

Mandatory attributes:

o associationID association id - specified as one of the IP address/port pairs of
the peer endpoint with which local handle to the SCTP association is to be established.

Optional attributes:

o eligibleNetList new state - a list the new state of destination IP address/port pairs that heart beat for this association (either
enabled or disabled).

J) Request HeartBeat

Format: REQUESTHEARTBEAT(association id, transport address)

Instructs the peer endpoint is allowed local SCTP to use in its network rotation. By
default, all destination IP address/port pairs perform a HeartBeat on the peer are
available.

C) Term.Association

Terminating an association.

Mandatory attributes:

o associationID - specified as one
transport address of the IP address/port pairs given association. The results of the peer endpoint with which the association is to be terminated.

Optional attributes:

None.

D) Send.Data primitive

This is
HeartBeat should update the main method to send datagrams via MDTP. RTT information.

Mandatory attributes:

o data association id - This is the payload ULP wants local handle to transmit;
o size - The size of the payload in number of octets; SCTP association

o associationID transport address - One of the IP address/port pair transport address of the peer endpoint.
Note association
on which a heartbeat should be issued.

9.2 SCTP-to-ULP

It is assumed that the actual destination address sent operating system or application environment provides
a means for the SCTP to will asynchronously signal the ULP process. When SCTP
does signal an ULP process, certain information is passed to the ULP.

A) DATA ARRIVE notification

SCTP shall invoke this notification on the ULP when a datagram is
successfully received and ready for retrieval.

The following may be determined
by MDTP due optionally be passed with the notification:

o association id - local handle to the network rotation, unless SCTP association

o stream id - to indicate which stream the current mode
prohibits MDTP network rotation; in such data is received on.

B) SEND FAILURE notification

If a case datagram can not be delivered SCTP shall invoke this notification
on the datagram will ULP.

The following may be sent to optionally be passed with the IP address/port specified by associationID.

Optional attributes: notification:

o mode-flags data - This indicates a new MDTP operation mode, taking effect
immediately including the current datagram send;

Stewart, et al [Page 31]

Internet Draft Multi-network Datagram Transmission Protocol June 1999 location ULP can find the un-delivered datagram.

o context - optional information that will be carried in the
Send.Failure notification to the ULP if the transportation of associated with this datagram fails. (see
D in section 9.1).

o streamID association id - local handle to indicate which stream to send the data on. By
default, SCTP association

C) NETWORK STATUS CHANGE notification

When a destination transport address is marked down (e.g., when SCTP
detects a failure), or marked up (e.g., when SCTP detects a recovery),
SCTP shall invoke this notification on the global stream will ULP.

The following shall be used.

E) Receive.Data primitive passed with the notification:

o destination transport address - This primitive shall return indicates the first datagram in destination
transport address of the MDTP in-queue peer endpoint affected by the change;

o new-status - This indicates the new status.

D) COMMUNICATION UP notification

This notification is used when SCTP becomes ready to
ULP, if there send or receive
datagrams, or when a lost communication to an endpoint is one available. It may, depending on the specific
implementation, also return other informations such restored.

IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a blocking
function call, the sender's
address, whether there association parameters are more datagrams available for retrieval,
etc. The behavior is undefined if no datagram is available when this returned as a result of the
ASSOCIATE primitive itself. In that case, COMMUNICATION UP notification is invoked.

Mandatory attributes:
optional at the association initiator's side.

The following shall be passed with the notification:

o status - This indicates what type of event that has occurred;

o buffer association id - the memory location indicated by the ULP local handle to store the
received datagram.

Optional attributes: SCTP association

o associationID destination transport address list - the storage to be filled with one set of the IP
address/port pair transport addresses of the peer endpoint that sent this datagram.

F) Data.Arrive notification

MDTP shall invoke

o outbound stream count - the maximum number of streams allowed to be used
in this notification on association by the ULP when a datagram is
successfully received and ready for retrieval.

G) Send.Failure

E) COMMUNICATION LOST notification

If a datagram can not be delivered MDTP

When SCTP loses communication to an endpoint completely or detects
that the endpoint has performed an abort or graceful shutdown
operation, it shall invoke this notification on the ULP.

The following shall be passed with the notification:

o status - This indicates what type of event that has occurred;

o association id - local handle to the SCTP association

The following may be optionally be passed with the notification:

o data packets-enqueue - the The number and location ULP can find of un-sent datagrams
still in hold by SCTP;

o last-acked - the sequence number last acked by that peer endpoint;

o last-sent - the sequence number last sent to that peer endpoint;

o received-but-not-delivered - datagrams that were committed to transport but
not acknowledged.

9.3 Interfaces to Layer Management

This section models interfaces to a Layer Management (LM) entity, which
manages resources that have transport layer-wide impact. Layer Management
consists of primitives related to the management of SCTP performed as a
subset of systems management.

9.3.1 LM-to-SCTP

The following ULP-to-SCTP primitives from section 9.1 could be implemented
as part of the LM entity.

INITIALIZE
SETPRIMARY
ABORT
STATUS

9.3.2 SCTP-to-LM

The following SCTP-to-ULP primitives from section 9.2 could be implemented
as part of the LM entity.

SEND FAILURE notification
NETWORK STATUS CHANGE notification
COMMUNICATION UP notification
COMMUNICATION LOST notification

10. Security Considerations

10.1 Security Objectives

As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signalling messages for
telephony services, between two networked endpoints, SCTP has the un-delivered datagram.
o context
following security objectives.
- optional information associated with this datagram (see
D).
o associationID availability of reliable and timely data transport services
- One integrity of the IP address/port pair user-to-user information carried by SCTP

10.2 SCTP Responses To Potential Threats

It is clear that SCTP may potentially be used in a wide variety of
risk situations. It is important for operator(s) of the peer this
datagram was attempted SCTP Hosts
concerned to be sent to.

H) Network.Status.Change notification

When analyze their particular situations and decide on the
appropriate counter-measures.

Where the SCTP Host serves a endpoint-id group of users, it is marked down (e.g., when MDTP detects probably
operating as part of a failure), professionally managed corporate or marked up (e.g., when MDTP detects a recovery), MDTP shall
invoke service
provider network. It is reasonable to expect that this notification on management
includes an appropriate security policy framework. [RFC 2196, "Site
Security Handbook", B. Fraser Ed., September 1997] should be
consulted for guidance.

The case is more difficult where the ULP. SCTP Host is operated by a
private user. The following shall be passed service provider with whom that user has a
contractual arrangement SHOULD provide help to ensure that the notification:

o endpoint-id - This indicates the IP address/port
user's site is secure, ranging from advice on configuration through
downloaded scripts and security software.

10.2.1 Countering Insider Attacks

The principles of the
peer endpoint affected Site Security Handbook [ ] should be applied
to minimize the risk of theft of information or sabotage by
insiders. These include publication of security policies, control
of access at the change;
o new-status - This indicates physical, software, and network levels, and
separation of services.

10.2.2 Protecting against Data Corruption in the new status.

Stewart, et al [Page 32]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

I) Communication.Up notification

This notification Network

Where the risk of undetected errors in datagrams delivered by the
lower layer transport services is used when MDTP becomes ready considered to send or receive
datagrams, be too great,
additional checksum protection may be required. The question is
whether this is appropriately provided as an SCTP service because it
is needed by most potential users of SCTP, or when a lost communication whether instead it
should be provided by the SCTP user application. (The SCTP protocol
overhead, as opposed to an endpoint the signalling payload, is restored.

The following shall protected
adequately by the UDP checksum and measures taken in SCTP to prevent
replay attacks and masquerade.) In any event, the checksum must be passed with
specifically designed to ensure that it detects the notification:

o status - This indicates what type errors left
behind by the UDP checksum.

10.2.3 Protecting Confidentiality

In most cases, the risk of event that has occurred;
o associationID - An IP address/port breach of confidentiality applies to identify the peer endpoint;

J) Communication.Lost notification

When MDTP loses communication
signalling data payload, not to an endpoint completely the SCTP or detects lower-layer protocol
overheads. If that is true, encryption of the endpoint has SCTP user data only
may be considered. As with the supplementary checksum service, user
data encryption may be performed a abort either by the SCTP user application
or graceful shutdown
operation, as a service of SCTP itself. If it shall invoke this notification on is performed by SCTP, the ULP.

The following shall
user data must be passed with the notification:

o status - This indicates what type of event that has occurred;
o associationID - An IP address/port number to identify encrypted before any checksum is applied.

Particularly for mobile users, the peer
endpoint;

The following requirement for confidentiality
may be optionally passed with include the notification:

o packets-enqueue - The number masking of IP addresses and location ports. In this case
IPSEC ESP should be used instead of un-sent datagrams
still holding by MDTP;
o last-acked - application-level encryption.
Similarly, where other reasons prompt the sequence number last acked by that peer endpoint;
o last-sent - use of the sequence number last sent IPSEC ESP
service, application-level encryption is unnecessary. It will be up
to that peer endpoint;

K) Change.Network.Rotation primitive

When the upper layer wants to inform MDTP SCTP Host operators to make a specific network
eligible or ineligible configure the application
appropriately.

Regardless of which level performs the encryption, the IPSEC ISAKMP
service should be used for key management.

Operators should consult [RFC 2401, "Security Architecture for in network rotation, the upper layer will send
this primitive to MDTP.

Mandatory attributes:

o action - This indicates if
Internet Protocol", S. Kent, R. Atkinson, November 1998] for
information on the configuration of IPSEC services between hosts
with and without intervening firewalls.

10.2.4 Protecting against Blind Denial of Service Attacks

A blind attack is one where the network attacker is unable to be made eligible intercept or
ineligible for network rotation.
o network-id - This is
otherwise see the IP address/port content of the peer endpoint data flows passing to
be added or removed and from network rotation consideration.

L) Open.Stream primitive

This should be used by the upper layer to open
target SCTP Host where it is not a new outbound stream.

Mandatory attributes:

o associationID - One party to the association. Blind
denial of service attacks may take the IP address/port form of flooding, masquerade,
or improper monopolization of services.

10.2.4.1 Flooding

The objective of flooding is to identify cause loss of service and incorrect
behaviour at target systems through resource exhaustion,
interference with legitimate transactions, and exploitation of
buffer-related software bugs. Flooding may be directed either at
the peer
endpoint SCTP Host or at resources in the intervening IP Access Links or
the Internetwork. Where the latter entities are the target,
flooding will manifest itself as loss of network services, including
potentially the association to which breach of any firewalls in place.

In general, protection against flooding begins at the stream 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 be opened. An
association must have existed at completion of processing in progress over the time
acceptance of stream open.

Optional attributes:

o streamInfo new work
- identification and removal of duplicate or stale queued requests
for service.

Network equipment should be capable of generating an alarm and log
if a suspicious increase in traffic occurs. The upper layer log should use this field to pass any
stream-specific data to provide
information such as the other endpoint identity of the association.

M) Open.Stream.Succeed notification

This should be incoming link and source
address(es) used which will help the network or SCTP Host operator
to report take protective measures. Procedures should be in place for the successful opening
operator to act on such alarms if a clear pattern of an new outbound
stream.

Mandatory attributes:

o associationID - One 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 IP address/port responding SCTP Host until the
handshake is completed, and its use of a verification tag to identify prevent
insertion of extraneous messages into the peer
endpoint flow of an established
association.

10.2.4.2 Masquerade

Masquerade can be used to deny service in several ways:
- by tying up resources at the association target SCTP Host to which the outbound stream
impersonated host has been
successfully opened.

o streamID - The stream number of limited access. For example, the outbound stream assigned target host
may by
MDTP.

Optional attributes:

o streamInfo - policy permit a maximum of one SCTP association with the
impersonated SCTP Host. The streamInfo used for opening this outbound stream.

N) Open.Stream.Rejected notification

This reports masquerading attacker may attempt to
establish an association purporting to come from the ULP impersonated
host so that the open of an outbound stream is
rejected by the peer endpoint.

Mandatory attributes:

o associationID latter cannot do so when it requires it.
- One of by deliberately allowing the IP address/port impersonation to identify be detected,
thereby provoking counter-measures which cause the peer
endpoint impersonated host
to be locked out of the target SCTP Host
- by interfering with an established association by which inserting
extraneous content such as a SHUTDOWN request.

SCTP prevents masquerade through IP spoofing by use of the stream open four-way
startup handshake. Because the initial exchange is rejected.

Optional attributes:

o streamInfo - The info used in memoryless, no
lockout mechanism is triggered by masquerade attacks. SCTP protects
against insertion of extraneous messages into the failed attempt flow of an
established association by use of the stream
open.

O) Close.Stream notification

This should verification tag.

Logging of received INIT requests and abnormalities such as
unexpected INIT ACKs might be used considered as a way to report the successful closing detect patterns
of an outbound
stream.

Mandatory attributes:

o associationID - One hostile activity. However, the potential usefulness of such
logging must be weighed against the IP address/port increased SCTP startup
processing it implies, rendering the SCTP Host more vulnerable to identify
flooding attacks. Logging is pointless without the peer
endpoint establishment of
operating procedures to review and analyze the logs on a routine
basis.

10.2.4.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 association with which target
SCTP Host or of the stream is closed.
o streamID - The stream shared resources between the attacker and the
target host. Possible attacks include the opening of a large number
of associations between the closed stream.

P) Peer.Open.Stream notification

This notifies attacker's host and the ULP that a new inbound steam is opened by target, or
transfer of large volumes of information within a peer
endpoint.

Mandatory attributes:

o associationID - One legitimately-
established association.

Such attacks take advantage of policy deficiencies at the IP address/port target
SCTP Host. Defense begins with a contractual prohibition of
behaviour directed to identify the peer
endpoint denial of service to others. Policy limits
should be placed on the number of associations per adjoining SCTP
Host. SCTP user applications should be capable of detecting large
volumes of illegitimate or "no-op" messages within a given
association to which and either logging or terminating the stream is opened.
o streamID - association as a
result, based on local policy.

10.3 Protection against Fraud and Repudiation

The stream number objective of fraud is to obtain services without authorization
and specifically without paying for them. In order to achieve this
objective, the new inbound stream assigned
by attacker must induce the peer.

Optional attributes:

o streamInfo - The stream-specific Information passed from SCTP user application at the peer
endpoint.

Q) Peer.Close.Stream notification

This reports
target SCTP Host to provide the ULP the closing by desired service while accepting
invalid billing data or failing to collect it. Repudiation is a remote peer of an inbound
stream.

Mandatory attributes:

o associationID - One
related problem, since it may occur as a deliberate act of fraud or
simply because the IP address/port to identify the peer
endpoint 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 messages passing through a target SCTP association in real time.

The interception attack is countered by which the inbound stream confidentiality measures
discussed in section 10.2.3 above.

Section 10.2.4.2 describes how SCTP is closed.
o streamID - The stream number resistant to blind masquerade
attacks, as a result of the closed inbound stream.

Stewart, et al [Page 33]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

R) Close.Stream primitive

This shall be used by four-way startup handshake and the upper layer to close
validation tag. The validation tag and TSN together are protections
against blind replay attacks, where the replay is into an outbound stream.

Mandatory attributes:

o associationID - One of existing
association.

However, SCTP does not protect against man-in-the-middle attacks
where the IP address/port attacker is able to identify intercept and alter the peer
endpoint messages sent
and received in an association. Where a significant possibility of the association to which the outbound stream
such attacks is seen to be
closed.
o streamID - The stream identifier to identify exist, or where possible repudiation is an
issue, the use of the stream IPSEC AH service is recommended to be
closed (this ensure both
the integrity and the authenticity of the messages passed.

SCTP also provides no protection against attacks originating at or
beyond the SCTP Host and taking place within the context of an
existing association. Prevention of such attacks should be the number returned covered
by appropriate security policies at the Stream.Open
primitive on this stream).

10. host site, as discussed in
section 10.2.1.

11. IANA Consideration

[Editor's Note: text to be added]

12. Suggested MDTP SCTP Timer and Protocol Parameter Values

The following are suggested timer values for MDTP: SCTP:

T1-init Timer - 160 200 ms
T2-receive
T2-shutdown Timer - 20 300 ms
T3-send
T3-rxt Timer - 160 ms (TL3-default)
T4-shutdown Timer - 300 ms
T5-heartBeat timer - 4000 ms (TL5-default)
T6-streamInit timer - same as T3-send

The following protocol parameters are recommended:

Max.Outstanding.dg - 20 messages
Max.Retransmit

Max.Retransmits - 10 attempts
Max.Init.Retransmit - 8 attempts

11. Abbreviations

MDTP
Max.HeartBeat.Misses - Multi-network Datagram Transmission Protocol.

NAT 3 attempts
Max.retrans.at.once - Network Address Translation

RTT 2 datagrams
Valid.cookie.life - Round Trip Time

TSN 5 seconds

Protocol variables/counters:

'retrans.count' - Transport Sequence Number

ULP per association counter
'heartbeat.sent.count' - Upper Layer Protocol

12. per destination transport address counter

13. Acknowledgments

The authors wish to thank Brian Wyld, A. Sankar, Richard Band, Scott Bradner, Ram Dantu,
Matt Holdrege, Henry Houh, Gary Lehecka, Lyndon Ong, Greg Sidebottom, Lixia Zhang, Jarno Rajahalme,
Heinz Prantner, Matt Holdrege, Vern Paxson,
Kelvin Porter, Richard Band, Heinz Prantner, Jarno Rajahalme, A. Sankar, Greg
Sidebottom, Brian Wyld, and many others for their invaluable
comments.

13.

14. Authors' Addresses

Randall R. Stewart Tel: +1-847-632-7438
Cellular Infrastructure Group EMail: stewrtrs@cig.mot.com
Motorola, Inc.
1475 EMail: rstewar1@email.mot.com
1501 W. Shure Drive, #2C-6 #2315
Arlington Heights, IL 60004
USA

Stewart, et al [Page 34]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

Qiaobing Xie Tel: +1-847-632-3028
Cellular Infrastructure Group EMail: xieqb@cig.mot.com
Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA

Ken Morneau Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail:kmorneau@cisco.com
13615 Dulles Technology Drive
Herndon, VA. 20171
USA

Chip Sharp Tel: +1-919-851-2085 +1-919-472-3121
Cisco Systems Inc. EMail:chsharp@cisco.com
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA

Hanns Juergen Schwarzbauer Tel: +49-89-722-24236
SIEMENS AG
Hofmannstr. 51
81359 Munich, Munich
Germany
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de

Tom Taylor Tel: +1-613-736-0961
Nortel Networks EMail:taylor@nortelnetworks.com
1852 Lorraine Ave.
Ottawa
Ottawa, Ontario
Canada
K1H6Z8 K1H 6Z8

Ian Rytina Tel:
Ericsson Australia EMail:ian.rytina@ericsson.com
37/360 Elizabeth Street
Melbourne, Victoria 3000, 3000
Australia

14.

Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: kalla@research.telcordia.com
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA

Lixia Zhang Tel: +1-310-825-2695
UCLA Computer Science Department EMail: lixia@cs.ucla.edu
4531G Boelter Hall
Los Angeles, CA 90095-1596
USA

15. References

[Editor's Note: text to be updated]

[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences Institute,
September 1981.

[2] Postel, J., J. (ed.), "User Datagram Protocol", RFC 768,
USC/Information Sciences Institute, August 1980.

[3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, USC/
Information Sciences Institute, September 1981.

[4] Jacobson V., "Congestion Avoidance and Control", Proceedings of
SIGCOMM '88, pp 314-329, August 1988.

[5] Seth, T., etc. "Performance Requirements for Signaling in Internet
Telephony", Internet-Draft <draft-seth-sigtran-req-00.txt>, May 1999.

Stewart, et al [Page 35]

Internet Draft Multi-network Datagram Transmission Protocol June 1999

[6] Rytina, I., "Framework for Generic Common Signaling Transport
Protocol", draft-rytina-sigtran-generic-framework-00.txt>, Feb. 1999. Comer D., Stevens D., "Interworking with TCP/IP volume II Design
Implementation and Internals", Prentice-Hall, Inc 1994.

[7] Ashworth, J., "The Naming of Hosts", RFC 2100, April 1997.

[8] Braden, R., R. (ed.), "Requirements for Internet hosts - Application and
Support", Hosts --
Communication Layers", RFC 1122, October 1989.

[9] Eastlake 3rd, D., Crocker, S., Braden, R. (ed.), "Requirements for Internet Hosts --
application and Schiller, J., support", RFC 1123, October 1989.

[10] Baker, F. "Requirements for IP Version 4 Routers", RFC1812, June 1995

[11] Eastlake , D. (ed.), "Randomness Recommendations for Security",
RFC 1750, December 1994.

[10]

[12] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC1948, May 1996

[11] 1996.

[13] ITU-T Recommendation Q.703 "Q.703 - Signaling link", July 1996.

[14] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
Control", RFC 2581, April 1999.

[15] Rivest, R., "The MD5 Message-Digest Algorithm", August 1999,
RFC 1321.

This Internet Draft expires in 6 months from June September 1999.

Stewart, et al [Page 36]

----