Squashed 'third_party/lksctp-tools/' content from commit 200eca7f1
Change-Id: I8f7575513f114b205178cac5c6b3706f3d725cb5
git-subtree-dir: third_party/lksctp-tools
git-subtree-split: 200eca7f1419b1ae53958b51e8551f7e7f6cd467
diff --git a/doc/rfc3758.txt b/doc/rfc3758.txt
new file mode 100644
index 0000000..1c0dc15
--- /dev/null
+++ b/doc/rfc3758.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group R. Stewart
+Request for Comments: 3758 M. Ramalho
+Category: Standards Track Cisco Systems, Inc.
+ Q. Xie
+ Motorola, Inc.
+ M. Tuexen
+ Univ. of Applied Sciences Muenster
+ P. Conrad
+ University of Delaware
+ May 2004
+
+
+ Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This memo describes an extension to the Stream Control Transmission
+ Protocol (SCTP) that allows an SCTP endpoint to signal to its peer
+ that it should move the cumulative ack point forward. When both
+ sides of an SCTP association support this extension, it can be used
+ by an SCTP implementation to provide partially reliable data
+ transmission service to an upper layer protocol. This memo describes
+ the protocol extensions, which consist of a new parameter for INIT
+ and INIT ACK, and a new FORWARD TSN chunk type, and provides one
+ example of a partially reliable service that can be provided to the
+ upper layer via this mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 1]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Overview of Protocol Extensions. . . . . . . . . . . . . 2
+ 1.2. Overview of New Services Provided to the Upper Layer . . 3
+ 1.3. Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . . 5
+ 3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK. . 5
+ 3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN). . 5
+ 3.3. Negotiation of Forward-TSN-Supported parameter . . . . . 7
+ 3.3.1. Sending Forward-TSN-Supported param in INIT . . . 7
+ 3.3.2. Receipt of Forward-TSN-Supported parameter in
+ INIT or INIT-ACK. . . . . . . . . . . . . . . . . 7
+ 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.5. Sender Side Implementation of PR-SCTP. . . . . . . . . . 9
+ 3.6. Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
+ 4. Services provided by PR-SCTP to the upper layer. . . . . . . . 14
+ 4.1. PR-SCTP Service Definition for "timed reliability" . . . 15
+ 4.2. PR-SCTP Association Establishment. . . . . . . . . . . . 16
+ 4.3. Guidelines for defining other PR-SCTP Services . . . . . 17
+ 4.4. Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
+ 5. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
+ 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 20
+ 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
+
+1. Introduction
+
+ This memo describes an extension to the Stream Control Transmission
+ Protocol (SCTP) RFC 2960 [2] that allows an SCTP sender to signal to
+ its peer that it should no longer expect to receive one or more DATA
+ chunks.
+
+1.1. Overview of Protocol Extensions
+
+ The protocol extension described in this document consists of two new
+ elements:
+
+ 1. a single new parameter in the INIT/INIT-ACK exchange that
+ indicates whether the endpoint supports the extension
+
+
+
+Stewart, et al. Standards Track [Page 2]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ 2. a single new chunk type, FORWARD TSN, that indicates that the
+ receiver should move its cumulative ack point forward (possibly
+ skipping past one or more DATA chunks that may not yet have been
+ received and/or acknowledged.)
+
+1.2. Overview of New Services Provided to the Upper Layer
+
+ When this extension is supported by both sides of an SCTP
+ association, it can be used to provide partially reliable transport
+ service over an SCTP association. We define partially reliable
+ transport service as a service that allows the user to specify, on a
+ per message basis, the rules governing how persistent the transport
+ service should be in attempting to send the message to the receiver.
+
+ One example of partially reliable service is specified in this
+ document, namely a "timed reliability" service. This service allows
+ the service user to indicate a limit on the duration of time that the
+ sender should try to transmit/retransmit the message (this is a
+ natural extension of the "lifetime" parameter already in the base
+ protocol).
+
+ In addition to this example, we will also show that defining the
+ semantics of a particular partially reliable service involves two
+ elements, namely:
+
+ 1. how the service user indicates the level of reliability required
+ for a particular message, and
+
+ 2. how the sender side implementation uses that reliability level to
+ determine when to give up on further retransmissions of that
+ message.
+
+ Note that other than the fact that the FORWARD-TSN chunk is required,
+ neither of these two elements impacts the "on-the-wire" protocol;
+ only the API and the sender side implementation are affected by the
+ way in which the service is defined to the upper layer. Therefore,
+ in principle, it is feasible to implement many varieties of partially
+ reliable services in a particular SCTP implementation without
+ changing the on-the-wire protocol. Also, the SCTP receiver does not
+ necessarily need to know which semantics of partially reliable
+ service are being used by the sender, since the receiver's only role
+ is to correctly interpret FORWARD TSN chunks, thereby skipping past
+ messages that the sender has decided to no longer transmit (or
+ retransmit).
+
+ Nevertheless, it is recommended that a limited number of standard
+ definitions of partially reliable services be standardized by the
+ IETF so that the designers of IETF application layer protocols can
+
+
+
+Stewart, et al. Standards Track [Page 3]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ match the requirements of their upper layer protocols to standard
+ service definitions provided by a particular SCTP implementation.
+ One such definition, "timed reliability", is included in this
+ document. Given the extensions proposed in this document, other
+ definitions may be standardized as the need arises without further
+ changes to the on-the-wire protocol.
+
+1.3. Benefits of PR-SCTP
+
+ Hereafter, we use the notation "Partial Reliable Stream Control
+ 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
+ reliable data service into SCTP, i.e., benefits of PR-SCTP:
+
+ 1. Some application layer protocols may benefit from being able to
+ use a single SCTP association to carry both reliable content, --
+ such as text pages, billing and accounting information, setup
+ signaling -- and unreliable content, e.g., state that is highly
+ sensitive to timeliness, where generating a new packet is more
+ advantageous than transmitting an old one [3].
+
+ 2. Partially reliable data traffic carried by PR-SCTP will enjoy the
+ same communication failure detection and protection capabilities
+ as the normal reliable SCTP data traffic does. This includes the
+ ability to quickly detect a failed destination address, fail-over
+ to an alternate destination address, and be notified if the data
+ receiver becomes unreachable.
+
+ 3. In addition to providing unordered, unreliable data transfer as
+ UDP does, PR-SCTP can provide ordered, unreliable data transfer
+ service.
+
+ 4. PR-SCTP employs the same congestion control and congestion
+ avoidance for all data traffic, whether reliable or partially
+ reliable - this is very desirable since SCTP enforces TCP-
+ friendliness (unlike UDP.)
+
+ 5. Because of the chunk bundling function of SCTP, reliable and
+ unreliable messages can be multiplexed over a single PR-SCTP
+ association. Therefore, the number of IP datagrams (and hence the
+ network overhead) can be reduced instead of having to send these
+ different types of data using separate protocols. Additionally,
+ this multiplexing allows for port savings versus using different
+ ports for reliable and unreliable connections.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 4]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+2. Conventions
+
+ The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+ SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
+ they appear in this document, are to be interpreted as described in
+ BCP 14, RFC 2119 [1].
+
+ Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are
+ governed by the rules in Section 1.6 of RFC 2960 [2].
+
+3. Protocol Changes to support PR-SCTP
+
+3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK
+
+ The following new OPTIONAL parameter is added to the INIT and INIT
+ ACK chunks.
+
+ Parameter Name Status Type Value
+ -------------------------------------------------------------
+ Forward-TSN-Supported OPTIONAL 49152 (0xC000)
+
+ At the initialization of the association, the sender of the INIT or
+ INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer
+ that it is able to support the Forward TSN chunk (see Section 3.3 for
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Parameter Type = 49152 | Parameter Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 16 bit u_int
+
+ 49152, indicating Forward-TSN-Supported parameter
+
+ Length: 16 bit u_int
+
+ Indicates the size of the parameter, i.e., 4.
+
+3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
+
+ The following new chunk type is defined:
+
+ Chunk Type Chunk Name
+ ------------------------------------------------------
+ 192 (0xC0) Forward Cumulative TSN (FORWARD TSN)
+
+
+
+
+Stewart, et al. Standards Track [Page 5]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ This chunk shall be used by the data sender to inform the data
+ receiver to adjust its cumulative received TSN point forward because
+ some missing TSNs are associated with data chunks that SHOULD NOT be
+ transmitted or retransmitted by the sender.
+
+ Forward Cumulative TSN 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 192 | Flags = 0x00 | Length = Variable |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | New Cumulative TSN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Stream-1 | Stream Sequence-1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ \ /
+ / \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Stream-N | Stream Sequence-N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Chunk Flags:
+
+ Set to all zeros on transmit and ignored on receipt.
+
+ New Cumulative TSN: 32 bit u_int
+
+ This indicates the new cumulative TSN to the data receiver. Upon
+ the reception of this value, the data receiver MUST consider
+ any missing TSNs earlier than or equal to this value as received,
+ and stop reporting them as gaps in any subsequent SACKs.
+
+ Stream-N: 16 bit u_int
+
+ This field holds a stream number that was skipped by this
+ FWD-TSN.
+
+ Stream Sequence-N: 16 bit u_int
+
+ This field holds the sequence number associated with the stream
+ that was skipped. The stream sequence field holds the largest
+ stream sequence number in this stream being skipped. The receiver
+ of the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
+ to enable delivery of any stranded TSN's that remain on the stream
+ re-ordering queues. This field MUST NOT report TSN's corresponding
+ to DATA chunks that are marked as unordered. For ordered DATA
+ chunks this field MUST be filled in.
+
+
+
+Stewart, et al. Standards Track [Page 6]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+3.3. Negotiation of Forward-TSN-Supported parameter
+
+3.3.1. Sending Forward-TSN-Supported param in INIT
+
+ If an SCTP endpoint supports the FORWARD TSN chunk, then any time it
+ sends an INIT during association establishment, it MAY include the
+ Forward-TSN-supported parameter in the INIT chunk to indicate this
+ 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
+
+ When a receiver of an INIT detects a Forward-TSN-Supported parameter
+ and does not support the Forward-TSN chunk type, the receiver MUST
+ follow the rules defined in Section 3.3.3 of RFC 2960 [2].
+
+ When a receiver of an INIT-ACK detects a Forward-TSN-Supported
+ parameter and it does not support the Forward-TSN chunk type, the
+ receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960
+ [2].
+
+ When a receiver of an INIT detects a Forward-TSN-Supported parameter
+ and it does support the Forward-TSN chunk type, the receiver MAY
+ respond 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
+ that does not contain the Forward-TSN-Supported Parameter, that
+ endpoint:
+
+ 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
+ TSN chunk,
+ o MUST NOT send a FORWARD TSN chunk at any time during the
+ associations life,
+ o SHOULD inform the upper layer if the upper layer has requested
+ such notification.
+
+
+
+
+Stewart, et al. Standards Track [Page 7]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+3.3.3. Receipt of Op. Error for Forward-TSN-Supported Param
+
+ When an SCTP endpoint that desires to use the FORWARD TSN chunk
+ feature for partially reliable data transfer receives an operational
+ error from the remote endpoint (either bundled with the COOKIE or as
+ an unrecognized parameter in the INIT-ACK), indicating that the
+ remote endpoint does not recognize the Forward-TSN-Supported
+ parameter, the local endpoint SHOULD inform its upper layer of the
+ remote endpoint's inability to support partially reliable data
+ transfer.
+
+ The local endpoint may then choose to either:
+
+ 1) end the initiation process (in cases where the initiation process
+ has already ended, the endpoint may need to send an ABORT) in
+ consideration of the peer's inability to supply the requested
+ features for the new association, or
+
+ 2) continue the initiation process (in cases where the initiation
+ process has already completed, the endpoint MUST just mark the
+ association as not supporting partial reliability), but with the
+ understanding that partially reliable data transmission is not
+ supported. In this case, the endpoint receiving the operational
+ error SHOULD note that the FORWARD TSN chunk is not supported, and
+ MUST NOT transmit a FORWARD TSN chunk at any time during the life
+ of the association.
+
+3.4. Definition of "abandoned" in the context of PR-SCTP
+
+ At some point, a sending PR-SCTP implementation MAY determine that a
+ particular data chunk SHOULD NOT be transmitted or retransmitted
+ further, in accordance with the rules governing some particular PR-
+ SCTP service definition (such as the definition of "timed
+ reliability" in Section 4.1.) For purposes of this document, we
+ define the term "abandoned" to refer to any data chunk about which
+ the SCTP sender has made this determination.
+
+ Each PR-SCTP service defines the rules for determining when a TSN is
+ "abandoned", and accordingly, the rules that govern how, whether, and
+ when to "abandon" a TSN may vary from one service definition to
+ another. However, the rules governing the actions taken when a TSN
+ is "abandoned" do NOT vary between service definitions; these rules
+ are included in Section 3.5.
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 8]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+3.5. Sender Side Implementation of PR-SCTP
+
+ The sender side implementation of PR-SCTP is identical to that of the
+ base SCTP protocol, except for:
+
+ o actions a sending side PR-SCTP implementation must take when a TSN
+ is "abandoned" (as per the rules of whatever PR-SCTP service
+ definition is in effect)
+ o special actions that a PR-SCTP implementation must take upon
+ receipt of SACK
+ o rules governing the generation of FORWARD TSN chunks.
+
+ In detail, these exceptions are as follows:
+
+ A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer
+ to track a theoretical cumulative TSN point of the peer (Note,
+ this is a _new_ protocol variable and its value is NOT
+ necessarily the same as the SCTP "Cumulative TSN Ack Point" as
+ defined in Section 1.4 of RFC 2960 [2], and as discussed
+ throughout that document.)
+
+ A2) From time to time, as governed by the rules of a particular PR-
+ SCTP service definition (see Section 4), the SCTP data sender may
+ make a determination that a particular data chunk that has
+ already been assigned a TSN SHOULD be "abandoned".
+
+ When a data chunk is "abandoned", the sender MUST treat the data
+ chunk as being finally acked and no longer outstanding.
+
+ The sender MUST NOT credit an "abandoned" data chunk to the
+ partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2],
+ and MUST NOT advance the cwnd based on this "abandoned" data
+ chunk.
+
+ 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
+ at the same time.
+
+ A4) Whenever the data sender receives a SACK from the data receiver,
+ it MUST first process the SACK using the normal procedures as
+ defined in Section 6.2.1 of RFC 2960 [2].
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 9]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ The data sender MUST then perform the following additional steps:
+
+ C1) Let SackCumAck be the Cumulative TSN ACK carried in the
+ received SACK.
+
+ If (Advanced.Peer.Ack.Point < SackCumAck), then update
+ Advanced.Peer.Ack.Point to be equal to SackCumAck.
+
+ C2) Try to further advance the "Advanced.Peer.Ack.Point" locally,
+ 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 shown in the following example:
+
+ Assuming that a SACK arrived with the Cumulative TSN ACK =
+ 102 and the Advanced.Peer.Ack.Point is updated to this
+ value:
+
+ out-queue at the end of ==> out-queue after Adv.Ack.Point
+ normal SACK processing local advancement
+
+ ... ...
+ Adv.Ack.Pt-> 102 acked 102 acked
+ 103 abandoned 103 abandoned
+ 104 abandoned Adv.Ack.P-> 104 abandoned
+ 105 105
+ 106 acked 106 acked
+ ... ...
+
+ In this example, the data sender successfully advanced the
+ "Advanced.Peer.Ack.Point" from 102 to 104 locally.
+
+ C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
+ greater than the Cumulative TSN ACK carried in the received
+ SACK, the data sender MUST send the data receiver a FORWARD
+ TSN chunk containing the latest value of the
+ "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 implementation decision as to
+ which destination address it is to be sent to, the only
+ restriction being that the address MUST be one that is
+ CONFIRMED.
+
+ C4) For each "abandoned" TSN, the sender of the FORWARD TSN MUST
+ determine if the chunk has a valid stream and sequence number
+ (i.e., it was ordered). If the chunk has a valid stream and
+ sequence number, the sender MUST include the stream and
+ sequence number in the FORWARD TSN. This information will
+ enable the receiver to easily find any stranded TSN's waiting
+
+
+
+Stewart, et al. Standards Track [Page 10]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ on stream reorder queues. Each stream SHOULD only be
+ reported once; this means that if multiple abandoned messages
+ occur in the same stream, then only the highest abandoned
+ stream sequence number is reported. If the total size of the
+ FORWARD TSN does NOT fit in a single MTU, then the sender of
+ the FORWARD TSN SHOULD lower the Advanced.Peer.Ack.Point to
+ the last TSN that will fit in a single MTU.
+
+ C5) If a FORWARD TSN is sent, the sender MUST assure that at
+ least one T3-rtx timer is running. IMPLEMENTATION NOTE: Any
+ destination's timer may be used for the purposes of rule C5.
+
+ A5) Any time the T3-rtx timer expires, on any destination, the sender
+ SHOULD try to advance the "Advanced.Peer.Ack.Point" by following
+ the procedures outlined in C2 - C5.
+
+ The following additional rules govern the generation of FORWARD TSN
+ chunks:
+
+ F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other
+ than circumstances described in this document.
+
+ F2) The data sender SHOULD always attempt to bundle an outgoing
+ FORWARD TSN with outbound DATA chunks for efficiency.
+
+ A sender MAY even choose to delay the sending of the FORWARD TSN
+ in the hope of bundling it with an outbound DATA chunk.
+
+ IMPLEMENTATION NOTE: An implementation may wish to limit the
+ number of duplicate FORWARD TSN chunks it sends by either only
+ sending a duplicate FORWARD TSN every other SACK or waiting a
+ full RTT before sending a duplicate FORWARD TSN.
+
+ IMPLEMENTATION NOTE: An implementation may allow the maximum
+ delay for generating a FORWARD TSN to be configured either
+ statically or dynamically in order to meet the specific timing
+ requirements of the protocol being carried, but see the next
+ rule:
+
+ F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT
+ exceed 200ms and MUST NOT exceed 500ms. In other words, an
+ implementation MAY lower this value below 500ms but MUST NOT
+ raise it above 500ms.
+
+ NOTE: Delaying the sending of FORWARD TSN chunks may cause delays
+ in the receiver's ability to deliver other data being held at the
+ receiver for re-ordering. The values of 200ms and 500ms match
+
+
+
+
+Stewart, et al. Standards Track [Page 11]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ the required values for the delayed acknowledgement in RFC 2960
+ [2] since delaying a FORWARD TSN has the same consequences but in
+ the reverse direction.
+
+ F4) The detection criterion for out-of-order SACKs MUST remain the
+ same as stated in RFC 2960, that is, a SACK is only considered
+ out-of-order if the Cumulative TSN ACK carried in the SACK is
+ earlier than that of the previous received SACK (i.e., the
+ comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
+
+ F5) If the decision to "abandon" a chunk is made, no matter how such
+ a decision is made, the appropriate congestion adjustment MUST be
+ made as specified in RFC 2960 if the chunk would have been marked
+ for retransmission later (e.g., either by T3-Timeout or by Fast
+ Retransmit).
+
+3.6. Receiver Side Implementation of PR-SCTP
+
+ The receiver side implementation of PR-SCTP at an SCTP endpoint A is
+ capable of supporting any PR-SCTP service definition used by the
+ sender at endpoint B, even if that service definition is not
+ supported by the sending side functionality of host A. All that is
+ necessary is that the receiving side correctly handle the Forward-
+ TSN-Supported parameter as specified in Section 3.3, and correctly
+ handle the receipt of FORWARD TSN chunks as specified below.
+
+ DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA
+ chunk arrival at a base protocol SCTP receiver---that is, the
+ receiver MUST perform the same TSN handling, including duplicate
+ detection, gap detection, SACK generation, cumulative TSN
+ advancement, etc. as defined in RFC 2960 [2]---with the following
+ exceptions and additions.
+
+ When a FORWARD TSN chunk arrives, the data receiver MUST first update
+ its cumulative TSN point to the value carried in the FORWARD TSN
+ chunk, and then MUST further advance its cumulative TSN point locally
+ if possible, as shown by the following example:
+
+ Assuming that the new cumulative TSN carried in the arrived
+ FORWARD TSN is 103:
+
+ in-queue before processing in-queue after processing
+ the FORWARD TSN ==> the FORWARD TSN and further
+ advancement
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 12]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ cum.TSN.Pt-> 102 received 102 --
+ 103 missing 103 --
+ 104 received 104 --
+ 105 received cum.TSN.Pt-> 105 received
+ 106 missing 106 missing
+ 107 received 107 received
+ ... ...
+
+ In this example, the receiver's cumulative TSN point is first
+ updated to 103 and then further advanced to 105.
+
+ After the above processing, the data receiver MUST stop reporting any
+ missing TSNs earlier than or equal to the new cumulative TSN point.
+
+ Note, if the "New Cumulative TSN" value carried in the arrived
+ FORWARD TSN chunk is found to be behind or at the current cumulative
+ TSN point, the data receiver MUST treat this FORWARD TSN as 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 such a
+ duplicate may indicate the previous SACK was lost in the network.
+
+ 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
+ been received (i.e., follow the delayed sack rules specified in RFC
+ 2960 [2] section 6.2).
+
+ 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
+ chunk for reordering. Since it is possible with PR-SCTP that a DATA
+ chunk being waited upon will not be retransmitted, special actions
+ will need to be taken upon the arrival of a FORWARD TSN.
+
+ In particular, during processing of a FORWARD TSN, the receiver MUST
+ use the stream sequence information to examine all of the listed
+ stream reordering queues, and immediately make available for delivery
+ stream sequence numbers earlier than or equal to the stream sequence
+ 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.
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 13]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ After receiving and processing a FORWARD TSN, the data receiver MUST
+ take cautions in updating its re-assembly queue. The receiver MUST
+ remove any partially reassembled message, which is still missing one
+ 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 notification SHOULD also be generated to inform the upper layer API
+ 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 RFC 2960 [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
+
+ As described in Section 1.2, it is feasible to implement a variety of
+ partially reliable transport services using the new protocol
+ mechanisms introduced in Section 3; introducing these new services
+ requires making changes only at the sending side API, and the sending
+ side protocol implementation. Thus, there may be a temptation to
+ standardize only the protocol, and leave the service definition as
+ "implementation specific" or leave it to be defined in
+ "informational" documents.
+
+ However, for those who may wish to write IETF standards for upper
+ layer protocols implemented over PR-SCTP, it is important to be able
+ to refer to a standard definition of services provided. Therefore,
+ this section provides example definitions of one such service, while
+ also providing guidelines for the definition of additional services
+ as required. Each such service may be proposed as a separate new
+ RFC.
+
+ Section 4 is organized as follows:
+
+ o Section 4.1 provides the definition of one specific PR-SCTP
+ service: timed reliability.
+
+ o Section 4.2 describes how a particular PR-SCTP service definition
+ is requested by the upper layer during association establishment,
+ and how the upper layer is notified if that request cannot be
+ satisfied.
+
+ o Section 4.3 then provides guidelines for the specification of PR-
+ SCTP services other then the one defined in this memo.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 14]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ o Finally, Section 4.4 describes some additional usage notes that
+ upper layer protocol designers and implementors may find helpful.
+
+4.1. PR-SCTP Service Definition for "timed reliability"
+
+ The "timed reliability" service is a natural extension of the
+ "lifetime" concept already present in the base SCTP protocol.
+
+ When this service is requested for an SCTP association, it changes
+ the meaning of the lifetime parameter specified in the SEND primitive
+ (see Section 10.1, part (E) of RFC 2960 [2]; note that the parameter
+ is spelled "life time" in that document.)
+
+ In the base SCTP protocol, the lifetime parameter is used to avoid
+ sending stale data. When a lifetime value is indicated for a
+ particular message and that lifetime expires, SCTP cancels the
+ sending of this message, and notifies the ULP if the first
+ transmission of the data does not take place (because of rwnd or cwnd
+ limitations, or for any other reason). However, in the base
+ protocol, if SCTP has sent the first transmission before the lifetime
+ expires, then the message MUST be sent as a normal reliable message.
+ During episodes of congestion this is particularly unfortunate, as
+ retransmission wastes bandwidth that could have been used for other
+ (non-lifetime expired) messages.
+
+ When the "timed reliability" service is invoked, this latter
+ restriction is removed. Specifically, when the "timed reliability"
+ service is in effect, the following rules govern all messages that
+ are sent with a lifetime parameter:
+
+ TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE
+ (or unspecified see Section 5), that message is treated as a
+ normal reliable SCTP message, just as in the base SCTP protocol.
+
+ TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see
+ 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 not yet expired.
+
+ TR3) Before assigning a TSN to any message, the SCTP sender MUST
+ evaluate the lifetime of that message. If it is expired, the
+ SCTP sender MUST NOT assign a TSN to that message, but instead,
+ SHOULD issue a notification to the upper layer and abandon the
+ message.
+
+ TR4) Before transmitting or retransmitting a message for which a TSN
+ is already assigned, the SCTP sender MUST evaluate the lifetime
+ of the message. If the lifetime of the message is expired, the
+
+
+
+Stewart, et al. Standards Track [Page 15]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ SCTP sender MUST "abandon" the message, as per the rules
+ specified in Section 3.5 marking that TSN as eligible for
+ forward TSN. Note that this meets the requirement G1 defined in
+ Section 4.3. IMPLEMENTATION NOTE: An implementation SHOULD
+ delay TSN assignment as mentioned in RFC 2960 [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
+ anytime. Expired messages that have not been assigned a TSN MAY
+ be handled as per rule TR3. Expired messages that HAVE been
+ assigned a TSN MAY be handled as per rule TR4.
+
+ TR6) The sending application MUST NOT change the lifetime parameter
+ once the message is passed to the sending SCTP.
+
+ Implementation Note: Rules TR1 through TR4 are designed in such a way
+ as to avoid requiring the implementer to maintain a separate timer
+ for each message; instead, the lifetime need only be evaluated at
+ points in the life of the message where actions are already being
+ taken, such as TSN assignment, transmission, or expiration of a
+ retransmission timeout. Rule TR5 is intended to give the SCTP
+ implementor flexibility to evaluate lifetime at any other convenient
+ opportunity, WITHOUT requiring that lifetime be evaluated immediately
+ at the point in time where it expires.
+
+4.2. PR-SCTP Association Establishment
+
+ An upper layer protocol (ULP) that uses PR-SCTP may need to know
+ whether PR-SCTP can be supported on a given association. Therefore,
+ the ULP needs to have some indication of whether the FORWARD-TSN
+ chunk is supported by its peer.
+
+ Section 10.1 of RFC 2960 [2] describes abstract primitives for the
+ ULP-to-SCTP interface, while noting that "individual implementations
+ must define their own exact format, and may provide combinations or
+ subsets of the basic functions in single calls."
+
+ In this section, we describe one additional return value that may be
+ added to the ASSOCIATE primitive to allow an SCTP service user to
+ indicate whether the FORWARD-TSN chunk is supported by its peer.
+
+ RFC 2960 indicates that the ASSOCIATE primitive "allows the upper
+ layer to initiate an association to a specific peer endpoint". It is
+ structured as follows:
+
+
+
+
+
+Stewart, et al. Standards Track [Page 16]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ Format: ASSOCIATE(local SCTP instance name, destination transport
+ addr, outbound stream count)
+ -> association id [,destination transport addr list]
+ [,outbound stream count]
+
+ This extension adds one new OPTIONAL return value, such that the new
+ primitive reads as follows:
+
+ Format: ASSOCIATE(local SCTP instance name, destination transport
+ addr, outbound stream count )
+ -> association id [,destination transport addr list]
+ [,outbound stream count] [,forward tsn supported]
+
+ NOTE: As per RFC 2960, if the ASSOCIATE primitive is implemented as a
+ non-blocking call, the new OPTIONAL return value shall be passed with
+ the association parameters using the COMMUNICATION UP notification.
+
+ The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
+
+ (0) false [default] indicates that FORWARD TSN is not enabled by both
+ endpoints.
+
+ (1) true indicates that FORWARD TSN is enabled on both endpoints.
+
+ 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
+
+ Other PR-SCTP services may be defined and implemented as dictated by
+ the needs of upper layer protocols. If such upper layer protocols
+ are to be standardized and require some particular PR-SCTP service
+ other than the one defined in this document (i.e., "timed
+ reliability"), then those additional PR-SCTP services should also be
+ specified and standardized in a new RFC.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 17]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ It is suggested that any such additional service definitions be
+ modeled after the contents of Section 4.1. In particular, the
+ service definition should provide:
+
+ 1. A description of how the service user specifies any parameters
+ that need to be associated with a particular message (and/or any
+ other communication that takes place between the application and
+ the SCTP transport sender) that provides the SCTP transport sender
+ with the information needed to determine when to give up on
+ transmission of a particular message.
+
+ Preferably, this description should reference the primitives in
+ the abstract API provided in Section 10 of RFC 2960 [2],
+ indicating any:
+
+ * changes to the interpretation of the existing parameters of
+ existing primitives,
+
+ * additional parameters to be added to existing primitives (these
+ should be OPTIONAL, and default values should be indicated),
+
+ * additional primitives that may be needed.
+
+ 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
+ assigned a TSN. This description should also indicate what
+ protocol events trigger the evaluation, and what actions to take
+ (e.g., notifications.)
+
+ 3. A description of the rules used by the sender side implementation
+ to determine when to give up on the transmission or retransmission
+ of messages that have already been assigned a TSN, and may have
+ been transmitted and possibly retransmitted zero or more times.
+
+ Items (2) and (3) in the list above should also indicate what
+ protocol events trigger the evaluation, and what actions to take if
+ the determination is made that the sender should give up on
+ transmitting the message (e.g., notifications to the ULP.)
+
+ Note that in any PR-SCTP service, the following rule MUST be
+ specified to avoid a protocol deadlock:
+
+ (G1) When the sender side implementation gives up on transmitting a
+ message that has been assigned a TSN (i.e., when that message is
+ "abandoned", as defined in Section 3.4), the sender side MUST
+ mark that TSN as eligible for forward TSN, and the rules in
+ Section 3.4 regarding the sending of FORWARD TSN chunks MUST be
+ followed.
+
+
+
+Stewart, et al. Standards Track [Page 18]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ Finally, a PR-SCTP service definition should specify a "canonical
+ service name" to uniquely identify the service, and distinguish it
+ from other PR-SCTP services. This name can then be used in upper
+ layer protocol standards to indicate which PR-SCTP service definition
+ is required by that upper layer protocol. It can also be used in the
+ documentation of APIs of PR-SCTP implementations to indicate how an
+ upper layer indicates which definition of PR-SCTP service should
+ apply. The canonical service name for the PR-SCTP service defined in
+ Section 4.1 is "timed reliability".
+
+4.4. Usage Notes
+
+ Detecting missing data in a PR-SCTP stream is useful for some
+ applications (e.g., Fibre channel or SCSI over IP). With PR-SCTP,
+ this becomes possible - the upper layer simply needs to examine the
+ stream sequence number of the arrived user messages of that stream to
+ detect any missing data. Note, this detection only works when all
+ the messages on that stream are sent in order, i.e., the "U" bit is
+ not set.
+
+5. Variables
+
+ This section defines variables used throughout this document:
+
+ SCTP_LIFETIME_RELIABLE - A user interface indication defined by an
+ implementation and used to indicate when a message is to be
+ considered fully reliable.
+
+6. Acknowledgments
+
+ The authors would like to thank Brian Bidulock, Scott Bradner, Jon
+ Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias
+ Rodriguez, Ian Rytina, Chip Sharp, and others for their comments.
+
+7. Security Considerations
+
+ This document does not introduce any new security concerns to SCTP
+ other than the ones already documented in RFC 2960 [2]. In
+ particular, this document shares the same security issues as
+ unordered data within RFC 2960 [2] identified by RFC 3436 [4]. An
+ application using the PR-SCTP extension should not use transport
+ layer security; further details can be found in RFC 3436 [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
+
+
+
+Stewart, et al. Standards Track [Page 19]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ MIM to skip selective messages when the application has this feature
+ enabled since the MIM would have less state to maintain.
+
+8. IANA Considerations
+
+ IANA has assigned 192 as a new chunk type to SCTP.
+
+ IANA has assigned 49152 as a new parameter type code to SCTP.
+
+9. References
+
+9.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+ H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
+ "Stream Control Transmission Protocol", RFC 2960, October 2000.
+
+9.2. Informative References
+
+ [3] Clark, D. and D. Tennenhouse, "Architectural Considerations for
+ a New Generation of Protocols", SIGCOMM 1990 pp. 200-208,
+ September 1990.
+
+ [4] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
+ Security over Stream Control Transmission Protocol", RFC 3436,
+ December 2002.
+
+10. Authors' Addresses
+
+ Randall R. Stewart
+ Cisco Systems, Inc.
+ 8725 West Higgins Road
+ Suite 300
+ Chicago, IL 60631
+ USA
+
+ Phone: +1-815-477-2127
+ EMail: rrs@cisco.com
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 20]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+ Michael A. Ramalho
+ Cisco Systems, Inc.
+ 1802 Rue de la Porte
+ Wall Township, NJ 07719-3784
+ USA
+
+ Phone: +1.732.449.5762
+ EMail: mramalho@cisco.com
+
+
+ Qiaobing Xie
+ Motorola, Inc.
+ 1501 W. Shure Drive, #2309
+ Arlington Heights, IL 60004
+ USA
+
+ Phone: +1-847-632-3028
+ EMail: qxie1@email.mot.com
+
+
+ Michael Tuexen
+ Univ. of Applied Sciences Muenster
+ Stegerwaldstr. 39
+ 48565 Steinfurt
+ Germany
+
+ EMail: tuexen@fh-muenster.de
+
+
+ Phillip T. Conrad
+ University of Delaware
+ Department of Computer and Information Sciences
+ Newark, DE 19716
+ USA
+
+ Phone: +1 302 831 8622
+ EMail: conrad@acm.org
+ URI: http://www.cis.udel.edu/~pconrad
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 21]
+
+RFC 3758 SCTP Partial Reliability Extension May 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 22]
+