draft-ietf-tsvwg-sctpimpguide-06.txt   draft-ietf-tsvwg-sctpimpguide-07.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: October 30, 2002 L. Ong Expires: April 1, 2003 L. Ong
Ciena Systems Ciena Systems
I. Arias-Rodriguez I. Arias-Rodriguez
Nokia Research Center Nokia Research Center
K. Poon K. Poon
Sun Microsysystems, Inc. Sun Microsysystems, Inc.
P. Conrad P. Conrad
Temple University Temple University
A. Caro A. Caro
Department of Computer & Department of Computer &
Information Sciences University of Information Sciences University of
Delaware Delaware
M. Tuexen M. Tuexen
Siemens AG Siemens AG
May 2002 October 1, 2002
Stream Control Transmission Protocol (SCTP) Implementers Guide Stream Control Transmission Protocol (SCTP) Implementers Guide
draft-ietf-tsvwg-sctpimpguide-06.txt draft-ietf-tsvwg-sctpimpguide-07.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 groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 30, 2002. This Internet-Draft will expire on April 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). 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 [3]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [3]. 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 [3] and text within this document This document updates RFC2960 [3] and text within this document
supersedes the text found in RFC2960 [3]. supersedes the text found in RFC2960 [3].
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 . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 12 2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 18
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 . . . . 22
2.9.1 Description of the problem . . . . . . . . . . . . . . . . 21 2.9.1 Description of the problem . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . 23 2.10.2 Text changes to the document . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . 28 2.12.2 Text changes to the document . . . . . . . . . . . . . . . 29
2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29 2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 30
2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29 2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . 31 2.14.1 Description of the problem . . . . . . . . . . . . . . . . 32
2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31 2.14.2 Text changes to the document . . . . . . . . . . . . . . . 32
2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 33 2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 34
2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 34 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 35
2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34 2.15.1 Description of the problem . . . . . . . . . . . . . . . . 35
2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34 2.15.2 Text changes to the document . . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . 37
2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36 2.16.1 Description of the problem . . . . . . . . . . . . . . . . 37
2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36 2.16.2 Text changes to the document . . . . . . . . . . . . . . . 37
2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37 2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 38
2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37 2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 38
2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37 2.17.1 Description of the problem . . . . . . . . . . . . . . . . 38
2.17.2 Text changes to the document . . . . . . . . . . . . . . . 38 2.17.2 Text changes to the document . . . . . . . . . . . . . . . 39
2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38 2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 39
2.18 Handling of address parameters within the INIT or INIT-ACK 38 2.18 Handling of address parameters within the INIT or INIT-ACK 39
2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38 2.18.1 Description of the problem . . . . . . . . . . . . . . . . 39
2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38 2.18.2 Text changes to the document . . . . . . . . . . . . . . . 39
2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39 2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 40
2.19 Handling of stream shortages . . . . . . . . . . . . . . . 39 2.19 Handling of stream shortages . . . . . . . . . . . . . . . 40
2.19.1 Description of the problem . . . . . . . . . . . . . . . . 40 2.19.1 Description of the problem . . . . . . . . . . . . . . . . 41
2.19.2 Text changes to the document . . . . . . . . . . . . . . . 40 2.19.2 Text changes to the document . . . . . . . . . . . . . . . 41
2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 41 2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 42
2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 41 2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 42
2.20.1 Description of the problem . . . . . . . . . . . . . . . . 41 2.20.1 Description of the problem . . . . . . . . . . . . . . . . 42
2.20.2 Text changes to the document . . . . . . . . . . . . . . . 41 2.20.2 Text changes to the document . . . . . . . . . . . . . . . 42
2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 42 2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 43
2.21 User initiated abort of an association . . . . . . . . . . 42 2.21 User initiated abort of an association . . . . . . . . . . 43
2.21.1 Description of the problem . . . . . . . . . . . . . . . . 43 2.21.1 Description of the problem . . . . . . . . . . . . . . . . 44
2.21.2 Text changes to the document . . . . . . . . . . . . . . . 43 2.21.2 Text changes to the document . . . . . . . . . . . . . . . 44
2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 48 2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 49
2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 48 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 49
2.22.1 Description of the problem . . . . . . . . . . . . . . . . 48 2.22.1 Description of the problem . . . . . . . . . . . . . . . . 49
2.22.2 Text changes to the document . . . . . . . . . . . . . . . 48 2.22.2 Text changes to the document . . . . . . . . . . . . . . . 49
2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 49 2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 50
2.23 ABORT sending in response to an INIT . . . . . . . . . . . 49 2.23 ABORT sending in response to an INIT . . . . . . . . . . . 50
2.23.1 Description of the problem . . . . . . . . . . . . . . . . 50 2.23.1 Description of the problem . . . . . . . . . . . . . . . . 51
2.23.2 Text changes to the document . . . . . . . . . . . . . . . 50 2.23.2 Text changes to the document . . . . . . . . . . . . . . . 51
2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 50 2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 51
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 51 2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 52 2.24.1 Description of the problem . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 52 2.24.2 Text changes to the document . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . 54 2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 52
2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 52
2.25.1 Description of the problem . . . . . . . . . . . . . . . . 52
2.25.2 Text changes to the document . . . . . . . . . . . . . . . 53
2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 53
2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 53
2.26.1 Description of the problem . . . . . . . . . . . . . . . . 53
2.26.2 Text changes to the document . . . . . . . . . . . . . . . 53
2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 55
2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 55
2.27.1 Description of the problem . . . . . . . . . . . . . . . . 55
2.27.2 Text changes to the document . . . . . . . . . . . . . . . 56
2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 57
2.28 Handling of IP Address Parameters . . . . . . . . . . . . 57
2.28.1 Description of the problem . . . . . . . . . . . . . . . . 57
2.28.2 Text changes to the document . . . . . . . . . . . . . . . 58
2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 58
2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 58
2.29.1 Description of the problem . . . . . . . . . . . . . . . . 58
2.29.2 Text changes to the document . . . . . . . . . . . . . . . 59
2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 59
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 60
References . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61
Full Copyright Statement . . . . . . . . . . . . . . . . . 63
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 [3]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [3]. 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 13, line 41 skipping to change at page 13, line 41
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
New text: (Note no old text, new error added in section 3.3.10) New text: (Note no old text, new error cause added in section 3.3.10)
--------- ---------
3.3.10.11 Restart of an association with new addresses (11) 3.3.10.11 Restart of an association with new addresses (11)
Cause of error Cause of error
-------------- --------------
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
skipping to change at page 28, line 41 skipping to change at page 28, line 41
receiver shall continue to follow normal data transmission procedures receiver shall 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) then than the cumulative TSN and thus gaps exist in the TSN sequence) or
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 shall send a SHUTDOWN ACK and start a
skipping to change at page 43, line 13 skipping to change at page 43, line 13
2.21 User initiated abort of an association 2.21 User initiated abort of an association
2.21.1 Description of the problem 2.21.1 Description of the problem
It is not possible for an upper layer to abort the association and It is not possible for an upper layer to abort the association and
provide the peer with an indication why the association is aborted. provide the peer with an indication why the association is aborted.
2.21.2 Text changes to the document 2.21.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 2.6.2 of this document. section Section 2.6 of this document.
--------- ---------
Old text: (Section 3.3.10) Old text: (Section 3.3.10)
--------- ---------
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
1 Invalid Stream Identifier 1 Invalid Stream Identifier
2 Missing Mandatory Parameter 2 Missing Mandatory Parameter
skipping to change at page 44, line 35 skipping to change at page 44, line 35
This field carries the details of the error condition. This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
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.12 User Initiated Abort (11) 3.3.10.12 User Initiated Abort (12)
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 are send
because of an upper layer request. The upper layer can specify because of an upper layer request. The upper layer can specify
an Upper Layer Abort Reason which is transported by SCTP an Upper Layer Abort Reason which is transported by SCTP
transparently and MAY be delivered to the upper layer protocol transparently and MAY be delivered to the upper layer protocol
at the peer. at the peer.
skipping to change at page 49, line 37 skipping to change at page 49, line 37
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.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
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 SHOULD 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 an ABORT for helping debugging. 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 51, line 5 skipping to change at page 50, line 37
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 1 indicating that
no TCB was destroyed. Otherwise, no 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.1 Description of the problem
RFC 2960 does not describe the fact that the SSN have to initialized
to 0 in he way it is required by RFC2119.
2.24.2 Text changes to the document
---------
Old text: (Section 6.5)
---------
The stream sequence number in all the streams shall start from 0 when
the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall
be set to 0.
---------
New text: (Section 6.5)
---------
The stream sequence number in all the streams MUST start from 0 when
the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall
be set to 0.
2.24.3 Solution description
The 'shall' in the text is replaced by a 'MUST' to clearly state the
required behavior.
2.25 SACK packet format
2.25.1 Description of the problem
It is not clear in RFC 2960 whether a SACK must contain the fields
Number of Gap Ack Blocks and Number of Duplicate TSNs or not.
2.25.2 Text changes to the document
---------
Old text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver
Window Credit (a_rwnd) parameters.
---------
New text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver
Window Credit (a_rwnd), Number of Gap Ack Blocks, and
Number of Duplicate TSNs fields.
2.25.3 Solution description
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
TSNs.
2.26 Protocol Violation Error Cause
2.26.1 Description of the problem
There are many situations a SCTP endpoints detects that the peer
violates the protocol. Therefore the association has to be aborted.
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
Some of the changes given here already include changes suggested in
section Section 2.6 and Section 2.21 of this document.
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Section 3.2.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an association with new addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note no old text, new error added in section 3.3.10)
---------
3.3.10.13 Protocol Violation (13)
Cause of error
--------------
This error cause MAY be included in ABORT chunks which are send
because a SCTP endpoint detects a protocol violation of the peer
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
specifying what kind of protocol violation has been detected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\\ \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26.3 Solution description
An additional error cause which can be used by an endpoint to
indicate a protocol violation of the peer has been defined.
2.27 Reporting of Unrecognized Parameters
2.27.1 Description of the problem
It is not stated clearly in RFC2960 [3] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could
be reported in the INIT-ACK chunk or in a separate ERROR chunk which
can get lost. Unrecognized parameters in an INIT-ACK chunk have to
be reported in an ERROR-chunk. This can be bundled with the COOKIE-
ERROR chunk or sent separately. If it is sent separately and
received before the COOKIE-ECHO it will be handled as an OOTB packet
resulting in sending out an ABORT chunk. Therefore the association
would not be established.
2.27.2 Text changes to the document
Some of the changes given here already include changes suggested in
section Section 2.2 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 SCTP chunk and discard it, do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, 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.
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.
2.27.3 Solution description
The procedure of reporting unrecognized parameters has been described
clearly.
2.28 Handling of IP Address Parameters
2.28.1 Description of the problem
It is not stated clearly in RFC2960 [3] how a SCTP endpoint which
supports either IPv4 addresses or IPv6 addresses should respond if
IPv4 and IPv6 addresses are presented by the peer in the INIT or
INIT-ACK chunk.
2.28.2 Text changes to the document
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type, it
can abort the initiation process and then attempt a re-initiation by
using a 'Supported Address Types' parameter in the new INIT to
indicate what types of address it prefers.
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type, it
can abort the initiation process and then attempt a re-initiation by
using a 'Supported Address Types' parameter in the new INIT to
indicate what types of address it prefers.
IMPLEMENTATION NOTE: If a SCTP endpoint only supporting either IPv4
or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk
from its peer it MUST use all of the addresses belonging to the
supported address family. The other addresses MAY be ignored. The
endpoint SHOULD NOT respond with any kind of error indication.
2.28.3 Solution description
The procedure of handling IP address parameters has been described
clearly.
2.29 Handling of COOKIE ECHO chunks when a TCB exists
2.29.1 Description of the problem
The description of be behavior in RFC2960 [3] when a COOKIE ECHO
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
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
the endpoint has already left again the ESTABLISHED state then it
should not go back to established. In case D the endpoint can only
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
about the peer's tag which is requested to match in this case.
2.29.2 Text changes to the document
---------
Old text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should always
enter the ESTABLISHED state, if it has not already done so. It
should stop any init or cookie timers that may be running and send
a COOKIE ACK.
---------
New text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state.
It should stop any cookie timer that may be running and send
a COOKIE ACK.
2.29.3 Solution description
The procedure of handling of COOKIE-ECHO chunks when a TCB exists 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:
A special thanks to Mark Allman, who should actually be a co-author Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
for his work on the max-burst, but managed to wiggle out due to a
technicality.
For their comments on the list, Atsushi Fukumoto, David Lehmann.
For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon
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, Michael Tuexen, Andreas Jungmaier, Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred
Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon,
Kacheong Poon, Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep
Bhondwe, Sandeep Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep
IRIE, Sandeep Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll,
Monte Yarroll, Gareth Keily, Ian Periam, Nathalie Mouellic, and Stan Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David
McClellan. Lehmann, Rob Brennan, Thomas Curran, and Stan McClellan.
For their comments on the list and his detailed analysis and A special thanks to Mark Allman, who should actually be a co-author
simulations of SCTP, Rob Brennan and Thomas Curran. for his work on the max-burst, but managed to wiggle out due to a
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] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
skipping to change at page 53, line 41 skipping to change at page 61, line 41
Phone: Phone:
EMail: acaro@cis.udel.edu EMail: acaro@cis.udel.edu
Michael Tuexen Michael Tuexen
Siemens AG Siemens AG
ICN WN CC SE 7 ICN WN CC SE 7
D-81359 Munich D-81359 Munich
Germany Germany
Phone: Phone:
EMail: Michael.Tuexen@icn.siemens.de EMail: Michael.Tuexen@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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