idnits 2.17.1 draft-stewart-tsvwg-prsctp-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([5]), 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 (May 16, 2003) is 7650 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: '2' is defined on line 831, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: November 14, 2003 Cisco Systems, Inc. 5 Q. Xie 6 Motorola, Inc. 7 M. Tuexen 8 Univ. of Applied Sciences Muenster 9 P. Conrad 10 Temple University 11 May 16, 2003 13 SCTP Partial Reliability Extension 14 draft-stewart-tsvwg-prsctp-04.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 November 14, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This memo describes an extension to the Stream Control Transmission 45 Protocol (SCTP) RFC2960 [5] 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . 7 63 3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK . . . 7 64 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) . . . 7 65 3.3 Negotiation of Forward-TSN-Supported parameter . . . . . . . 8 66 3.3.1 Sending Forward-TSN-Supported param in INIT . . . . . . . . 8 67 3.3.2 Receipt of Forward-TSN-Supported param in INIT or 68 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param . . . . 9 70 3.4 Definition of "abandoned" in the context of PR-SCTP . . . . 10 71 3.5 Sender Side Implementation of PR-SCTP . . . . . . . . . . . 10 72 3.6 Receiver Side Implementation of PR-SCTP . . . . . . . . . . 13 73 4. Services provided by PR-SCTP to the upper layer . . . . . . 16 74 4.1 PR-SCTP Service Definition for "timed reliability" . . . . . 16 75 4.2 PR-SCTP Association Establishment . . . . . . . . . . . . . 18 76 4.3 Guidelines for defining other PR-SCTP Services . . . . . . . 19 77 4.4 Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . 20 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 79 6. Security Considerations . . . . . . . . . . . . . . . . . . 22 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . 26 85 1. Introduction 87 This memo describes an extension to the Stream Control Transmission 88 Protocol (SCTP) RFC2960 [5] that allows an SCTP sender to signal to 89 its peer that it should no longer expect to receive one or more DATA 90 chunks. 92 1.1 Overview of Protocol Extensions 94 The protocol extension described in this document consists of two new 95 elements: 97 1. a single new parameter in the INIT/INIT-ACK exchange that 98 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: 125 1. how the service user indicates the level of reliability required 126 for a particular message, and 128 2. how the sender side implementation uses that reliability level to 129 determine when to give up on further retransmissions of that 130 message. 132 Note that other than the fact that the FORWARD-TSN chunk is required, 133 neither of these two elements impacts the "on-the-wire" protocol; 134 only the API, and the sender side implementation is affected by the 135 way in which the service is defined to the upper layer. Therefore, 136 in principle, it is feasible to implement many varieties of partially 137 reliable services in a particular SCTP implementation without 138 changing the on-the-wire protocol. Also, the SCTP receiver does not 139 necessarily need to know which semantics of partially reliable 140 service are being used by the sender, since the receiver's only role 141 is to correctly interpret FORWARD TSN chunks, thereby skipping past 142 messages that the sender has decided to no longer transmit (or 143 retransmit). 145 Nevertheless, it is recommended that a limited number of standard 146 definitions of partially reliable services be standardized by the 147 IETF so that that the designers of IETF application layer protocols 148 can match the requirements of their upper layer protocols to standard 149 service definitions provided by a particular SCTP implementation. 150 One such definition, "timed reliability" is included in this 151 document. Given the extensions proposed in this document, other 152 definitions may be standardized as the need arises without further 153 changes to the on-the-wire protocol. 155 1.3 Benefits of PR-SCTP 157 Hereafter, we use the notation "PR-SCTP" to refer to the SCTP 158 protocol extended as defined in this document. 160 The following are some of the advantages for integrating partially 161 reliable data service into SCTP, i.e., benefits of PR-SCTP: 163 1. Some application layer protocols may benefit from being able to 164 use a single SCTP association to carry both reliable content, -- 165 such as text pages, billing and accounting information, setup 166 signaling -- and unreliable content, e.g. state that is highly 167 sensitive to timeliness, where generating a new packet is more 168 advantageous than transmitting an old one [1]. 170 2. Partially reliable data traffic carried by PR-SCTP will enjoy the 171 same communication failure detection and protection capabilities 172 as the normal reliable SCTP data traffic does. This includes the 173 ability to: - quickly detect a failed destination address; - 174 fail-over to an alternate destination address, and; - be notified 175 if the data receiver becomes unreachable. 177 3. In addition to providing unordered unreliable data transfer as 178 UDP does, PR-SCTP can provide ordered unreliable data transfer 179 service. 181 4. PR-SCTP employs the same congestion control and congestion 182 avoidance for all data traffic, whether reliable or partially 183 reliable - this is very desirable since SCTP enforces 184 TCP-friendliness (unlike UDP.) 186 5. Because of the chunk bundling function of SCTP, reliable and 187 unreliable messages can be multiplexed over a single PR-SCTP 188 association. Therefore, the number of IP datagrams (and hence 189 the network overhead) can be reduced versus having to send these 190 different types of data using separate protocols. Additionally, 191 this multiplexing allows for port savings versus using different 192 ports for reliable and unreliable connections. 194 2. Conventions 196 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 197 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 198 they appear in this document, are to be interpreted as described in 199 RFC2119 [3]. 201 Comparisons and arithmetic on TSNs are governed by the rules in 202 Section 1.6 of RFC2960 [5]. 204 3. Protocol Changes to support PR-SCTP 206 3.1 Forward-TSN-Supported Parameter For INIT and INIT ACK 208 The following new OPTIONAL parameter is added to the INIT and INIT 209 ACK chunks. 211 Parameter Name Status Type Value 212 ------------------------------------------------------------- 213 Forward-TSN-Supported OPTIONAL 0xC000 215 At the initialization of the association, the sender of the INIT or 216 INIT ACK chunk shall include this OPTIONAL parameter to inform its 217 peer that it is able to support the Forward TSN chunk. The format of 218 this parameter is defined as follows: 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Parameter Type = 0xC000 | Parameter Length = 4 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Type: 16 bit u_int 227 0xC000, indicating Forward-TSN-Supported parameter 229 Length: 16 bit u_int 231 Indicate the size of the parameter i.e. 4. 233 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 235 The following new chunk type is defined: 237 Chunk Type Chunk Name 238 ------------------------------------------------------ 239 0xC0 Forward Cumulative TSN (FORWARD TSN) 241 This chunk shall be used by the data sender to inform the data 242 receiver to adjust its cumulative received TSN point forward because 243 some missing TSNs are associated with data chunks that SHOULD NOT be 244 transmitted or retransmitted by the sender. 246 Forward Cumulative TSN chunk has the following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 0xC0 | Flags = 0x00 | Length = Variable | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | New Cumulative TSN | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Stream-1 | Stream Sequence-1 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 \ / 258 / \ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Stream-N | Stream Sequence-N | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Chunk Flags: 265 Set to all zeros on transmit and ignored on receipt. 267 New Cumulative TSN: 32 bit u_int 269 This indicates the new cumulative TSN to the data receiver. Upon 270 the reception of this value, the data receiver MUST consider 271 any missing TSNs earlier than or equal to this value as received 272 and stop reporting them as gaps in any subsequent SACKs. 274 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 receiver of the FWD-TSN's can use the Stream-N 283 and Stream Sequence-N fields to enable delivery of any stranded TSN's 284 that remain on the stream re-ordering queues. 286 3.3 Negotiation of Forward-TSN-Supported parameter 288 3.3.1 Sending Forward-TSN-Supported param in INIT 290 If an SCTP endpoint supports the FORWARD TSN chunk, then any time it 291 sends an INIT during association establishment, it SHOULD include the 292 Forward-TSN-supported parameter in the INIT chunk to indicate this 293 fact to its peer. 295 3.3.2 Receipt of Forward-TSN-Supported param in INIT or INIT-ACK 296 When a receiver of an INIT detects a Forward-TSN-Supported parameter, 297 and does not support the Forward-TSN chunk type, the receiver SHOULD 298 treat this parameter as an invalid or unrecognized parameter and 299 respond to the data sender with an unrecognized parameter in the 300 INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960 301 [5]. 303 When a receiver of an INIT-ACK detects a Forward-TSN-Supported 304 parameter, and does not support the Forward-TSN chunk type, the 305 receiver SHOULD treat this parameter as an invalid or unrecognized 306 parameter and respond to the data sender with an unrecognized 307 parameter error, following the rules defined in Section 3.3.3 of 308 RFC2960 [4]. This error SHOULD be reported in an ERROR chunk bundled 309 with the COOKIE-ECHO. 311 When a receiver of an INIT detects a Forward-TSN-Supported parameter, 312 and does support the Forward-TSN chunk type, the receiver SHOULD 313 respond with a Forward-TSN-supported parameter in the INIT-ACK chunk. 315 When an endpoint that supports the FORWARD TSN chunk receives an INIT 316 that does not contain the Forward-TSN-Supported Parameter, that 317 endpoint: 319 o MAY include the Forward-TSN-Supported parameter in the INIT-ACK, 321 o SHOULD record the fact that the peer does not support the FORWARD 322 TSN chunk, 324 o MUST NOT send a FORWARD TSN chunk at any time during the 325 associations life, 327 o SHOULD inform the upper layer, if the upper layer has requested 328 such notification. 330 3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param 332 When an SCTP endpoint that desires to use the FORWARD TSN chunk 333 feature for partially reliable data transfer receives an operational 334 error from the remote endpoint (either bundled with the COOKIE or as 335 a unrecognized parameter in the INIT-ACK), indicating that the remote 336 endpoint does not recognize the Forward-TSN-Supported parameter, the 337 local endpoint SHOULD inform its upper layer of the remote endpoint's 338 inability to support partially reliable data transfer. 340 The local endpoint may then choose to either: 342 1) end the initiation process (in cases where the initiation 343 process has already ended the endpoint may need to send an ABORT), 344 in consideration of the peer's inability to supply the requested 345 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) 382 o special actions that a PR-SCTP implementation must take upon 383 receipt of SACK 385 o rules governing generation of FORWARD TSN chunks. 387 In detail, these exceptions are as follows: 389 A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer 390 to track a theoretical cumulative TSN point of the peer (Note, 391 this is a _new_ protocol variable and its value is NOT necessarily 392 the same as the SCTP "Cumulative TSN Ack Point" as defined in 393 Section 1.4 of RFC2960 [5]) and discussed throughout that 394 document. 396 A2) From time to time, as governed by the rules of a particular 397 PR-SCTP service definition (see Section 4), the SCTP data sender 398 may make a determination that a particular data chunk that has 399 already been assigned a TSN SHOULD be "abandoned". 401 When a data chunk is "abandoned", the sender MUST treat the data 402 chunk as being finally acked and no longer outstanding. 404 The sender MUST NOT credit an "abandoned" data chunk to the 405 partial_bytes_acked as defined in Section 7.2.2 of RFC2960 [5], 406 and MUST NOT advance the cwnd based on this "abandoned" data 407 chunk. 409 A3) Whenever the data sender receives a SACK from the data receiver, 410 it MUST first process the SACK using the normal procedures as 411 defined in Section 6.2.1 of RFC2960 [5]. 413 The data sender MUST then perform the following additional steps : 415 C1) Let SackCumAck be the Cumulative TSN ACK carried in the 416 received SACK. 418 If (Advanced.Peer.Ack.Point < SackCumAck), then update 419 Advanced.Peer.Ack.Point to be equal to SackCumAck. 421 C2) Try to further advance the "Advanced.Peer.Ack.Point" locally, 422 that is, to move "Advanced.Peer.Ack.Point" up as long as the 423 chunk next in the out-queue space is marked as "abandoned" as 424 shown in the following example: 426 Assuming that a SACK arrived with the Cumulative TSN ACK = 427 102 and the Advanced.Peer.Ack.Point is updated to this 428 value: 430 out-queue at the end of ==> out-queue after Adv.Ack.Point 431 normal SACK processing local advancement 432 ... ... 433 Adv.Ack.Pt-> 102 acked 102 acked 434 103 abandoned 103 abandoned 435 104 abandoned Adv.Ack.P-> 104 abandoned 436 105 105 437 106 acked 106 acked 438 ... ... 440 In this example, the data sender successfully advanced the 441 "Advanced.Peer.Ack.Point" from 102 to 104 locally. 443 C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is 444 greater than the Cumulative TSN ACK carried in the received 445 SACK, the data sender MUST send the data receiver a FORWARD TSN 446 chunk containing the latest value of the 447 "Advanced.Peer.Ack.Point". 449 C4) For each "abandoned" TSN the sender of the FORWARD TSN SHOULD 450 list each stream and sequence number in the forwarded TSN. This 451 information will enable the receiver to easily find any 452 stranded TSN's waiting on stream reorder queues. Each stream 453 SHOULD only be reported once; this means that if multiple 454 abandoned messages occur in the same stream then only the 455 highest abandoned stream sequence number is reported. If the 456 total size of the FORWARD TSN does NOT fit in a single MTU then 457 the sender of the FORWARD TSN SHOULD lower the 458 Advanced.Peer.Ack.Point to the last TSN that will fit in a 459 single MTU. 461 C5) If a FORWARD TSN is sent, the sender MUST assure that at least 462 one T3-rtx timer is running. 464 A4) Any time the T3-rtx timer expires, on any destination, the sender 465 SHOULD try to advance the "Advanced.Peer.Ack.Point" by following 466 the procedures outlined in C1 - C5. 468 The following additional rules govern the generation of FORWARD TSN 469 chunks: 471 F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other 472 than circumstances described in this document. 474 F2) The data sender SHOULD always attempt to bundle an outgoing 475 FORWARD TSN with outbound DATA chunks for efficiency. 477 A sender MAY even choose to delay the sending of the FORWARD TSN 478 in the hope of bundling it with an outbound DATA chunk. 480 IMPLEMENTATION NOTE: An implementation may allow the maximum delay 481 for generating a forward TSN to be configured either statically or 482 dynamically in order to meet the specific timing requirements of 483 the protocol being carried, but see the next rule: 485 F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT 486 exceed 200ms and MUST NOT exceed 500ms. In other words an 487 implementation MAY lower this value below 500ms but MUST NOT raise 488 it above 500ms. 490 NOTE: Delaying the sending of FORWARD TSN chunks may cause delays 491 in the receiver's ability to deliver other data being held at the 492 receiver for re-ordering. 494 F4) The detection criterion for out-of-order SACKs MUST remain the 495 same as stated in RFC2960, that is, a SACK is only considered 496 out-of-order if the Cumulative TSN ACK carried in the SACK is 497 earlier than that of the previous received SACK (i.e., the 498 comparison MUST NOT be made against "Advanced.Peer.Ack.Point"). 500 F5 If a decision to "abandon" a chunk is made based on a 501 retransmission decision (e.g T3-Timeout or Fast Retransmit) the 502 appropriate congestion adjustment as specified in RFC2960 MUST be 503 made before any FORWARD TSN chunk is sent. 505 3.6 Receiver Side Implementation of PR-SCTP 507 The receiver side implementation of PR-SCTP at an SCTP endpoint A is 508 capable of supporting any PR-SCTP service definition used by the 509 sender at endpoint B, even if that service definition is not 510 supported by the sending side functionality of host A. All that is 511 necessary is that the receiving side correctly handle the 512 Forward-TSN-Supported parameter as specified in Section 3.3, and 513 correctly handle the receipt of FORWARD TSN chunks as specified 514 below. 516 DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA 517 chunk arrival at a base protocol SCTP receiver---that is, the 518 receiver MUST perform the same TSN handling including duplicate 519 detection, gap detection, SACK generation, cumulative TSN 520 advancement, etc. as defined in RFC2960 [5]---with the following 521 exceptions and additions. 523 When a FORWARD TSN chunk arrives, the data receiver MUST first update 524 its cumulative TSN point to the value carried in the FORWARD TSN 525 chunk, and then MUST further advance its cumulative TSN point locally 526 if possible, as shown by the following example: 528 Assuming that the new cumulative TSN carried in the arrived 529 FORWARD TSN is 103: 531 in-queue before processing in-queue after processing the 532 the FORWARD TSN ==> the FORWARD TSN and further 533 advancement 535 cum.TSN.Pt-> 102 received 102 -- 536 103 missing 103 -- 537 104 received 104 -- 538 105 received cum.TSN.Pt-> 105 received 539 106 missing 106 missing 540 107 received 107 received 541 ... ... 543 In this example, the receiver's cumulative TSN point is first 544 updated to 103 and then further advanced to 105. 546 After the above processing, the data receiver MUST stop reporting any 547 missing TSNs earlier than or equal to the new cumulative TSN point. 549 Note, if the "New Cumulative TSN" value carried in the arrived 550 FORWARD TSN chunk is found to be behind the current cumulative TSN 551 point, the data receiver MUST treat this FORWARD TSN as out-of-date 552 and MUST NOT update its Cumulative TSN. The receiver SHOULD send a 553 SACK to its peer (the sender of the FORWARD TSN) since such a 554 duplicate may indicate the previous SACK was lost in the network. 556 Any time a FORWARD TSN chunk arrives, for the purposes of sending a 557 SACK, the receiver MUST follow the same rules as if a DATA chunk had 558 been received (i.e. follow the delayed sack rules specified in 559 RFC2960 [5] section 6.2). 561 Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating 562 ordered delivery) and is out of order, the receiver must hold the 563 chunk for reordering. Since it is possible with PR-SCTP that a DATA 564 chunk being waited upon will not be retransmitted, special actions 565 will need to be taken upon the arrival of a FORWARD TSN. 567 In particular, during processing of a FORWARD TSN, the receiver MUST 568 use the stream sequence information to examine all of the listed 569 stream reordering queues, and immediately make available for delivery 570 stream sequence numbers earlier than or equal to the stream sequence 571 number listed inside the FORWARD TSN. 573 After receiving and processing a FORWARD TSN, the data receiver MUST 574 take cautions in updating its re-assembly queue. The receiver MUST 575 remove any partially reassembled message which is still missing one 576 or more TSNs earlier than or equal to the new cumulative TSN point. 577 In the event that the receiver has invoked the partial delivery API a 578 notification SHOULD also be generated to inform the upper layer API 579 that the message being partially delivered will NOT be completed. 581 4. Services provided by PR-SCTP to the upper layer 583 As described in Section 1.2, it is feasible to implement a variety of 584 partially reliable transport services using the new protocol 585 mechanisms introduced in Section 3; introducing these new services 586 requires making changes only at the sending side API, and the sending 587 side protocol implementation. Thus, there may be a temptation to 588 standardize only the protocol, and leave the service definition as 589 "implementation specific" or leave it to be defined in 590 "informational" documents. 592 However, for those who may wish to write IETF standards for upper 593 layer protocols implemented over PR-SCTP, it is important to be able 594 to refer to a standard definition of services provided. Therefore, 595 this section provides an example definitions of one such service, 596 while also providing guidelines for the definition of additional 597 services as required. Each such service may be proposed as a 598 separate new standard. 600 Section 4 is organized as follows: 602 Section 4.1 provides the definition of one specific PR-SCTP 603 service: timed reliability. 605 Section 4.2 describes how a particular PR-SCTP service definition 606 is requested by the upper layer during association establishment, 607 and how the upper layer is notified if that request cannot be 608 satisfied. 610 Section 4.3 then provides guidelines for the specification of 611 PR-SCTP services other then the one defined in this memo. 613 Finally, Section 4.4 describes some additional usage notes that 614 upper layer protocol designers and implementors may find helpful. 616 4.1 PR-SCTP Service Definition for "timed reliability" 618 The "timed reliability" service is a natural extension of the 619 "lifetime" concept already present in the base SCTP protocol. 621 When this service is requested for an SCTP association, it changes 622 the meaning of the lifetime parameter specified in the SEND primitive 623 (see Section 10.1, part (E) of RFC2960 [5]; note that the parameter 624 is spelled "life time" in that document.) 626 In the base SCTP protocol, the lifetime parameter is used to avoid 627 sending stale data. When a lifetime value is indicated for a 628 particular message, SCTP cancels the sending of this message, and 629 notifies the ULP if the first transmission of the data does not take 630 place (because of rwnd or cwnd limitations, or for any other reason) 631 before the lifetime expires. However, in the base protocol, if SCTP 632 has sent the first transmission before the lifetime expires, then the 633 message MUST be sent as a normal reliable message. During episodes 634 of congestion this is particularly unfortunate, as retransmission 635 wastes bandwidth that could have been used for other (non-lifetime 636 expired) messages. 638 When the "timed reliability" service is invoked, this latter 639 restriction is removed. Specifically, when the "timed reliability" 640 service is in effect, the following rules govern all messages that 641 are sent with a lifetime parameter: 643 TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE 644 (or unspecified) that message is treated as a normal reliable SCTP 645 message, just as in the base SCTP protocol. 647 TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE, then 648 the SCTP sender MUST treat the message just as if it were a normal 649 reliable SCTP message as long as the lifetime has not yet expired. 651 TR3) Before assigning a TSN to any message, the SCTP sender MUST 652 evaluate the lifetime of that message. If it is expired, the SCTP 653 sender MUST NOT assign a TSN to that message, but instead, SHOULD 654 issue a notification to the upper layer and abandon the message. 656 TR4) Before transmitting or retransmitting a message for which a TSN 657 is already assigned, the SCTP sender MUST evaluate the lifetime of 658 the message. If the lifetime of the message is expired, the SCTP 659 sender MUST "abandon" the message, as per the rules specified in 660 Section 3.5. 662 TR5) The sending SCTP MAY evaluate the lifetime of messages at 663 anytime. Expired messages that have not been assigned a TSN MAY be 664 handled as per rule TR3. Expired messages that HAVE been assigned 665 a TSN MAY be handled as per rule TR4. 667 TR6) The sending application MUST NOT change the lifetime parameter 668 once the message is passed to the sending SCTP. 670 Implementation Note: Rules TR1 through TR4 are designed in such as 671 way to avoid requiring the implementer to maintain a separate timer 672 for each message; instead, the lifetime need only be evaluated at 673 points in the life of the message where actions are already being 674 taken, such as TSN assignment, transmission, or expiration of a 675 retransmission timeout. Rule TR5 is intended to give the SCTP 676 implementor flexibility to evaluate lifetime at any other convenient 677 opportunity, WITHOUT requiring that lifetime be evaluated immediately 678 at the point in time where it expires. 680 4.2 PR-SCTP Association Establishment 682 An upper layer protocol (ULP) that uses PR-SCTP may need to know 683 whether PR-SCTP can be supported on a given association. Therefore, 684 the ULP needs to have some indication of whether the FORWARD-TSN 685 chunk is supported by its peer. 687 Section 10.1 of RFC2960 [5] describes abstract primitives for the 688 ULP-to-SCTP interface, while noting that "individual implementations 689 must define their own exact format, and may provide combinations or 690 subsets of the basic functions in single calls." 692 In this section, we describe one additional return value that may be 693 added to the ASSOCIATE primitive to allow an SCTP service user to 694 indicate whether the FORWARD-TSN chunk is supported by its peer. 696 RFC2960 indicates that the associate primitive "allows the upper 697 layer to initiate an association to a specific peer endpoint". It is 698 structured as follows: 700 Format: ASSOCIATE(local SCTP instance name, destination transport addr, 701 outbound stream count) 702 -> association id [,destination transport addr list] 703 [,outbound stream count] 705 This extension adds one new OPTIONAL return value, such that the new 706 primitive reads as follows: 708 Format: ASSOCIATE(local SCTP instance name, destination transport addr, 709 outbound stream count ) 710 -> association id [,destination transport addr list] 711 [,outbound stream count] [,forward tsn supported] 713 NOTE: As per RFC2960, if the ASSOCIATE primitive is implemented as a 714 non-blocking call, the new OPTIONAL return value shall be passed with 715 the association parameters using the COMMUNICATION UP notification. 717 The new OPTIONAL parameter "forward tsn supported" is a boolean flag: 719 (0) false [default] indicates that FORWARD TSN is not supported by 720 the peer. 722 (1) true indicates that FORWARD TSN is supported by the peer. 724 4.3 Guidelines for defining other PR-SCTP Services 726 Other PR-SCTP services may be defined and implemented as dictated by 727 the needs of upper layer protocols. If such upper layer protocols 728 are to be standardized and require some particular PR-SCTP service 729 other than the one defined in this document (i.e. "timed 730 reliability") then those additional PR-SCTP services should also be 731 specified and standardized. 733 It is suggested that any such additional service definitions be 734 modeled after the contents of Section 4.1 . In particular, the 735 service definition should provide: 737 1. A description of how the service user specifies any parameters 738 that need to be associated with a particular message (and/or any 739 other communication that takes place between the application and 740 the SCTP transport sender) that provides the SCTP transport 741 sender with the information needed to determine when to give up 742 on transmission of a particular message. 744 Preferably this description should reference the primitives in 745 the abstract API provided in Section 10 of RFC2960 [5], 746 indicating any: 748 * changes to the interpretation of the existing parameters of 749 existing primitives, 751 * additional parameters to be added to existing primitives 752 (these should be OPTIONAL, and default values should be 753 indicated), 755 * additional primitives that may be needed. 757 2. A description of the rules used by the sender side implementation 758 to determine when to give up on messages that have not yet been 759 assigned a TSN. This description should also indicate what 760 protocol events trigger the evaluation, and what actions to take 761 (e.g. notifications.) 763 3. A description of the rules used by the sender side implementation 764 to determine when to give up on the transmission or 765 retransmission of messages that have already been assigned a TSN, 766 and may have been transmitted and possibly retransmitted zero or 767 more times. 769 Items (2) and (3) in the list above should also indicate what 770 protocol events trigger the evaluation, and what actions to take if 771 the determination is made that the sender should give up on 772 transmitting the message (e.g. notifications to the ULP.) 774 Note that in any PR-SCTP service, the following rule MUST be 775 specified to avoid a protocol deadlock: 777 (G1) When the sender side implementation gives up on transmitting a 778 message that has been assigned a TSN (i.e., when that message is 779 "abandoned", as defined in Section 3.4) the sender side MUST mark 780 that TSN as eligible for forward TSN, and the rules in Section 3.4 781 regarding the sending of FORWARD TSN chunks MUST be followed. 783 Finally, a PR-SCTP service definition should specify a "canonical 784 service name" to uniquely identify the service, and distinguish it 785 from other PR-SCTP services. This name can then be used in upper 786 layer protocol standards, to indicate which PR-SCTP service 787 definition is required by that upper layer protocol. It can also be 788 used in the documentation of APIs of PR-SCTP implementations to 789 indicate how an upper layer indicates which definition of PR-SCTP 790 service should apply. The canonical service name for the PR-SCTP 791 service defined in Section 4.1 is "timed reliability". 793 4.4 Usage Notes 795 Detecting missing data in a PR-SCTP stream is useful for some 796 applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this 797 becomes possible - the upper layer simply needs to examine the stream 798 sequence number of the arrived user messages of that stream to detect 799 any missing data. Note, this detection only works when all the 800 messages on that stream are sent in order, i.e. the "U" bit is not 801 set. 803 5. Acknowledgments 805 The authors would like to thank Brian Bidulock, Scott Bradner, Jon 806 Berger, Armando L. Caro Jr., John Loughney, Ivan Arias Rodriguez, Ian 807 Rytina, Chip Sharp, and others for their comments. 809 6. Security Considerations 811 This document does not introduce any new security concerns to SCTP 812 other than the ones already documented in RFC2960 [5]. In particular 813 this document shares the same security issues as unordered data 814 within RFC2960 [5]. An application using the PR-SCTP extension should 815 not use transport layer security. Further details can be found in 816 RFC3436 [4]. 818 7. IANA Considerations 820 One new chunk type is added to SCTP ('0xC0') by this document. 822 One new parameter type code is defined by this document to be added 823 to SCTP ('0xC000'). 825 References 827 [1] Clark, D. and D. Tennenhouse, "Architectural Considerations for 828 a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, 829 September 1990. 831 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 832 9, RFC 2026, October 1996. 834 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 835 Levels", BCP 14, RFC 2119, March 1997. 837 [4] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 838 3436, December 2002. 840 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 841 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 842 "Stream Control Transmission Protocol", RFC 2960, October 2000. 844 Authors' Addresses 846 Randall R. Stewart 847 Cisco Systems, Inc. 848 8725 West Higgins Road 849 Suite 300 850 Chicago, IL 60631 851 USA 853 Phone: +1-815-477-2127 854 EMail: rrs@cisco.com 856 Michael A. Ramalho 857 Cisco Systems, Inc. 858 1802 Rue de la Porte 859 Wall Township, NJ 07719-3784 860 USA 862 Phone: +1.732.449.5762 863 EMail: mramalho@cisco.com 864 Qiaobing Xie 865 Motorola, Inc. 866 1501 W. Shure Drive, #2309 867 Arlington Heights, IL 60004 868 USA 870 Phone: +1-847-632-3028 871 EMail: qxie1@email.mot.com 873 Michael Tuexen 874 Univ. of Applied Sciences Muenster 875 Stegerwaldstr. 39 876 48565 Steinfurt 877 Germany 879 EMail: tuexen@fh-muenster.de 881 Phillip T. Conrad 882 Temple University 883 CIS Department 884 Room 303, Computer Building (038-24) 885 1805 N. Broad St. 886 Philadelphia, PA 19122 887 US 889 Phone: +1 215 204 7910 890 EMail: conrad@acm.org 891 URI: http://www.cis.temple.edu/~conrad 893 Intellectual Property Statement 895 The IETF takes no position regarding the validity or scope of any 896 intellectual property or other rights that might be claimed to 897 pertain to the implementation or use of the technology described in 898 this document or the extent to which any license under such rights 899 might or might not be available; neither does it represent that it 900 has made any effort to identify any such rights. Information on the 901 IETF's procedures with respect to rights in standards-track and 902 standards-related documentation can be found in BCP-11. Copies of 903 claims of rights made available for publication and any assurances of 904 licenses to be made available, or the result of an attempt made to 905 obtain a general license or permission for the use of such 906 proprietary rights by implementors or users of this specification can 907 be obtained from the IETF Secretariat. 909 The IETF invites any interested party to bring to its attention any 910 copyrights, patents or patent applications, or other proprietary 911 rights which may cover technology that may be required to practice 912 this standard. Please address the information to the IETF Executive 913 Director. 915 Full Copyright Statement 917 Copyright (C) The Internet Society (2003). All Rights Reserved. 919 This document and translations of it may be copied and furnished to 920 others, and derivative works that comment on or otherwise explain it 921 or assist in its implementation may be prepared, copied, published 922 and distributed, in whole or in part, without restriction of any 923 kind, provided that the above copyright notice and this paragraph are 924 included on all such copies and derivative works. However, this 925 document itself may not be modified in any way, such as by removing 926 the copyright notice or references to the Internet Society or other 927 Internet organizations, except as needed for the purpose of 928 developing Internet standards in which case the procedures for 929 copyrights defined in the Internet Standards process must be 930 followed, or as required to translate it into languages other than 931 English. 933 The limited permissions granted above are perpetual and will not be 934 revoked by the Internet Society or its successors or assignees. 936 This document and the information contained herein is provided on an 937 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 938 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 939 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 940 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 941 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 943 Acknowledgement 945 Funding for the RFC Editor function is currently provided by the 946 Internet Society.