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
<draft-ietf-sigtran-relreq-sctp-01.txt>
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]
