diff options
Diffstat (limited to 'doc/rfc/rfc3758.txt')
| -rw-r--r-- | doc/rfc/rfc3758.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3758.txt b/doc/rfc/rfc3758.txt new file mode 100644 index 0000000..1c0dc15 --- /dev/null +++ b/doc/rfc/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] + |