idnits 2.17.1 draft-stewart-tsvwg-qsp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3725 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: 'RFC2481' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 314, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 4782 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 2 errors (**), 0 flaws (~~), 3 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 Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: July 19, 2014 Muenster Univ. of Appl. Sciences 6 January 15, 2014 8 Quick Start Plus 9 draft-stewart-tsvwg-qsp-03.txt 11 Abstract 13 This document describes an extension to Quick Start including the 14 missing Stream Control Transmission Protocol (SCTP) QuickStart chunk 15 types and procedures so that SCTP may also use the QuickStart 16 extension. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 19, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Data Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Quick Start Extended IP option . . . . . . . . . . . . . 3 57 4.2. Quick Start Echo (133) for SCTP . . . . . . . . . . . . . 4 58 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Quick Start Added Procedures . . . . . . . . . . . . . . 5 60 5.2. SCTP QSE Receiver Procedures . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative references . . . . . . . . . . . . . . . . . . 7 66 9.2. Informational References . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 QuickStart [RFC4782] was introduced as an expermental RFC in 2007. 72 This document attempts to address several issues in QuickStart 73 including granularity of request, active router participation in 74 quick start besides setup, and the lack of QuickStart for SCTP 75 [RFC4960]. In order to address these issues this document specifies: 77 * An extended format for QuickStart that allows a more finegrained 78 rate to be specified by the router. 80 * A new code QuickStart Function Code to allow a router to initiate 81 a rate change to a transport endpoint. 83 * Chunk format's and handling procedures for SCTP's use of 84 QuickStart. 86 Note that with few exceptions this document does not change the 87 general procedures laid out in [RFC4782] readers unfamiliar with that 88 document are encouraged to read it before reading this document. 90 2. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Terminology 98 All integer fields defined in this document MUST be transmitted in 99 network byte order, unless otherwise stated. 101 4. Data Format 103 4.1. Quick Start Extended IP option 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Option | Length=12 | Func. | Rate | QS TTL | 109 | | | 1100 | Upper | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | QS Nonce |R|1| 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Rate Lower | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Option: 8 bits 118 As defined in [RFC4782]. 120 Length: 8 bits 122 Contains the value 12 to indicate the new extended option. If the 123 field contains the value 8, then the shorter classic version of 124 the rate is used per [RFC4782]. 126 Function: 4 bits 128 Contains the values 0000 or 1000 as defined in [RFC4782] or the 129 new value 1100 which indicates that a router is adjusting the rate 130 and should be treated the same as a request 0000 (i.e. echoed by 131 the destination endpoint in an appropriate transport option back 132 to the sender of the packet). 134 Rate: 4 bits 136 In the extended form, these four bits are the upper bits of the 137 rate being requested (or set). The combined rate field yeilds a 138 36 bit integer indicating the number of kilobits per second that 139 is being requested or authorized. 141 QS TTL: 8 bits 142 As defined in [RFC4782]. 144 QS Nonce: 30 bits 146 As defined in [RFC4782]. 148 Reserved: 1 bits 150 This bit is reserved and SHOULD be set to 0 on transmit and 151 ignored upon reception. 153 E bit: 1 bits 155 This bit is set to 1 to indicate that the extended form of the 156 option is present. This can also be verified by confirming that 157 the length field is set to 12. 159 Rate Lower: 32 bits 161 This field holds the lower 32 bits of the rate. This field is 162 combined with the 4 bit Rate Upper field to yeild a 36 bit rate in 163 kilo-bits per second. 165 4.2. Quick Start Echo (133) for SCTP 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Chunk Type=133| Flags=00000000| Chunk Length = 12 or 16 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | QuickStart Option as copied from IP options field | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Chunk Flags: 8 bits 177 Set to all zeros on transmit and ignored on receipt. 179 This parameter contains the exact copy of the IP options field 180 received on the incoming packet that caused this chunk to be sent. 181 The chunk is normally added to the next outgoing packet (often 182 times a SACK or DATA chunk). 184 5. Procedures 186 5.1. Quick Start Added Procedures 188 Procedures for the extended form of Quickstart are identical to those 189 defined in [RFC4782]. The only two differences are as follows. 191 First when presented with the extended version of QuickStart the 192 receiver of the IP option must combine the two Rate fields defined to 193 extract the rate information being requested (or authorized). The 194 handling of the rate by a router is still done as previously, i.e. 195 examine the rate, decrement the TTL and possibly lower the rate 196 (these procedures do not change and remain the same). For an 197 endpoint receiving a QuickStart option in the extended form, the 198 transport option is also increased by four bytes and the entire 199 option is copied and sent to the peer endpoint if the arriving 200 Function Code is either 0000 or the new 1100. 202 Secondly both endpoints and routers may receive the new function code 203 1100. When such a function code arrives, it should be treated the 204 same as a function code 0000 in classic QuickStart i.e. it is treated 205 as a rate request. If a router is receiving this code, it again 206 looks to see if it needs to lower the rate, decrements the TTL and 207 possibly updates the rate and nonce fields. Transport endpoints 208 receiving this Function code echo the complete 12 byte option within 209 there transport specific manner to the peer transport endpoint (i.e. 210 the sender of the arriving packet that contains the Quickstart 211 option). 213 The sender of the 1100 function code, however is not a transport 214 endpoint requesting a rate. Instead this option may be inserted by 215 any router on the path to adjust the rate of a flow passing through 216 it. The router MUST have flow state and MUST have previously seen a 217 QuickStart Rate Request (Func 0000) and a subsequent Quickstart Rate 218 Report (Func 1000) from that flow before inserting this option. In 219 other words the router MUST know that the flow supports QuickStart 220 and that all downstream routers also support QuickStart. Furthermore 221 the router must know if the extended form of QuickStart is in use by 222 the flow or as an alternative use the non-extended format. This is 223 determined based on if the initial QuickStart Rate Request which was 224 received is in the extended format (aka 12 bytes with the E bit set) 225 or in the old original format (aka 8 bytes with two reserved bits set 226 to zero). 228 When a Router inserts the 1100 funtion code, the router MUST use the 229 last saved QS Nonce and TTL's that were seen when the flow originally 230 sent its QuickStart Rate Request. The router MUST adjust the TTL so 231 that the difference between the original packets Rate Requests TTL is 232 present in the packet being inserted. The router should also adjust 233 the proper field in the nonce per [RFC4782] to reflect which rate 234 range the router was adjusting the flow to. This allows the endpoint 235 to validate both the Nonce and the TTL in the same manner in which it 236 would if it had sent the IP option as a rate request. 238 5.2. SCTP QSE Receiver Procedures 240 Proceedures for SCTP are identical with those associated with TCP and 241 can be found within [RFC4782]. The key difference is the method in 242 which the Response Option is carried in SCTP. SCTP does not use 243 options, instead a new chunk is defined that carries either the 244 traditional QuickStart option, or the extended form. 246 At SCTP association startup the two endpoint exchange an INIT and 247 INIT-ACK chunk as defined in [RFC4960]. During this exchange both 248 endpoints MUST include a Supported Extensions chunk as defined in 249 [RFC5061]. Both endpoints MUST indicate support for the new QSE 250 chunk type. If both endpoints do not indicate this then the use of 251 QuickStart is not enabled for this SCTP association. If both 252 endpoints do indicate the support of QuickStart, then the next packet 253 out (usually the Cookie-Echo or Cookie-Ack) SHOULD include an IP 254 option requesting a rate. Note the endpoint SHOULD use the extended 255 format. The fields are initialized the same as defined in [RFC4782] 256 with the exception that if the extended format is used, the rate is 257 an exact 36 bit value representing the requested rate. 259 Upon receiving a packet with an IP option indicating either Function 260 0000 or Function 1100, the SCTP endpoint MUST include in the next 261 outgoing packet (most likely a SACK or DATA chunk) the QSE chunk with 262 a copy of the IP option that arrived. 264 When receiving a QSE chunk, an endpoint follows the procedures in 265 [RFC4960] validating the TTL difference and the nonce before setting 266 the local cwnd to the new rate. Any validation failure, for example 267 if there is a TTL difference indicating that not all routers 268 participated in the QuickStart exchange, then the endpoint MUST NOT 269 use the QuickStart procedures to change the cwnd. 271 Note that because IP options are not always passed correctly by 272 routers and middle boxes, an endpoint SHOULD be prepared to disable 273 the use of QuickStart if the initial transmissions of the IP option 274 is not acknowledged (e.g. the endpoint sends a COOKIE-ECHO with the 275 QS IP option and the retransmit timer fires due to the lack of a 276 COOKIE-ACK response from the endpoint). 278 6. Security Considerations 280 [RFC4782] defines the security considerations for Quickstart. These 281 same consideration that are described for TCP are applicable to this 282 document. 284 7. IANA Considerations 286 Nothing requested. 288 8. Acknowledgements 290 9. References 292 9.1. Normative references 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 298 Start for TCP and IP", RFC 4782, January 2007. 300 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 301 4960, September 2007. 303 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 304 Kozuka, "Stream Control Transmission Protocol (SCTP) 305 Dynamic Address Reconfiguration", RFC 5061, September 306 2007. 308 9.2. Informational References 310 [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit 311 Congestion Notification (ECN) to IP", RFC 2481, January 312 1999. 314 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 315 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 316 Zhang, L., and V. Paxson, "Stream Control Transmission 317 Protocol", RFC 2960, October 2000. 319 Authors' Addresses 320 Randall R. Stewart 321 Adara Networks 322 Chapin, SC 29036 323 USA 325 Email: randall@lakerest.net 327 Michael Tuexen 328 Muenster University of Applied Sciences 329 Stegerwaldstr. 39 330 48565 Steinfurt 331 Germany 333 Email: tuexen@fh-muenster.de