draft-ietf-tsvwg-sctpimpguide-10.txt   draft-ietf-tsvwg-sctpimpguide-11.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 13, 2004 I. Arias-Rodriguez Expires: March 21, 2005 I. Arias-Rodriguez
Nokia Research Center Nokia Research Center
K. Poon K. Poon
Consultant Sun Microsystems, Inc.
A. Caro A. Caro
University of Delaware University of Delaware
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Muenster Univ. of Applied Sciences
November 13, 2003 September 20, 2004
Stream Control Transmission Protocol (SCTP) Implementer's Guide Stream Control Transmission Protocol (SCTP) Implementer's Guide
draft-ietf-tsvwg-sctpimpguide-10.txt draft-ietf-tsvwg-sctpimpguide-11.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2004. This Internet-Draft will expire on March 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors document to be used in the implementation of SCTP to clarify errors
in the original SCTP document. in the original SCTP document.
This document updates RFC2960 [5] and text within this document This document updates RFC2960 [6] and text within this document
supersedes the text found in RFC2960 [5]. supersedes the text found in RFC2960 [6].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 7 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . . 5
2.1 Incorrect error type during chunk processing. . . . . . . 7 2.1 Incorrect error type during chunk processing. . . . . . . 5
2.1.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 5
2.1.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 7 2.4 Parameter types across all chunk types . . . . . . . . . . 8
2.2 Parameter processing issue . . . . . . . . . . . . . . . . 7 2.5 Stream parameter clarification . . . . . . . . . . . . . . 10
2.2.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.6 Restarting association security issue . . . . . . . . . . 11
2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 15
2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 8 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 16
2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Description of the problem . . . . . . . . . . . . . . . . 8
2.3.2 Text changes to the document . . . . . . . . . . . . . . . 8
2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 10
2.4 Parameter types across all chunk types . . . . . . . . . . 10
2.4.1 Description of the problem . . . . . . . . . . . . . . . . 10
2.4.2 Text changes to the document . . . . . . . . . . . . . . . 10
2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 11
2.5 Stream parameter clarification . . . . . . . . . . . . . . 12
2.5.1 Description of the problem . . . . . . . . . . . . . . . . 12
2.5.2 Text changes to the document . . . . . . . . . . . . . . . 12
2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 12
2.6 Restarting association security issue . . . . . . . . . . 13
2.6.1 Description of the problem . . . . . . . . . . . . . . . . 13
2.6.2 Text changes to the document . . . . . . . . . . . . . . . 13
2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 17
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 17
2.7.1 Description of the problem . . . . . . . . . . . . . . . . 17
2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17
2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 18
2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 18
2.8.1 Description of the problem . . . . . . . . . . . . . . . . 18
2.8.2 Text changes to the document . . . . . . . . . . . . . . . 18
2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 21
2.9 Missing statement about partial_bytes_acked update . . . . 21 2.9 Missing statement about partial_bytes_acked update . . . . 21
2.9.1 Description of the problem . . . . . . . . . . . . . . . . 21 2.10 Issues with Heartbeating and failure detection . . . . . 22
2.9.2 Text changes to the document . . . . . . . . . . . . . . . 22 2.11 Security interactions with firewalls . . . . . . . . . . 25
2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 23 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . 27
2.10 Issues with Heartbeating and failure detection . . . . . . 23 2.13 Inconsistency in ABORT processing . . . . . . . . . . . 29
2.10.1 Description of the problem . . . . . . . . . . . . . . . . 23 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . 30
2.10.2 Text changes to the document . . . . . . . . . . . . . . . 23 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . 32
2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 26 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . 34
2.11 Security interactions with firewalls . . . . . . . . . . . 26 2.17 Initial value of the cumulative TSN Ack . . . . . . . . 36
2.11.1 Description of the problem . . . . . . . . . . . . . . . . 26
2.11.2 Text changes to the document . . . . . . . . . . . . . . . 26
2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 28
2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 28
2.12.1 Description of the problem . . . . . . . . . . . . . . . . 28
2.12.2 Text changes to the document . . . . . . . . . . . . . . . 28
2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29
2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29
2.13.1 Description of the problem . . . . . . . . . . . . . . . . 30
2.13.2 Text changes to the document . . . . . . . . . . . . . . . 30
2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30
2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 31
2.14.1 Description of the problem . . . . . . . . . . . . . . . . 31
2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31
2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 34
2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 34
2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34
2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34
2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 36
2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36
2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36
2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36
2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37
2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37
2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37
2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37
2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38
2.18 Handling of address parameters within the INIT or 2.18 Handling of address parameters within the INIT or
INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 38 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . 36
2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38 2.19 Handling of stream shortages . . . . . . . . . . . . . . 38
2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38 2.20 Indefinite postponement . . . . . . . . . . . . . . . . 39
2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39 2.21 User initiated abort of an association . . . . . . . . . 40
2.19 Handling of stream shortages . . . . . . . . . . . . . . . 39 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . 46
2.19.1 Description of the problem . . . . . . . . . . . . . . . . 39 2.23 ABORT sending in response to an INIT . . . . . . . . . . 47
2.19.2 Text changes to the document . . . . . . . . . . . . . . . 39 2.24 Stream Sequence Number (SSN) Initialization . . . . . . 48
2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 40 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . 49
2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 40 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . 50
2.20.1 Description of the problem . . . . . . . . . . . . . . . . 40 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . 52
2.20.2 Text changes to the document . . . . . . . . . . . . . . . 40 2.28 Handling of IP Address Parameters . . . . . . . . . . . 54
2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 41 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . 55
2.21 User initiated abort of an association . . . . . . . . . . 41 2.30 The Initial Congestion Window Size . . . . . . . . . . . 56
2.21.1 Description of the problem . . . . . . . . . . . . . . . . 41 2.31 Stream Sequence Numbers in Figures . . . . . . . . . . . 58
2.21.2 Text changes to the document . . . . . . . . . . . . . . . 41 2.32 Unrecognized Parameters . . . . . . . . . . . . . . . . 63
2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 47 2.33 Handling of unrecognized parameters . . . . . . . . . . 64
2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 47 2.34 Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . 66
2.22.1 Description of the problem . . . . . . . . . . . . . . . . 47 2.35 Port number verification in the COOKIE-ECHO . . . . . . 68
2.22.2 Text changes to the document . . . . . . . . . . . . . . . 47 2.36 Path Initialization . . . . . . . . . . . . . . . . . . 70
2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 48 2.37 ICMP handling procedures . . . . . . . . . . . . . . . . 71
2.23 ABORT sending in response to an INIT . . . . . . . . . . . 48 2.38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 73
2.23.1 Description of the problem . . . . . . . . . . . . . . . . 48 2.39 Retransmission Policy . . . . . . . . . . . . . . . . . 80
2.23.2 Text changes to the document . . . . . . . . . . . . . . . 48 2.40 Port Number 0 . . . . . . . . . . . . . . . . . . . . . 82
2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 48 2.41 T Bit . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 49 2.42 Unknown Parameter Handling . . . . . . . . . . . . . . . 88
2.24.1 Description of the problem . . . . . . . . . . . . . . . . 49 2.43 Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . 89
2.24.2 Text changes to the document . . . . . . . . . . . . . . . 49 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 91
2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 49 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 92
2.25.1 Description of the problem . . . . . . . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . 94
2.25.2 Text changes to the document . . . . . . . . . . . . . . . 49
2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 50
2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 50
2.26.1 Description of the problem . . . . . . . . . . . . . . . . 50
2.26.2 Text changes to the document . . . . . . . . . . . . . . . 50
2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 52
2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 52
2.27.1 Description of the problem . . . . . . . . . . . . . . . . 52
2.27.2 Text changes to the document . . . . . . . . . . . . . . . 53
2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 54
2.28 Handling of IP Address Parameters . . . . . . . . . . . . 54
2.28.1 Description of the problem . . . . . . . . . . . . . . . . 54
2.28.2 Text changes to the document . . . . . . . . . . . . . . . 54
2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 55
2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 55
2.29.1 Description of the problem . . . . . . . . . . . . . . . . 55
2.29.2 Text changes to the document . . . . . . . . . . . . . . . 55
2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 56
2.30 The Initial Congestion Window Size . . . . . . . . . . . . 56
2.30.1 Description of the problem . . . . . . . . . . . . . . . . 56
2.30.2 Text changes to the document . . . . . . . . . . . . . . . 56
2.30.3 Solution description . . . . . . . . . . . . . . . . . . . 56
2.31 Stream Sequence Numbers in Figures . . . . . . . . . . . . 57
2.31.1 Description of the problem . . . . . . . . . . . . . . . . 57
2.31.2 Text changes to the document . . . . . . . . . . . . . . . 57
2.31.3 Solution description . . . . . . . . . . . . . . . . . . . 61
2.32 Unrecognized Parameters . . . . . . . . . . . . . . . . . 61
2.32.1 Description of the problem . . . . . . . . . . . . . . . . 61
2.32.2 Text changes to the document . . . . . . . . . . . . . . . 61
2.32.3 Solution description . . . . . . . . . . . . . . . . . . . 63
2.33 Handling of unrecognized parameters . . . . . . . . . . . 63
2.33.1 Description of the problem . . . . . . . . . . . . . . . . 63
2.33.2 Text changes to the document . . . . . . . . . . . . . . . 63
2.33.3 Solution description . . . . . . . . . . . . . . . . . . . 64
2.34 Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.34.1 Description of the problem . . . . . . . . . . . . . . . . 64
2.34.2 Text changes to the document . . . . . . . . . . . . . . . 65
2.34.3 Solution description . . . . . . . . . . . . . . . . . . . 66
2.35 Port number verification in the COOKIE-ECHO . . . . . . . 66
2.35.1 Description of the problem . . . . . . . . . . . . . . . . 66
2.35.2 Text changes to the document . . . . . . . . . . . . . . . 67
2.35.3 Solution description . . . . . . . . . . . . . . . . . . . 68
2.36 Path Initialization . . . . . . . . . . . . . . . . . . . 68
2.36.1 Description of the problem . . . . . . . . . . . . . . . . 68
2.36.2 Text changes to the document . . . . . . . . . . . . . . . 68
2.36.3 Solution description . . . . . . . . . . . . . . . . . . . 69
2.37 ICMP handling procedures . . . . . . . . . . . . . . . . . 70
2.37.1 Description of the problem . . . . . . . . . . . . . . . . 70
2.37.2 Text changes to the document . . . . . . . . . . . . . . . 70
2.37.3 Solution description . . . . . . . . . . . . . . . . . . . 71
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 72
References . . . . . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 73
Intellectual Property and Copyright Statements . . . . . . 75
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
the publishing of this document for the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors document to be used in the implementation of SCTP to clarify errors
in the original SCTP document. in the original SCTP document.
This document updates RFC2960 and text within this document, where This document updates RFC2960 and text within this document, where
noted, supersedes the text found in RFC2960 [5]. Each error will be noted, supersedes the text found in RFC2960 [6]. Each error will be
detailed within this document in the form of: detailed within this document in the form of:
o The problem description, o The problem description,
o The text quoted from RFC2960 [6],
o The text quoted from RFC2960 [5],
o The replacement text, o The replacement text,
o A description of the solution. o A description of the solution.
1.1 Conventions 1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
2. Corrections to RFC2960 2. Corrections to RFC2960
skipping to change at page 7, line 11 skipping to change at page 5, line 11
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
2. Corrections to RFC2960 2. Corrections to RFC2960
2.1 Incorrect error type during chunk processing. 2.1 Incorrect error type during chunk processing.
2.1.1 Description of the problem 2.1.1 Description of the problem
A typo was discovered in RFC2960 [5] that incorrectly specifies an A typo was discovered in RFC2960 [6] that incorrectly specifies an
action to be taken when processing chunks of unknown identity. action to be taken when processing chunks of unknown identity.
2.1.2 Text changes to the document 2.1.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
01 - Stop processing this SCTP packet and discard it, do not process 01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized any further chunks within it, and report the unrecognized
skipping to change at page 8, line 27 skipping to change at page 6, line 34
any further parameters within this chunk. any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process 01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk, and report the any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK). either an ERROR or in the INIT ACK).
2.2.3 Solution description 2.2.3 Solution description
It was always the intent to stop processing at the level one was at It was always the intent to stop processing at the level one was at
in an unknown chunk or parameter with the upper bit set to 0. Thus if in an unknown chunk or parameter with the upper bit set to 0. Thus
you are processing a chunk, you should drop the packet. If you are if you are processing a chunk, you should drop the packet. If you
processing a parameter, you should drop the chunk. are processing a parameter, you should drop the chunk.
2.3 Padding issues 2.3 Padding issues
2.3.1 Description of the problem 2.3.1 Description of the problem
A problem was found in that when a Chunk terminated in a TLV A problem was found in that when a Chunk terminated in a TLV
parameter. If this last TLV was not on a 32 bit boundary (as parameter. If this last TLV was not on a 32 bit boundary (as
required), there was confusion as to if the last padding was included required), there was confusion as to if the last padding was included
in the chunk length. in the chunk length.
skipping to change at page 10, line 5 skipping to change at page 8, line 6
Note: A robust implementation should accept the Chunk whether Note: A robust implementation should accept the Chunk whether
or not the final padding has been included in the Chunk Length. or not the final padding has been included in the Chunk Length.
Chunk Value: variable length Chunk Value: variable length
The Chunk Value field contains the actual information to be The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type. dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields)
MUST be a multiple of 4 bytes. If the length of the chunk is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
2.3.3 Solution description 2.3.3 Solution description
The above text makes clear that the padding of the last parameter is The above text makes clear that the padding of the last parameter is
not included in the Chunk Length field. It also clarifies that the not included in the Chunk Length field. It also clarifies that the
padding of parameters that are not the last one must be counted in padding of parameters that are not the last one must be counted in
the Chunk Length field. the Chunk Length field.
2.4 Parameter types across all chunk types 2.4 Parameter types across all chunk types
2.4.1 Description of the problem 2.4.1 Description of the problem
skipping to change at page 11, line 47 skipping to change at page 10, line 9
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
e) Each parameter type MUST be unique across all chunks. e) Each parameter type MUST be unique across all chunks.
2.4.3 Solution description 2.4.3 Solution description
By having all parameters unique across all chunk assignments (the By having all parameters unique across all chunk assignments (the
current assignment policy) no ambiguity exists as to what a parameter current assignment policy) no ambiguity exists as to what a parameter
means based on context. The trade off for this is a smaller parameter means based on context. The trade off for this is a smaller
space i.e. 65,536 parameters versus 65,536 * Number-of-chunks. parameter space i.e. 65,536 parameters versus 65,536 *
Number-of-chunks.
2.5 Stream parameter clarification 2.5 Stream parameter clarification
2.5.1 Description of the problem 2.5.1 Description of the problem
A problem was found where the specification is unclear on the A problem was found where the specification is unclear on the
legality of an endpoint asking for more stream resources than were legality of an endpoint asking for more stream resources than were
allowed in the MIS value of the INIT. In particular the value in the allowed in the MIS value of the INIT. In particular the value in the
INIT ACK requested in its OS value was larger than the MIS value INIT ACK requested in its OS value was larger than the MIS value
received in the INIT chunk. This behavior is illegal yet it was received in the INIT chunk. This behavior is illegal yet it was
unspecified in RFC2960 [5] unspecified in RFC2960 [6]
2.5.2 Text changes to the document 2.5.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
Number of Outbound Streams (OS): 16 bits (unsigned integer) Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK Defines the number of outbound streams the sender of this INIT ACK
skipping to change at page 14, line 50 skipping to change at page 13, line 9
Restart of an association with new addresses: An INIT was received Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The association that were previously NOT part of the association. The
New addresses are listed in the error code. This ERROR is normally New addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see section 5.2). sent as part of an ABORT refusing the INIT (see section 5.2).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable | | Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs / / New Address TLVs /
\\ \\ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: each New Address TLV is an exact copy of the TLV
that was found in the INIT chunk that was new including the
Parameter Type and the Parameter length.
--------- ---------
Old text: (Section 5.2.1) Old text: (Section 5.2.1)
--------- ---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag, sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters State Cookie with the INIT ACK. The endpoint uses the parameters
skipping to change at page 15, line 33 skipping to change at page 13, line 45
responding the endpoint MUST send the INIT ACK back to the same responding the endpoint MUST send the INIT ACK back to the same
address that the original INIT (sent by this endpoint) was sent to. address that the original INIT (sent by this endpoint) was sent to.
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged) original INIT chunk (including its Initiation Tag, unchanged)
provided that no NEW address have been added to the forming provided that no NEW address have been added to the forming
association. If the INIT message indicates that a new address(es) association. If the INIT message indicates that a new address(es)
have been added to the association, then the entire INIT MUST be have been added to the association, then the entire INIT MUST be
discarded and NO changes should be made to the existing association. discarded and NO changes should be made to the existing association.
An ABORT MUST be sent in response that SHOULD include the error An ABORT MUST be sent in response that MAY include the error
'Restart of an association with new addresses'. The error SHOULD list 'Restart of an association with new addresses'. The error SHOULD list
the addresses that were added to the restarting association. the addresses that were added to the restarting association.
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
an INIT ACK the original parameters are combined with those from the an INIT ACK the original parameters are combined with those from the
newly received INIT chunk. The endpoint shall also generate a State newly received INIT chunk. The endpoint shall also generate a State
Cookie with the INIT ACK. The endpoint uses the parameters sent in Cookie with the INIT ACK. The endpoint uses the parameters sent in
its INIT to calculate the State Cookie. its INIT to calculate the State Cookie.
--------- ---------
skipping to change at page 16, line 39 skipping to change at page 14, line 50
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a this association, the endpoint shall generate an INIT ACK with a
State Cookie. Before responding the endpoint MUST check to see if the State Cookie. Before responding the endpoint MUST check to see if the
unexpected INIT adds new addresses to the association. If new unexpected INIT adds new addresses to the association. If new
addresses are added to the association, the endpoint MUST respond addresses are added to the association, the endpoint MUST respond
with an ABORT copying the 'Initiation Tag' of the unexpected INIT with an ABORT copying the 'Initiation Tag' of the unexpected INIT
into the 'Verification Tag' of the outbound packet carrying the ABORT. into the 'Verification Tag' of the outbound packet carrying the ABORT.
In the ABORT response the cause of error SHOULD be set to 'restart In the ABORT response the cause of error MAY be set to 'restart
of an association with new addresses'. The error SHOULD list the of an association with new addresses'. The error SHOULD list the
addresses that were added to the restarting association. addresses that were added to the restarting association.
If no new addresses are added, when responding to the INIT in the If no new addresses are added, when responding to the INIT in the
outbound INIT ACK the endpoint MUST copy its current Verification Tag outbound INIT ACK the endpoint MUST copy its current Verification Tag
and peer's Verification Tag into a reserved place within the state and peer's Verification Tag into a reserved place within the state
cookie. We shall refer to these locations as the Peer's-Tie-Tag and cookie. We shall refer to these locations as the Peer's-Tie-Tag and
the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK
MUST carry a Verification Tag value equal to the Initiation Tag found MUST carry a Verification Tag value equal to the Initiation Tag found
in the unexpected INIT. And the INIT ACK MUST contain a new in the unexpected INIT. And the INIT ACK MUST contain a new
skipping to change at page 17, line 21 skipping to change at page 15, line 32
Note: Only when a TCB exists and the association is not in a COOKIE- Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags
populated with a value other than 0. For a normal association INIT populated with a value other than 0. For a normal association INIT
(i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set (i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set
to 0 (indicating that no previous TCB existed). to 0 (indicating that no previous TCB existed).
2.6.3 Solution description 2.6.3 Solution description
A new error code is being added and specific instructions to send A new error code is being added and specific instructions to send
back an ABORT to a new association in a restart case or collision back an ABORT to a new association in a restart case or collision
case, where new addresses have been added. The error code can be used case, where new addresses have been added. The error code can be
by a legitimate restart to inform the endpoint that it has made a used by a legitimate restart to inform the endpoint that it has made
software error in adding a new address. The endpoint then can choose a software error in adding a new address. The endpoint then can
to wait until the OOTB ABORT tears down the old association, or choose to wait until the OOTB ABORT tears down the old association,
restart without the new address. or restart without the new address.
Also the Note at the end of section 5.2.2 explaining the use of the Also the Note at the end of section 5.2.2 explaining the use of the
Tie-Tags was modified to properly explain the states in which the Tie-Tags was modified to properly explain the states in which the
Tie-Tags should be set to a value different than 0. Tie-Tags should be set to a value different than 0.
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes
2.7.1 Description of the problem 2.7.1 Description of the problem
Some implementations were having difficulty growing their cwnd. This Some implementations were having difficulty growing their cwnd. This
skipping to change at page 18, line 29 skipping to change at page 16, line 40
2.8 Issues with Fast Retransmit 2.8 Issues with Fast Retransmit
2.8.1 Description of the problem 2.8.1 Description of the problem
Several problems were found in the current specification of fast Several problems were found in the current specification of fast
retransmit. The current wording did not require GAP ACK blocks to be retransmit. The current wording did not require GAP ACK blocks to be
sent, even though they are essential to the workings of SCTP's sent, even though they are essential to the workings of SCTP's
congestion control. The specification left unclear how to handle the congestion control. The specification left unclear how to handle the
fast retransmit cycle, having the implementation to wait on the cwnd fast retransmit cycle, having the implementation to wait on the cwnd
to retransmit a TSN that was marked for fast retransmit. No limit was to retransmit a TSN that was marked for fast retransmit. No limit
placed on how many times a TSN could be fast retransmitted. Fast was placed on how many times a TSN could be fast retransmitted. Fast
Recovery was not specified, causing the congestion window to be Recovery was not specified, causing the congestion window to be
reduced drastically when there are multiple losses in a single RTT. reduced drastically when there are multiple losses in a single RTT.
2.8.2 Text changes to the document 2.8.2 Text changes to the document
--------- ---------
Old text: (Section 6.2) Old text: (Section 6.2)
--------- ---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be greater than the value in the Cumulative TSN Ack field SHOULD also be
reported in the Gap Ack Block fields. reported in the Gap Ack Block fields.
skipping to change at page 19, line 20 skipping to change at page 17, line 31
the reception of multiple DATA chunks. See Section 3.3.4 for SACK the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with valid DATA chunk) it has received. Any received DATA chunks with
TSN greater than the value in the Cumulative TSN Ack field are reported TSN greater than the value in the Cumulative TSN Ack field are reported
in the Gap Ack Block fields. The SCTP endpoint MUST report as many in the Gap Ack Block fields. The SCTP endpoint MUST report as many
Gap Ack Blocks that can fit in a single SACK chunk limited by the Gap Ack Blocks that can fit in a single SACK chunk limited by the
current path MTU. current path MTU.
--------- ---------
Old text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk as
available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no retransmit
timer is running for the destination address to which the DATA
chunk was originally transmitted, then T3-rtx is started for
that destination address.
---------
New text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk as
available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no retransmit
timer is running for the destination address to which the DATA
chunk was originally transmitted, then T3-rtx is started for
that destination address.
iv) If the Cumulative TSN Ack exceeds the Fast Recovery exit
point (Section 7.2.4), Fast Recovery is exited.
---------
Old text: (Section 7.2.4) Old text: (Section 7.2.4)
--------- ---------
Whenever an endpoint receives a SACK that indicates some TSN(s) Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit. regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall: SACK, the data sender shall:
skipping to change at page 21, line 27 skipping to change at page 20, line 43
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first. must be applied first.
2.8.3 Solution description 2.8.3 Solution description
The effect of the above wording changes are as follows: The effect of the above wording changes are as follows:
o It requires with a MUST the sending of GAP Ack blocks instead of o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC2960 [5] SHOULD. the current RFC2960 [6] SHOULD.
o It allows a TSN being Fast Retransmitted (FR) to be sent only once o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR. via FR.
o It ends the delay in awaiting for the flight size to drop when a o It ends the delay in awaiting for the flight size to drop when a
TSN is identified ready to FR. TSN is identified ready to FR.
o It changes the way chunks are marked during fast retransmit, so o It changes the way chunks are marked during fast retransmit, so
that only new reports are counted. that only new reports are counted.
o It introduces a Fast Recovery period to avoid multiple congestion o It introduces a Fast Recovery period to avoid multiple congestion
window reductions when there are multiple losses in a single RTT window reductions when there are multiple losses in a single RTT
(as shown by Caro et al. [3]). (as shown by Caro et al. [3]).
These changes will effectively allow SCTP to follow a similar model These changes will effectively allow SCTP to follow a similar model
as TCP+SACK in the handling of Fast Retransmit. as TCP+SACK in the handling of Fast Retransmit.
skipping to change at page 24, line 28 skipping to change at page 23, line 34
8.1 Endpoint Failure Detection 8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes retransmissions to all the retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed), destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT Chunks. If the value of this including unacknowledged HEARTBEAT Chunks. If the value of this
counter exceeds the limit indicated in the protocol parameter counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer 'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, the (and thus the association enters the CLOSED state). In addition, the
endpoint shall report the failure to the upper layer, and optionally endpoint MAY report the failure to the upper layer, and optionally
report back all outstanding user data remaining in its outbound report back all outstanding user data remaining in its outbound
queue. The association is automatically closed when the peer queue. The association is automatically closed when the peer
endpoint becomes unreachable. endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
skipping to change at page 25, line 4 skipping to change at page 24, line 9
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). address(es).
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint SHOULD monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state, and is discontinued after sending either SHUTDOWN ESTABLISHED state, and is discontinued after sending either SHUTDOWN
or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
(INIT sender) or the ESTABLISHED state (INIT receiver), up until (INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the
SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
skipping to change at page 27, line 33 skipping to change at page 26, line 39
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999. Computer Communication Review, 29(5), October 1999.
--------- ---------
New text: (Section 18) New text: (Section 18)
--------- ---------
18. References 18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999. Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review, Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21. V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994. Security", RFC 1750, December 1994.
skipping to change at page 28, line 21 skipping to change at page 27, line 26
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999. Computer Communication Review, 29(5), October 1999.
2.11.3 Solution description 2.11.3 Solution description
The above text adding a new subsection to the Security Considerations The above text adding a new subsection to the Security Considerations
section of RFC2960 [5] makes clear that, to make easier the section of RFC2960 [6] makes clear that, to make easier the
interaction with firewalls, an INIT chunk must not be bundled in any interaction with firewalls, an INIT chunk must not be bundled in any
case with any other chunk, being this rule enforced by the packet case with any other chunk, being this rule enforced by the packet
receiver, that will silently discard the packets that do not follow receiver, that will silently discard the packets that do not follow
this rule. this rule.
2.12 Shutdown ambiguity 2.12 Shutdown ambiguity
2.12.1 Description of the problem 2.12.1 Description of the problem
Currently there is an ambiguity between the statements in section 6.2 Currently there is an ambiguity between the statements in section 6.2
skipping to change at page 29, line 18 skipping to change at page 28, line 23
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own, send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
entering the SHUTDOWN-ACK-SENT state. If the timer expires, the entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
endpoint must re-send the SHUTDOWN ACK. endpoint must re-send the SHUTDOWN ACK.
--------- ---------
New text: (Section 9.2) New text: (Section 9.2)
--------- ---------
If there are still outstanding DATA chunks left, the SHUTDOWN If there are still outstanding DATA chunks left, the SHUTDOWN
receiver shall continue to follow normal data transmission procedures receiver MUST continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user. from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s) respond to each received packet containing one or more DATA chunk(s)
with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a
SHUTDOWN chunk by itself cannot acknowledge all of the received DATA SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
chunks (i.e. there are TSN's that can be acknowledged that are larger chunks (i.e. there are TSN's that can be acknowledged that are larger
than the cumulative TSN and thus gaps exist in the TSN sequence) or than the cumulative TSN and thus gaps exist in the TSN sequence) or
if duplicate TSN's have been recieved then a SACK chunk MUST also be sent. if duplicate TSN's have been recieved then a SACK chunk MUST also be sent.
The sender of the SHUTDOWN MAY also start an overall guard timer The sender of the SHUTDOWN MAY also start an overall guard timer
'T5-shutdown-guard' to bound the overall time for shutdown sequence. 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
At the expiration of this timer the sender SHOULD abort the At the expiration of this timer the sender SHOULD abort the
association by sending an ABORT chunk. If the 'T5-shutdown-guard' association by sending an ABORT chunk. If the 'T5-shutdown-guard'
timer is used, it SHOULD be set to the recommended value of 5 times timer is used, it SHOULD be set to the recommended value of 5 times
'RTO.Max'. 'RTO.Max'.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
If the timer expires, the endpoint must re-send the SHUTDOWN ACK. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
2.12.3 Solution description 2.12.3 Solution description
The above text clarifies the use of a SACK in conjunction with a The above text clarifies the use of a SACK in conjunction with a
SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown
sequence to protect against errant receivers of SHUTDOWN chunks. sequence to protect against errant receivers of SHUTDOWN chunks.
2.13 Inconsistency in ABORT processing 2.13 Inconsistency in ABORT processing
skipping to change at page 30, line 36 skipping to change at page 29, line 40
matches either its own tag, OR the tag of its peer. Otherwise, matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no the receiver MUST silently discard the packet and take no
further action. further action.
--------- ---------
New text: (Section 8.5.1) New text: (Section 8.5.1)
--------- ---------
B) Rules for packet carrying ABORT: B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of - The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value the outbound packet with the destination endpoint's tag value
if it is known. if it is known.
- If the ABORT is sent in response to an OOTB packet, the - If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4. endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT shall accept the packet if the - The receiver of a ABORT MUST accept the packet if the
Verification Tag field of the packet matches its own tag OR it Verification Tag field of the packet matches its own tag OR it
is set to its peer's tag and the T bit is set in the Chunk is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the packet Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action. and take no further action.
2.13.3 Solution description 2.13.3 Solution description
The above text change clarifies that the T bit must be set before an The above text change clarifies that the T bit must be set before an
implementation looks for the peers tag. implementation looks for the peers tag.
2.14 Cwnd gated by its full use 2.14 Cwnd gated by its full use
2.14.1 Description of the problem 2.14.1 Description of the problem
A problem was found with the current specification of the growth and A problem was found with the current specification of the growth and
decay of cwnd. The cwnd should only be increased if it is being fully decay of cwnd. The cwnd should only be increased if it is being
utilized, and after periods of under utilization, the cwnd should be fully utilized, and after periods of under utilization, the cwnd
decreased. In some sections, the current wording is weak and is not should be decreased. In some sections, the current wording is weak
clearly defined. Also, the current specification unnecessarily and is not clearly defined. Also, the current specification
introduces the need for special case code to ensure cwnd degradation. unnecessarily introduces the need for special case code to ensure
Plus, the cwnd should not be increased during Fast Recovery since a cwnd degradation. Plus, the cwnd should not be increased during Fast
full cwnd during Fast Recovery does not qualify the cwnd as being Recovery since a full cwnd during Fast Recovery does not qualify the
fully utilized. Additionally, multiple loss scenarios in a single cwnd as being fully utilized. Additionally, multiple loss scenarios
window may cause the cwnd to grow more rapidly as the number of in a single window may cause the cwnd to grow more rapidly as the
losses in a window increases [3]. number of losses in a window increases [3].
2.14.2 Text changes to the document 2.14.2 Text changes to the document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
D) Then, the sender can send out as many new DATA chunks as Rule A D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow. and Rule B above allow.
--------- ---------
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
D) When the time comes for the sender to transmit new DATA chunks, the D) When the time comes for the sender to transmit new DATA chunks, the
protocol parameter Max.Burst MUST first be applied to limit how many protocol parameter Max.Burst SHOULD be used to limit the number of
new DATA chunks may be sent. The limit is applied by adjusting cwnd packets sent. The limit MAY be applied by adjusting cwnd as follows:
as follows:
if((flightsize + Max.Burst*MTU) < cwnd) if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU cwnd = flightsize + Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.
E) Then, the sender can send out as many new DATA chunks as Rule A E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow. and Rule B above allow.
--------- ---------
Old text: (Section 7.2.1) Old text: (Section 7.2.1)
--------- ---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an current congestion window is being fully utilized). If an
skipping to change at page 32, line 20 skipping to change at page 31, line 26
attack outlined in [SAVAGE99]. attack outlined in [SAVAGE99].
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use
the slow start algorithm to increase cwnd only if the current the slow start algorithm to increase cwnd only if the current
congestion window is being fully utilized, an incoming SACK advances congestion window is being fully utilized, an incoming SACK advances
the Cumulative TSN Ack Point, and the data sender is not in Fast the Cumulative TSN Ack Point, and the data sender is not in Fast
Recovery. Only when these three conditions are met can the cwnd be Recovery. Only when these three conditions are met, can the cwnd be
increased otherwise the cwnd MUST not be increased. If these conditions increased; otherwise the cwnd MUST not be increased. If these conditions
are met then cwnd MUST be increased by at most the lesser of 1) the are met then cwnd MUST be increased by at most the lesser of 1) the
total size of the previously outstanding DATA chunk(s) acknowledged, total size of the previously outstanding DATA chunk(s) acknowledged,
and 2) the destination's path MTU. This protects against the and 2) the destination's path MTU. This upper bound protects against the
ACK-Splitting attack outlined in [SAVAGE99]. ACK-Splitting attack outlined in [SAVAGE99].
--------- ---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 2*MTU) per RTO.
---------
New text: (Section 7.2.1)
---------
o When the association does not transmit data on a given transport address
within an RTO, the cwnd of the transport address SHOULD be adjusted to
2*MTU.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA on
a given transport address within an RTO, the cwnd of the transport
address should be adjusted to 2*MTU.
---------
Old text: (Section 14) Old text: (Section 14)
--------- ---------
14. Suggested SCTP Protocol Parameter Values 14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
skipping to change at page 34, line 9 skipping to change at page 32, line 28
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds HB.Interval - 30 seconds
2.14.3 Solution description 2.14.3 Solution description
The above changes strengthens the rules and makes it much more The above changes strengthens the rules and makes it much more
apparent as to the need to block cwnd growth when the full cwnd is apparent as to the need to block cwnd growth when the full cwnd is
not being utilized. The changes also applies cwnd degradation without not being utilized. The changes also applies cwnd degradation
introducing the need for complex special case code. without introducing the need for complex special case code.
2.15 Window probes in SCTP 2.15 Window probes in SCTP
2.15.1 Description of the problem 2.15.1 Description of the problem
When a receiver clamps its rwnd to 0 to flow control the peer, the When a receiver clamps its rwnd to 0 to flow control the peer, the
specification implies that one must continue to accept data from the specification implies that one must continue to accept data from the
remote peer. This is incorrect and needs clarification. remote peer. This is incorrect and needs clarification.
2.15.2 Text changes to the document 2.15.2 Text changes to the document
skipping to change at page 34, line 38 skipping to change at page 33, line 11
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
The SCTP endpoint MUST always acknowledge the reception of each The SCTP endpoint MUST always acknowledge the reception of each
valid DATA chunk when the DATA chunk received is inside its receive valid DATA chunk when the DATA chunk received is inside its receive
window. window.
When the receiver's advertised window is 0, the receiver MUST drop When the receiver's advertised window is 0, the receiver MUST drop
all new incoming DATA chunk and immediately send back a SACK with any new incoming DATA chunk with a TSN larger than the largest TSN
the current receive window showing only DATA chunks received and received so far. If the new incoming DATA chunk holds a TSN value
accepted so far. The dropped DATA chunk MUST NOT be included in the less than the largest TSN received so far, then the receiver SHOULD
SACK as they were not accepted. The receiver MUST also have an drop the largest TSN held for reordering, and accept the new
algorithm for advertising its receive window to avoid receiver silly incoming DATA chunk. In either case, if such a DATA chunk is dropped, the
window syndrome (SWS) as described in RFC 813. The algorithm can be receiver MUST immediately send back a SACK with the current receive
similar to the one described in Section 4.2.3.3 of RFC 1122. window showing only DATA chunks received and accepted so far.
Because of receiver SWS avoidance, even when the receiver's internal The dropped DATA chunk(s) MUST NOT be included in the SACK as they
buffer is not full anymore, as long as the advertised window is were not accepted. The receiver MUST also have an algorithm for
still 0, the receiver MUST still drop all new incoming DATA chunk. advertising its receive window to avoid receiver silly window syndrome
(SWS) as described in RFC 813. The algorithm can be similar to the
one described in Section 4.2.3.3 of RFC 1122.
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
A) At any given time, the data sender MUST NOT transmit new data to A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e. rwnd is 0, see Section that the peer has no buffer space (i.e. rwnd is 0, see Section
6.2.1). However, regardless of the value of rwnd (including if it 6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B below). This rule the receiver if allowed by cwnd (see rule B below). This rule
allows the sender to probe for a change in rwnd that the sender allows the sender to probe for a change in rwnd that the sender
missed due to the SACK having been lost in transit from the data missed due to the SACK having been lost in transit from the data
receiver to the data sender. receiver to the data sender.
skipping to change at page 35, line 29 skipping to change at page 34, line 7
any destination transport address if its peer's rwnd indicates any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e. rwnd is 0, see Section that the peer has no buffer space (i.e. rwnd is 0, see Section
6.2.1). However, regardless of the value of rwnd (including if it 6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B below). This rule the receiver if allowed by cwnd (see rule B below). This rule
allows the sender to probe for a change in rwnd that the sender allows the sender to probe for a change in rwnd that the sender
missed due to the SACK having been lost in transit from the data missed due to the SACK having been lost in transit from the data
receiver to the data sender. receiver to the data sender.
When the receiver's advertised window is zero, this probe is called When the receiver's advertised window is zero, this probe is called
a zero window probe. Note that zero window probe SHOULD only be sent a zero window probe. Note that a zero window probe SHOULD only be sent
when all outstanding DATA chunks have been cumulatively acknowledged when all outstanding DATA chunks have been cumulatively acknowledged
and no DATA chunk(s) are in flight. Zero window probing MUST and no DATA chunk(s) are in flight. Zero window probing MUST
be supported. be supported.
When a sender is doing zero window probing, it should not time If the sender continues to receive new packets from the receiver
out the association if it continues to receive new packets from while doing zero window probing, the unacknowledged window probes
the receiver. The reason is that the receiver MAY keep its window should not increment the error counter for the association or any
closed for an indefinite time. Refer to Section 6.2 on the receiver destination transport address.The reason is that the receiver MAY keep
behavior when it advertises a zero window. The sender SHOULD its window closed for an indefinite time. Refer to Section 6.2 on
the receiver behavior when it advertises a zero window. The sender SHOULD
send the first zero window probe after 1 RTO when it detects that send the first zero window probe after 1 RTO when it detects that
the receiver has closed its window, and SHOULD increase the probe the receiver has closed its window, and SHOULD increase the probe
interval exponentially afterwards. Also note that the cwnd SHOULD interval exponentially afterwards. Also note that the cwnd SHOULD
be adjusted according to Section 7.2.1. Zero window probing does be adjusted according to Section 7.2.1. Zero window probing does
not affect the calculation of cwnd. not affect the calculation of cwnd.
The sender MUST also have algorithm in sending new DATA chunks to The sender MUST also have an algorithm for sending new DATA chunks to
avoid silly window syndrome (SWS) as described in RFC 813. The avoid silly window syndrome (SWS) as described in RFC 813. The
algorithm can be similar to the one described in Section 4.2.3.4 algorithm can be similar to the one described in Section 4.2.3.4
of RFC 1122. of RFC 1122.
2.15.3 Solution description 2.15.3 Solution description
The above allows a receiver to drop new data that arrives and yet The above allows a receiver to drop new data that arrives and yet
still requires the receiver to send a SACK showing the conditions still requires the receiver to send a SACK showing the conditions
unchanged (with the possible exception of a new a_rwnd) and the unchanged (with the possible exception of a new a_rwnd) and the
dropped chunk as missing. This will allow the association to continue dropped chunk as missing. This will allow the association to
until the rwnd condition clears. continue until the rwnd condition clears.
2.16 Fragmentation and Path MTU issues 2.16 Fragmentation and Path MTU issues
2.16.1 Description of the problem 2.16.1 Description of the problem
The current wording of the Fragmentation and Reassembly forces an The current wording of the Fragmentation and Reassembly forces an
implementation that supports fragmentation to always fragment. This implementation that supports fragmentation to always fragment. This
prohibits an implementation from offering its users an option to prohibits an implementation from offering its users an option to
disable sends that exceed the SCTP fragmentation point. disable sends that exceed the SCTP fragmentation point.
The restriction in RFC2960 [5] section 6.9 was never meant to The restriction in RFC2960 [6] section 6.9 was never meant to
restrict an implementations API from this behavior. restrict an implementations API from this behavior.
2.16.2 Text changes to the document 2.16.2 Text changes to the document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
6.9 Fragmentation and Reassembly 6.9 Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint MUST support reassembly when receiving DATA chunks. If an endpoint
supports fragmentation, it MUST fragment a user message if the size supports fragmentation, it MUST fragment a user message if the size
of the user message to be sent causes the outbound SCTP packet size of the user message to be sent causes the outbound SCTP packet size
skipping to change at page 37, line 8 skipping to change at page 35, line 33
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
6.9 Fragmentation and Reassembly 6.9 Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint MUST support reassembly when receiving DATA chunks. If an endpoint
supports fragmentation, it MUST fragment a user message if the size supports fragmentation, it MUST fragment a user message if the size
of the user message to be sent causes the outbound SCTP packet size of the user message to be sent causes the outbound SCTP packet size
to exceed the current MTU. If an implementation does not support to exceed the current MTU. If an implementation does not support
fragmentation of outbound user messages, the endpoint must return an fragmentation of outbound user messages, the endpoint MUST return an
error to its upper layer and not attempt to send the user message. error to its upper layer and not attempt to send the user message.
Note: If an implementation that supports fragmentation makes Note: If an implementation that supports fragmentation makes
available to its upper layer a mechanism to turn off fragmentation available to its upper layer a mechanism to turn off fragmentation
it may do so. However in so doing, it MUST react just like an it may do so. However in so doing, it MUST react just like an
implementation that does NOT support fragmentation i.e. it MUST implementation that does NOT support fragmentation i.e. it MUST
reject sends that exceed the current P-MTU. reject sends that exceed the current P-MTU.
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
skipping to change at page 38, line 44 skipping to change at page 37, line 24
or INIT ACK chunk and the source IP address of the IP datagram. or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to destination transport addresses when sending subsequent packets to
its peer. its peer.
--------- ---------
New text: (Section 5.1.2) New text: (Section 5.1.2)
--------- ---------
C) If there are only IPv4/IPv6 addresses present in the received INIT 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 or INIT ACK chunk, the receiver MUST derive and record all the
transport address(es) from the received chunk AND the source IP transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es) address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT 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. or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to destination transport addresses when sending subsequent packets to
its peer. its peer.
D) An INIT or INIT ACK chunk MUST be treated as belonging D) An INIT or INIT ACK chunk MUST be treated as belonging
to an already established association (or one in the to an already established association (or one in the
process of being established) if the use of any of the process of being established) if the use of any of the
valid address parameters contained within the chunk valid address parameters contained within the chunk
would identify an existing TCB. would identify an existing TCB.
skipping to change at page 39, line 22 skipping to change at page 37, line 47
valid address parameters contained within the chunk valid address parameters contained within the chunk
would identify an existing TCB. would identify an existing TCB.
2.18.3 Solution description 2.18.3 Solution description
This new text clearly specifies to an implementor the need to look This new text clearly specifies to an implementor the need to look
within the INIT or INIT ACK. Any implementation that does not do within the INIT or INIT ACK. Any implementation that does not do
this, may for example not be able to recognize an INIT chunk coming this, may for example not be able to recognize an INIT chunk coming
from an already established association that adds new addresses (see from an already established association that adds new addresses (see
section 2.6), or an incoming INIT ACK chunk sent from a source section 2.6), or an incoming INIT ACK chunk sent from a source
address different to the destination address used to send the INIT address different than the destination address used to send the INIT
chunk. chunk.
2.19 Handling of stream shortages 2.19 Handling of stream shortages
2.19.1 Description of the problem 2.19.1 Description of the problem
The current wording in the RFC places the choice of sending an ABORT The current wording in the RFC places the choice of sending an ABORT
upon the SCTP stack when a stream shortage occurs. This decision upon the SCTP stack when a stream shortage occurs. This decision
should really be made by the upper layer not the SCTP stack. should really be made by the upper layer not the SCTP stack.
skipping to change at page 40, line 14 skipping to change at page 38, line 40
to configure, the endpoint MUST either use MIS outbound streams, or to configure, the endpoint MUST either use MIS outbound streams, or
abort the association and report to its upper layer the resources abort the association and report to its upper layer the resources
shortage at its peer. shortage at its peer.
--------- ---------
New text: (Section 5.1.2) New text: (Section 5.1.2)
--------- ---------
5.1.1 Handle Stream Parameters 5.1.1 Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall In the INIT and INIT ACK chunks, the sender of the chunk MUST
indicate the number of outbound streams (OS) it wishes to have in the indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint. accept from the other endpoint.
After receiving the stream configuration information from the other After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's side, each endpoint MUST perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST use MIS outbound streams and MAY to configure, the endpoint MUST use MIS outbound streams and MAY
report any shortage to the upper layer. The upper layer can then report any shortage to the upper layer. The upper layer can then
choose to abort the association if the resource shortage choose to abort the association if the resource shortage
is unacceptable. is unacceptable.
2.19.3 Solution description 2.19.3 Solution description
The above changes take the decision to ABORT out of the realm of the The above changes take the decision to ABORT out of the realm of the
skipping to change at page 44, line 21 skipping to change at page 43, line 29
After checking the Verification Tag, the receiving endpoint shall After checking the Verification Tag, the receiving endpoint shall
remove the association from its record, and shall report the remove the association from its record, and shall report the
termination to its upper layer. termination to its upper layer.
--------- ---------
New text: (Section 9.1) New text: (Section 9.1)
--------- ---------
9.1 Abort of an Association 9.1 Abort of an Association
When an endpoint decides to abort an existing association, it shall When an endpoint decides to abort an existing association, it MUST
send an ABORT chunk to its peer endpoint. The sender MUST fill in send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. If the association is aborted bundle any DATA chunk with the ABORT. If the association is aborted
on request of the upper layer an User Initiated Abort error cause on request of the upper layer a User Initiated Abort error cause
(see 3.3.10.12) SHOULD be present in the ABORT chunk. (see 3.3.10.12) SHOULD be present in the ABORT chunk.
An endpoint MUST NOT respond to any received packet that contains an An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4). ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification An endpoint receiving an ABORT MUST apply the special Verification
Tag check rules described in Section 8.5.1. Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall After checking the Verification Tag, the receiving endpoint MUST
remove the association from its record, and shall report the remove the association from its record, and SHOULD report the
termination to its upper layer. If an User Initiated Abort error termination to its upper layer. If an User Initiated Abort error
cause is present in the ABORT chunk the Upper Layer Abort Reason cause is present in the ABORT chunk the Upper Layer Abort Reason
shall be made available to the upper layer. SHOULD be made available to the upper layer.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
D) Abort D) Abort
Format: ABORT(association id [, cause code]) Format: ABORT(association id [, cause code])
-> result -> result
Ungracefully closes an association. Any locally queued user data Ungracefully closes an association. Any locally queued user data
will be discarded and an ABORT chunk is sent to the peer. A success will be discarded and an ABORT chunk is sent to the peer. A success
code will be returned on successful abortion of the association. If code will be returned on successful abortion of the association. If
attempting to abort the association results in a failure, an error attempting to abort the association results in a failure, an error
code shall be returned. code shall be returned.
skipping to change at page 47, line 16 skipping to change at page 46, line 20
The above allows an upper layer to provide its peer with an The above allows an upper layer to provide its peer with an
indication why the association was aborted. Therefore an addition indication why the association was aborted. Therefore an addition
error cause was introduced. error cause was introduced.
2.22 Handling of invalid Initiate Tag of INIT-ACK 2.22 Handling of invalid Initiate Tag of INIT-ACK
2.22.1 Description of the problem 2.22.1 Description of the problem
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
Tag set to zero handles this as an error and sends back an ABORT. But Tag set to zero handles this as an error and sends back an ABORT.
the sender of the INIT-ACK normally has no TCB and so the ABORT is But the sender of the INIT-ACK normally has no TCB and so the ABORT
useless. is useless.
2.22.2 Text changes to the document 2.22.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
Initiate Tag: 32 bits (unsigned integer) Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the Initiate Tag The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits field of every SCTP packet that the INIT ACK receiver transmits
within this association. within this association.
skipping to change at page 48, line 13 skipping to change at page 47, line 44
more on the selection of the Initiate Tag value. more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK chunk is If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST destroy the association discarding found to be 0, the receiver MUST destroy the association discarding
its TCB. The receiver MAY send an ABORT for debugging purpose. its TCB. The receiver MAY send an ABORT for debugging purpose.
2.22.3 Solution description 2.22.3 Solution description
The new text does not require the receiver of the invalid INIT-ACK to The new text does not require the receiver of the invalid INIT-ACK to
send the ABORT. This behavior is in tune with the error case of send the ABORT. This behavior is in tune with the error case of
invalid stream numbers in the INIT-ACK. However it is allowed to send invalid stream numbers in the INIT-ACK. However it is allowed to
an ABORT for debugging purposes. send an ABORT for debugging purposes.
2.23 ABORT sending in response to an INIT 2.23 ABORT sending in response to an INIT
2.23.1 Description of the problem 2.23.1 Description of the problem
Whenever the receiver of an INIT chunk has to send an ABORT chunk in Whenever the receiver of an INIT chunk has to send an ABORT chunk in
response for whatever reason it is not stated clearly which response for whatever reason it is not stated clearly which
Verification Tag and value of the T-bit should be used. Verification Tag and value of the T-bit should be used.
2.23.2 Text changes to the document 2.23.2 Text changes to the document
skipping to change at page 50, line 27 skipping to change at page 50, line 32
2.25.3 Solution description 2.25.3 Solution description
The text has been modified. It is now clear that a SACK always The text has been modified. It is now clear that a SACK always
contains the fields Number of Gap Ack Blocks and Number of Duplicate contains the fields Number of Gap Ack Blocks and Number of Duplicate
TSNs. TSNs.
2.26 Protocol Violation Error Cause 2.26 Protocol Violation Error Cause
2.26.1 Description of the problem 2.26.1 Description of the problem
There are many situations a SCTP endpoints detects that the peer There are many situations where an SCTP endpoint may detect that its
violates the protocol. Therefore the association has to be aborted. peer violates the protocol. The result of such detection often
Currently there are only some error causes which could be used to results in the association being destroyed by the sending of an
indicate the reason of the abort but these do not cover all cases. ABORT. Currently there are only some error causes which could be
used to indicate the reason of the abort but these do not cover all
cases.
2.26.2 Text changes to the document 2.26.2 Text changes to the document
Some of the changes given here already include changes suggested in Some of the changes given here already include changes suggested in
section Section 2.6 and Section 2.21 of this document. section Section 2.6 and Section 2.21 of this document.
--------- ---------
Old text: (Section 3.3.10) Old text: (Section 3.3.10)
--------- ---------
skipping to change at page 52, line 19 skipping to change at page 52, line 24
--------- ---------
New text: (Note no old text, new error added in section 3.3.10) New text: (Note no old text, new error added in section 3.3.10)
--------- ---------
3.3.10.13 Protocol Violation (13) 3.3.10.13 Protocol Violation (13)
Cause of error Cause of error
-------------- --------------
This error cause MAY be included in ABORT chunks which are send This error cause MAY be included in ABORT chunks which is sent
because a SCTP endpoint detects a protocol violation of the peer because an SCTP endpoint detects a protocol violation of the peer
which is not covered by the error causes described in 3.3.10.1 to which is not covered by the error causes described in 3.3.10.1 to
3.3.10.12. An implementation MAY provide Additional Information 3.3.10.12. An implementation MAY provide Additional Information
specifying what kind of protocol violation has been detected. specifying what kind of protocol violation has been detected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable | | Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information / / Additional Information /
\\ \\ \\ \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26.3 Solution description 2.26.3 Solution description
An additional error cause which can be used by an endpoint to An additional error cause which can be used by an endpoint to
indicate a protocol violation of the peer has been defined. indicate a protocol violation of the peer has been defined.
2.27 Reporting of Unrecognized Parameters 2.27 Reporting of Unrecognized Parameters
2.27.1 Description of the problem 2.27.1 Description of the problem
It is not stated clearly in RFC2960 [5] how unrecognized parameters It is not stated clearly in RFC2960 [6] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could be should be reported. Unrecognized parameters in an INIT chunk could
reported in the INIT-ACK chunk or in a separate ERROR chunk which can be reported in the INIT-ACK chunk or in a separate ERROR chunk which
get lost. Unrecognized parameters in an INIT-ACK chunk have to be can get lost. Unrecognized parameters in an INIT-ACK chunk have to
reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR be reported in an ERROR-chunk. This can be bundled with the
chunk or sent separately. If it is sent separately and received COOKIE-ERROR chunk or sent separately. If it is sent separately and
before the COOKIE-ECHO it will be handled as an OOTB packet resulting received before the COOKIE-ECHO it will be handled as an OOTB packet
in sending out an ABORT chunk. Therefore the association would not be resulting in sending out an ABORT chunk. Therefore the association
established. would not be established.
2.27.2 Text changes to the document 2.27.2 Text changes to the document
Some of the changes given here already include changes suggested in Some of the changes given here already include changes suggested in
section Section 2.2 of this document. section Section 2.2 of this document.
--------- ---------
Old text: (Section 3.2.1) Old text: (Section 3.2.1)
--------- ---------
skipping to change at page 54, line 33 skipping to change at page 54, line 38
2.27.3 Solution description 2.27.3 Solution description
The procedure of reporting unrecognized parameters has been described The procedure of reporting unrecognized parameters has been described
clearly. clearly.
2.28 Handling of IP Address Parameters 2.28 Handling of IP Address Parameters
2.28.1 Description of the problem 2.28.1 Description of the problem
It is not stated clearly in RFC2960 [5] how a SCTP endpoint which It is not stated clearly in RFC2960 [6] how a SCTP endpoint which
supports either IPv4 addresses or IPv6 addresses should respond if supports either IPv4 addresses or IPv6 addresses should respond if
IPv4 and IPv6 addresses are presented by the peer in the INIT or IPv4 and IPv6 addresses are presented by the peer in the INIT or
INIT-ACK chunk. INIT-ACK chunk.
2.28.2 Text changes to the document 2.28.2 Text changes to the document
--------- ---------
Old text: (Section 5.1.2) Old text: (Section 5.1.2)
--------- ---------
skipping to change at page 55, line 30 skipping to change at page 55, line 42
2.28.3 Solution description 2.28.3 Solution description
The procedure of handling IP address parameters has been described The procedure of handling IP address parameters has been described
clearly. clearly.
2.29 Handling of COOKIE ECHO chunks when a TCB exists 2.29 Handling of COOKIE ECHO chunks when a TCB exists
2.29.1 Description of the problem 2.29.1 Description of the problem
The description of be behavior in RFC2960 [5] when a COOKIE ECHO The description of the behavior in RFC2960 [6] when a COOKIE ECHO
chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is
received, a TCB exist and the local and peer's tag match it is stated received, a TCB exist and the local and peer's tag match it is stated
that the endpoint should enter the ESTABLISHED state if it has not that the endpoint should enter the ESTABLISHED state if it has not
already done so and send a COOKIE ACK. It was not clear that in case already done so and send a COOKIE ACK. It was not clear that in case
the endpoint has already left again the ESTABLISHED state then it the endpoint has already left again the ESTABLISHED state then it
should not go back to established. In case D the endpoint can only should not go back to established. In case D the endpoint can only
enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it
has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing
about the peer's tag which is requested to match in this case. about the peer's tag which is requested to match in this case.
skipping to change at page 56, line 42 skipping to change at page 57, line 11
--------- ---------
o The initial cwnd before DATA transmission or after a sufficiently o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be <= 2*MTU. long idle period MUST be <= 2*MTU.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o The initial cwnd before DATA transmission or after a sufficiently o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). long idle period MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)).
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 2*MTU) per RTO.
---------
New text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
2.30.3 Solution description 2.30.3 Solution description
The change to SCTP's initial congestion window will allow it to The change to SCTP's initial congestion window will allow it to
continue to maintain the same congestion control properties as TCP. continue to maintain the same congestion control properties as TCP.
2.31 Stream Sequence Numbers in Figures 2.31 Stream Sequence Numbers in Figures
2.31.1 Description of the problem 2.31.1 Description of the problem
In Section 2.24 of this document it is clarified that the SSN are In Section 2.24 of this document it is clarified that the SSN are
initialized with 0. Two figures in RFC2960 [5] illustrate that they initialized with 0. Two figures in RFC2960 [6] illustrate that they
start with 1. start with 1.
2.31.2 Text changes to the document 2.31.2 Text changes to the document
--------- ---------
Old text: (Section 7.2.1) Old text: (Section 7.2.1)
--------- ---------
Endpoint A Endpoint Z Endpoint A Endpoint Z
{app sets association with Z} {app sets association with Z}
skipping to change at page 63, line 14 skipping to change at page 64, line 41
2.32.3 Solution description 2.32.3 Solution description
The new text states clearly that only one unrecognized parameter is The new text states clearly that only one unrecognized parameter is
reported per parameter. reported per parameter.
2.33 Handling of unrecognized parameters 2.33 Handling of unrecognized parameters
2.33.1 Description of the problem 2.33.1 Description of the problem
It is not stated clearly in RFC2960 [5] how unrecognized parameters It is not stated clearly in RFC2960 [6] how unrecognized parameters
should be handled. The problem came up when an INIT contains an should be handled. The problem came up when an INIT contains an
unrecognized parameter with highest bits 00. It was not clear if an unrecognized parameter with highest bits 00. It was not clear if an
INIT-ACK should be sent or not. INIT-ACK should be sent or not.
2.33.2 Text changes to the document 2.33.2 Text changes to the document
Some of the changes given here already include changes suggested in Some of the changes given here already include changes suggested in
section Section 2.27 of this document. section Section 2.27 of this document.
--------- ---------
skipping to change at page 66, line 17 skipping to change at page 67, line 45
MUST contain a new Initiation Tag (randomly generated see Section MUST contain a new Initiation Tag (randomly generated see Section
5.3.1). Other parameters for the endpoint SHOULD be copied from the 5.3.1). Other parameters for the endpoint SHOULD be copied from the
existing parameters of the association (e.g. number of outbound existing parameters of the association (e.g. number of outbound
streams) into the INIT ACK and cookie. streams) into the INIT ACK and cookie.
--------- ---------
New text: (Section 5.2.2) New text: (Section 5.2.2)
--------- ---------
Unless otherwise stated, upon reception of an unexpected INIT for Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a this association, the endpoint MUST generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Tie-Tags to a reserved place within the State Cookie and the current Tie-Tags to a reserved place within the State Cookie and the
association's TCB. We shall refer to these locations inside the association's TCB. We shall refer to these locations inside the
cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer
to the copy within an association's TCB as the Local Tag and Peer's Tag. to the copy within an association's TCB as the Local Tag and Peer's Tag.
The outbound SCTP packet containing this INIT ACK MUST carry The outbound SCTP packet containing this INIT ACK MUST carry
a Verification Tag value equal to the Initiation Tag found in the a Verification Tag value equal to the Initiation Tag found in the
unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag
(randomly generated see Section 5.3.1). Other parameters for the (randomly generated see Section 5.3.1). Other parameters for the
endpoint SHOULD be copied from the existing parameters of the endpoint SHOULD be copied from the existing parameters of the
association (e.g. number of outbound streams) into the INIT ACK association (e.g. number of outbound streams) into the INIT ACK
and cookie. and cookie.
2.34.3 Solution description 2.34.3 Solution description
The solution to this problem is not to use the real verification tags The solution to this problem is not to use the real verification tags
within the State Cookie as tie-tags. Instead two 32 bit random within the State Cookie as tie-tags. Instead two 32 bit random
numbers are created to form one 64 bit nonces and stored both in the numbers are created to form one 64 bit nonces and stored both in the
State Cookie and the existing association TCB. This prevents exposing State Cookie and the existing association TCB. This prevents
the verification tags inadvertently. exposing the verification tags inadvertently.
2.35 Port number verification in the COOKIE-ECHO 2.35 Port number verification in the COOKIE-ECHO
2.35.1 Description of the problem 2.35.1 Description of the problem
The State Cookie sent by a listening SCTP endpoint may not contain The State Cookie sent by a listening SCTP endpoint may not contain
the original port numbers or the local verification tag. It is then the original port numbers or the local verification tag. It is then
possible that the endpoint on reception of the COOKIE-ECHO will not possible that the endpoint on reception of the COOKIE-ECHO will not
be able to verify that these values match the original values found be able to verify that these values match the original values found
in the INIT and INIT-ACK that began the association setup. in the INIT and INIT-ACK that began the association setup.
skipping to change at page 69, line 15 skipping to change at page 70, line 45
1) Any address passed to the sender of the INIT by its 1) Any address passed to the sender of the INIT by its
upper layer is automatically considered to be CONFIRMED. upper layer is automatically considered to be CONFIRMED.
2) For the receiver of the COOKIE-ECHO the only CONFIRMED 2) For the receiver of the COOKIE-ECHO the only CONFIRMED
address is the one that the INIT-ACK was sent to. address is the one that the INIT-ACK was sent to.
3) All other addresses not covered by rules 1 and 2 are considered 3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification. UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send To probe an address for verification, an endpoint will send
HEARTBEAT's including a new 64 bit random nonce and a path HEARTBEAT's including a 64 bit random nonce and a path
indicator (to identify the address that the HEARTBEAT indicator (to identify the address that the HEARTBEAT
is sent to) within the HEARTBEAT parameter. is sent to) within the HEARTBEAT parameter.
Upon reception of the HEARTBEAT-ACK a verification is Upon reception of the HEARTBEAT-ACK a verification is
made that the nonce included in the HEARTBEAT parameter made that the nonce included in the HEARTBEAT parameter
is the one sent to the address indicated inside the is the one sent to the address indicated inside the
HEARTBEAT parameter. When this match occurs, the address HEARTBEAT parameter. When this match occurs, the address
that the original HEARTBEAT was sent to is now considered that the original HEARTBEAT was sent to is now considered
CONFIRMED and available for normal data transfer. CONFIRMED and available for normal data transfer.
These probing proceedures are started when an association These probing proceedures are started when an association
moves to the ESTABLISHED state and are ended when all moves to the ESTABLISHED state and are ended when all
paths are confirmed. paths are confirmed.
Each RTO a probe may be sent on an active UNCONFIRMED path Each RTO a probe may be sent on an active UNCONFIRMED path
in an attempt to move it to to the CONFIRMED state. in an attempt to move it to to the CONFIRMED state.
If during this probing the path becomes inactive this rate If during this probing the path becomes inactive this rate
is lowered to the normal HEARTBEAT rate. At the expiration is lowered to the normal HEARTBEAT rate. At the expiration
of the RTO timer the error counter of any path that was of the RTO timer the error counter of any path that was
probed but not CONFIRMED is incremented by one and subjected probed but not CONFIRMED is incremented by one and subjected
to path failure detection defined in section 8.2. to path failure detection defined in section 8.2. When probing
UNCONFIRMED addresses, however, the association overall error count
is NOT incremented.
The number of HEARTBEATS sent at each RTO MUST be limted The number of HEARTBEATS sent at each RTO SHOULD be limited
by the Max.Burst parameter. by the Max.Burst parameter. It is an implementation decision
as to how to distribute HEARTBEATS to the peers addresses
for path verification.
Whenever a path is confirmed an indication is given to Whenever a path is confirmed an indication MAY be given to
to the upper layer. to the upper layer.
An UNCONFIRMED path MUST NOT be used as the primary path An endpoint MUST NOT send any DATA chunks to an UNCONFIRMED
for the association. address.
2.36.3 Solution description 2.36.3 Solution description
By properly setting up initial path state and accelerated probing via By properly setting up initial path state and accelerated probing via
HEARTBEAT's an new association can verify that all addresses HEARTBEAT's an new association can verify that all addresses
presented by a peer belong to that peer. presented by a peer belong to that peer.
2.37 ICMP handling procedures 2.37 ICMP handling procedures
2.37.1 Description of the problem 2.37.1 Description of the problem
skipping to change at page 70, line 33 skipping to change at page 72, line 22
Appendix C ICMP Handling Appendix C ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint the Whenever an ICMP message is received by an SCTP endpoint the
following procedures should be followed to assure proper following procedures should be followed to assure proper
utilization of the information being provided by layer 3. utilization of the information being provided by layer 3.
ICMP1) Ignore all ICMPv4 messages where the type field is ICMP1) Ignore all ICMPv4 messages where the type field is
not set to "Destination Unreachable". not set to "Destination Unreachable".
ICMP2) Ignore all ICMPv6 messages where the type filed is ICMP2) Ignore all ICMPv6 messages where the type filed is
not "Parameter Problem" or "Packet Too Big". not "Destination Unreachable, "Parameter Problem" or
"Packet Too Big".
ICMP3) Ignore any ICMPv4 messages where the code does not ICMP3) Ignore any ICMPv4 messages where the code does not
indicate "Protocol Unreachable" or "Fragmentation Needed". indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if
the code is not "Unrecognized next header type encountered". the code is not "Unrecognized next header type encountered".
ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the
association which sent the message that ICMP is responding to. If association which sent the message that ICMP is responding to. If
the association cannot be found, ignore the ICMP message. the association cannot be found, ignore the ICMP message.
ICMP6) Validate that the verification tag contained in the ICMP message ICMP6) Validate that the verification tag contained in the ICMP message
matches the verification tag of the peer. matches the verification tag of the peer. If the verification
tag does NOT match, discard the ICMP message.
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
"Fragmentation Needed" process this information as defined for "Fragmentation Needed" process this information as defined for
PATH MTU discovery. PATH MTU discovery.
ICMP8) If the ICMP code is a "Unrecognized next header type encountered" ICMP8) If the ICMP code is a "Unrecognized next header type encountered"
or a "Protocol Unreachable" treat this message as an abort or a "Protocol Unreachable" treat this message as an abort
with the T bit set. with the T bit set.
ICMP9) If the ICMPv6 code is "Destination Unreachable" the implementation
MAY mark the destination into the unreachable state or alternatively
increment the path error counter.
2.37.3 Solution description 2.37.3 Solution description
The new appendix now describes proper handling of ICMP messages in The new appendix now describes proper handling of ICMP messages in
conjunction with SCTP. conjunction with SCTP.
2.38 Checksum
2.38.1 Description of the problem
RFC3309 [7] changes the SCTP checksum due to weaknesses in the
original Adler 32 checksum for small messages.
2.38.2 Text changes to the document
---------
Old text:
---------
6.8 Adler-32 Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall:
1) Fill in the proper Verification Tag in the SCTP common header and
initialize the checksum field to 0's.
2) Calculate the Adler-32 checksum of the whole packet, including the
SCTP common header and all the chunks. Refer to appendix B for
details of the Adler-32 algorithm. And,
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:
1) Store the received Adler-32 checksum value aside,
RFC 2960 Stream Control Transmission Protocol October 2000
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value of
the whole received packet. And,
3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat the
packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
---------
New text:
---------
6.8 CRC-32c Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the CRC32c checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter MUST:
1) Fill in the proper Verification Tag in the SCTP common header and
initialize the checksum field to 0's.
2) Calculate the CRC32c checksum of the whole packet, including the
SCTP common header and all the chunks. Refer to appendix B for
details of the CRC32c algorithm. And,
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
CRC32c checksum:
1) Store the received CRC32c checksum value aside,
RFC 2960 Stream Control Transmission Protocol October 2000
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate a CRC32c checksum value of
the whole received packet. And,
3) Verify that the calculated CRC32c checksum is the same as the
received CRC32c checksum. If not, the receiver MUST treat the
packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
Any hardware implementation SHOULD be done in a way that is
verifiable by the software.
---------
Old text:
---------
Appendix B Alder 32 bit checksum calculation
The Adler-32 checksum calculation given in this appendix is copied from
[RFC1950].
Adler-32 is composed of two sums accumulated per byte: s1 is the sum
of all bytes, s2 is the sum of all s1 values. Both sums are done
modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32
checksum is stored as s2*65536 + s1 in network byte order.
The following C code computes the Adler-32 checksum of a data buffer.
It is written for clarity, not for speed. The sample code is in the
ANSI C programming language. Non C users may find it easier to read
with these hints:
RFC 2960 Stream Control Transmission Protocol October 2000
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should be
initialized to 1.
Usage example:
unsigned long adler = 1L;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
---------
New text:
---------
Appendix B CRC32c checksum calculation
We define a 'reflected value' as one that is the opposite of the
normal bit order of the machine. The 32 bit CRC is calculated as
described for CRC-32c and uses the polynomial code 0x11EDC6F41
(Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The
CRC is computed using a procedure similar to ETHERNET CRC [ITU32],
modified to reflect transport level usage.
CRC computation uses polynomial division. A message bit-string M is
transformed to a polynomial, M(X), and the CRC is calculated from
M(X) using polynomial arithmetic [PETERSON 72].
When CRCs are used at the link layer, the polynomial is derived from
on-the-wire bit ordering: the first bit 'on the wire' is the high-
order coefficient. Since SCTP is a transport-level protocol, it
cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use different
link-level bit orders.
A convention must therefore be established for mapping SCTP transport
messages to polynomials for purposes of CRC computation. The bit-
ordering for mapping SCTP messages to polynomials is that bytes are
taken most-significant first; but within each byte, bits are taken
least-significant first. The first byte of the message provides the
eight highest coefficients. Within each byte, the least-significant
SCTP bit gives the most significant polynomial coefficient within
that byte, and the most-significant SCTP bit is the least significant
polynomial coefficient in that byte. (This bit ordering is sometimes
called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are
to be transformed back into SCTP transport-level byte values, using a
consistent mapping.
The SCTP transport-level CRC value should be calculated as follows:
- CRC input data are assigned to a byte stream, numbered from 0
to N-1.
- the transport-level byte-stream is mapped to a polynomial
value. An N-byte PDU with j bytes numbered 0 to N-1, is
considered as coefficients of a polynomial M(x) of order 8N-1,
with bit 0 of byte j being coefficient x^(8(N-j)-8), bit 7 of
byte j being coefficient x^(8(N-j)-1).
- the CRC remainder register is initialized with all 1s and the
CRC is computed with an algorithm that simultaneously
multiplies by x^32 and divides by the CRC polynomial.
- the polynomial is multiplied by x^32 and divided by G(x), the
generator polynomial, producing a remainder R(x) of degree less
than or equal to 31.
- the coefficients of R(x) are considered a 32 bit sequence.
- the bit sequence is complemented. The result is the CRC
polynomial.
- The CRC polynomial is mapped back into SCTP transport-level
bytes. Coefficient of x^31 gives the value of bit 7 of SCTP
byte 0, the coefficient of x^24 gives the value of bit 0 of
byte 0. The coefficient of x^7 gives bit 7 of byte 3 and the
coefficient of x^0 gives bit 0 of byte 3. The resulting four-
byte transport-level sequence is the 32-bit SCTP checksum
value.
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
literature on CRCs often follow an alternative formulation, in which
the register used to hold the remainder of the long-division
algorithm is initialized to zero rather than all-1s, and instead the
first 32 bits of the message are complemented. The long-division
algorithm used in our formulation is specified, such that the the
initial multiplication by 2^32 and the long-division are combined
into one simultaneous operation. For such algorithms, and for
messages longer than 64 bits, the two specifications are precisely
equivalent. That equivalence is the intent of this document.
Implementors of SCTP are warned that both specifications are to be
found in the literature, sometimes with no restriction on the long-
division algorithm. The choice of formulation in this document is to
permit non-SCTP usage, where the same CRC algorithm may be used to
protect messages shorter than 64 bits.
There may be a computational advantage in validating the Association
against the Verification Tag, prior to performing a checksum, as
invalid tags will result in the same action as a bad checksum in most
cases. The exceptions for this technique would be INIT and some
SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These
special case exchanges must represent small packets and will minimize
the effect of the checksum calculation.
---------
Old text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
---------
New text: (Section 18, including changes from 2.11)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[ITU32] ITU-T Recommendation V.42, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous
conversion", section 8.1.1.6.2, October 1996.
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
Codes, 2nd. edition, MIT Press, Cambridge,
Massachusetts.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR
DETECTION ALGORITHMS" - Internet publication, August
1993,
http://www.geocities.com/SiliconValley/Pines/
8659/crc.htm.
2.38.3 Solution description
This change adds the implementors guide the complete set of changes
that when combined with RFC2960 [6] encompasses the changes from
RFC3309 [7].
2.39 Retransmission Policy
2.39.1 Description of the problem
The current retransmission policy (send all retransmissions an
alternate destination) in the specification has performance issues
under certain loss conditions with multihomed endpoints. Instead,
fast retransmissions should be sent to the same destination, and only
timeout retransmissions should be sent to an alternate destination
[4].
2.39.2 Text changes to the document
---------
Old text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk to an active destination transport address that is
different from the last destination address to which the DATA chunk
was sent.
---------
New text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk that timed out to an active destination transport
address that is different from the last destination address to which
the DATA chunk was sent.
---------
Old text: (Section 6.4.1)
---------
When retransmitting data, if the endpoint is multi-homed, it should
consider each source-destination address pair in its retransmission
selection policy. When retransmitting the endpoint should attempt to
pick the most divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
---------
New text: (Section 6.4.1)
---------
When retransmitting data that timed out, if the endpoint is
multi-homed, it should consider each source-destination address pair in
its retransmission selection policy. When retransmitting timed out
data, the endpoint should attempt to pick the most divergent
source-destination pair from the original source-destination pair to
which the packet was transmitted.
2.39.3 Solution description
The above wording changes clarifies that only timeout retransmissions
should be sent to an alternate active destination.
2.40 Port Number 0
2.40.1 Description of the problem
The port number 0 has a special semantic in various APIs. For
example in the socket API, if the user specifies 0, the SCTP
implementation choses an appropriate port number for the user.
Therefore the port number 0 should not be used on the wire.
2.40.2 Text changes to the document
---------
Old text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port and possibly the destination IP address to
identify the association to which this packet belongs.
Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application.
---------
New text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port and possibly the destination IP address to
identify the association to which this packet belongs.
The port number 0 MUST NOT be used.
Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application.
The port number 0 MUST NOT be used.
2.40.3 Solution description
It is clearly stated that the port number 0 is an invalid value on
the wire.
2.41 T Bit
2.41.1 Description of the problem
The description of the T bit as the bit describing whether a TCB has
been destroyed or not is misleading. In additional, the procedure
described in Section 2.13 is not as precise as needed.
2.41.2 Text changes to the document
---------
Old text: (Section 3.3.7)
---------
T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it destroyed.
If the sender did not have a TCB it should set this bit to 1.
---------
New text: (Section 3.3.7)
---------
T bit: 1 bit
The T bit is set to 0 if the sender filled in the Verification
Tag expected by the peer. If the Verification Tag is reflected
the T bit MUST be set to 1. Reflecting means that the sent
Verification Tag is the same as the received one.
---------
Old text: (Section 3.3.13)
---------
T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it destroyed.
If the sender did not have a TCB it should set this bit to 1.
---------
New text: (Section 3.3.13)
---------
T bit: 1 bit
The T bit is set to 0 if the sender filled in the Verification
Tag expected by the peer. If the Verification Tag is reflected
the T bit MUST be set to 1. Reflecting means that the sent
Verification Tag is the same as the received one.
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. Otherwise,
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. If, for whatever
reason, the INIT can not be processed normally and an ABORT has to be
sent in response, the Verification Tag of the packet containing the
ABORT chunk MUST be the Initiate tag of the received INIT chunk
and the T-Bit of the ABORT chunk has to be set to 0 indicating that
the Verification Tag is NOT reflected.
---------
Old text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
packet must fill in the Verification Tag field of the outbound
packet with the Verification Tag received in the SHUTDOWN ACK and
set the T-bit in the Chunk Flags to indicate that no TCB was
found. Otherwise,
---------
New text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
packet must fill in the Verification Tag field of the outbound
packet with the Verification Tag received in the SHUTDOWN ACK and
set the T-bit in the Chunk Flags to indicate that the Verification
Tag is reflected. Otherwise,
---------
Old text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the Verification Tag field of the outbound packet
with the value found in the Verification Tag field of the OOTB
packet and set the T-bit in the Chunk Flags to indicate that no
TCB was found. After sending this ABORT, the receiver of the OOTB
packet shall discard the OOTB packet and take no further action.
---------
New text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the Verification Tag field of the outbound packet
with the value found in the Verification Tag field of the OOTB
packet and set the T-bit in the Chunk Flags to indicate that the
Verification Tag is reflected. After sending this ABORT, the
receiver of the OOTB packet shall discard the OOTB packet and take
no further action.
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no
further action.
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT MUST accept the packet
if the Verification Tag field of the packet matches its own tag and
the T bit is not set
OR
it is set to its peer's tag and the T bit is set in the Chunk
Flags.
Otherwise, the receiver MUST silently discard the packet
and take no further action.
---------
Old text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
be used. Only where no TCB exists should the sender use the
Verification Tag from the SHUTDOWN ACK.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if
the Verification Tag field of the packet matches its own tag OR
it is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
---------
New text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
be used. Only where no TCB exists should the sender use the
Verification Tag from the SHUTDOWN ACK.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet
if the Verification Tag field of the packet matches its own tag and
the T bit is not set
OR
it is set to its peer's tag and the T bit is set in the Chunk
Flags.
Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
2.41.3 Solution description
The description of the T bit now clearly describes the semantic of
the bit. The procedures for the reception of the T bit have been
clarified.
2.42 Unknown Parameter Handling
2.42.1 Description of the problem
The description given in Section 2.33 does not state clearly if an
INIT-ACK or COOKIE-ECHO is sent.
2.42.2 Text changes to the document
The changes given here already include changes suggested in sections
Section 2.2, Section 2.27, and Section 2.33 of this document.
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter, do not process
any further parameters within this chunk.
01 - Stop processing this parameter, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter Type' as
described in 3.2.2.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' as
described in 3.2.2.
Please note, that in all four cases an INIT-ACK or COOKIE-ECHO
chunk is sent. In the 00 or 01 case the processing of the
parameters after the unknown parameter is canceled, but no
processing already done is rolled back.
---------
New text: (Note no old text, clarification added in section 3.2)
---------
3.2.2 Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters
and has to report them according to section 3.2.1 it MUST put
the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
sent in response to the INIT-chunk. Note that if the receiver
of the INIT chunk is NOT going to establish an association (e.g.
due to lack of resources) an 'Unrecognized Parameters' would NOT
be included with any ABORT being sent to the sender of the INIT.
If the receiver of an INIT-ACK chunk detects unrecognized parameters
and has to report them according to section 3.2.1 it SHOULD bundle
the ERROR chunk containing the 'Unrecognized Parameters' error cause
with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk
with the ERROR chunk the ERROR chunk MAY be sent separately but not
before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the
first chunk.
2.42.3 Solution description
The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be
sent.
2.43 Cookie Echo Chunk
2.43.1 Description of the problem
The description given in section 3.3.11 of RFC2960 [6] is unclear as
to how the COOKIE-ECHO is composed.
2.43.2 Text changes to the document
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible to
insure interoperability.
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible to
insure interoperability.
Note: A Cookie Echo does NOT contain a State Cookie
Parameter, instead the data within the State Cookie's
Parameter Value becomes the data within the Cookie Echo's
Chunk Value. This allows an implementation to only change
the first two bytes of the State Cookie parameter to become
a Cookie Echo Chunk.
2.43.3 Solution description
The new text adds a note that helps clearify that a Cookie Echo chunk
is nothing more than the State Cookie parameter with only two bytes
modified.
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:
Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj 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
Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin,
Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson,
David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa
Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred
Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Sverre Slotte, Wang
Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken
Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel,
Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian
Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David Periam, Nathalie Mouellic, Atsushi Fukumoto, David Lehmann, Rob
Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Janardhan
Janardhan Iyengar, Serkan Cil and Caitlin Bestler. Iyengar, Serkan Cil, Bernward Meyknecht and Caitlin Bestler.
A special thanks to Mark Allman, who should actually be a co-author A special thanks to Mark Allman, who should actually be a co-author
for his work on the max-burst, but managed to wiggle out due to a for his work on the max-burst, but managed to wiggle out due to a
technicality. Also we would like to acknowledge Lyndon Ong and Phil technicality. Also we would like to acknowledge Lyndon Ong and Phil
Conrad for their valuable input and many contributions. Conrad for their valuable input and many contributions.
References 4 References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP [3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP
and TCP Variants: Congestion Control Under Multiple Losses", and TCP Variants: Congestion Control Under Multiple Losses",
Technical Report TR2003-04, Computer and Information Sciences Technical Report TR2003-04, Computer and Information Sciences
Department, University of Delaware, February 2003, <http:// Department, University of Delaware, February 2003,
www.cis.udel.edu/~acaro/papers>. <http://www.armandocaro.net/papers>.
[4] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window [4] Caro, A., Amer, P. and R. Stewart, "Retransmission Schemes for
End-to-end Failover with Transport Layer Multihoming", GLOBECOM
2004, November 2004., March 2004,
<http://www.armandocaro.net/papers>.
[5] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window
Validation", RFC 2861, June 2000. Validation", RFC 2861, June 2000.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[7] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission
Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 4875 Forest Drive
Suite 300 Suite 200
Chicago, IL 60631 Columbia, SC 29206
USA USA
Phone:
EMail: rrs@cisco.com EMail: rrs@cisco.com
Ivan Arias-Rodriguez Ivan Arias-Rodriguez
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Phone:
EMail: ivan.arias-rodriguez@nokia.com EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon
Consultant
Milpitas, CA Kacheong Poon
Sun Microsystems, Inc.
3571 N. First St.
San Jose, CA 95134
USA
Phone: EMail: kacheong.poon@sun.com
EMail: kcpoon@yahoo.com
Armando L. Caro Jr. Armando L. Caro Jr.
University of Delaware University of Delaware
Department of Computer & Information Sciences Department of Computer & Information Sciences
103 Smith Hall 103 Smith Hall
Newark, DE 19716 Newark, DE 19716
USA USA
Phone: EMail: me @ armandocaro . net
EMail: acaro@cis.udel.edu URI: http://www.armandocaro.net
URI: http://www.cis.udel.edu/~acaro
Michael Tuexen Michael Tuexen
Univ. of Applied Sciences Muenster Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
EMail: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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