draft-ietf-tsvwg-sctpimpguide-08.txt   draft-ietf-tsvwg-sctpimpguide-09.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 27, 2003 L. Ong Expires: March 12, 2004 L. Ong
Ciena Systems Ciena Systems
I. Arias-Rodriguez I. Arias-Rodriguez
Nokia Research Center Nokia Research Center
K. Poon K. Poon
Consultant Consultant
P. Conrad P. Conrad
Temple University
A. Caro A. Caro
University of Delaware University of Delaware
M. Tuexen M. Tuexen
February 26, 2003 Univ. of Applied Sciences Muenster
September 12, 2003
Stream Control Transmission Protocol (SCTP) Implementer's Guide Stream Control Transmission Protocol (SCTP) Implementer's Guide
draft-ietf-tsvwg-sctpimpguide-08.txt draft-ietf-tsvwg-sctpimpguide-09.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
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 http://
www.ietf.org/ietf/1id-abstracts.txt. 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 August 27, 2003. This Internet-Draft will expire on March 12, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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 [5]. 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 [5] and text within this document
supersedes the text found in RFC2960 [5]. supersedes the text found in RFC2960 [5].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 6 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 7
2.1 Incorrect error type during chunk processing. . . . . . . 6 2.1 Incorrect error type during chunk processing. . . . . . . 7
2.1.1 Description of the problem . . . . . . . . . . . . . . . . 6 2.1.1 Description of the problem . . . . . . . . . . . . . . . . 7
2.1.2 Text changes to the document . . . . . . . . . . . . . . . 6 2.1.2 Text changes to the document . . . . . . . . . . . . . . . 7
2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 6 2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 7
2.2 Parameter processing issue . . . . . . . . . . . . . . . . 6 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 7
2.2.1 Description of the problem . . . . . . . . . . . . . . . . 6 2.2.1 Description of the problem . . . . . . . . . . . . . . . . 7
2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7
2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 7 2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 8
2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.3.1 Description of the problem . . . . . . . . . . . . . . . . 8
2.3.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.3.2 Text changes to the document . . . . . . . . . . . . . . . 8
2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 9 2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 10
2.4 Parameter types across all chunk types . . . . . . . . . . 9 2.4 Parameter types across all chunk types . . . . . . . . . . 10
2.4.1 Description of the problem . . . . . . . . . . . . . . . . 9 2.4.1 Description of the problem . . . . . . . . . . . . . . . . 10
2.4.2 Text changes to the document . . . . . . . . . . . . . . . 9 2.4.2 Text changes to the document . . . . . . . . . . . . . . . 10
2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 10 2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 11
2.5 Stream parameter clarification . . . . . . . . . . . . . . 11 2.5 Stream parameter clarification . . . . . . . . . . . . . . 12
2.5.1 Description of the problem . . . . . . . . . . . . . . . . 11 2.5.1 Description of the problem . . . . . . . . . . . . . . . . 12
2.5.2 Text changes to the document . . . . . . . . . . . . . . . 11 2.5.2 Text changes to the document . . . . . . . . . . . . . . . 12
2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 11 2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 12
2.6 Restarting association security issue . . . . . . . . . . 12 2.6 Restarting association security issue . . . . . . . . . . 13
2.6.1 Description of the problem . . . . . . . . . . . . . . . . 12 2.6.1 Description of the problem . . . . . . . . . . . . . . . . 13
2.6.2 Text changes to the document . . . . . . . . . . . . . . . 12 2.6.2 Text changes to the document . . . . . . . . . . . . . . . 13
2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 16 2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 17
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 16 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 17
2.7.1 Description of the problem . . . . . . . . . . . . . . . . 16 2.7.1 Description of the problem . . . . . . . . . . . . . . . . 17
2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17 2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17
2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 17 2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 18
2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 17 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 18
2.8.1 Description of the problem . . . . . . . . . . . . . . . . 17 2.8.1 Description of the problem . . . . . . . . . . . . . . . . 18
2.8.2 Text changes to the document . . . . . . . . . . . . . . . 17 2.8.2 Text changes to the document . . . . . . . . . . . . . . . 18
2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 20 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.9.1 Description of the problem . . . . . . . . . . . . . . . . 21
2.9.2 Text changes to the document . . . . . . . . . . . . . . . 21 2.9.2 Text changes to the document . . . . . . . . . . . . . . . 22
2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 22 2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 23
2.10 Issues with Heartbeating and failure detection . . . . . . 22 2.10 Issues with Heartbeating and failure detection . . . . . . 23
2.10.1 Description of the problem . . . . . . . . . . . . . . . . 22 2.10.1 Description of the problem . . . . . . . . . . . . . . . . 23
2.10.2 Text changes to the document . . . . . . . . . . . . . . . 22 2.10.2 Text changes to the document . . . . . . . . . . . . . . . 23
2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 25 2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 26
2.11 Security interactions with firewalls . . . . . . . . . . . 25 2.11 Security interactions with firewalls . . . . . . . . . . . 26
2.11.1 Description of the problem . . . . . . . . . . . . . . . . 25 2.11.1 Description of the problem . . . . . . . . . . . . . . . . 26
2.11.2 Text changes to the document . . . . . . . . . . . . . . . 25 2.11.2 Text changes to the document . . . . . . . . . . . . . . . 26
2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 27 2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 28
2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 27 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 28
2.12.1 Description of the problem . . . . . . . . . . . . . . . . 27 2.12.1 Description of the problem . . . . . . . . . . . . . . . . 28
2.12.2 Text changes to the document . . . . . . . . . . . . . . . 27 2.12.2 Text changes to the document . . . . . . . . . . . . . . . 28
2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29 2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29
2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29 2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29
2.13.1 Description of the problem . . . . . . . . . . . . . . . . 29 2.13.1 Description of the problem . . . . . . . . . . . . . . . . 30
2.13.2 Text changes to the document . . . . . . . . . . . . . . . 29 2.13.2 Text changes to the document . . . . . . . . . . . . . . . 30
2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30 2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30
2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 30 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 31
2.14.1 Description of the problem . . . . . . . . . . . . . . . . 30 2.14.1 Description of the problem . . . . . . . . . . . . . . . . 31
2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31 2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31
2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 33 2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 34
2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 33 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 34
2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34 2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34
2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34 2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34
2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 35 2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 36
2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36
2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36 2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36
2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36 2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36
2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37 2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37
2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37 2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37
2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37 2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37
2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37 2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37
2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38 2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38
2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38 2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38
2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39 2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39
2.19 Handling of stream shortages . . . . . . . . . . . . . . . 40 2.19 Handling of stream shortages . . . . . . . . . . . . . . . 39
2.19.1 Description of the problem . . . . . . . . . . . . . . . . 40 2.19.1 Description of the problem . . . . . . . . . . . . . . . . 39
2.19.2 Text changes to the document . . . . . . . . . . . . . . . 40 2.19.2 Text changes to the document . . . . . . . . . . . . . . . 39
2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 41 2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 40
2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 41 2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 40
2.20.1 Description of the problem . . . . . . . . . . . . . . . . 41 2.20.1 Description of the problem . . . . . . . . . . . . . . . . 40
2.20.2 Text changes to the document . . . . . . . . . . . . . . . 41 2.20.2 Text changes to the document . . . . . . . . . . . . . . . 40
2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 42 2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 41
2.21 User initiated abort of an association . . . . . . . . . . 42 2.21 User initiated abort of an association . . . . . . . . . . 41
2.21.1 Description of the problem . . . . . . . . . . . . . . . . 42 2.21.1 Description of the problem . . . . . . . . . . . . . . . . 41
2.21.2 Text changes to the document . . . . . . . . . . . . . . . 43 2.21.2 Text changes to the document . . . . . . . . . . . . . . . 41
2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 48 2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 47
2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 48 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 47
2.22.1 Description of the problem . . . . . . . . . . . . . . . . 48 2.22.1 Description of the problem . . . . . . . . . . . . . . . . 47
2.22.2 Text changes to the document . . . . . . . . . . . . . . . 48 2.22.2 Text changes to the document . . . . . . . . . . . . . . . 47
2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 49 2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 48
2.23 ABORT sending in response to an INIT . . . . . . . . . . . 49 2.23 ABORT sending in response to an INIT . . . . . . . . . . . 48
2.23.1 Description of the problem . . . . . . . . . . . . . . . . 50 2.23.1 Description of the problem . . . . . . . . . . . . . . . . 48
2.23.2 Text changes to the document . . . . . . . . . . . . . . . 50 2.23.2 Text changes to the document . . . . . . . . . . . . . . . 48
2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 50 2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 48
2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 50 2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 49
2.24.1 Description of the problem . . . . . . . . . . . . . . . . 50 2.24.1 Description of the problem . . . . . . . . . . . . . . . . 49
2.24.2 Text changes to the document . . . . . . . . . . . . . . . 51 2.24.2 Text changes to the document . . . . . . . . . . . . . . . 49
2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 51 2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 49
2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 51 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 49
2.25.1 Description of the problem . . . . . . . . . . . . . . . . 51 2.25.1 Description of the problem . . . . . . . . . . . . . . . . 49
2.25.2 Text changes to the document . . . . . . . . . . . . . . . 52 2.25.2 Text changes to the document . . . . . . . . . . . . . . . 49
2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 52 2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 50
2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 52 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 50
2.26.1 Description of the problem . . . . . . . . . . . . . . . . 52 2.26.1 Description of the problem . . . . . . . . . . . . . . . . 50
2.26.2 Text changes to the document . . . . . . . . . . . . . . . 52 2.26.2 Text changes to the document . . . . . . . . . . . . . . . 50
2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 54 2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 52
2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 54 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 52
2.27.1 Description of the problem . . . . . . . . . . . . . . . . 54 2.27.1 Description of the problem . . . . . . . . . . . . . . . . 52
2.27.2 Text changes to the document . . . . . . . . . . . . . . . 55 2.27.2 Text changes to the document . . . . . . . . . . . . . . . 53
2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 56 2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 54
2.28 Handling of IP Address Parameters . . . . . . . . . . . . 56 2.28 Handling of IP Address Parameters . . . . . . . . . . . . 54
2.28.1 Description of the problem . . . . . . . . . . . . . . . . 56 2.28.1 Description of the problem . . . . . . . . . . . . . . . . 54
2.28.2 Text changes to the document . . . . . . . . . . . . . . . 57 2.28.2 Text changes to the document . . . . . . . . . . . . . . . 54
2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 57 2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 55
2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 57 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 55
2.29.1 Description of the problem . . . . . . . . . . . . . . . . 57 2.29.1 Description of the problem . . . . . . . . . . . . . . . . 55
2.29.2 Text changes to the document . . . . . . . . . . . . . . . 58 2.29.2 Text changes to the document . . . . . . . . . . . . . . . 55
2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 58 2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 56
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 59 2.30 The Initial Congestion Window Size . . . . . . . . . . . . 56
References . . . . . . . . . . . . . . . . . . . . . . . . 60 2.30.1 Description of the problem . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 60 2.30.2 Text changes to the document . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . 63 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
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 65
References . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . 69
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 [5]. 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.
skipping to change at page 7, line 34 skipping to change at page 8, line 27
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 in an unknown chunk or parameter with the upper bit set to 0. Thus if
if you are processing a chunk, you should drop the packet. If you you are processing a chunk, you should drop the packet. If you are
are processing a parameter, you should drop the chunk. 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 49 skipping to change at page 11, line 47
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 means based on context. The trade off for this is a smaller parameter
parameter space i.e. 65,536 parameters versus 65,536 * space i.e. 65,536 parameters versus 65,536 * Number-of-chunks.
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
skipping to change at page 16, line 17 skipping to change at page 17, line 12
Initiation Tag (randomly generated see Section 5.3.1). Other Initiation Tag (randomly generated see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g. number of outbound streams) into parameters of the association (e.g. number of outbound streams) into
the INIT ACK and cookie. the INIT ACK and cookie.
After sending out the INIT ACK or ABORT, the endpoint shall take no After sending out the INIT ACK or ABORT, the endpoint shall take no
further actions, i.e., the existing association, including its further actions, i.e., the existing association, including its
current state, and the corresponding TCB MUST NOT be changed. current state, and the corresponding TCB MUST NOT be changed.
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, COOKIE-ECHOED 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 case, where new addresses have been added. The error code can be used
used by a legitimate restart to inform the endpoint that it has made by a legitimate restart to inform the endpoint that it has made a
a software error in adding a new address. The endpoint then can software error in adding a new address. The endpoint then can choose
choose to wait until the OOTB ABORT tears down the old association, to wait until the OOTB ABORT tears down the old association, or
or restart without the new address. 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 17, line 39 skipping to change at page 18, line 29
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 to retransmit a TSN that was marked for fast retransmit. No limit was
was placed on how many times a TSN could be fast retransmitted. Fast 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
skipping to change at page 21, line 49 skipping to change at page 22, line 40
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU cwnd = 1*MTU
--------- ---------
New text: (Section 7.2.3) New text: (Section 7.2.3)
--------- ---------
7.2.3 Congestion Control 7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following: endpoint should do the following if not in Fast Recovery:
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh cwnd = ssthresh
partial_bytes_acked = 0 partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half. Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow When the T3-rtx timer expires on an address, SCTP should perform slow
start by: start by:
skipping to change at page 31, line 4 skipping to change at page 31, line 11
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 decay of cwnd. The cwnd should only be increased if it is being fully
fully utilized, and after periods of under utilization, the cwnd utilized, and after periods of under utilization, the cwnd should be
should be decreased. In some sections, the current wording is weak decreased. In some sections, the current wording is weak and is not
and is not clearly defined. Also, the current specification clearly defined. Also, the current specification unnecessarily
unnecessarily introduces the need for special case code to ensure introduces the need for special case code to ensure cwnd degradation.
cwnd degradation. Plus, the cwnd should not be increased during Fast Plus, the cwnd should not be increased during Fast Recovery since a
Recovery since a full cwnd during Fast Recovery does not qualify the full cwnd during Fast Recovery does not qualify the cwnd as being
cwnd as being fully utilized. Additionally, multiple loss scenarios fully utilized. Additionally, multiple loss scenarios in a single
in a single window may cause the cwnd to grow more rapidly as the window may cause the cwnd to grow more rapidly as the number of
number of losses in a window increases [3]. 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.
skipping to change at page 33, line 46 skipping to change at page 34, line 9
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 not being utilized. The changes also applies cwnd degradation without
without introducing the need for complex special case code. 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 35, line 47 skipping to change at page 36, line 10
The sender MUST also have algorithm in sending new DATA chunks to The sender MUST also have algorithm in 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 dropped chunk as missing. This will allow the association to continue
continue until the rwnd condition clears. 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.
skipping to change at page 39, line 30 skipping to change at page 39, line 4
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 shall 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) When searching for a matching TCB upon reception of an INIT D) An INIT or INIT ACK chunk MUST be treated as belonging
or INIT-ACK chunk the receiver SHOULD use not only the to an already established association (or one in the
source address of the packet (containing the INIT or process of being established) if the use of any of the
INIT-ACK) but the receiver SHOULD also use all valid valid address parameters contained within the chunk
address parameters contained within the chunk. 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 to the destination address used to send the INIT
chunk. chunk.
skipping to change at page 48, line 20 skipping to change at page 47, line 16
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. Tag set to zero handles this as an error and sends back an ABORT. But
But the sender of the INIT-ACK normally has no TCB and so the ABORT the sender of the INIT-ACK normally has no TCB and so the ABORT is
is useless. 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 49, line 44 skipping to change at page 48, line 13
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 invalid stream numbers in the INIT-ACK. However it is allowed to send
send an ABORT for debugging purposes. 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 29 skipping to change at page 48, line 42
--------- ---------
New text: (Section 8.4) New text: (Section 8.4)
--------- ---------
3) If the packet contains an INIT chunk with a Verification Tag set 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 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 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 sent in response, the Verification Tag of the packet containing the
ABORT chunk MUST be the Initiate tag of the received INIT chunk 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 1 indicating that and the T-Bit of the ABORT chunk has to be set to 0 indicating that
a TCB was destroyed. Otherwise, a TCB was destroyed. Otherwise,
2.23.3 Solution description 2.23.3 Solution description
The new text stated clearly which value of the Verification Tag and The new text stated clearly which value of the Verification Tag and
T-bit have to be used. T-bit have to be used.
2.24 Stream Sequence Number (SSN) Initialization 2.24 Stream Sequence Number (SSN) Initialization
2.24.1 Description of the problem 2.24.1 Description of the problem
RFC 2960 does not describe the fact that the SSN have to initialized RFC 2960 does not describe the fact that the SSN have to be
to 0 in he way it is required by RFC2119. initialized to 0 in the way it is required by RFC2119.
2.24.2 Text changes to the document 2.24.2 Text changes to the document
--------- ---------
Old text: (Section 6.5) Old text: (Section 6.5)
--------- ---------
The stream sequence number in all the streams shall start from 0 when The stream sequence number in all the streams shall start from 0 when
the association is established. Also, when the stream sequence the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall number reaches the value 65535 the next stream sequence number shall
skipping to change at page 54, line 46 skipping to change at page 52, line 42
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 [5] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could should be reported. Unrecognized parameters in an INIT chunk could be
be reported in the INIT-ACK chunk or in a separate ERROR chunk which reported in the INIT-ACK chunk or in a separate ERROR chunk which can
can get lost. Unrecognized parameters in an INIT-ACK chunk have to get lost. Unrecognized parameters in an INIT-ACK chunk have to be
be reported in an ERROR-chunk. This can be bundled with the reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR
COOKIE-ERROR chunk or sent separately. If it is sent separately and chunk or sent separately. If it is sent separately and received
received before the COOKIE-ECHO it will be handled as an OOTB packet before the COOKIE-ECHO it will be handled as an OOTB packet resulting
resulting in sending out an ABORT chunk. Therefore the association in sending out an ABORT chunk. Therefore the association would not be
would not be established. 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 59, line 5 skipping to change at page 56, line 18
D) When both local and remote tags match the endpoint should D) When both local and remote tags match the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state.
It should stop any cookie timer that may be running and send It should stop any cookie timer that may be running and send
a COOKIE ACK. a COOKIE ACK.
2.29.3 Solution description 2.29.3 Solution description
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has The procedure of handling of COOKIE-ECHO chunks when a TCB exists has
been described clearly. been described clearly.
2.30 The Initial Congestion Window Size
2.30.1 Description of the problem
RFC2960 was published with the intention of having the same
congestion control properties as TCP. Since the publication of
RFC2960, TCP's initial congestion window size as been increased via
RFC3390. This same update will be needed for SCTP to keep SCTP's
congestion control properties equivilant to that of TCP.
2.30.2 Text changes to the document
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be <= 2*MTU.
---------
New text: (Section 7.2.1)
---------
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)).
2.30.3 Solution description
The change to SCTP's initial congestion window will allow it to
continue to maintain the same congestion control properties as TCP.
2.31 Stream Sequence Numbers in Figures
2.31.1 Description of the problem
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
start with 1.
2.31.2 Text changes to the document
---------
Old text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
---------
New text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
---------
Old text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
---------
New text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
2.31.3 Solution description
Figure 4 and figure 5 were changed such that the SSN start with 0
instead of 1.
2.32 Unrecognized Parameters
2.32.1 Description of the problem
The RFC does not state clearly in section 3.3.3.1 if one or multiple
unrecognized parameters are included in the 'Unrecognized Parameter'
parameter.
2.32.2 Text changes to the document
---------
Old text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
New text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
Parameter Type Value: 8
Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter which has a
value that indicates that it should be reported to the sender.
This parameter value field will contain unrecognized parameters
copied from the INIT chunk complete with Parameter Type, Length
and Value fields.
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
Parameter Type Value: 8
Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter which has a
value that indicates that it should be reported to the sender.
This parameter value field will contain the unrecognized parameter
copied from the INIT chunk complete with Parameter Type, Length
and Value fields.
2.32.3 Solution description
The new text states clearly that only one unrecognized parameter is
reported per parameter.
2.33 Handling of unrecognized parameters
2.33.1 Description of the problem
It is not stated clearly in RFC2960 [5] how unrecognized parameters
should be handled. The problem came up when an INIT contains an
unrecognized parameter with highest bits 00. It was not clear if an
INIT-ACK should be sent or not.
2.33.2 Text changes to the document
Some of the changes given here already include changes suggested in
section Section 2.27 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.
---------
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.33.3 Solution description
The procedure of handling unrecognized parameters has been described
clearly.
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, Kacheong Poon,
Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep
Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep
Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll,
Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David
Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah,
Janardhan Iyengar, and Serkan Cil. Janardhan Iyengar, Serkan Cil 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. technicality.
References 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, <http://
www.cis.udel.edu/~acaro/publications>. www.cis.udel.edu/~acaro/papers>.
[4] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window [4] 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, [5] 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.
Authors' Addresses Authors' Addresses
skipping to change at page 61, line 22 skipping to change at page 67, line 22
Kacheong Poon Kacheong Poon
Consultant Consultant
Milpitas, CA Milpitas, CA
Phone: Phone:
EMail: kcpoon@yahoo.com EMail: kcpoon@yahoo.com
Phillip T. Conrad Phillip T. Conrad
Temple University University of Delaware
CIS Department Department of Computer & Information Sciences
Room 303, Computer Building (038-24) 103 Smith Hall
1805 N. Broad St. Newark, DE 19716
Philadelphia, PA 19122 USA
US
Phone: +1 215 204 7910 Phone:
EMail: conrad@acm.org EMail: conrad@acm.org
URI: http://www.cis.temple.edu/~conrad
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: Phone:
EMail: acaro@cis.udel.edu EMail: acaro@cis.udel.edu
URI: http://www.cis.udel.edu/~acaro URI: http://www.cis.udel.edu/~acaro
Michael Tuexen Michael Tuexen
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany Germany
Phone:
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 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; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
 End of changes. 

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