Network Working Group R. R. Stewart INTERNET-DRAFT Cisco Systems Q. Xie Motorola M. Tuexen Siemens AG I. Rytina Ericsson expires in six months February 23, 2001 Generic Method for Transmitting Reliable SCTP Control Chunks Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an extension to the Stream Control Transmission Protocol (SCTP) [RFC2960] to provide a generic method for transmitting a reliable control chunk. This provides a framework whereby future applications which require a specific SCTP control chunk(s) to be sent reliably can use this extension to provide the required functionality. TABLE OF CONTENTS 1. Introduction............................................... 2 2. Conventions................................................ 2 3. Chunk and Parameter Format................................. 2 3.1 New Chunk Types........................................... 2 3.1.1 Reliable Request Chunk (REL-REQ)....................... 2 3.1.2 Reliable Request Acknowledgement (REL-ACK).............. 4 4. Procedures................................................. 5 4.1 Reliable Chunk Procedures................................. 6 4.1.1 Congestion Control of Reliable Chunks................... 7 4.2 Upon reception of a REL-REQ Chunk......................... 7 5. Security Considerations.................................... 9 6. IANA considerations........................................ 9 7. Authors' Addresses.........................................10 8. References.................................................10 1. Introduction Stewart et.al [Page 1] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 Taking advantage of the extensibility of SCTP, this document adds a standard method to SCTP to send and receive reliable control information. This method is designed to be friendly to the TCP type congestion control within the the network. The following are some of the deemed advantages to this extension: A) An uniform method for adding control information that must be sent reliably. B) The reliable transfer extension is designed NOT to interfere with the currently defined congestion control mechanisms within SCTP and the network. This is accomplished by limiting when and how often a reliable control chunk may be sent. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 3. Chunk and Parameter Formats This section specifies the two chunks that are used by the reliable control chunk transfer. Each new chunk is detailed and described. 3.1 New Chunk Types This section defines the two new Chunk types that will be used to transfer reliable control information. Table 1 illustrates the two new chunk types. Chunk Type Chunk Name -------------------------------------------------------------- 11000001 Reliable Request Chunk (REL-REQ) 11000010 Reliable Request Acknowledgement Chunk (REL-ACK) Table 1 - New Chunk types It should be noted that the two reliable Chunk formats also call for the receiver to report to the sender if it does not understand either of the new chunk formats. This is accomplished by setting the upper bit in the Chunk type as described in [RFC2960] section 3.2. The upper two bits in both chunk types are set to one. As defined in [RFC2960] section 3.2, these upper bits set in this manner will cause the receiver that does not understand these chunks to skip these chunks and continue processing, but report in an Operation Error Chunk using the 'Unrecognized Chunk Type' cause of error. 3.1.1 Reliable Request Chunk (REL-REQ) This chunk is used to communicate to the remote endpoint reliable Stewart et.al [Page 2] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 information that must be acknowledged. The information that is being transfered reliably is always in the form of a Tag-Length-Value (TLV) as described in "3.2.1 Optional/Variable-length Parameter Format" in [RFC2960]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xC1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rel-Request Correlation ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REL-REQ Parameter #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / .... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rel-Request Correlation ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REL-REQ Parameter #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Serial Number : 32 bits (unsigned integer) This value represents a Serial Number for the Reliable Chunk. The valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). Serial Numbers wrap back to 0 after reaching 4294967295. Rel-Request Correlation ID: 32 bits (unsigned integer) This is an opaque integer assigned by the sender to identify each request parameter. It is in host byte order and is only meaningful to the sender. The receiver of the REL-REQ will copy this 32 bit value into the Rel-Request Correlation ID field of the REL-AC. The sender of the REL-REQ can use this same value in the REL-ACK to find which request the response is for. REL-REQ Parameter: TLV format Each piece of information that the sending endpoint wishes to communicate reliably is incorporated in a TLV format. Multiple REL-REQ Parameters may be included in a REL-REQ. The REL-REQ Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the REL-REQ Parameter Type. 00 - Reserved (Not Allowed). 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the 'Unrecognized Stewart et.al [Page 3] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 Parameter Type' (in an Error cause placed within the REL-ACK chunk). 10 - Reserved (Not Allowed). 11 - Skip this REL-REQ parameter and continue processing but report the unrecongized parameter in an 'Unrecognized Parameter Type' (in an Error cause placed within the REL-ACK chunk). 3.1.2 Reliable Request Acknowledgement Chunk (REL-ACK) This chunk is used by the receiver of a REL-REQ chunk to acknowledge its reception. It carries zero or more error causes for any REL-REQ Parameters that were not understood (based on the reporting bits as defined in 3.1.1 or refused by the receiver. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xC2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rel-Request Correlation ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REL-REQ Parameter Response #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / .... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rel-Request Correlation ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REL-REQ Parameter Response #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Serial Number : 32 bits (unsigned integer) This value represents the Serial Number for the Reliable Chunk that was received to which this Chunk is acknowledgment of. This value is copied from the received REL-REQ message. Rel-Request Correlation ID: 32 bits (unsigned integer) This value is copied from the REL-REQ Correlation ID received in the REL-REQ. It is used by the receiver of the REL-ACK to identify which REL-REQ parameter this response is associated with. REL-REQ Parameter Response : TLV format The REL-REQ Parameter Error or response is used in the REL-ACK to report errors. By default if a responder does not include a an Error cause, for any requested TLV, a success is indicated. Thus a sender of a REL-ACK MAY indicate complete success of all TLV's in a REL-REQ Stewart et.al [Page 4] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 by returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) and the Serial Number. REL-REQ Parameter Error Type Value ------------------------------------------------- Error Cause TLV 49157 (0xC005) Success report 49158 (0xC008) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 49157 or 49158 | Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Cause(s) or Return Info on Success | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When reporting an error, the response parameter is used to "wrap" one or more standard error cause normally found within an SCTP Operational Error or SCTP Abort (as defined in [RFC2960]). The Error Cause(s) follow the format defined in section 3.3.10 of [RFC2960]. New error causes may be defined according to the application which is using the reliable chunk transfer mechanism. These error causes would be primarily defined to be used as part of the REL-REQ Parameter Error in the REL-ACK (as outlined above), but may be also be used with an Operational Error or an Abort (as defined in [RFC2960]). By default if a responder does not report an error for any requested TLV, a success is implicitly indicated. Thus a sender of a REL-ACK MAY indicate complete success of all TLV's in a REL-REQ by returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) and the Serial Number. The responder MAY also choose to explicitly report a success for a requested TLV, by returning a success report REL-REQ Parameter Response, and MAY also attach a return value (in TLV format) to the success report. The return value TLVs may be defined according to the application which is using the reliable chunk transfer mechanism. 4. Procedures This section will lay out the procedures for the reliable chunk transfer. Future SCTP extensions that wish to use the reliable chunk transfer MUST NOT change the procedures of the chunk transfer itself. Extensions SHOULD detail only procedures related to the REL-REQ Parameters being defined by them. Stewart et.al [Page 5] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 4.1 Reliable Chunk Procedures When an endpoint has reliable control information to be sent to the remote endpoint it should do the following: A1) Create a Reliable Request Chunk as defined in section 3.1.1. The chunk should contain all of the TLV('s) of information necessary to be sent to the remote endpoint, and unique correlation identities for each request. A2) A serial number should be assigned to the Chunk. The serial number should be a monotonically increasing number. All serial numbers are defined to be initialized at the start of the association to the same value as the Initial TSN. A3) If no REL-REQ chunk is outstanding (un-acknowledged) with the remote peer AND there is less than cwnd bytes of user data outstanding send the chunk. A4) Start a T-4 RTO timer, using the RTO value of the selected destination address (normally the primary path see [RFC2960] section 6.4 for details). A5) When the REL-ACK which acknowledges the serial number last sent arrives, stop the T-4 RTO timer and clear the appropriate association and destination error counters as defined in [RFC2960] section 8.1 and 8.2. A6) Process all of the TLV's within the REL-ACK to find out particular status information returned in the various requests that were sent. Use the Correlation IDs to correlate the request and the responses. A7) If an error response is received to a TLV whose parameter type begins 01, all TLVs with no response before the failed TLV are considered successful if not reported. All TLVs after the failed response are considered unsuccessful. A8) If there are no responses to TLVs whose parameter type begins 01, all TLVs not responded to are considered successful. If the T-4 RTO timer expires the endpoint should do the following: B1) Increment the error counter and perform path failure detection on the appropriate destination address as defined in [RFC2960] section 8.2. B2) Increment the association error counter and perform endpoint failure detection on the association as defined in [RFC2960] section 8.1. B3) Retransmit the REL-REQ chunk last sent and if possible choose an alternate destination address (please refer to [RFC2960] section 6.4.1). An endpoint MUST NOT add new parameters to this chunk, it MUST be the same (including its serial number) as the last REL-REQ sent. Stewart et.al [Page 6] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 B4) Restart the T-4 RTO timer. Note: That the the total number of retransmissions is limited by B2 above. If the maximum is reached the association will fail and enter a CLOSED state (see [RFC2960] section 6.4.1 for details). 4.1.1 Congestion Control of Reliable Chunks In defining the reliable chunk transfer procedures it is essential that these transfers MUST NOT cause congestion within the network. To achieve this we place these restrictions on the transfer of reliable chunks: R1) One and only one REL-REQ Chunk MAY be in flight and unacknowledged at any one time. If a sender, after sending a reliable chunk, decides it needs to transfer another REL-REQ Chunk, it MUST wait until the REL-ACK Chunk returns from the previous Chunk before sending a subsequent REL-REQ. Note this restriction binds each side, so at any time two REL-REQ may be in-flight on any given association (one sent from each endpoint). R2) A REL-REQ MUST NOT be sent if there is no room in the current cwnd. If there is room in the cwnd of the destination network the Chunk may be sent regardless of the value of rwnd. R3) A REL-REQ MUST carry only information to be used by the peer SCTP Endpoint (not by the user application). R4) A REL-REQ may be bundled with any other Chunk type except other REL-REQ's. R5) A REL-ACK may be bundled with any other Chunk type except other REL-ACK's. R6) Both REL-ACK and REL-REQ chunks MUST NOT be sent in any SCTP state except ESTABLISHED. R7) A REL-REQ and respective REL-ACK MUST NOT be larger than the path MTU of the destination. 4.2 Upon reception of a REL-REQ Chunk. When an endpoint receives a REL-REQ chunk from the remote peer it should perform the following: C1) Compare the value of the serial number to the value the endpoint stored in a new association variable 'Peer-Serial-Number'. This value MUST be initialized to the Initial TSN value minus 1. C2) If the value found in the serial number is equal to the the ('Peer-Serial-Number' + 1), the endpoint should: Stewart et.al [Page 7] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 V1) Process the TLV's contained within the Chunk performing the appropriate actions as indicated by each TLV type. The TLV's MUST be processed in order within the Chunk. In other words if the sender puts 3 TLV's in one chunk the first TLV (the one closest to the Chunk Header) in the Chunk MUST be processed first. The next TLV in the chunk (the middle one) would be processed second and finally the last TLV in the Chunk would be processed last. V2) In processing the chunk, the receiver should build a response message with the appropriate error TLV's, as specified in the REL-REQ Parameter type bits for any REL-REQ Parameter it does not understand. To indicate an unrecognized parameter, parameter type 8 as defined in in the INIT-ACK in 3.3.3 of [RFC2960] should be used. It may also use the response to carry rejections for other reasons such as resource shortages etc using the Error Cause TLV and an appropriate error condition. Note: a postive response is implied if no error is indicated by the sender. V3) All error responses must copy the Rel-Request Correlation ID field received in the REL-REQ, from the TLV the TLV being responded to, into the Rel-Request Correlation ID field. The Rel-Request Correlation ID always preceeds the request TLV. V4) After processing the entire Chunk, it MUST send all TLV's for both unrecognized parameters and any other status TLV's inside the REL-ACK chunk that acknowledges the arrival and processing of the REL-REQ Chunk. V5) Update the 'Peer-Serial-Number' to the value found in the serial number field. C3) If the value found in the serial number is equal to the value stored in the 'Peer-Serial-Number', the endpoint should: X1) Parse the REL-REQ Chunk TLV's but the endpoint MUST not take any action on the TLV's parsed (since it has already performed these actions). X2) Build a response message with the appropriate response TLV's as specified in the REL-REQ Parameter type bits, for any parameter it does not understand or could not process. X3) After parsing the entire Chunk, it MUST send any response TLV errors and status with a REL-ACK chunk acknowledging the arrival and processing of the REL-REQ Chunk. X4) The endpoint MUST NOT update its 'Peer-Serial-Number'. IMPLEMENTATION NOTE: As an optimization a receiver is allowed to Stewart et.al [Page 8] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 save the last REL-ACK for some predetermined period of time and instead of re-processing the REL-REQ with the same serial number it may jut retransmit the REL-ACK. It may wish to use the arrival of a new serial number to discard the previously saved REL-ACK or any other means it may choose to expire the saved REL-ACK. C4) Otherwise, the REL-REQ chunk is discarded since it must be either a stale packet or from an attacker. C5) In both cases C2:V5 and C3:X3 the REL-ACK MUST be sent back to the source address contained in the IP header of the REL-REQ being responded to. 5. Security Considerations The reliable chunk passing mechanism itself does not add any security considerations other than those addressed by the base level SCTP protocol. However each new extension MAY result in new security threats and each extension SHOULD make appropriate consideration of these threats. 6. IANA considerations Two new SCTP Chunk types are being allocated for use by this feature. The assignment of new REL-REQ Parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the new REL-REQ Parameter MUST contain the following information: a) Name of the REL-REQ Parameter type. b) Detailed description of the structure of the REL-REQ Parameter field. This structure MUST conform to the general type-length-value format described in Section 3.1.1. c) Detailed definition of each component of the REL-REQ Parameter value. d) Detailed description of the intended use of this REL-REQ Parameter type, and an indication of whether and under what circumstances multiple instances of this REL-REQ Parameter type may be found within the same Reliable Request chunk. The assignment of new error causes carried in the REL-ACK is outlined in [RFC2960] section 13.3. Stewart et.al [Page 9] Internet draft Generic Reliable Request Mechanism for SCTP February 2001 7. Authors' Addresses Randall R. Stewart Tel: +1-815-477-2127 Cisco Systems, Inc. EMail: rrs@cisco.com 8745 W. Higgins Road, Suite 200 Chicago, Ill 60631 USA Qiaobing Xie Tel: +1-847-632-3028 Motorola, Inc. EMail: qxie1@email.mot.com 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Michael Tuexen Tel: +49-89-722-47210 SIEMENS AG EMail: Michael.Tuexen@icn.siemens.de Hofmannstr. 51 81359 Munich Germany Ian Rytina Tel: +61-3-9301-6164 Ericsson Australia EMail:ian.rytina@ericsson.com 37/360 Elizabeth Street Melbourne, Victoria 3000 Australia 8. References [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC 2402, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. This Internet Draft expires in 6 months from February, 2001 Stewart et.al [Page 10]