Network Working Group R. Stewart Internet-Draft Adara Networks Intended status: Standards Track M. Tuexen Expires: April 18, 2013 Muenster Univ. of Appl. Sciences P. Mahan Adara Networks October 15, 2012 Quick Start Plus draft-stewart-tsvwg-qsp-01.txt Abstract This document describes an extension to Quick Start including the missing Stream Control Transmission Protocol (SCTP) QuickStart chunk types and procedures so that SCTP may also use the QuickStart extension. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Stewart, et al. Expires April 18, 2013 [Page 1] Internet-Draft QSP October 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Quick Start Extended IP option . . . . . . . . . . . . . . 3 4.2. Quick Start Echo (133) for SCTP . . . . . . . . . . . . . . 5 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Quick Start Added Procedures . . . . . . . . . . . . . . . 5 5.2. SCTP QSE Receiver Procedures . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative references . . . . . . . . . . . . . . . . . . . 8 9.2. Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Stewart, et al. Expires April 18, 2013 [Page 2] Internet-Draft QSP October 2012 1. Introduction QuickStart [RFC4782] was introduced as an expermental RFC in 2007. This document attempts to address several issues in QuickStart including granularity of request, active router participation in quick start besides setup, and the lack of QuickStart for SCTP [RFC4960]. In order to address these issues this document specifies: * An extended format for QuickStart that allows a more finegrained rate to be specified by the router. * A new code QuickStart Function Code to allow a router to initiate a rate change to a transport endpoint. * Chunk format's and handling procedures for SCTP's use of QuickStart. Note that with few exceptions this document does not change the general procedures laid out in [RFC4782] readers unfamiliar with that document are encouraged to read it before reading this document. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology All integer fields defined in this document MUST be transmitted in network byte order, unless otherwise stated. 4. Data Format 4.1. Quick Start Extended IP option Stewart, et al. Expires April 18, 2013 [Page 3] Internet-Draft QSP October 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option | Length=12 | Func. | Rate | QS TTL | | | | 1100 | Upper | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QS Nonce |R|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate Lower | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option: 8 bits As defined in [RFC4782]. Length: 8 bits Contains the value 12 to indicate the new extended option. If the field contains the value 8, then the shorter classic version of the rate is used per [RFC4782]. Function: 4 bits Contains the values 0000 or 1000 as defined in [RFC4782] or the new value 1100 which indicates that a router is adjusting the rate and should be treated the same as a request 0000 (i.e. echoed by the destination endpoint in an appropriate transport option back to the sender of the packet). Rate: 4 bits In the extended form, these four bits are the upper bits of the rate being requested (or set). The combined rate field yeilds a 36 bit integer indicating the number of kilobits per second that is being requested or authorized. QS TTL: 8 bits As defined in [RFC4782]. QS Nonce: 30 bits As defined in [RFC4782]. Reserved: 1 bits Stewart, et al. Expires April 18, 2013 [Page 4] Internet-Draft QSP October 2012 This bit is reserved and SHOULD be set to 0 on transmit and ignored upon reception. E bit: 1 bits This bit is set to 1 to indicate that the extended form of the option is present. This can also be verified by confirming that the length field is set to 12. Rate Lower: 32 bits This field holds the lower 32 bits of the rate. This field is combined with the 4 bit Rate Upper field to yeild a 36 bit rate in kilo-bits per second. 4.2. Quick Start Echo (133) for SCTP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=133| Flags=00000000| Chunk Length = 12 or 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QuickStart Option as copied from IP options field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to all zeros on transmit and ignored on receipt. This parameter contains the exact copy of the IP options field received on the incoming packet that caused this chunk to be sent. The chunk is normally added to the next outgoing packet (often times a SACK or DATA chunk). 5. Procedures 5.1. Quick Start Added Procedures Procedures for the extended form of Quickstart are identical to those defined in [RFC4782]. The only two differences are as follows. First when presented with the extended version of QuickStart the receiver of the IP option must combine the two Rate fields defined to extract the rate information being requested (or authorized). The Stewart, et al. Expires April 18, 2013 [Page 5] Internet-Draft QSP October 2012 handling of the rate by a router is still done as previously, i.e. examine the rate, decrement the TTL and possibly lower the rate (these procedures do not change and remain the same). For an endpoint receiving a QuickStart option in the extended form, the transport option is also increased by four bytes and the entire option is copied and sent to the peer endpoint if the arriving Function Code is either 0000 or the new 1100. Secondly both endpoints and routers may receive the new function code 1100. When such a function code arrives, it should be treated the same as a function code 0000 in classic QuickStart i.e. it is treated as a rate request. If a router is receiving this code, it again looks to see if it needs to lower the rate, decrements the TTL and possibly updates the rate and nonce fields. Transport endpoints receiving this Function code echo the complete 12 byte option within there transport specific manner to the peer transport endpoint (i.e. the sender of the arriving packet that contains the Quickstart option). The sender of the 1100 function code, however is not a transport endpoint requesting a rate. Instead this option may be inserted by any router on the path to adjust the rate of a flow passing through it. The router MUST have flow state and MUST have previously seen a QuickStart Rate Request (Func 0000) and a subsequent Quickstart Rate Report (Func 1000) from that flow before inserting this option. In other words the router MUST know that the flow supports QuickStart and that all downstream routers also support QuickStart. Furthermore the router must know if the extended form of QuickStart is in use by the flow or as an alternative use the non-extended format. This is determined based on if the initial QuickStart Rate Request which was received is in the extended format (aka 12 bytes with the E bit set) or in the old original format (aka 8 bytes with two reserved bits set to zero). When a Router inserts the 1100 funtion code, the router MUST use the last saved QS Nonce and TTL's that were seen when the flow originally sent its QuickStart Rate Request. The router MUST adjust the TTL so that the difference between the original packets Rate Requests TTL is present in the packet being inserted. The router should also adjust the proper field in the nonce per [RFC4782] to reflect which rate range the router was adjusting the flow to. This allows the endpoint to validate both the Nonce and the TTL in the same manner in which it would if it had sent the IP option as a rate request. 5.2. SCTP QSE Receiver Procedures Proceedures for SCTP are identical with those associated with TCP and can be found within [RFC4782]. The key difference is the method in Stewart, et al. Expires April 18, 2013 [Page 6] Internet-Draft QSP October 2012 which the Response Option is carried in SCTP. SCTP does not use options, instead a new chunk is defined that carries either the traditional QuickStart option, or the extended form. At SCTP association startup the two endpoint exchange an INIT and INIT-ACK chunk as defined in [RFC4960]. During this exchange both endpoints MUST include a Supported Extensions chunk as defined in [RFC5061]. Both endpoints MUST indicate support for the new QSE chunk type. If both endpoints do not indicate this then the use of QuickStart is not enabled for this SCTP association. If both endpoints do indicate the support of QuickStart, then the next packet out (usually the Cookie-Echo or Cookie-Ack) SHOULD include an IP option requesting a rate. Note the endpoint SHOULD use the extended format. The fields are initialized the same as defined in [RFC4782] with the exception that if the extended format is used, the rate is an exact 36 bit value representing the requested rate. Upon receiving a packet with an IP option indicating either Function 0000 or Function 1100, the SCTP endpoint MUST include in the next outgoing packet (most likely a SACK or DATA chunk) the QSE chunk with a copy of the IP option that arrived. When receiving a QSE chunk, an endpoint follows the procedures in [RFC4960] validating the TTL difference and the nonce before setting the local cwnd to the new rate. Any validation failure, for example if there is a TTL difference indicating that not all routers participated in the QuickStart exchange, then the endpoint MUST NOT use the QuickStart procedures to change the cwnd. Note that because IP options are not always passed correctly by routers and middle boxes, an endpoint SHOULD be prepared to disable the use of QuickStart if the initial transmissions of the IP option is not acknowledged (e.g. the endpoint sends a COOKIE-ECHO with the QS IP option and the retransmit timer fires due to the lack of a COOKIE-ACK response from the endpoint). 6. Security Considerations [RFC4782] defines the security considerations for Quickstart. These same consideration that are described for TCP are applicable to this document. 7. IANA Considerations Nothing requested. Stewart, et al. Expires April 18, 2013 [Page 7] Internet-Draft QSP October 2012 8. Acknowledgements 9. References 9.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", RFC 4782, January 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. 9.2. Informational References [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Randall R. Stewart Adara Networks Chapin, SC 29036 USA Email: randall@lakerest.net Stewart, et al. Expires April 18, 2013 [Page 8] Internet-Draft QSP October 2012 Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Patrick Mahan Adara Networks Soquel, CA 95073 USA Email: pmahan@adaranetworks.com Stewart, et al. Expires April 18, 2013 [Page 9]