the sending of a FORWARD TSN as defined in rule F2 below.
IMPLEMENTATION NOTE: It is an implementation decision as to
which destination address it is to be sent to, the only
restriction being that the address MUST be one that is
CONFIRMED.
C4) For each "abandoned" TSN, the sender of the FORWARD TSN MUST
determine if the chunk has a valid stream and sequence number
(i.e., it was ordered). If the chunk has a valid stream and
sequence number, the sender MUST include the stream and
sequence number in the FORWARD TSN. This information will
enable the receiver to easily find any stranded TSN’s waiting
on stream reorder queues. Each stream SHOULD only be
reported once; this means that if multiple abandoned messages
occur in the same stream, then only the highest abandoned
stream sequence number is reported. If the total size of the
FORWARD TSN does NOT fit in a single MTU, then the sender of
the FORWARD TSN SHOULD lower the Advanced.Peer.Ack.Point to
the last TSN that will fit in a single MTU.
C5) If a FORWARD TSN is sent, the sender MUST assure that at
least one T3-rtx timer is running. IMPLEMENTATION NOTE: Any
destination’s timer may be used for the purposes of rule C5.
A5) Any time the T3-rtx timer expires, on any destination, the sender
SHOULD try to advance the "Advanced.Peer.Ack.Point" by following
the procedures outlined in C2 - C5.
The following additional rules govern the generation of FORWARD TSN
chunks:
F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other
than circumstances described in this document.
F2) The data sender SHOULD always attempt to bundle an outgoing
FORWARD TSN with outbound DATA chunks for efficiency.
A sender MAY even choose to delay the sending of the FORWARD TSN
in the hope of bundling it with an outbound DATA chunk.
IMPLEMENTATION NOTE: An implementation may wish to limit the
number of duplicate FORWARD TSN chunks it sends by either only
sending a duplicate FORWARD TSN every other SACK or waiting a
full RTT before sending a duplicate FORWARD TSN.
IMPLEMENTATION NOTE: An implementation may allow the maximum
delay for generating a FORWARD TSN to be configured either
statically or dynamically in order to meet the specific timing
requirements of the protocol being carried, but see the next
rule:
F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT
exceed 200ms and MUST NOT exceed 500ms. In other words, an
implementation MAY lower this value below 500ms but MUST NOT
raise it above 500ms.
NOTE: Delaying the sending of FORWARD TSN chunks may cause delays
in the receiver’s ability to deliver other data being held at the
receiver for re-ordering. The values of 200ms and 500ms match
the required values for the delayed acknowledgement in RFC 2960
[2] since delaying a FORWARD TSN has the same consequences but in
the reverse direction.
F4) The detection criterion for out-of-order SACKs MUST remain the
same as stated in RFC 2960, that is, a SACK is only considered
out-of-order if the Cumulative TSN ACK carried in the SACK is
earlier than that of the previous received SACK (i.e., the
comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
F5) If the decision to "abandon" a chunk is made, no matter how such
a decision is made, the appropriate congestion adjustment MUST be
made as specified in RFC 2960 if the chunk would have been marked
for retransmission later (e.g., either by T3-Timeout or by Fast
Retransmit).
3.6. Receiver Side Implementation of PR-SCTP
The receiver side implementation of PR-SCTP at an SCTP endpoint A is
capable of supporting any PR-SCTP service definition used by the
sender at endpoint B, even if that service definition is not
supported by the sending side functionality of host A. All that is
necessary is that the receiving side correctly handle the Forward-
TSN-Supported parameter as specified in Section 3.3, and correctly
handle the receipt of FORWARD TSN chunks as specified below.
DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA
chunk arrival at a base protocol SCTP receiver---that is, the
receiver MUST perform the same TSN handling, including duplicate
detection, gap detection, SACK generation, cumulative TSN
advancement, etc. as defined in RFC 2960 [2]---with the following
exceptions and additions.
When a FORWARD TSN chunk arrives, the data receiver MUST first update
its cumulative TSN point to the value carried in the FORWARD TSN
chunk, and then MUST further advance its cumulative TSN point locally
if possible, as shown by the following example:
Assuming that the new cumulative TSN carried in the arrived
FORWARD TSN is 103:
in-queue before processing in-queue after processing
the FORWARD TSN ==> the FORWARD TSN and further
advancement
cum.TSN.Pt-> 102 received 102 --
103 missing 103 --
104 received 104 --
105 received cum.TSN.Pt-> 105 received
106 missing 106 missing
107 received 107 received
... ...
In this example, the receiver’s cumulative TSN point is first
updated to 103 and then further advanced to 105.
After the above processing, the data receiver MUST stop reporting any
missing TSNs earlier than or equal to the new cumulative TSN point.
Note, if the "New Cumulative TSN" value carried in the arrived
FORWARD TSN chunk is found to be behind or at the current cumulative
TSN point, the data receiver MUST treat this FORWARD TSN as out-of-
date and MUST NOT update its Cumulative TSN. The receiver SHOULD
send a SACK to its peer (the sender of the FORWARD TSN) since such a
duplicate may indicate the previous SACK was lost in the network.
Any time a FORWARD TSN chunk arrives, for the purposes of sending a
SACK, the receiver MUST follow the same rules as if a DATA chunk had
been received (i.e., follow the delayed sack rules specified in RFC
2960 [2] section 6.2).
Whenever a DATA chunk arrives with the ’U’ bit set to ’0’ (indicating
ordered delivery) and is out of order, the receiver must hold the
chunk for reordering. Since it is possible with PR-SCTP that a DATA
chunk being waited upon will not be retransmitted, special actions
will need to be taken upon the arrival of a FORWARD TSN.
In particular, during processing of a FORWARD TSN, the receiver MUST
use the stream sequence information to examine all of the listed
stream reordering queues, and immediately make available for delivery
stream sequence numbers earlier than or equal to the stream sequence
number listed inside the FORWARD TSN. Any such stranded data SHOULD
be made immediately available to the upper layer application.
An application using PR-SCTP receiving data should be aware of
possible missing messages. The stream sequence number can be used,
in such a case, to determine that an intervening message has been
skipped. When intervening messages are missing, it is an application
decision to process the messages or to take some other corrective
action.
After receiving and processing a FORWARD TSN, the data receiver MUST
take cautions in updating its re-assembly queue. The receiver MUST
remove any partially reassembled message, which is still missing one
or more TSNs earlier than or equal to the new cumulative TSN point.
In the event that the receiver has invoked the partial delivery API,
a notification SHOULD also be generated to inform the upper layer API
that the message being partially delivered will NOT be completed.
Note that after receiving a FORWARD TSN and updating the cumulative
acknowledgement point, if a TSN that was skipped does arrive (i.e.,
due to network reordering), then the receiver will follow the normal
rules defined in RFC 2960 [2] for handling duplicate data. This
implies that the receiver will drop the chunk and report it as a
duplicate in the next outbound SACK chunk.
4. Services provided by PR-SCTP to the upper layer
As described in Section 1.2, it is feasible to implement a variety of
partially reliable transport services using the new protocol
mechanisms introduced in Section 3; introducing these new services
requires making changes only at the sending side API, and the sending
side protocol implementation. Thus, there may be a temptation to
standardize only the protocol, and leave the service definition as
"implementation specific" or leave it to be defined in
"informational" documents.
However, for those who may wish to write IETF standards for upper
layer protocols implemented over PR-SCTP, it is important to be able
to refer to a standard definition of services provided. Therefore,
this section provides example definitions of one such service, while
also providing guidelines for the definition of additional services
as required. Each such service may be proposed as a separate new
RFC.
Section 4 is organized as follows:
o Section 4.1 provides the definition of one specific PR-SCTP
service: timed reliability.
o Section 4.2 describes how a particular PR-SCTP service definition
is requested by the upper layer during association establishment,
and how the upper layer is notified if that request cannot be
satisfied.
o Section 4.3 then provides guidelines for the specification of PR-
SCTP services other then the one defined in this memo.
o Finally, Section 4.4 describes some additional usage notes that
upper layer protocol designers and implementors may find helpful.
4.1. PR-SCTP Service Definition for "timed reliability"
The "timed reliability" service is a natural extension of the
"lifetime" concept already present in the base SCTP protocol.
When this service is requested for an SCTP association, it changes
the meaning of the lifetime parameter specified in the SEND primitive
(see Section 10.1, part (E) of RFC 2960 [2]; note that the parameter
is spelled "life time" in that document.)
In the base SCTP protocol, the lifetime parameter is used to avoid
sending stale data. When a lifetime value is indicated for a
particular message and that lifetime expires, SCTP cancels the
sending of this message, and notifies the ULP if the first
transmission of the data does not take place (because of rwnd or cwnd
limitations, or for any other reason). However, in the base
protocol, if SCTP has sent the first transmission before the lifetime
expires, then the message MUST be sent as a normal reliable message.
During episodes of congestion this is particularly unfortunate, as
retransmission wastes bandwidth that could have been used for other
(non-lifetime expired) messages.
When the "timed reliability" service is invoked, this latter
restriction is removed. Specifically, when the "timed reliability"
service is in effect, the following rules govern all messages that
are sent with a lifetime parameter:
TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE
(or unspecified see Section 5), that message is treated as a
normal reliable SCTP message, just as in the base SCTP protocol.
TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see
Section 5), then the SCTP sender MUST treat the message just as
if it were a normal reliable SCTP message, as long as the
lifetime has not yet expired.
TR3) Before assigning a TSN to any message, the SCTP sender MUST
evaluate the lifetime of that message. If it is expired, the
SCTP sender MUST NOT assign a TSN to that message, but instead,
SHOULD issue a notification to the upper layer and abandon the
message.
TR4) Before transmitting or retransmitting a message for which a TSN
is already assigned, the SCTP sender MUST evaluate the lifetime
of the message. If the lifetime of the message is expired, the
SCTP sender MUST "abandon" the message, as per the rules
specified in Section 3.5 marking that TSN as eligible for
forward TSN. Note that this meets the requirement G1 defined in
Section 4.3. IMPLEMENTATION NOTE: An implementation SHOULD
delay TSN assignment as mentioned in RFC 2960 [2] Section 10.1.
In such a case, the lifetime parameter should be checked BEFORE
assigning a TSN, thus allowing a message to be abandoned without
the need to send a FORWARD TSN.
TR5) The sending SCTP MAY evaluate the lifetime of messages at
anytime. Expired messages that have not been assigned a TSN MAY
be handled as per rule TR3. Expired messages that HAVE been
assigned a TSN MAY be handled as per rule TR4.
TR6) The sending application MUST NOT change the lifetime parameter
once the message is passed to the sending SCTP.
Implementation Note: Rules TR1 through TR4 are designed in such a way
as to avoid requiring the implementer to maintain a separate timer
for each message; instead, the lifetime need only be evaluated at
points in the life of the message where actions are already being
taken, such as TSN assignment, transmission, or expiration of a
retransmission timeout. Rule TR5 is intended to give the SCTP
implementor flexibility to evaluate lifetime at any other convenient
opportunity, WITHOUT requiring that lifetime be evaluated immediately
at the point in time where it expires.
4.2. PR-SCTP Association Establishment
An upper layer protocol (ULP) that uses PR-SCTP may need to know
whether PR-SCTP can be supported on a given association. Therefore,
the ULP needs to have some indication of whether the FORWARD-TSN
chunk is supported by its peer.
Section 10.1 of RFC 2960 [2] describes abstract primitives for the
ULP-to-SCTP interface, while noting that "individual implementations
must define their own exact format, and may provide combinations or
subsets of the basic functions in single calls."
In this section, we describe one additional return value that may be
added to the ASSOCIATE primitive to allow an SCTP service user to
indicate whether the FORWARD-TSN chunk is supported by its peer.
RFC 2960 indicates that the ASSOCIATE primitive "allows the upper
layer to initiate an association to a specific peer endpoint". It is
structured as follows:
Format: ASSOCIATE(local SCTP instance name, destination transport
addr, outbound stream count)
-> association id [,destination transport addr list]
[,outbound stream count]
This extension adds one new OPTIONAL return value, such that the new
primitive reads as follows:
Format: ASSOCIATE(local SCTP instance name, destination transport
addr, outbound stream count )
-> association id [,destination transport addr list]
[,outbound stream count] [,forward tsn supported]
NOTE: As per RFC 2960, if the ASSOCIATE primitive is implemented as a
non-blocking call, the new OPTIONAL return value shall be passed with
the association parameters using the COMMUNICATION UP notification.
The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
(0) false [default] indicates that FORWARD TSN is not enabled by both
endpoints.
(1) true indicates that FORWARD TSN is enabled on both endpoints.
We also add a new primitive to allow the user application to enable/
disable the PR-SCTP service on its endpoint before an association is
established.
Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable)
The boolean parameter enable, if set to true, will enable PR-SCTP
upon future endpoint associations. If the boolean parameter is set
to false, then the local endpoint will not advertise support of PR-
SCTP and thus disable the feature on future associations. It is
recommended that this option be disabled by default, i.e., in order
to enable PR-SCTP, the user will need to call this API option with
the enable flag set to "true".
4.3. Guidelines for defining other PR-SCTP Services
Other PR-SCTP services may be defined and implemented as dictated by
the needs of upper layer protocols. If such upper layer protocols
are to be standardized and require some particular PR-SCTP service
other than the one defined in this document (i.e., "timed
reliability"), then those additional PR-SCTP services should also be
specified and standardized in a new RFC.
It is suggested that any such additional service definitions be
modeled after the contents of Section 4.1. In particular, the
service definition should provide:
1. A description of how the service user specifies any parameters
that need to be associated with a particular message (and/or any
other communication that takes place between the application and
the SCTP transport sender) that provides the SCTP transport sender
with the information needed to determine when to give up on
transmission of a particular message.
Preferably, this description should reference the primitives in
the abstract API provided in Section 10 of RFC 2960 [2],
indicating any:
* changes to the interpretation of the existing parameters of
existing primitives,
* additional parameters to be added to existing primitives (these
should be OPTIONAL, and default values should be indicated),
* additional primitives that may be needed.
2. A description of the rules used by the sender side implementation
to determine when to give up on messages that have not yet been
assigned a TSN. This description should also indicate what
protocol events trigger the evaluation, and what actions to take
(e.g., notifications.)
3. A description of the rules used by the sender side implementation
to determine when to give up on the transmission or retransmission
of messages that have already been assigned a TSN, and may have
been transmitted and possibly retransmitted zero or more times.
Items (2) and (3) in the list above should also indicate what
protocol events trigger the evaluation, and what actions to take if
the determination is made that the sender should give up on
transmitting the message (e.g., notifications to the ULP.)
Note that in any PR-SCTP service, the following rule MUST be
specified to avoid a protocol deadlock:
(G1) When the sender side implementation gives up on transmitting a
message that has been assigned a TSN (i.e., when that message is
"abandoned", as defined in Section 3.4), the sender side MUST
mark that TSN as eligible for forward TSN, and the rules in
Section 3.4 regarding the sending of FORWARD TSN chunks MUST be
followed.
Finally, a PR-SCTP service definition should specify a "canonical
service name" to uniquely identify the service, and distinguish it
from other PR-SCTP services. This name can then be used in upper
layer protocol standards to indicate which PR-SCTP service definition
is required by that upper layer protocol. It can also be used in the
documentation of APIs of PR-SCTP implementations to indicate how an
upper layer indicates which definition of PR-SCTP service should
apply. The canonical service name for the PR-SCTP service defined in
Section 4.1 is "timed reliability".
4.4. Usage Notes
Detecting missing data in a PR-SCTP stream is useful for some
applications (e.g., Fibre channel or SCSI over IP). With PR-SCTP,
this becomes possible - the upper layer simply needs to examine the
stream sequence number of the arrived user messages of that stream to
detect any missing data. Note, this detection only works when all
the messages on that stream are sent in order, i.e., the "U" bit is
not set.
5. Variables
This section defines variables used throughout this document:
SCTP_LIFETIME_RELIABLE - A user interface indication defined by an
implementation and used to indicate when a message is to be
considered fully reliable.
6. Acknowledgments
The authors would like to thank Brian Bidulock, Scott Bradner, Jon
Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias
Rodriguez, Ian Rytina, Chip Sharp, and others for their comments.
7. Security Considerations
This document does not introduce any new security concerns to SCTP
other than the ones already documented in RFC 2960 [2]. In
particular, this document shares the same security issues as
unordered data within RFC 2960 [2] identified by RFC 3436 [4]. An
application using the PR-SCTP extension should not use transport
layer security; further details can be found in RFC 3436 [4].
Note that the ability to cause a message to be skipped (i.e, the
FORWARD TSN chunk) does not provide any new attack for a Man-In-the-
Middle (MIM), since the MIM already is capable of changing and/or
withholding data, thus effectively skipping messages. However, the
FORWARD TSN chunk does provide a mechanism to make it easier for a
MIM to skip selective messages when the application has this feature
enabled since the MIM would have less state to maintain.
8. IANA Considerations
IANA has assigned 192 as a new chunk type to SCTP.
IANA has assigned 49152 as a new parameter type code to SCTP.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
9.2. Informative References
[3] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols", SIGCOMM 1990 pp. 200-208,
September 1990.
[4] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
10. Authors’ Addresses
Randall R. Stewart
Cisco Systems, Inc.
8725 West Higgins Road
Suite 300
Chicago, IL 60631
USA
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Michael A. Ramalho
Cisco Systems, Inc.
1802 Rue de la Porte
Wall Township, NJ 07719-3784
USA
Phone: +1.732.449.5762
EMail: mramalho@cisco.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com