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