draft-ietf-tsvwg-sctpimpguide-03.txt   draft-ietf-tsvwg-sctpimpguide-04.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
L. Ong L. Ong
Ciena Systems Ciena Systems
I. Arias-Rodriguez I. Arias-Rodriguez
Nokia Nokia
K. Poon K. Poon
Sun Microsystems Sun Microsystems
expires in six months January 29 2002 expires in six months January 29 2002
SCTP Implementors Guide SCTP Implementors Guide
<draft-ietf-tsvwg-sctpimpguide-03.txt> <draft-ietf-tsvwg-sctpimpguide-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
January 2002 for the Stream Control Transmission Protocol (SCTP) January 2002 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of SCTP to clarify errors in the original SCTP the implementation of SCTP to clarify errors in the original SCTP
document. document.
This document updates RFC2960 and text within this document This document updates RFC2960 and text within this document
supersedes the text found in RFC2960. supersedes the text found in RFC2960.
Table of Contents Table of Contents
1. Introduction......................................... 2 1. Introduction.........................................
1.1 Conventions........................................ 2 1.1 Conventions........................................
2. Corrections to RFC2960............................... 2 2. Corrections to RFC2960...............................
2.1 Incorrect error type during chunk processing....... 3 2.1 Incorrect error type during chunk processing.......
2.2 Parameter processing issue......................... 3 2.2 Parameter processing issue.........................
2.3 Padding issues..................................... 4 2.3 Padding issues.....................................
2.4 Parameter types across all chunk types............. 5 2.4 Parameter types across all chunk types.............
2.5 Stream parameter clarification..................... 7 2.5 Stream parameter clarification.....................
2.6 Restarting association security issue.............. 8 2.6 Restarting association security issue..............
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....12 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....
2.8 Issues with Fast Retransmit........................12 2.8 Issues with Fast Retransmit........................
2.9 Missing statement about partial_bytes_acked update.17 2.9 Missing statement about partial_bytes_acked update.
2.10 Issues with Heartbeating and failure detection....18 2.10 Issues with Heartbeating and failure detection....
2.11 Security interactions with firewalls..............21 2.11 Security interactions with firewalls..............
2.12 Shutdown ambiguity................................22 2.12 Shutdown ambiguity................................
2.13 Inconsistency in ABORT processing.................23 2.13 Inconsistency in ABORT processing.................
2.14 Cwnd gated by its full use in Slow start..........24 2.14 Cwnd gated by its full use in Slow start..........
2.15 Window probes in SCTP.............................25 2.15 Window probes in SCTP.............................
2.16 Fragmentation and Path MTU issues.................27 2.16 Fragmentation and Path MTU issues.................
3. Acknowledgments......................................28 2.17 Initial value of the cumulative TSN ACK...........
4. Authors' Addresses...................................29 2.18 Handling of address parameters within the INIT or
5. References...........................................29 INIT-ACK..........................................
2.19 Handling of stream shortages......................
2.20 Indefinite postponement...........................
3. Acknowledgments......................................
4. Authors' Addresses...................................
5. References...........................................
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
January 2002 for the Stream Control Transmission Protocol (SCTP) January 2002 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of SCTP to clarify errors in the original SCTP the implementation of SCTP to clarify errors in the original SCTP
document. document.
skipping to change at page 28, line 46 skipping to change at page 28, line 52
IMPLEMENTATION NOTE: In this error case, the Send primitive IMPLEMENTATION NOTE: In this error case, the Send primitive
discussed in Section 10.1 would need to return an error to the upper discussed in Section 10.1 would need to return an error to the upper
layer. layer.
2.16.3 Solution description 2.16.3 Solution description
The above wording will allow an implementation to offer the The above wording will allow an implementation to offer the
option of rejecting sends that exceed the P-MTU size even option of rejecting sends that exceed the P-MTU size even
when the implementation supports fragmentation. when the implementation supports fragmentation.
2.17 Initial value of the cumulative TSN Ack
2.17.1 Description of the problem
The current description of the SACK chunk within the RFC does not
clearly state the value that would be put within a
SACK when no DATA chunk has been received.
2.17.2 Text changes to the document
---------
Old text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap.
---------
New text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. In the case where no DATA chunk has
been received, this value is set to the peers Initial TSN minus
one.
2.17.3 Solution description
This change clearly states what the initial value will be for a
SACK sender.
2.18 Handling of address parameters within the INIT or INIT-ACK
2.18.1 Description of the problem
The current description on handling address parameters contained
within the INIT and INIT-ACK do not fully describe a requirement
for their handling.
2.18.2 Text changes to the document
---------
Old text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver shall derive and record all the
transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
---------
New text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver shall derive and record all the
transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
D) When searching for a matching TCB upon reception of an INIT
or INIT-ACK chunk the receiver SHOULD use not only the
source address of the packet (containing the INIT or
INIT-ACK) but the receiver SHOULD also use all valid
address parameters contained within the chunk.
2.18.3 Solution description
This new text clearly specifies to an implementor the need
to look within the INIT or INIT-ACK. Any implementation that
does not do this, may not be able to establish associations
in certain circumstances.
2.19 Handling of stream shortages
2.19.1 Description of the problem
The current wording in the RFC places the choice of sending
an ABORT upon the SCTP stack when a stream shortage occurs.
This decision should really be made by the upper layer
not the SCTP stack.
2.19.2 Text changes to the document
---------
Old text:
---------
5.1.1 Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint.
After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST either use MIS outbound streams, or
abort the association and report to its upper layer the resources
shortage at its peer.
---------
New text: (Section 5.1.2)
---------
5.1.1 Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint.
After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST use MIS outbound streams and MAY
report any shortage to the upper layer. The upper layer can then
choose to abort the association if the resource shortage
is unacceptable.
2.19.3 Solution description
The above changes take the decision to ABORT out of the
realm of the SCTP stack and places it into the users
hands.
2.20 Indefinite postponement
2.20.1 Description of the problem
The current RFC does not provide any guidance on the assignment
of TSN sequence numbers to outbound message nor reception of
these message. This could lead to a possible indefinite postponement.
2.20.2 Text changes to the document
---------
Old text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
6.2 Acknowledgment on Reception of DATA Chunks
---------
New text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
The algorithm by which an implementation assigns sequential TSNs to
messages on a particular association MUST ensure that no user
message that has been accepted by SCTP is indefinitely postponed
from being assigned a TSN. Acceptable algorithms for assigning TSNs
include
(a) assigning TSNs in round-robin order over all streams with
pending data
(b) preserving the linear order in which the user messages were
submitted to the SCTP association.
When an upper layer requests to read data on an SCTP association,
the SCTP receiver SHOULD choose the message with the lowest TSN from
among all deliverable messages. In SCTP implementations that allow a
user to request data on a specific stream, this operation SHOULD NOT
block if data is not available, since this can lead to a deadlock
under certain conditions.
6.2 Acknowledgment on Reception of DATA Chunks
2.20.3 Solution description
The above wording clarifies how TSNs SHOULD be assigned by
the sender.
3. Acknowledgments 3. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input for this document: provided comments and input for this document:
For their comments on the list, Atsushi Fukumoto, David Lehmann. For their comments on the list, Atsushi Fukumoto, David Lehmann.
For their participation in the RTP Bakeoff number 2 and all of their For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/