| |
| |
| |
| |
| |
| |
| 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] |
| |