draft-ietf-tsvwg-prsctp-02.txt   draft-ietf-tsvwg-prsctp-03.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: May 26, 2004 Cisco Systems, Inc. Expires: July 26, 2004 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
P. Conrad P. Conrad
University of Delaware University of Delaware
November 26, 2003 January 26, 2004
SCTP Partial Reliability Extension SCTP Partial Reliability Extension
draft-ietf-tsvwg-prsctp-02.txt draft-ietf-tsvwg-prsctp-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 26, 2004. This Internet-Draft will expire on July 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo describes an extension to the Stream Control Transmission This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) RFC2960 [3] that allows an SCTP endpoint to signal to Protocol (SCTP) RFC2960 [2] that allows an SCTP endpoint to signal to
its peer that it should move the cumulative ack point forward. When its peer that it should move the cumulative ack point forward. When
both sides of an SCTP association support this extension, it can be both sides of an SCTP association support this extension, it can be
used by an SCTP implementation to provide partially reliable data used by an SCTP implementation to provide partially reliable data
transmission service to an upper layer protocol. This memo describes transmission service to an upper layer protocol. This memo describes
(1) the protocol extensions, which consist of a new parameter for (1) the protocol extensions, which consist of a new parameter for
INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example
partially reliable service that can be provided to the upper layer partially reliable service that can be provided to the upper layer
via this mechanism. via this mechanism.
Table of Contents Table of Contents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) . . . 6 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) . . . 6
3.3 Negotiation of Forward-TSN-Supported parameter . . . . . . . 7 3.3 Negotiation of Forward-TSN-Supported parameter . . . . . . . 7
3.3.1 Sending Forward-TSN-Supported param in INIT . . . . . . . . 7 3.3.1 Sending Forward-TSN-Supported param in INIT . . . . . . . . 7
3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or 3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or
INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 7 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param . . . . 8 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param . . . . 8
3.4 Definition of "abandoned" in the context of PR-SCTP . . . . 8 3.4 Definition of "abandoned" in the context of PR-SCTP . . . . 8
3.5 Sender Side Implementation of PR-SCTP . . . . . . . . . . . 9 3.5 Sender Side Implementation of PR-SCTP . . . . . . . . . . . 9
3.6 Receiver Side Implementation of PR-SCTP . . . . . . . . . . 12 3.6 Receiver Side Implementation of PR-SCTP . . . . . . . . . . 12
4. Services provided by PR-SCTP to the upper layer . . . . . . 14 4. Services provided by PR-SCTP to the upper layer . . . . . . 14
4.1 PR-SCTP Service Definition for "timed reliability" . . . . . 15 4.1 PR-SCTP Service Definition for "timed reliability" . . . . . 14
4.2 PR-SCTP Association Establishment . . . . . . . . . . . . . 16 4.2 PR-SCTP Association Establishment . . . . . . . . . . . . . 16
4.3 Guidelines for defining other PR-SCTP Services . . . . . . . 17 4.3 Guidelines for defining other PR-SCTP Services . . . . . . . 17
4.4 Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Variables . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Variables . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
Normative references . . . . . . . . . . . . . . . . . . . . 19 Normative references . . . . . . . . . . . . . . . . . . . . 19
Informational References . . . . . . . . . . . . . . . . . . 19 Informational References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 22
1. Introduction 1. Introduction
This memo describes an extension to the Stream Control Transmission This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) RFC2960 [3] that allows an SCTP sender to signal to Protocol (SCTP) RFC2960 [2] that allows an SCTP sender to signal to
its peer that it should no longer expect to receive one or more DATA its peer that it should no longer expect to receive one or more DATA
chunks. chunks.
1.1 Overview of Protocol Extensions 1.1 Overview of Protocol Extensions
The protocol extension described in this document consists of two new The protocol extension described in this document consists of two new
elements: elements:
1. a single new parameter in the INIT/INIT-ACK exchange that 1. a single new parameter in the INIT/INIT-ACK exchange that
indicates whether the endpoint supports the extension indicates whether the endpoint supports the extension
2. a single new chunk type, FORWARD TSN, that indicates that the 2. a single new chunk type, FORWARD TSN, that indicates that the
receiver should move its cumulative ack point forward (possibly receiver should move its cumulative ack point forward (possibly
skipping past one or more DATA chunks that may not yet have been skipping past one or more DATA chunks that may not yet have been
received and/or acknowledged.) received and/or acknowledged.)
1.2 Overview of New Services Provided to the Upper Layer 1.2 Overview of New Services Provided to the Upper Layer
When this extension is supported by both sides of an SCTP When this extension is supported by both sides of an SCTP
association, it can be used to provide partially reliable transport association, it can be used to provide partially reliable transport
service over an SCTP association. We define partially reliable service over an SCTP association. We define partially reliable
skipping to change at page 4, line 30 skipping to change at page 4, line 24
IETF so that the designers of IETF application layer protocols can IETF so that the designers of IETF application layer protocols can
match the requirements of their upper layer protocols to standard match the requirements of their upper layer protocols to standard
service definitions provided by a particular SCTP implementation. service definitions provided by a particular SCTP implementation.
One such definition, "timed reliability" is included in this One such definition, "timed reliability" is included in this
document. Given the extensions proposed in this document, other document. Given the extensions proposed in this document, other
definitions may be standardized as the need arises without further definitions may be standardized as the need arises without further
changes to the on-the-wire protocol. changes to the on-the-wire protocol.
1.3 Benefits of PR-SCTP 1.3 Benefits of PR-SCTP
Hereafter, we use the notation "PR-SCTP" to refer to the SCTP Hereafter, we use the notation "Partial Reliable Stream Control
protocol extended as defined in this document. Transmission Protocol (PR-SCTP)" to refer to the SCTP protocol
extended as defined in this document.
The following are some of the advantages for integrating partially The following are some of the advantages for integrating partially
reliable data service into SCTP, i.e., benefits of PR-SCTP: reliable data service into SCTP, i.e., benefits of PR-SCTP:
1. Some application layer protocols may benefit from being able to 1. Some application layer protocols may benefit from being able to
use a single SCTP association to carry both reliable content, -- use a single SCTP association to carry both reliable content, --
such as text pages, billing and accounting information, setup such as text pages, billing and accounting information, setup
signaling -- and unreliable content, e.g. state that is highly signaling -- and unreliable content, e.g. state that is highly
sensitive to timeliness, where generating a new packet is more sensitive to timeliness, where generating a new packet is more
advantageous than transmitting an old one [4]. advantageous than transmitting an old one [3].
2. Partially reliable data traffic carried by PR-SCTP will enjoy the 2. Partially reliable data traffic carried by PR-SCTP will enjoy the
same communication failure detection and protection capabilities same communication failure detection and protection capabilities
as the normal reliable SCTP data traffic does. This includes the as the normal reliable SCTP data traffic does. This includes the
ability to: - quickly detect a failed destination address; - ability to: - quickly detect a failed destination address; -
fail-over to an alternate destination address, and; - be notified fail-over to an alternate destination address, and; - be notified
if the data receiver becomes unreachable. if the data receiver becomes unreachable.
3. In addition to providing unordered unreliable data transfer as 3. In addition to providing unordered unreliable data transfer as
UDP does, PR-SCTP can provide ordered unreliable data transfer UDP does, PR-SCTP can provide ordered unreliable data transfer
service. service.
4. PR-SCTP employs the same congestion control and congestion 4. PR-SCTP employs the same congestion control and congestion
avoidance for all data traffic, whether reliable or partially avoidance for all data traffic, whether reliable or partially
reliable - this is very desirable since SCTP enforces reliable - this is very desirable since SCTP enforces
TCP-friendliness (unlike UDP.) TCP-friendliness (unlike UDP.)
5. Because of the chunk bundling function of SCTP, reliable and 5. Because of the chunk bundling function of SCTP, reliable and
unreliable messages can be multiplexed over a single PR-SCTP unreliable messages can be multiplexed over a single PR-SCTP
association. Therefore, the number of IP datagrams (and hence association. Therefore, the number of IP datagrams (and hence
the network overhead) can be reduced versus having to send these the network overhead) can be reduced versus having to send these
different types of data using separate protocols. Additionally, different types of data using separate protocols. Additionally,
this multiplexing allows for port savings versus using different this multiplexing allows for port savings versus using different
ports for reliable and unreliable connections. ports for reliable and unreliable connections.
2. Conventions 2. Conventions
skipping to change at page 5, line 23 skipping to change at page 5, line 15
the network overhead) can be reduced versus having to send these the network overhead) can be reduced versus having to send these
different types of data using separate protocols. Additionally, different types of data using separate protocols. Additionally,
this multiplexing allows for port savings versus using different this multiplexing allows for port savings versus using different
ports for reliable and unreliable connections. ports for reliable and unreliable connections.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [1].
Comparisons and arithmetic on TSNs are governed by the rules in Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are
Section 1.6 of RFC2960 [3]. governed by the rules in Section 1.6 of RFC2960 [2].
3. Protocol Changes to support PR-SCTP 3. Protocol Changes to support PR-SCTP
3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK 3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK
The following new OPTIONAL parameter is added to the INIT and INIT The following new OPTIONAL parameter is added to the INIT and INIT
ACK chunks. ACK chunks.
Parameter Name Status Type Value Parameter Name Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Forward-TSN-Suppored OPTIONAL 49152 (0xC000) Forward-TSN-Suppored OPTIONAL 49152 (0xC000)
At the initialization of the association, the sender of the INIT or At the initialization of the association, the sender of the INIT or
INIT ACK chunk shall include this OPTIONAL parameter to inform its INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer
peer that it is able to support the Forward TSN chunk. The format of that it is able to support the Forward TSN chunk (see Section 3.3 for
this parameter is defined as follows: further details). The format of this parameter is defined as follows:
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 49152 | Parameter Length = 4 | | Parameter Type = 49152 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int Type: 16 bit u_int
49152, indicating Forward-TSN-Supported parameter 49152, indicating Forward-TSN-Supported parameter
Length: 16 bit u_int Length: 16 bit u_int
Indicates the size of the parameter i.e., 4. Indicates the size of the parameter i.e., 4.
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
The following new chunk type is defined: The following new chunk type is defined:
Chunk Type Chunk Name Chunk Type Chunk Name
------------------------------------------------------ ------------------------------------------------------
skipping to change at page 7, line 23 skipping to change at page 7, line 18
to enable delivery of any stranded TSN's that remain on the stream to enable delivery of any stranded TSN's that remain on the stream
re-ordering queues. This field MUST NOT report TSN's corresponding re-ordering queues. This field MUST NOT report TSN's corresponding
to DATA chunk that are marked as unordered. For ordered DATA to DATA chunk that are marked as unordered. For ordered DATA
chunks this field MUST be filled in. chunks this field MUST be filled in.
3.3 Negotiation of Forward-TSN-Supported parameter 3.3 Negotiation of Forward-TSN-Supported parameter
3.3.1 Sending Forward-TSN-Supported param in INIT 3.3.1 Sending Forward-TSN-Supported param in INIT
If an SCTP endpoint supports the FORWARD TSN chunk, then any time it If an SCTP endpoint supports the FORWARD TSN chunk, then any time it
sends an INIT during association establishment, it SHOULD include the sends an INIT during association establishment, it MAY include the
Forward-TSN-supported parameter in the INIT chunk to indicate this Forward-TSN-supported parameter in the INIT chunk to indicate this
fact to its peer. fact to its peer.
Note that if the endpoint chooses NOT to include the parameter, then
at no time during the life of the association can it send or process
a FORWARD TSN. It MUST instead act as if it does NOT support the
FORWARD TSN chunk returning an ERROR to the peer upon receipt of any
FORWARD TSN.
3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK 3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK
When a receiver of an INIT detects a Forward-TSN-Supported parameter, When a receiver of an INIT detects a Forward-TSN-Supported parameter,
and does not support the Forward-TSN chunk type, the receiver SHOULD and does not support the Forward-TSN chunk type, the receiver MUST
treat this parameter as an invalid or unrecognized parameter and follow the rules defined in Section 3.3.3 of RFC2960 [2].
respond to the data sender with an unrecognized parameter in the
INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
[3].
When a receiver of an INIT-ACK detects a Forward-TSN-Supported When a receiver of an INIT-ACK detects a Forward-TSN-Supported
parameter, and does not support the Forward-TSN chunk type, the parameter, and does not support the Forward-TSN chunk type, the
receiver SHOULD treat this parameter as an invalid or unrecognized receiver MUST follow the rules defined in Section 3.3.3 of RFC2960
parameter and respond to the data sender with an unrecognized [2].
parameter error, following the rules defined in Section 3.3.3 of
RFC2960 [3]. This error SHOULD be reported in an ERROR chunk bundled
with the COOKIE-ECHO.
When a receiver of an INIT detects a Forward-TSN-Supported parameter, When a receiver of an INIT detects a Forward-TSN-Supported parameter,
and does support the Forward-TSN chunk type, the receiver SHOULD and does support the Forward-TSN chunk type, the receiver MAY respond
respond with a Forward-TSN-supported parameter in the INIT-ACK chunk. with a Forward-TSN-supported parameter in the INIT-ACK chunk.
Note that if the endpoint chooses NOT to include the parameter, then
at no time during the life of the association can it send or process
a FORWARD TSN. It MUST instead act as if it does NOT support the
FORWARD TSN chunk returning an ERROR to the peer upon receipt of any
FORWARD TSN.
When an endpoint that supports the FORWARD TSN chunk receives an INIT When an endpoint that supports the FORWARD TSN chunk receives an INIT
that does not contain the Forward-TSN-Supported Parameter, that that does not contain the Forward-TSN-Supported Parameter, that
endpoint: endpoint:
o MAY include the Forward-TSN-Supported parameter in the INIT-ACK, o MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
o SHOULD record the fact that the peer does not support the FORWARD o SHOULD record the fact that the peer does not support the FORWARD
TSN chunk, TSN chunk,
o MUST NOT send a FORWARD TSN chunk at any time during the o MUST NOT send a FORWARD TSN chunk at any time during the
associations life, associations life,
o SHOULD inform the upper layer, if the upper layer has requested o SHOULD inform the upper layer, if the upper layer has requested
such notification. such notification.
3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param
When an SCTP endpoint that desires to use the FORWARD TSN chunk When an SCTP endpoint that desires to use the FORWARD TSN chunk
feature for partially reliable data transfer receives an operational feature for partially reliable data transfer receives an operational
error from the remote endpoint (either bundled with the COOKIE or as error from the remote endpoint (either bundled with the COOKIE or as
an unrecognized parameter in the INIT-ACK), indicating that the an unrecognized parameter in the INIT-ACK), indicating that the
remote endpoint does not recognize the Forward-TSN-Supported remote endpoint does not recognize the Forward-TSN-Supported
skipping to change at page 9, line 23 skipping to change at page 9, line 16
are included in Section 3.5. are included in Section 3.5.
3.5 Sender Side Implementation of PR-SCTP 3.5 Sender Side Implementation of PR-SCTP
The sender side implementation of PR-SCTP is identical to that of the The sender side implementation of PR-SCTP is identical to that of the
base SCTP protocol, except for: base SCTP protocol, except for:
o actions a sending side PR-SCTP implementation must take when a TSN o actions a sending side PR-SCTP implementation must take when a TSN
is "abandoned" (as per the rules of whatever PR-SCTP service is "abandoned" (as per the rules of whatever PR-SCTP service
definition is in effect) definition is in effect)
o special actions that a PR-SCTP implementation must take upon o special actions that a PR-SCTP implementation must take upon
receipt of SACK receipt of SACK
o rules governing generation of FORWARD TSN chunks. o rules governing generation of FORWARD TSN chunks.
In detail, these exceptions are as follows: In detail, these exceptions are as follows:
A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer
to track a theoretical cumulative TSN point of the peer (Note, to track a theoretical cumulative TSN point of the peer (Note,
this is a _new_ protocol variable and its value is NOT necessarily this is a _new_ protocol variable and its value is NOT necessarily
the same as the SCTP "Cumulative TSN Ack Point" as defined in the same as the SCTP "Cumulative TSN Ack Point" as defined in
Section 1.4 of RFC2960 [3]) and discussed throughout that Section 1.4 of RFC2960 [2]) and discussed throughout that
document. document.
A2) From time to time, as governed by the rules of a particular A2) From time to time, as governed by the rules of a particular
PR-SCTP service definition (see Section 4), the SCTP data sender PR-SCTP service definition (see Section 4), the SCTP data sender
may make a determination that a particular data chunk that has may make a determination that a particular data chunk that has
already been assigned a TSN SHOULD be "abandoned". already been assigned a TSN SHOULD be "abandoned".
When a data chunk is "abandoned", the sender MUST treat the data When a data chunk is "abandoned", the sender MUST treat the data
chunk as being finally acked and no longer outstanding. chunk as being finally acked and no longer outstanding.
The sender MUST NOT credit an "abandoned" data chunk to the The sender MUST NOT credit an "abandoned" data chunk to the
partial_bytes_acked as defined in Section 7.2.2 of RFC2960 [3], partial_bytes_acked as defined in Section 7.2.2 of RFC2960 [2],
and MUST NOT advance the cwnd based on this "abandoned" data and MUST NOT advance the cwnd based on this "abandoned" data
chunk. chunk.
A3) When a TSN is "abandoned", if it is part of a fragmented message, A3) When a TSN is "abandoned", if it is part of a fragmented message,
all other TSN's within that fragmented message MUST be abandoned all other TSN's within that fragmented message MUST be abandoned
at the same time. at the same time.
A4) Whenever the data sender receives a SACK from the data receiver, A4) Whenever the data sender receives a SACK from the data receiver,
it MUST first process the SACK using the normal procedures as it MUST first process the SACK using the normal procedures as
defined in Section 6.2.1 of RFC2960 [3]. defined in Section 6.2.1 of RFC2960 [2].
The data sender MUST then perform the following additional steps : The data sender MUST then perform the following additional steps :
C1) Let SackCumAck be the Cumulative TSN ACK carried in the C1) Let SackCumAck be the Cumulative TSN ACK carried in the
received SACK. received SACK.
If (Advanced.Peer.Ack.Point < SackCumAck), then update If (Advanced.Peer.Ack.Point < SackCumAck), then update
Advanced.Peer.Ack.Point to be equal to SackCumAck. Advanced.Peer.Ack.Point to be equal to SackCumAck.
C2) Try to further advance the "Advanced.Peer.Ack.Point" locally, C2) Try to further advance the "Advanced.Peer.Ack.Point" locally,
that is, to move "Advanced.Peer.Ack.Point" up as long as the that is, to move "Advanced.Peer.Ack.Point" up as long as the
chunk next in the out-queue space is marked as "abandoned" as chunk next in the out-queue space is marked as "abandoned" as
shown in the following example: shown in the following example:
Assuming that a SACK arrived with the Cumulative TSN ACK = Assuming that a SACK arrived with the Cumulative TSN ACK =
102 and the Advanced.Peer.Ack.Point is updated to this 102 and the Advanced.Peer.Ack.Point is updated to this
value: value:
out-queue at the end of ==> out-queue after Adv.Ack.Point out-queue at the end of ==> out-queue after Adv.Ack.Point
skipping to change at page 11, line 4 skipping to change at page 10, line 32
... ... ... ...
Adv.Ack.Pt-> 102 acked 102 acked Adv.Ack.Pt-> 102 acked 102 acked
103 abandoned 103 abandoned 103 abandoned 103 abandoned
104 abandoned Adv.Ack.P-> 104 abandoned 104 abandoned Adv.Ack.P-> 104 abandoned
105 105 105 105
106 acked 106 acked 106 acked 106 acked
... ... ... ...
In this example, the data sender successfully advanced the In this example, the data sender successfully advanced the
"Advanced.Peer.Ack.Point" from 102 to 104 locally. "Advanced.Peer.Ack.Point" from 102 to 104 locally.
C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
greater than the Cumulative TSN ACK carried in the received greater than the Cumulative TSN ACK carried in the received
SACK, the data sender MUST send the data receiver a FORWARD TSN SACK, the data sender MUST send the data receiver a FORWARD TSN
chunk containing the latest value of the chunk containing the latest value of the
"Advanced.Peer.Ack.Point". "Advanced.Peer.Ack.Point". Note that the sender MAY delay the
sending of a FORWARD TSN as defined in rule F2 below.
IMPLEMENTATION NOTE: It is an implemenation decision as to IMPLEMENTATION NOTE: It is an implemenation decision as to
which destination address is to be sent to, the only which destination address is to be sent to, the only
restriction being that the address MUST be one that is restriction being that the address MUST be one that is
CONFIRMED. CONFIRMED.
C4) For each "abandoned" TSN the sender of the FORWARD TSN MUST C4) For each "abandoned" TSN the sender of the FORWARD TSN MUST
determine if the chunk has a valid stream and sequence number determine if the chunk has a valid stream and sequence number
(i.e., it was ordered). If the chunk has a valid stream and (i.e., it was ordered). If the chunk has a valid stream and
sequence number the sender MUST include the stream and sequence sequence number the sender MUST include the stream and sequence
number in the FORWARD TSN. This information will enable the number in the FORWARD TSN. This information will enable the
receiver to easily find any stranded TSN's waiting on stream receiver to easily find any stranded TSN's waiting on stream
reorder queues. Each stream SHOULD only be reported once; this reorder queues. Each stream SHOULD only be reported once; this
means that if multiple abandoned messages occur in the same means that if multiple abandoned messages occur in the same
stream then only the highest abandoned stream sequence number stream then only the highest abandoned stream sequence number
is reported. If the total size of the FORWARD TSN does NOT fit is reported. If the total size of the FORWARD TSN does NOT fit
skipping to change at page 12, line 12 skipping to change at page 11, line 37
IMPLEMENTATION NOTE: An implementation may wish to limit the IMPLEMENTATION NOTE: An implementation may wish to limit the
number of duplicate FORWARD TSN chunks it sends by either only number of duplicate FORWARD TSN chunks it sends by either only
sending a duplicate FORWARD TSN every other SACK or waiting a full sending a duplicate FORWARD TSN every other SACK or waiting a full
RTT before sending a duplicate FORWARD TSN. RTT before sending a duplicate FORWARD TSN.
IMPLEMENTATION NOTE: An implementation may allow the maximum delay IMPLEMENTATION NOTE: An implementation may allow the maximum delay
for generating a FORWARD TSN to be configured either statically or for generating a FORWARD TSN to be configured either statically or
dynamically in order to meet the specific timing requirements of dynamically in order to meet the specific timing requirements of
the protocol being carried, but see the next rule: the protocol being carried, but see the next rule:
F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT
exceed 200ms and MUST NOT exceed 500ms. In other words an exceed 200ms and MUST NOT exceed 500ms. In other words an
implementation MAY lower this value below 500ms but MUST NOT raise implementation MAY lower this value below 500ms but MUST NOT raise
it above 500ms. it above 500ms.
NOTE: Delaying the sending of FORWARD TSN chunks may cause delays NOTE: Delaying the sending of FORWARD TSN chunks may cause delays
in the receiver's ability to deliver other data being held at the in the receiver's ability to deliver other data being held at the
receiver for re-ordering. The values of 200ms and 500ms match the receiver for re-ordering. The values of 200ms and 500ms match the
required values for the delayed acknowledgement in RFC2960 [3] required values for the delayed acknowledgement in RFC2960 [2]
since delaying a FORWARD TSN has the same consequences but in the since delaying a FORWARD TSN has the same consequences but in the
reverse direction. reverse direction.
F4) The detection criterion for out-of-order SACKs MUST remain the F4) The detection criterion for out-of-order SACKs MUST remain the
same as stated in RFC2960, that is, a SACK is only considered same as stated in RFC2960, that is, a SACK is only considered
out-of-order if the Cumulative TSN ACK carried in the SACK is out-of-order if the Cumulative TSN ACK carried in the SACK is
earlier than that of the previous received SACK (i.e., the earlier than that of the previous received SACK (i.e., the
comparison MUST NOT be made against "Advanced.Peer.Ack.Point"). comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
F5) If the decision to "abandon" a chunk is made, no matter how such F5) If the decision to "abandon" a chunk is made, no matter how such
a decision is made, the appropriate congestion adjustment MUST be a decision is made, the appropriate congestion adjustment MUST be
made as specified in RFC2960 if the chunk would have been marked made as specified in RFC2960 if the chunk would have been marked
for retransmission later (e.g. either by T3-Timeout or by Fast for retransmission later (e.g. either by T3-Timeout or by Fast
Retransmit). Retransmit).
3.6 Receiver Side Implementation of PR-SCTP 3.6 Receiver Side Implementation of PR-SCTP
The receiver side implementation of PR-SCTP at an SCTP endpoint A is The receiver side implementation of PR-SCTP at an SCTP endpoint A is
capable of supporting any PR-SCTP service definition used by the capable of supporting any PR-SCTP service definition used by the
skipping to change at page 13, line 5 skipping to change at page 12, line 26
supported by the sending side functionality of host A. All that is supported by the sending side functionality of host A. All that is
necessary is that the receiving side correctly handle the necessary is that the receiving side correctly handle the
Forward-TSN-Supported parameter as specified in Section 3.3, and Forward-TSN-Supported parameter as specified in Section 3.3, and
correctly handle the receipt of FORWARD TSN chunks as specified correctly handle the receipt of FORWARD TSN chunks as specified
below. below.
DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA
chunk arrival at a base protocol SCTP receiver---that is, the chunk arrival at a base protocol SCTP receiver---that is, the
receiver MUST perform the same TSN handling including duplicate receiver MUST perform the same TSN handling including duplicate
detection, gap detection, SACK generation, cumulative TSN detection, gap detection, SACK generation, cumulative TSN
advancement, etc. as defined in RFC2960 [3]---with the following advancement, etc. as defined in RFC2960 [2]---with the following
exceptions and additions. exceptions and additions.
When a FORWARD TSN chunk arrives, the data receiver MUST first update When a FORWARD TSN chunk arrives, the data receiver MUST first update
its cumulative TSN point to the value carried in the FORWARD TSN its cumulative TSN point to the value carried in the FORWARD TSN
chunk, and then MUST further advance its cumulative TSN point locally chunk, and then MUST further advance its cumulative TSN point locally
if possible, as shown by the following example: if possible, as shown by the following example:
Assuming that the new cumulative TSN carried in the arrived Assuming that the new cumulative TSN carried in the arrived
FORWARD TSN is 103: FORWARD TSN is 103:
skipping to change at page 13, line 45 skipping to change at page 13, line 22
FORWARD TSN chunk is found to be behind or at the current cumulative FORWARD TSN chunk is found to be behind or at the current cumulative
TSN point, the data receiver MUST treat this FORWARD TSN as TSN point, the data receiver MUST treat this FORWARD TSN as
out-of-date and MUST NOT update its Cumulative TSN. The receiver out-of-date and MUST NOT update its Cumulative TSN. The receiver
SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since
such a duplicate may indicate the previous SACK was lost in the such a duplicate may indicate the previous SACK was lost in the
network. network.
Any time a FORWARD TSN chunk arrives, for the purposes of sending a Any time a FORWARD TSN chunk arrives, for the purposes of sending a
SACK, the receiver MUST follow the same rules as if a DATA chunk had SACK, the receiver MUST follow the same rules as if a DATA chunk had
been received (i.e., follow the delayed sack rules specified in been received (i.e., follow the delayed sack rules specified in
RFC2960 [3] section 6.2). RFC2960 [2] section 6.2).
Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
ordered delivery) and is out of order, the receiver must hold the ordered delivery) and is out of order, the receiver must hold the
chunk for reordering. Since it is possible with PR-SCTP that a DATA chunk for reordering. Since it is possible with PR-SCTP that a DATA
chunk being waited upon will not be retransmitted, special actions chunk being waited upon will not be retransmitted, special actions
will need to be taken upon the arrival of a FORWARD TSN. will need to be taken upon the arrival of a FORWARD TSN.
In particular, during processing of a FORWARD TSN, the receiver MUST In particular, during processing of a FORWARD TSN, the receiver MUST
use the stream sequence information to examine all of the listed use the stream sequence information to examine all of the listed
stream reordering queues, and immediately make available for delivery stream reordering queues, and immediately make available for delivery
stream sequence numbers earlier than or equal to the stream sequence stream sequence numbers earlier than or equal to the stream sequence
number listed inside the FORWARD TSN. number listed inside the FORWARD TSN. Any such stranded data SHOULD
be made immediately available to the upper layer application.
An application using PR-SCTP receiving data should be aware of
possible missing messages. The stream sequence number can be used, in
such a case, to determine that an intervening message has been
skipped. When intervening messages are missing it is an application
decision to process the messages or to take some other corrective
action.
After receiving and processing a FORWARD TSN, the data receiver MUST After receiving and processing a FORWARD TSN, the data receiver MUST
take cautions in updating its re-assembly queue. The receiver MUST take cautions in updating its re-assembly queue. The receiver MUST
remove any partially reassembled message which is still missing one remove any partially reassembled message which is still missing one
or more TSNs earlier than or equal to the new cumulative TSN point. or more TSNs earlier than or equal to the new cumulative TSN point.
In the event that the receiver has invoked the partial delivery API a In the event that the receiver has invoked the partial delivery API a
notification SHOULD also be generated to inform the upper layer API notification SHOULD also be generated to inform the upper layer API
that the message being partially delivered will NOT be completed. that the message being partially delivered will NOT be completed.
Note that after receiving a FORWARD TSN and updating the cumulative
acknowledgement point, if a TSN that was skipped does arrive (i.e.
due to network reordering) then the receiver will follow the normal
rules defined in RFC2960 [2] for handling duplicate data. This
implies that the receiver will drop the chunk and report it as a
duplicate in the next outbound SACK chunk.
4. Services provided by PR-SCTP to the upper layer 4. Services provided by PR-SCTP to the upper layer
As described in Section 1.2, it is feasible to implement a variety of As described in Section 1.2, it is feasible to implement a variety of
partially reliable transport services using the new protocol partially reliable transport services using the new protocol
mechanisms introduced in Section 3; introducing these new services mechanisms introduced in Section 3; introducing these new services
requires making changes only at the sending side API, and the sending requires making changes only at the sending side API, and the sending
side protocol implementation. Thus, there may be a temptation to side protocol implementation. Thus, there may be a temptation to
standardize only the protocol, and leave the service definition as standardize only the protocol, and leave the service definition as
"implementation specific" or leave it to be defined in "implementation specific" or leave it to be defined in
"informational" documents. "informational" documents.
However, for those who may wish to write IETF standards for upper However, for those who may wish to write IETF standards for upper
layer protocols implemented over PR-SCTP, it is important to be able layer protocols implemented over PR-SCTP, it is important to be able
to refer to a standard definition of services provided. Therefore, to refer to a standard definition of services provided. Therefore,
this section provides an example definitions of one such service, this section provides an example definitions of one such service,
while also providing guidelines for the definition of additional while also providing guidelines for the definition of additional
services as required. Each such service may be proposed as a services as required. Each such service may be proposed as a
separate new informational RFC. separate new RFC.
Section 4 is organized as follows: Section 4 is organized as follows:
Section 4.1 provides the definition of one specific PR-SCTP Section 4.1 provides the definition of one specific PR-SCTP
service: timed reliability. service: timed reliability.
Section 4.2 describes how a particular PR-SCTP service definition Section 4.2 describes how a particular PR-SCTP service definition
is requested by the upper layer during association establishment, is requested by the upper layer during association establishment,
and how the upper layer is notified if that request cannot be and how the upper layer is notified if that request cannot be
satisfied. satisfied.
Section 4.3 then provides guidelines for the specification of Section 4.3 then provides guidelines for the specification of
PR-SCTP services other then the one defined in this memo. PR-SCTP services other then the one defined in this memo.
Finally, Section 4.4 describes some additional usage notes that Finally, Section 4.4 describes some additional usage notes that
upper layer protocol designers and implementors may find helpful. upper layer protocol designers and implementors may find helpful.
4.1 PR-SCTP Service Definition for "timed reliability" 4.1 PR-SCTP Service Definition for "timed reliability"
The "timed reliability" service is a natural extension of the The "timed reliability" service is a natural extension of the
"lifetime" concept already present in the base SCTP protocol. "lifetime" concept already present in the base SCTP protocol.
When this service is requested for an SCTP association, it changes When this service is requested for an SCTP association, it changes
the meaning of the lifetime parameter specified in the SEND primitive the meaning of the lifetime parameter specified in the SEND primitive
skipping to change at page 15, line 18 skipping to change at page 14, line 48
Finally, Section 4.4 describes some additional usage notes that Finally, Section 4.4 describes some additional usage notes that
upper layer protocol designers and implementors may find helpful. upper layer protocol designers and implementors may find helpful.
4.1 PR-SCTP Service Definition for "timed reliability" 4.1 PR-SCTP Service Definition for "timed reliability"
The "timed reliability" service is a natural extension of the The "timed reliability" service is a natural extension of the
"lifetime" concept already present in the base SCTP protocol. "lifetime" concept already present in the base SCTP protocol.
When this service is requested for an SCTP association, it changes When this service is requested for an SCTP association, it changes
the meaning of the lifetime parameter specified in the SEND primitive the meaning of the lifetime parameter specified in the SEND primitive
(see Section 10.1, part (E) of RFC2960 [3]; note that the parameter (see Section 10.1, part (E) of RFC2960 [2]; note that the parameter
is spelled "life time" in that document.) is spelled "life time" in that document.)
In the base SCTP protocol, the lifetime parameter is used to avoid In the base SCTP protocol, the lifetime parameter is used to avoid
sending stale data. When a lifetime value is indicated for a sending stale data. When a lifetime value is indicated for a
particular message and that lifetime expires, SCTP cancels the particular message and that lifetime expires, SCTP cancels the
sending of this message, and notifies the ULP if the first sending of this message, and notifies the ULP if the first
transmission of the data does not take place (because of rwnd or cwnd transmission of the data does not take place (because of rwnd or cwnd
limitations, or for any other reason). However, in the base limitations, or for any other reason). However, in the base
protocol, if SCTP has sent the first transmission before the lifetime protocol, if SCTP has sent the first transmission before the lifetime
expires, then the message MUST be sent as a normal reliable message. expires, then the message MUST be sent as a normal reliable message.
skipping to change at page 15, line 41 skipping to change at page 15, line 23
(non-lifetime expired) messages. (non-lifetime expired) messages.
When the "timed reliability" service is invoked, this latter When the "timed reliability" service is invoked, this latter
restriction is removed. Specifically, when the "timed reliability" restriction is removed. Specifically, when the "timed reliability"
service is in effect, the following rules govern all messages that service is in effect, the following rules govern all messages that
are sent with a lifetime parameter: are sent with a lifetime parameter:
TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE
(or unspecified see Section 5) that message is treated as a normal (or unspecified see Section 5) that message is treated as a normal
reliable SCTP message, just as in the base SCTP protocol. reliable SCTP message, just as in the base SCTP protocol.
TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see
Section 5), then the SCTP sender MUST treat the message just as if Section 5), then the SCTP sender MUST treat the message just as if
it were a normal reliable SCTP message as long as the lifetime has it were a normal reliable SCTP message as long as the lifetime has
not yet expired. not yet expired.
TR3) Before assigning a TSN to any message, the SCTP sender MUST TR3) Before assigning a TSN to any message, the SCTP sender MUST
evaluate the lifetime of that message. If it is expired, the SCTP evaluate the lifetime of that message. If it is expired, the SCTP
sender MUST NOT assign a TSN to that message, but instead, SHOULD sender MUST NOT assign a TSN to that message, but instead, SHOULD
issue a notification to the upper layer and abandon the message. issue a notification to the upper layer and abandon the message.
TR4) Before transmitting or retransmitting a message for which a TSN TR4) Before transmitting or retransmitting a message for which a TSN
is already assigned, the SCTP sender MUST evaluate the lifetime of is already assigned, the SCTP sender MUST evaluate the lifetime of
the message. If the lifetime of the message is expired, the SCTP the message. If the lifetime of the message is expired, the SCTP
sender MUST "abandon" the message, as per the rules specified in sender MUST "abandon" the message, as per the rules specified in
Section 3.5 marking that TSN as eligible for forward TSN. Note Section 3.5 marking that TSN as eligible for forward TSN. Note
that this meets the requirement G1 defined in Section 4.3 that this meets the requirement G1 defined in Section 4.3
IMPLEMENTATION NOTE: An implementation SHOULD delay TSN assignment
as mentioned in RFC2960 [2] Section 10.1. In such a case the
lifetime parameter should be checked BEFORE assigning a TSN thus
allowing a message to be abandoned without the need to send a
FORWARD TSN.
TR5) The sending SCTP MAY evaluate the lifetime of messages at TR5) The sending SCTP MAY evaluate the lifetime of messages at
anytime. Expired messages that have not been assigned a TSN MAY be anytime. Expired messages that have not been assigned a TSN MAY be
handled as per rule TR3. Expired messages that HAVE been assigned handled as per rule TR3. Expired messages that HAVE been assigned
a TSN MAY be handled as per rule TR4. a TSN MAY be handled as per rule TR4.
TR6) The sending application MUST NOT change the lifetime parameter TR6) The sending application MUST NOT change the lifetime parameter
once the message is passed to the sending SCTP. once the message is passed to the sending SCTP.
Implementation Note: Rules TR1 through TR4 are designed in such a way Implementation Note: Rules TR1 through TR4 are designed in such a way
as to avoid requiring the implementer to maintain a separate timer as to avoid requiring the implementer to maintain a separate timer
for each message; instead, the lifetime need only be evaluated at for each message; instead, the lifetime need only be evaluated at
points in the life of the message where actions are already being points in the life of the message where actions are already being
taken, such as TSN assignment, transmission, or expiration of a taken, such as TSN assignment, transmission, or expiration of a
retransmission timeout. Rule TR5 is intended to give the SCTP retransmission timeout. Rule TR5 is intended to give the SCTP
implementor flexibility to evaluate lifetime at any other convenient implementor flexibility to evaluate lifetime at any other convenient
skipping to change at page 16, line 37 skipping to change at page 16, line 18
opportunity, WITHOUT requiring that lifetime be evaluated immediately opportunity, WITHOUT requiring that lifetime be evaluated immediately
at the point in time where it expires. at the point in time where it expires.
4.2 PR-SCTP Association Establishment 4.2 PR-SCTP Association Establishment
An upper layer protocol (ULP) that uses PR-SCTP may need to know An upper layer protocol (ULP) that uses PR-SCTP may need to know
whether PR-SCTP can be supported on a given association. Therefore, whether PR-SCTP can be supported on a given association. Therefore,
the ULP needs to have some indication of whether the FORWARD-TSN the ULP needs to have some indication of whether the FORWARD-TSN
chunk is supported by its peer. chunk is supported by its peer.
Section 10.1 of RFC2960 [3] describes abstract primitives for the Section 10.1 of RFC2960 [2] describes abstract primitives for the
ULP-to-SCTP interface, while noting that "individual implementations ULP-to-SCTP interface, while noting that "individual implementations
must define their own exact format, and may provide combinations or must define their own exact format, and may provide combinations or
subsets of the basic functions in single calls." subsets of the basic functions in single calls."
In this section, we describe one additional return value that may be In this section, we describe one additional return value that may be
added to the ASSOCIATE primitive to allow an SCTP service user to added to the ASSOCIATE primitive to allow an SCTP service user to
indicate whether the FORWARD-TSN chunk is supported by its peer. indicate whether the FORWARD-TSN chunk is supported by its peer.
RFC2960 indicates that the ASSOCIATE primitive "allows the upper RFC2960 indicates that the ASSOCIATE primitive "allows the upper
layer to initiate an association to a specific peer endpoint". It is layer to initiate an association to a specific peer endpoint". It is
skipping to change at page 17, line 20 skipping to change at page 17, line 5
outbound stream count ) outbound stream count )
-> association id [,destination transport addr list] -> association id [,destination transport addr list]
[,outbound stream count] [,forward tsn supported] [,outbound stream count] [,forward tsn supported]
NOTE: As per RFC2960, if the ASSOCIATE primitive is implemented as a NOTE: As per RFC2960, if the ASSOCIATE primitive is implemented as a
non-blocking call, the new OPTIONAL return value shall be passed with non-blocking call, the new OPTIONAL return value shall be passed with
the association parameters using the COMMUNICATION UP notification. the association parameters using the COMMUNICATION UP notification.
The new OPTIONAL parameter "forward tsn supported" is a boolean flag: The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
(0) false [default] indicates that FORWARD TSN is not supported by (0) false [default] indicates that FORWARD TSN is not enabled by both
the peer. endpoints.
(1) true indicates that FORWARD TSN is enabled on both endpoints.
(1) true indicates that FORWARD TSN is supported by the peer. We also add a new primitive to allow the user application to enable/
disable the PR-SCTP service on its endpoint before an association is
established.
Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable)
The boolean parameter enable if set to true will enable PR-SCTP upon
future endpoint associations. If the boolean parameter is set to
false, then the local endpoint will not advertise support of PR-SCTP
and thus disable the feature on future associations. It is
recommended that this option be disabled by default I.e. in order to
enable PR-SCTP the user will need to call this API option with the
enable flag set to "true".
4.3 Guidelines for defining other PR-SCTP Services 4.3 Guidelines for defining other PR-SCTP Services
Other PR-SCTP services may be defined and implemented as dictated by Other PR-SCTP services may be defined and implemented as dictated by
the needs of upper layer protocols. If such upper layer protocols the needs of upper layer protocols. If such upper layer protocols
are to be standardized and require some particular PR-SCTP service are to be standardized and require some particular PR-SCTP service
other than the one defined in this document (i.e., "timed other than the one defined in this document (i.e., "timed
reliability") then those additional PR-SCTP services should also be reliability") then those additional PR-SCTP services should also be
specified and standardized in an informational RFC. specified and standardized in a new RFC.
It is suggested that any such additional service definitions be It is suggested that any such additional service definitions be
modeled after the contents of Section 4.1 . In particular, the modeled after the contents of Section 4.1 . In particular, the
service definition should provide: service definition should provide:
1. A description of how the service user specifies any parameters 1. A description of how the service user specifies any parameters
that need to be associated with a particular message (and/or any that need to be associated with a particular message (and/or any
other communication that takes place between the application and other communication that takes place between the application and
the SCTP transport sender) that provides the SCTP transport the SCTP transport sender) that provides the SCTP transport
sender with the information needed to determine when to give up sender with the information needed to determine when to give up
on transmission of a particular message. on transmission of a particular message.
Preferably this description should reference the primitives in Preferably this description should reference the primitives in
the abstract API provided in Section 10 of RFC2960 [3], the abstract API provided in Section 10 of RFC2960 [2],
indicating any: indicating any:
* changes to the interpretation of the existing parameters of * changes to the interpretation of the existing parameters of
existing primitives, existing primitives,
* additional parameters to be added to existing primitives * additional parameters to be added to existing primitives
(these should be OPTIONAL, and default values should be (these should be OPTIONAL, and default values should be
indicated), indicated),
* additional primitives that may be needed. * additional primitives that may be needed.
2. A description of the rules used by the sender side implementation 2. A description of the rules used by the sender side implementation
to determine when to give up on messages that have not yet been to determine when to give up on messages that have not yet been
assigned a TSN. This description should also indicate what assigned a TSN. This description should also indicate what
protocol events trigger the evaluation, and what actions to take protocol events trigger the evaluation, and what actions to take
(e.g. notifications.) (e.g. notifications.)
3. A description of the rules used by the sender side implementation 3. A description of the rules used by the sender side implementation
to determine when to give up on the transmission or to determine when to give up on the transmission or
retransmission of messages that have already been assigned a TSN, retransmission of messages that have already been assigned a TSN,
and may have been transmitted and possibly retransmitted zero or and may have been transmitted and possibly retransmitted zero or
more times. more times.
Items (2) and (3) in the list above should also indicate what Items (2) and (3) in the list above should also indicate what
protocol events trigger the evaluation, and what actions to take if protocol events trigger the evaluation, and what actions to take if
the determination is made that the sender should give up on the determination is made that the sender should give up on
transmitting the message (e.g. notifications to the ULP.) transmitting the message (e.g. notifications to the ULP.)
skipping to change at page 19, line 20 skipping to change at page 19, line 13
This section defines variables used throughout this document: This section defines variables used throughout this document:
SCTP_LIFETIME_RELIABLE - A user interface indication defined by an SCTP_LIFETIME_RELIABLE - A user interface indication defined by an
implementation and used to indicate when a message is to be implementation and used to indicate when a message is to be
considered fully reliable. considered fully reliable.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Brian Bidulock, Scott Bradner, Jon The authors would like to thank Brian Bidulock, Scott Bradner, Jon
Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias
Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s Rodriguez, Ian Rytina, Chip Sharp, and others for their comments.
7. Security Considerations 7. Security Considerations
This document does not introduce any new security concerns to SCTP This document does not introduce any new security concerns to SCTP
other than the ones already documented in RFC2960 [3]. In particular other than the ones already documented in RFC2960 [2]. In particular
this document shares the same security issues as unordered data this document shares the same security issues as unordered data
within RFC2960 [3] identified by RFC3436 [5]. An application using within RFC2960 [2] identified by RFC3436 [4]. An application using
the PR-SCTP extension should not use transport layer security; the PR-SCTP extension should not use transport layer security;
further details can be found in RFC3436 [5]. further details can be found in RFC3436 [4].
Note that the ability to cause a message to be skipped (I.e: the
FORWARD TSN chunk) does not provide any new attack for a
Man-In-the-Middle (MIM), since the MIM already is capable of changing
and/or withholding data thus effectively skipping messages. However
the FORWARD TSN chunk does provide a mechanism to make it easier for
a MIM to skip selective messages when the application has this
feature enabled since the MIM would have less state to maintain.
8. IANA Considerations 8. IANA Considerations
One new chunk type is added to SCTP (192) by this document. IANA is requested to assign one new chunk type to SCTP using "192" is
recommended. An alternate number can be assigned as long as the two
upper bits are both set to one.
One new parameter type code is defined by this document to be added IANA is requested to assign one new parameter type code to SCTP using
to SCTP (49152). "49152" is recommended. An altenate number can be assigned as long as
the two upper bits are both set to one.
Normative references Normative references
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
Informational References Informational References
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for [3] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, a New Generation of Protocols", SIGCOMM 1990 pp. 200-208,
September 1990. September 1990.
[5] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [4] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
USA USA
skipping to change at page 22, line 29 skipping to change at page 22, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 23, line 7 skipping to change at page 23, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/