idnits 2.17.1 draft-ietf-tsvwg-prsctp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 26, 2004) is 7397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft M. Ramalho 4 Expires: July 26, 2004 Cisco Systems, Inc. 5 Q. Xie 6 Motorola, Inc. 7 M. Tuexen 8 Univ. of Applied Sciences Muenster 9 P. Conrad 10 University of Delaware 11 January 26, 2004 13 SCTP Partial Reliability Extension 14 draft-ietf-tsvwg-prsctp-03.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 26, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This memo describes an extension to the Stream Control Transmission 45 Protocol (SCTP) RFC2960 [2] that allows an SCTP endpoint to signal to 46 its peer that it should move the cumulative ack point forward. When 47 both sides of an SCTP association support this extension, it can be 48 used by an SCTP implementation to provide partially reliable data 49 transmission service to an upper layer protocol. This memo describes 50 (1) the protocol extensions, which consist of a new parameter for 51 INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example 52 partially reliable service that can be provided to the upper layer 53 via this mechanism. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Overview of Protocol Extensions . . . . . . . . . . . . . . 3 59 1.2 Overview of New Services Provided to the Upper Layer . . . . 3 60 1.3 Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . 5 63 3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK . . . 5 64 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) . . . 6 65 3.3 Negotiation of Forward-TSN-Supported parameter . . . . . . . 7 66 3.3.1 Sending Forward-TSN-Supported param in INIT . . . . . . . . 7 67 3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or 68 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param . . . . 8 70 3.4 Definition of "abandoned" in the context of PR-SCTP . . . . 8 71 3.5 Sender Side Implementation of PR-SCTP . . . . . . . . . . . 9 72 3.6 Receiver Side Implementation of PR-SCTP . . . . . . . . . . 12 73 4. Services provided by PR-SCTP to the upper layer . . . . . . 14 74 4.1 PR-SCTP Service Definition for "timed reliability" . . . . . 14 75 4.2 PR-SCTP Association Establishment . . . . . . . . . . . . . 16 76 4.3 Guidelines for defining other PR-SCTP Services . . . . . . . 17 77 4.4 Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . 18 78 5. Variables . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 80 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 82 Normative references . . . . . . . . . . . . . . . . . . . . 19 83 Informational References . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . 22 87 1. Introduction 89 This memo describes an extension to the Stream Control Transmission 90 Protocol (SCTP) RFC2960 [2] that allows an SCTP sender to signal to 91 its peer that it should no longer expect to receive one or more DATA 92 chunks. 94 1.1 Overview of Protocol Extensions 96 The protocol extension described in this document consists of two new 97 elements: 98 1. a single new parameter in the INIT/INIT-ACK exchange that 99 indicates whether the endpoint supports the extension 100 2. a single new chunk type, FORWARD TSN, that indicates that the 101 receiver should move its cumulative ack point forward (possibly 102 skipping past one or more DATA chunks that may not yet have been 103 received and/or acknowledged.) 105 1.2 Overview of New Services Provided to the Upper Layer 107 When this extension is supported by both sides of an SCTP 108 association, it can be used to provide partially reliable transport 109 service over an SCTP association. We define partially reliable 110 transport service as a service that allows the user to specify, on a 111 per message basis, the rules governing how persistent the transport 112 service should be in attempting to send the message to the receiver. 114 One example of partially reliable service is specified in this 115 document, namely a "timed reliability" service. This service allows 116 the service user to indicate a limit on the duration of time that the 117 sender should try to transmit/retransmit the message (this is a 118 natural extension of the "lifetime" parameter already in the base 119 protocol). 121 In addition to this example, we will also show that defining the 122 semantics of a particular partially reliable service involves two 123 elements, namely: 124 1. how the service user indicates the level of reliability required 125 for a particular message, and 126 2. how the sender side implementation uses that reliability level to 127 determine when to give up on further retransmissions of that 128 message. 130 Note that other than the fact that the FORWARD-TSN chunk is required, 131 neither of these two elements impacts the "on-the-wire" protocol; 132 only the API, and the sender side implementation is affected by the 133 way in which the service is defined to the upper layer. Therefore, 134 in principle, it is feasible to implement many varieties of partially 135 reliable services in a particular SCTP implementation without 136 changing the on-the-wire protocol. Also, the SCTP receiver does not 137 necessarily need to know which semantics of partially reliable 138 service are being used by the sender, since the receiver's only role 139 is to correctly interpret FORWARD TSN chunks, thereby skipping past 140 messages that the sender has decided to no longer transmit (or 141 retransmit). 143 Nevertheless, it is recommended that a limited number of standard 144 definitions of partially reliable services be standardized by the 145 IETF so that the designers of IETF application layer protocols can 146 match the requirements of their upper layer protocols to standard 147 service definitions provided by a particular SCTP implementation. 148 One such definition, "timed reliability" is included in this 149 document. Given the extensions proposed in this document, other 150 definitions may be standardized as the need arises without further 151 changes to the on-the-wire protocol. 153 1.3 Benefits of PR-SCTP 155 Hereafter, we use the notation "Partial Reliable Stream Control 156 Transmission Protocol (PR-SCTP)" to refer to the SCTP protocol 157 extended as defined in this document. 159 The following are some of the advantages for integrating partially 160 reliable data service into SCTP, i.e., benefits of PR-SCTP: 162 1. Some application layer protocols may benefit from being able to 163 use a single SCTP association to carry both reliable content, -- 164 such as text pages, billing and accounting information, setup 165 signaling -- and unreliable content, e.g. state that is highly 166 sensitive to timeliness, where generating a new packet is more 167 advantageous than transmitting an old one [3]. 168 2. Partially reliable data traffic carried by PR-SCTP will enjoy the 169 same communication failure detection and protection capabilities 170 as the normal reliable SCTP data traffic does. This includes the 171 ability to: - quickly detect a failed destination address; - 172 fail-over to an alternate destination address, and; - be notified 173 if the data receiver becomes unreachable. 174 3. In addition to providing unordered unreliable data transfer as 175 UDP does, PR-SCTP can provide ordered unreliable data transfer 176 service. 177 4. PR-SCTP employs the same congestion control and congestion 178 avoidance for all data traffic, whether reliable or partially 179 reliable - this is very desirable since SCTP enforces 180 TCP-friendliness (unlike UDP.) 181 5. Because of the chunk bundling function of SCTP, reliable and 182 unreliable messages can be multiplexed over a single PR-SCTP 183 association. Therefore, the number of IP datagrams (and hence 184 the network overhead) can be reduced versus having to send these 185 different types of data using separate protocols. Additionally, 186 this multiplexing allows for port savings versus using different 187 ports for reliable and unreliable connections. 189 2. Conventions 191 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 192 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 193 they appear in this document, are to be interpreted as described in 194 RFC2119 [1]. 196 Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are 197 governed by the rules in Section 1.6 of RFC2960 [2]. 199 3. Protocol Changes to support PR-SCTP 201 3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK 203 The following new OPTIONAL parameter is added to the INIT and INIT 204 ACK chunks. 206 Parameter Name Status Type Value 207 ------------------------------------------------------------- 208 Forward-TSN-Suppored OPTIONAL 49152 (0xC000) 210 At the initialization of the association, the sender of the INIT or 211 INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer 212 that it is able to support the Forward TSN chunk (see Section 3.3 for 213 further details). The format of this parameter is defined as follows: 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Parameter Type = 49152 | Parameter Length = 4 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Type: 16 bit u_int 222 49152, indicating Forward-TSN-Supported parameter 224 Length: 16 bit u_int 226 Indicates the size of the parameter i.e., 4. 228 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 230 The following new chunk type is defined: 232 Chunk Type Chunk Name 233 ------------------------------------------------------ 234 192 (0xC0) Forward Cumulative TSN (FORWARD TSN) 236 This chunk shall be used by the data sender to inform the data 237 receiver to adjust its cumulative received TSN point forward because 238 some missing TSNs are associated with data chunks that SHOULD NOT be 239 transmitted or retransmitted by the sender. 241 Forward Cumulative TSN chunk has the following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type = 192 | Flags = 0x00 | Length = Variable | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | New Cumulative TSN | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Stream-1 | Stream Sequence-1 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 \ / 253 / \ 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Stream-N | Stream Sequence-N | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Chunk Flags: 260 Set to all zeros on transmit and ignored on receipt. 262 New Cumulative TSN: 32 bit u_int 264 This indicates the new cumulative TSN to the data receiver. Upon 265 the reception of this value, the data receiver MUST consider 266 any missing TSNs earlier than or equal to this value as received 267 and stop reporting them as gaps in any subsequent SACKs. 269 Stream-N: 16 bit u_int 271 This field holds a stream number that was skipped by this 272 FWD-TSN. 274 Stream Sequence-N: 16 bit u_int 275 This field holds the sequence number associated with the stream 276 that was skipped. The stream sequence field holds the largest stream 277 sequence number in this stream being skipped. The receiver of 278 the FWD-TSN's can use the Stream-N and Stream Sequence-N fields 279 to enable delivery of any stranded TSN's that remain on the stream 280 re-ordering queues. This field MUST NOT report TSN's corresponding 281 to DATA chunk that are marked as unordered. For ordered DATA 282 chunks this field MUST be filled in. 284 3.3 Negotiation of Forward-TSN-Supported parameter 286 3.3.1 Sending Forward-TSN-Supported param in INIT 288 If an SCTP endpoint supports the FORWARD TSN chunk, then any time it 289 sends an INIT during association establishment, it MAY include the 290 Forward-TSN-supported parameter in the INIT chunk to indicate this 291 fact to its peer. 293 Note that if the endpoint chooses NOT to include the parameter, then 294 at no time during the life of the association can it send or process 295 a FORWARD TSN. It MUST instead act as if it does NOT support the 296 FORWARD TSN chunk returning an ERROR to the peer upon receipt of any 297 FORWARD TSN. 299 3.3.2 Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK 301 When a receiver of an INIT detects a Forward-TSN-Supported parameter, 302 and does not support the Forward-TSN chunk type, the receiver MUST 303 follow the rules defined in Section 3.3.3 of RFC2960 [2]. 305 When a receiver of an INIT-ACK detects a Forward-TSN-Supported 306 parameter, and does not support the Forward-TSN chunk type, the 307 receiver MUST follow the rules defined in Section 3.3.3 of RFC2960 308 [2]. 310 When a receiver of an INIT detects a Forward-TSN-Supported parameter, 311 and does support the Forward-TSN chunk type, the receiver MAY respond 312 with a Forward-TSN-supported parameter in the INIT-ACK chunk. 314 Note that if the endpoint chooses NOT to include the parameter, then 315 at no time during the life of the association can it send or process 316 a FORWARD TSN. It MUST instead act as if it does NOT support the 317 FORWARD TSN chunk returning an ERROR to the peer upon receipt of any 318 FORWARD TSN. 320 When an endpoint that supports the FORWARD TSN chunk receives an INIT 321 that does not contain the Forward-TSN-Supported Parameter, that 322 endpoint: 323 o MAY include the Forward-TSN-Supported parameter in the INIT-ACK, 324 o SHOULD record the fact that the peer does not support the FORWARD 325 TSN chunk, 326 o MUST NOT send a FORWARD TSN chunk at any time during the 327 associations life, 328 o SHOULD inform the upper layer, if the upper layer has requested 329 such notification. 331 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param 333 When an SCTP endpoint that desires to use the FORWARD TSN chunk 334 feature for partially reliable data transfer receives an operational 335 error from the remote endpoint (either bundled with the COOKIE or as 336 an unrecognized parameter in the INIT-ACK), indicating that the 337 remote endpoint does not recognize the Forward-TSN-Supported 338 parameter, the local endpoint SHOULD inform its upper layer of the 339 remote endpoint's inability to support partially reliable data 340 transfer. 342 The local endpoint may then choose to either: 343 1) end the initiation process (in cases where the initiation 344 process has already ended the endpoint may need to send an ABORT), 345 in consideration of the peer's inability to supply the requested 346 features for the new association, or 347 2) continue the initiation process (in cases where the initiation 348 process has already completed the endpoint MUST just mark the 349 association as not supporting partial reliability), but with the 350 understanding that partially reliable data transmission is not 351 supported. In this case, the endpoint receiving the operational 352 error SHOULD note that the FORWARD TSN chunk is not supported, and 353 MUST NOT transmit a FORWARD TSN chunk at any time during the life 354 of the association. 356 3.4 Definition of "abandoned" in the context of PR-SCTP 358 At some point, a sending PR-SCTP implementation MAY determine that a 359 particular data chunk SHOULD NOT be transmitted or retransmitted 360 further, in accordance with the rules governing some particular 361 PR-SCTP service definition (such as the definition of "timed 362 reliability" in Section 4.1.) For purposes of this document, we 363 define the term "abandoned" to refer to any data chunk about which 364 the SCTP sender has made this determination. 366 Each PR-SCTP service defines the rules for determining when a TSN is 367 "abandoned", and accordingly, the rules that govern how, whether, and 368 when to "abandon" a TSN may vary from one service definition to 369 another. However, the rules governing the actions taken when a TSN 370 is "abandoned" do NOT vary between service definitions; these rules 371 are included in Section 3.5. 373 3.5 Sender Side Implementation of PR-SCTP 375 The sender side implementation of PR-SCTP is identical to that of the 376 base SCTP protocol, except for: 378 o actions a sending side PR-SCTP implementation must take when a TSN 379 is "abandoned" (as per the rules of whatever PR-SCTP service 380 definition is in effect) 381 o special actions that a PR-SCTP implementation must take upon 382 receipt of SACK 383 o rules governing generation of FORWARD TSN chunks. 385 In detail, these exceptions are as follows: 387 A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer 388 to track a theoretical cumulative TSN point of the peer (Note, 389 this is a _new_ protocol variable and its value is NOT necessarily 390 the same as the SCTP "Cumulative TSN Ack Point" as defined in 391 Section 1.4 of RFC2960 [2]) and discussed throughout that 392 document. 393 A2) From time to time, as governed by the rules of a particular 394 PR-SCTP service definition (see Section 4), the SCTP data sender 395 may make a determination that a particular data chunk that has 396 already been assigned a TSN SHOULD be "abandoned". 398 When a data chunk is "abandoned", the sender MUST treat the data 399 chunk as being finally acked and no longer outstanding. 401 The sender MUST NOT credit an "abandoned" data chunk to the 402 partial_bytes_acked as defined in Section 7.2.2 of RFC2960 [2], 403 and MUST NOT advance the cwnd based on this "abandoned" data 404 chunk. 405 A3) When a TSN is "abandoned", if it is part of a fragmented message, 406 all other TSN's within that fragmented message MUST be abandoned 407 at the same time. 408 A4) Whenever the data sender receives a SACK from the data receiver, 409 it MUST first process the SACK using the normal procedures as 410 defined in Section 6.2.1 of RFC2960 [2]. 412 The data sender MUST then perform the following additional steps : 414 C1) Let SackCumAck be the Cumulative TSN ACK carried in the 415 received SACK. 417 If (Advanced.Peer.Ack.Point < SackCumAck), then update 418 Advanced.Peer.Ack.Point to be equal to SackCumAck. 419 C2) Try to further advance the "Advanced.Peer.Ack.Point" locally, 420 that is, to move "Advanced.Peer.Ack.Point" up as long as the 421 chunk next in the out-queue space is marked as "abandoned" as 422 shown in the following example: 424 Assuming that a SACK arrived with the Cumulative TSN ACK = 425 102 and the Advanced.Peer.Ack.Point is updated to this 426 value: 428 out-queue at the end of ==> out-queue after Adv.Ack.Point 429 normal SACK processing local advancement 431 ... ... 432 Adv.Ack.Pt-> 102 acked 102 acked 433 103 abandoned 103 abandoned 434 104 abandoned Adv.Ack.P-> 104 abandoned 435 105 105 436 106 acked 106 acked 437 ... ... 439 In this example, the data sender successfully advanced the 440 "Advanced.Peer.Ack.Point" from 102 to 104 locally. 441 C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is 442 greater than the Cumulative TSN ACK carried in the received 443 SACK, the data sender MUST send the data receiver a FORWARD TSN 444 chunk containing the latest value of the 445 "Advanced.Peer.Ack.Point". Note that the sender MAY delay the 446 sending of a FORWARD TSN as defined in rule F2 below. 447 IMPLEMENTATION NOTE: It is an implemenation decision as to 448 which destination address is to be sent to, the only 449 restriction being that the address MUST be one that is 450 CONFIRMED. 451 C4) For each "abandoned" TSN the sender of the FORWARD TSN MUST 452 determine if the chunk has a valid stream and sequence number 453 (i.e., it was ordered). If the chunk has a valid stream and 454 sequence number the sender MUST include the stream and sequence 455 number in the FORWARD TSN. This information will enable the 456 receiver to easily find any stranded TSN's waiting on stream 457 reorder queues. Each stream SHOULD only be reported once; this 458 means that if multiple abandoned messages occur in the same 459 stream then only the highest abandoned stream sequence number 460 is reported. If the total size of the FORWARD TSN does NOT fit 461 in a single MTU then the sender of the FORWARD TSN SHOULD lower 462 the Advanced.Peer.Ack.Point to the last TSN that will fit in a 463 single MTU. 464 C5) If a FORWARD TSN is sent, the sender MUST assure that at least 465 one T3-rtx timer is running. 466 IMPLEMENTATION NOTE: Any destination's timer may be used for 467 the purposes of rule C5. 468 A5) Any time the T3-rtx timer expires, on any destination, the sender 469 SHOULD try to advance the "Advanced.Peer.Ack.Point" by following 470 the procedures outlined in C2 - C5. 472 The following additional rules govern the generation of FORWARD TSN 473 chunks: 475 F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other 476 than circumstances described in this document. 477 F2) The data sender SHOULD always attempt to bundle an outgoing 478 FORWARD TSN with outbound DATA chunks for efficiency. 480 A sender MAY even choose to delay the sending of the FORWARD TSN 481 in the hope of bundling it with an outbound DATA chunk. 483 IMPLEMENTATION NOTE: An implementation may wish to limit the 484 number of duplicate FORWARD TSN chunks it sends by either only 485 sending a duplicate FORWARD TSN every other SACK or waiting a full 486 RTT before sending a duplicate FORWARD TSN. 488 IMPLEMENTATION NOTE: An implementation may allow the maximum delay 489 for generating a FORWARD TSN to be configured either statically or 490 dynamically in order to meet the specific timing requirements of 491 the protocol being carried, but see the next rule: 492 F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT 493 exceed 200ms and MUST NOT exceed 500ms. In other words an 494 implementation MAY lower this value below 500ms but MUST NOT raise 495 it above 500ms. 497 NOTE: Delaying the sending of FORWARD TSN chunks may cause delays 498 in the receiver's ability to deliver other data being held at the 499 receiver for re-ordering. The values of 200ms and 500ms match the 500 required values for the delayed acknowledgement in RFC2960 [2] 501 since delaying a FORWARD TSN has the same consequences but in the 502 reverse direction. 503 F4) The detection criterion for out-of-order SACKs MUST remain the 504 same as stated in RFC2960, that is, a SACK is only considered 505 out-of-order if the Cumulative TSN ACK carried in the SACK is 506 earlier than that of the previous received SACK (i.e., the 507 comparison MUST NOT be made against "Advanced.Peer.Ack.Point"). 508 F5) If the decision to "abandon" a chunk is made, no matter how such 509 a decision is made, the appropriate congestion adjustment MUST be 510 made as specified in RFC2960 if the chunk would have been marked 511 for retransmission later (e.g. either by T3-Timeout or by Fast 512 Retransmit). 514 3.6 Receiver Side Implementation of PR-SCTP 516 The receiver side implementation of PR-SCTP at an SCTP endpoint A is 517 capable of supporting any PR-SCTP service definition used by the 518 sender at endpoint B, even if that service definition is not 519 supported by the sending side functionality of host A. All that is 520 necessary is that the receiving side correctly handle the 521 Forward-TSN-Supported parameter as specified in Section 3.3, and 522 correctly handle the receipt of FORWARD TSN chunks as specified 523 below. 525 DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA 526 chunk arrival at a base protocol SCTP receiver---that is, the 527 receiver MUST perform the same TSN handling including duplicate 528 detection, gap detection, SACK generation, cumulative TSN 529 advancement, etc. as defined in RFC2960 [2]---with the following 530 exceptions and additions. 532 When a FORWARD TSN chunk arrives, the data receiver MUST first update 533 its cumulative TSN point to the value carried in the FORWARD TSN 534 chunk, and then MUST further advance its cumulative TSN point locally 535 if possible, as shown by the following example: 537 Assuming that the new cumulative TSN carried in the arrived 538 FORWARD TSN is 103: 540 in-queue before processing in-queue after processing the 541 the FORWARD TSN ==> the FORWARD TSN and further 542 advancement 544 cum.TSN.Pt-> 102 received 102 -- 545 103 missing 103 -- 546 104 received 104 -- 547 105 received cum.TSN.Pt-> 105 received 548 106 missing 106 missing 549 107 received 107 received 550 ... ... 552 In this example, the receiver's cumulative TSN point is first 553 updated to 103 and then further advanced to 105. 555 After the above processing, the data receiver MUST stop reporting any 556 missing TSNs earlier than or equal to the new cumulative TSN point. 558 Note, if the "New Cumulative TSN" value carried in the arrived 559 FORWARD TSN chunk is found to be behind or at the current cumulative 560 TSN point, the data receiver MUST treat this FORWARD TSN as 561 out-of-date and MUST NOT update its Cumulative TSN. The receiver 562 SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since 563 such a duplicate may indicate the previous SACK was lost in the 564 network. 566 Any time a FORWARD TSN chunk arrives, for the purposes of sending a 567 SACK, the receiver MUST follow the same rules as if a DATA chunk had 568 been received (i.e., follow the delayed sack rules specified in 569 RFC2960 [2] section 6.2). 571 Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating 572 ordered delivery) and is out of order, the receiver must hold the 573 chunk for reordering. Since it is possible with PR-SCTP that a DATA 574 chunk being waited upon will not be retransmitted, special actions 575 will need to be taken upon the arrival of a FORWARD TSN. 577 In particular, during processing of a FORWARD TSN, the receiver MUST 578 use the stream sequence information to examine all of the listed 579 stream reordering queues, and immediately make available for delivery 580 stream sequence numbers earlier than or equal to the stream sequence 581 number listed inside the FORWARD TSN. Any such stranded data SHOULD 582 be made immediately available to the upper layer application. 584 An application using PR-SCTP receiving data should be aware of 585 possible missing messages. The stream sequence number can be used, in 586 such a case, to determine that an intervening message has been 587 skipped. When intervening messages are missing it is an application 588 decision to process the messages or to take some other corrective 589 action. 591 After receiving and processing a FORWARD TSN, the data receiver MUST 592 take cautions in updating its re-assembly queue. The receiver MUST 593 remove any partially reassembled message which is still missing one 594 or more TSNs earlier than or equal to the new cumulative TSN point. 595 In the event that the receiver has invoked the partial delivery API a 596 notification SHOULD also be generated to inform the upper layer API 597 that the message being partially delivered will NOT be completed. 599 Note that after receiving a FORWARD TSN and updating the cumulative 600 acknowledgement point, if a TSN that was skipped does arrive (i.e. 601 due to network reordering) then the receiver will follow the normal 602 rules defined in RFC2960 [2] for handling duplicate data. This 603 implies that the receiver will drop the chunk and report it as a 604 duplicate in the next outbound SACK chunk. 606 4. Services provided by PR-SCTP to the upper layer 608 As described in Section 1.2, it is feasible to implement a variety of 609 partially reliable transport services using the new protocol 610 mechanisms introduced in Section 3; introducing these new services 611 requires making changes only at the sending side API, and the sending 612 side protocol implementation. Thus, there may be a temptation to 613 standardize only the protocol, and leave the service definition as 614 "implementation specific" or leave it to be defined in 615 "informational" documents. 617 However, for those who may wish to write IETF standards for upper 618 layer protocols implemented over PR-SCTP, it is important to be able 619 to refer to a standard definition of services provided. Therefore, 620 this section provides an example definitions of one such service, 621 while also providing guidelines for the definition of additional 622 services as required. Each such service may be proposed as a 623 separate new RFC. 625 Section 4 is organized as follows: 626 Section 4.1 provides the definition of one specific PR-SCTP 627 service: timed reliability. 628 Section 4.2 describes how a particular PR-SCTP service definition 629 is requested by the upper layer during association establishment, 630 and how the upper layer is notified if that request cannot be 631 satisfied. 632 Section 4.3 then provides guidelines for the specification of 633 PR-SCTP services other then the one defined in this memo. 634 Finally, Section 4.4 describes some additional usage notes that 635 upper layer protocol designers and implementors may find helpful. 637 4.1 PR-SCTP Service Definition for "timed reliability" 639 The "timed reliability" service is a natural extension of the 640 "lifetime" concept already present in the base SCTP protocol. 642 When this service is requested for an SCTP association, it changes 643 the meaning of the lifetime parameter specified in the SEND primitive 644 (see Section 10.1, part (E) of RFC2960 [2]; note that the parameter 645 is spelled "life time" in that document.) 647 In the base SCTP protocol, the lifetime parameter is used to avoid 648 sending stale data. When a lifetime value is indicated for a 649 particular message and that lifetime expires, SCTP cancels the 650 sending of this message, and notifies the ULP if the first 651 transmission of the data does not take place (because of rwnd or cwnd 652 limitations, or for any other reason). However, in the base 653 protocol, if SCTP has sent the first transmission before the lifetime 654 expires, then the message MUST be sent as a normal reliable message. 655 During episodes of congestion this is particularly unfortunate, as 656 retransmission wastes bandwidth that could have been used for other 657 (non-lifetime expired) messages. 659 When the "timed reliability" service is invoked, this latter 660 restriction is removed. Specifically, when the "timed reliability" 661 service is in effect, the following rules govern all messages that 662 are sent with a lifetime parameter: 664 TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE 665 (or unspecified see Section 5) that message is treated as a normal 666 reliable SCTP message, just as in the base SCTP protocol. 667 TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see 668 Section 5), then the SCTP sender MUST treat the message just as if 669 it were a normal reliable SCTP message as long as the lifetime has 670 not yet expired. 671 TR3) Before assigning a TSN to any message, the SCTP sender MUST 672 evaluate the lifetime of that message. If it is expired, the SCTP 673 sender MUST NOT assign a TSN to that message, but instead, SHOULD 674 issue a notification to the upper layer and abandon the message. 675 TR4) Before transmitting or retransmitting a message for which a TSN 676 is already assigned, the SCTP sender MUST evaluate the lifetime of 677 the message. If the lifetime of the message is expired, the SCTP 678 sender MUST "abandon" the message, as per the rules specified in 679 Section 3.5 marking that TSN as eligible for forward TSN. Note 680 that this meets the requirement G1 defined in Section 4.3 681 IMPLEMENTATION NOTE: An implementation SHOULD delay TSN assignment 682 as mentioned in RFC2960 [2] Section 10.1. In such a case the 683 lifetime parameter should be checked BEFORE assigning a TSN thus 684 allowing a message to be abandoned without the need to send a 685 FORWARD TSN. 686 TR5) The sending SCTP MAY evaluate the lifetime of messages at 687 anytime. Expired messages that have not been assigned a TSN MAY be 688 handled as per rule TR3. Expired messages that HAVE been assigned 689 a TSN MAY be handled as per rule TR4. 690 TR6) The sending application MUST NOT change the lifetime parameter 691 once the message is passed to the sending SCTP. 693 Implementation Note: Rules TR1 through TR4 are designed in such a way 694 as to avoid requiring the implementer to maintain a separate timer 695 for each message; instead, the lifetime need only be evaluated at 696 points in the life of the message where actions are already being 697 taken, such as TSN assignment, transmission, or expiration of a 698 retransmission timeout. Rule TR5 is intended to give the SCTP 699 implementor flexibility to evaluate lifetime at any other convenient 700 opportunity, WITHOUT requiring that lifetime be evaluated immediately 701 at the point in time where it expires. 703 4.2 PR-SCTP Association Establishment 705 An upper layer protocol (ULP) that uses PR-SCTP may need to know 706 whether PR-SCTP can be supported on a given association. Therefore, 707 the ULP needs to have some indication of whether the FORWARD-TSN 708 chunk is supported by its peer. 710 Section 10.1 of RFC2960 [2] describes abstract primitives for the 711 ULP-to-SCTP interface, while noting that "individual implementations 712 must define their own exact format, and may provide combinations or 713 subsets of the basic functions in single calls." 715 In this section, we describe one additional return value that may be 716 added to the ASSOCIATE primitive to allow an SCTP service user to 717 indicate whether the FORWARD-TSN chunk is supported by its peer. 719 RFC2960 indicates that the ASSOCIATE primitive "allows the upper 720 layer to initiate an association to a specific peer endpoint". It is 721 structured as follows: 723 Format: ASSOCIATE(local SCTP instance name, destination transport addr, 724 outbound stream count) 725 -> association id [,destination transport addr list] 726 [,outbound stream count] 728 This extension adds one new OPTIONAL return value, such that the new 729 primitive reads as follows: 731 Format: ASSOCIATE(local SCTP instance name, destination transport addr, 732 outbound stream count ) 733 -> association id [,destination transport addr list] 734 [,outbound stream count] [,forward tsn supported] 736 NOTE: As per RFC2960, if the ASSOCIATE primitive is implemented as a 737 non-blocking call, the new OPTIONAL return value shall be passed with 738 the association parameters using the COMMUNICATION UP notification. 740 The new OPTIONAL parameter "forward tsn supported" is a boolean flag: 742 (0) false [default] indicates that FORWARD TSN is not enabled by both 743 endpoints. 744 (1) true indicates that FORWARD TSN is enabled on both endpoints. 746 We also add a new primitive to allow the user application to enable/ 747 disable the PR-SCTP service on its endpoint before an association is 748 established. 750 Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable) 752 The boolean parameter enable if set to true will enable PR-SCTP upon 753 future endpoint associations. If the boolean parameter is set to 754 false, then the local endpoint will not advertise support of PR-SCTP 755 and thus disable the feature on future associations. It is 756 recommended that this option be disabled by default I.e. in order to 757 enable PR-SCTP the user will need to call this API option with the 758 enable flag set to "true". 760 4.3 Guidelines for defining other PR-SCTP Services 762 Other PR-SCTP services may be defined and implemented as dictated by 763 the needs of upper layer protocols. If such upper layer protocols 764 are to be standardized and require some particular PR-SCTP service 765 other than the one defined in this document (i.e., "timed 766 reliability") then those additional PR-SCTP services should also be 767 specified and standardized in a new RFC. 769 It is suggested that any such additional service definitions be 770 modeled after the contents of Section 4.1 . In particular, the 771 service definition should provide: 773 1. A description of how the service user specifies any parameters 774 that need to be associated with a particular message (and/or any 775 other communication that takes place between the application and 776 the SCTP transport sender) that provides the SCTP transport 777 sender with the information needed to determine when to give up 778 on transmission of a particular message. 780 Preferably this description should reference the primitives in 781 the abstract API provided in Section 10 of RFC2960 [2], 782 indicating any: 783 * changes to the interpretation of the existing parameters of 784 existing primitives, 785 * additional parameters to be added to existing primitives 786 (these should be OPTIONAL, and default values should be 787 indicated), 788 * additional primitives that may be needed. 790 2. A description of the rules used by the sender side implementation 791 to determine when to give up on messages that have not yet been 792 assigned a TSN. This description should also indicate what 793 protocol events trigger the evaluation, and what actions to take 794 (e.g. notifications.) 795 3. A description of the rules used by the sender side implementation 796 to determine when to give up on the transmission or 797 retransmission of messages that have already been assigned a TSN, 798 and may have been transmitted and possibly retransmitted zero or 799 more times. 801 Items (2) and (3) in the list above should also indicate what 802 protocol events trigger the evaluation, and what actions to take if 803 the determination is made that the sender should give up on 804 transmitting the message (e.g. notifications to the ULP.) 806 Note that in any PR-SCTP service, the following rule MUST be 807 specified to avoid a protocol deadlock: 808 (G1) When the sender side implementation gives up on transmitting a 809 message that has been assigned a TSN (i.e., when that message is 810 "abandoned", as defined in Section 3.4) the sender side MUST mark 811 that TSN as eligible for forward TSN, and the rules in Section 3.4 812 regarding the sending of FORWARD TSN chunks MUST be followed. 814 Finally, a PR-SCTP service definition should specify a "canonical 815 service name" to uniquely identify the service, and distinguish it 816 from other PR-SCTP services. This name can then be used in upper 817 layer protocol standards, to indicate which PR-SCTP service 818 definition is required by that upper layer protocol. It can also be 819 used in the documentation of APIs of PR-SCTP implementations to 820 indicate how an upper layer indicates which definition of PR-SCTP 821 service should apply. The canonical service name for the PR-SCTP 822 service defined in Section 4.1 is "timed reliability". 824 4.4 Usage Notes 826 Detecting missing data in a PR-SCTP stream is useful for some 827 applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this 828 becomes possible - the upper layer simply needs to examine the stream 829 sequence number of the arrived user messages of that stream to detect 830 any missing data. Note, this detection only works when all the 831 messages on that stream are sent in order, i.e., the "U" bit is not 832 set. 834 5. Variables 836 This section defines variables used throughout this document: 838 SCTP_LIFETIME_RELIABLE - A user interface indication defined by an 839 implementation and used to indicate when a message is to be 840 considered fully reliable. 842 6. Acknowledgments 844 The authors would like to thank Brian Bidulock, Scott Bradner, Jon 845 Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias 846 Rodriguez, Ian Rytina, Chip Sharp, and others for their comments. 848 7. Security Considerations 850 This document does not introduce any new security concerns to SCTP 851 other than the ones already documented in RFC2960 [2]. In particular 852 this document shares the same security issues as unordered data 853 within RFC2960 [2] identified by RFC3436 [4]. An application using 854 the PR-SCTP extension should not use transport layer security; 855 further details can be found in RFC3436 [4]. 857 Note that the ability to cause a message to be skipped (I.e: the 858 FORWARD TSN chunk) does not provide any new attack for a 859 Man-In-the-Middle (MIM), since the MIM already is capable of changing 860 and/or withholding data thus effectively skipping messages. However 861 the FORWARD TSN chunk does provide a mechanism to make it easier for 862 a MIM to skip selective messages when the application has this 863 feature enabled since the MIM would have less state to maintain. 865 8. IANA Considerations 867 IANA is requested to assign one new chunk type to SCTP using "192" is 868 recommended. An alternate number can be assigned as long as the two 869 upper bits are both set to one. 871 IANA is requested to assign one new parameter type code to SCTP using 872 "49152" is recommended. An altenate number can be assigned as long as 873 the two upper bits are both set to one. 875 Normative references 877 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 878 Levels", BCP 14, RFC 2119, March 1997. 880 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 881 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 882 "Stream Control Transmission Protocol", RFC 2960, October 2000. 884 Informational References 886 [3] Clark, D. and D. Tennenhouse, "Architectural Considerations for 887 a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, 888 September 1990. 890 [4] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 891 3436, December 2002. 893 Authors' Addresses 895 Randall R. Stewart 896 Cisco Systems, Inc. 897 8725 West Higgins Road 898 Suite 300 899 Chicago, IL 60631 900 USA 902 Phone: +1-815-477-2127 903 EMail: rrs@cisco.com 905 Michael A. Ramalho 906 Cisco Systems, Inc. 907 1802 Rue de la Porte 908 Wall Township, NJ 07719-3784 909 USA 911 Phone: +1.732.449.5762 912 EMail: mramalho@cisco.com 914 Qiaobing Xie 915 Motorola, Inc. 916 1501 W. Shure Drive, #2309 917 Arlington Heights, IL 60004 918 USA 920 Phone: +1-847-632-3028 921 EMail: qxie1@email.mot.com 923 Michael Tuexen 924 Univ. of Applied Sciences Muenster 925 Stegerwaldstr. 39 926 48565 Steinfurt 927 Germany 929 EMail: tuexen@fh-muenster.de 930 Phillip T. Conrad 931 University of Delaware 932 Department of Computer and Information Sciences 933 Newark, DE 19716 934 US 936 Phone: +1 302 831 8622 937 EMail: conrad@acm.org 938 URI: http://www.cis.udel.edu/~pconrad 940 Intellectual Property Statement 942 The IETF takes no position regarding the validity or scope of any 943 intellectual property or other rights that might be claimed to 944 pertain to the implementation or use of the technology described in 945 this document or the extent to which any license under such rights 946 might or might not be available; neither does it represent that it 947 has made any effort to identify any such rights. Information on the 948 IETF's procedures with respect to rights in standards-track and 949 standards-related documentation can be found in BCP-11. Copies of 950 claims of rights made available for publication and any assurances of 951 licenses to be made available, or the result of an attempt made to 952 obtain a general license or permission for the use of such 953 proprietary rights by implementors or users of this specification can 954 be obtained from the IETF Secretariat. 956 The IETF invites any interested party to bring to its attention any 957 copyrights, patents or patent applications, or other proprietary 958 rights which may cover technology that may be required to practice 959 this standard. Please address the information to the IETF Executive 960 Director. 962 Full Copyright Statement 964 Copyright (C) The Internet Society (2004). All Rights Reserved. 966 This document and translations of it may be copied and furnished to 967 others, and derivative works that comment on or otherwise explain it 968 or assist in its implementation may be prepared, copied, published 969 and distributed, in whole or in part, without restriction of any 970 kind, provided that the above copyright notice and this paragraph are 971 included on all such copies and derivative works. However, this 972 document itself may not be modified in any way, such as by removing 973 the copyright notice or references to the Internet Society or other 974 Internet organizations, except as needed for the purpose of 975 developing Internet standards in which case the procedures for 976 copyrights defined in the Internet Standards process must be 977 followed, or as required to translate it into languages other than 978 English. 980 The limited permissions granted above are perpetual and will not be 981 revoked by the Internet Society or its successors or assignees. 983 This document and the information contained herein is provided on an 984 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 985 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 986 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 987 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 988 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 990 Acknowledgment 992 Funding for the RFC Editor function is currently provided by the 993 Internet Society.