SCTP

STATEMENT OF COMPLIANCE

1	General
1.1	Introduction
1.2	Terms
1.3	Concept
2	Compliance Lists
2.1	IETF - Stream Control Transmission Protocol
3	Notes
Reference List

1 General

1.1 Introduction

This document describes to what extent the Ericsson SCTP signaling component conforms with the IETF RFC 1191 (see Reference [1]), RFC 1981 (see Reference [2]), RFC 4820 (see Reference [3]) and RFC 4821 (see Reference [4]).

1.2 Terms

IP		Internet Protocol

MTU		Maximum Transmission Unit

PAD		SCTP padding chunk

PLPMTUD		Packetization Layer Path MTU Discovery

PMTU		Path MTU

PMTUD		Path MTU Discovery

RTO		Retransmission Time-Out

RFC		Request For Comments

SCTP		Stream Control Transmission Protocol

1.3 Concept

The terms that are used are:

C		The Ericsson signaling component complies with the specified section in RFC 1191 (see Reference [1]), RFC 1981 (see Reference [2]), RFC 4820 (see Reference [3]) or RFC 4821 (see Reference [4]).

N		The Ericsson signaling component does not comply with the specified section in RFC 1191 (see Reference [1]), RFC 1981 (see Reference [2]), RFC 4820 (see Reference [3]) or RFC 4821 (see Reference [4]).

P		The Ericsson signaling component complies partly with the specified section in RFC 1191 (see Reference [1]), RFC 1981 (see Reference [2]), RFC 4820 (see Reference [3]) or RFC 4821 (see Reference [4]).

-		There is nothing to implement in the referred section (always placed in column C).

2 Compliance Lists

2.1 IETF - Stream Control Transmission Protocol

2.1.1 RFC 1191

Table 1 RFC 1191
Reference		C	N	P	Comments
1	Introduction	-
2	Protocol overview	X
3	Host specification			X	Note 1 Note 2
3.1	TCP MSS Option		X		Note 3
4	Router specification	-
5	Host processing of old-style message			X	Note 4
6	Host implementation	-
6.1	Layering	X
6.2	Storing PMTU information	X
6.3	Purging stale PMTU information			X	Note 5
6.4	TCP layer actions			X	Note 6 Note 7 Note 8
6.5	Issues for other transport protocols	-
6.6	Management interface	X
7	Likely values for Path MTU's	-
7.1	A better way to detect PMTU increases			X	Note 2 Note 19
8	Security considerations	X			Note 4 Note 6
References		-

2.1.2 RFC 1981

Table 2 RFC 1981
Reference		C	P	Comments
1	Introduction	X
2	Terminology	-
3	Protocol overview	-
4	Protocol Requirements	X
5	Implementation Issues	-
5.1	Layering	X
5.2	Storing PMTU information		X	Note 21 Note 9
5.3	Purging stale PMTU information	X
5.4	TCP layer actions		X	Note 7 Note 9
5.5	Issues for other transport protocols	-
5.6	Management interface		X	Note 10
6	Security Considerations	X
Acknowledgements		-
Appendix A - Comparison to RFC 1191		X
References		-

2.1.3 RFC 4820

Table 3 RFC 4820
Reference		C	P	Comments
1	Introduction	-
2	Conventions	-
3	Padding Chunk (PAD)	X
4	Padding Parameter (PAD)		X	Note 11
5	IANA Considerations	-
5.1	A New Chunk Type	-
5.2	A New Parameter Type	-
6	Security Considerations	-
7	Acknowledgements	-
8	References	-
8.1	Normative References	-
8.2	Informative References	-

2.1.4 RFC 4821

Table 4 RFC 4821
Reference		C	N	P	Comments
1	Introduction	-
2	Overview	-			Note 12
3	Terminology	-
4	Requirements	X
5	Layering	-
5.1	Accounting for Header Sizes	X
5.2	Storing PMTU Information	X
5.3	Accounting for IPsec	-			Note 20
5.4	Multicast	X
6	Common Packetization Properties	-
6.1	Mechanism to Detect Loss	X
6.2	Generating Probes	X			Note 13
7	The Probing Method	-
7.1	Packet Size Ranges	X			Note 14
7.2	Selecting Initial Values	X			Note 14
7.3	Selecting Probe Size			X	Note 15 Note 16
7.4	Probing Preconditions	X
7.5	Conducting a Probe	X
7.6	Response to Probe Results	X
7.6.1	Probe Success			X	Note 17
7.6.2	Probe Failure	X			Note 18
7.6.3	Probe Timeout Failure			X	Note 18
7.6.4	Probe Inconclusive	X
7.7	Full-Stop Timeout	X
7.8	MTU Verification		X		Note 17
8	Host Fragmentation	X
9	Application Probing	X
10	Specific Packetization Layers	X
10.1	Probing Method Using TCP	-
10.2	Probing Method Using SCTP	X			Note 13
10.3	Probing Method for IP Fragmentation	-
10.4	Probing Method Using Applications	X
11	Security Considerations	X			Note 12
12	References	-
12.1	Normative References	-
12.2	Informative References	-
Appendix A. Acknowledgements		-

3 Notes

Note 1		When SCTP received a Datagram Too Big message to Probe packet, SCTP doesn't reduce the PMTU for the relevant path.

Note 2		SCTP tries to detect PMTU increase at least afterPMTUD interval (see Reference [5]) after a Datagram Too Big message has been received and at least after Wait Next Probe interval (see Reference [5]) after the previous successful attempted increase.

Note 3		SCTP can send IP datagram larger than 576 octets.

Note 4

If SCTP receives a Datagram Too Big message without Next-Hop MTU field to Data packet and the current PMTU is greater than Initial PMTU (see Reference [5]), it will reduce PMTU to Initial PMTU.

If SCTP receives a Datagram Too Big message without Next-Hop MTU field to Data packet and the current PMTU is less than Initial PMTU, it will reduce PMTU to Minimum PMTU (see Reference [5]).

Due to SCTP uses PLPMTUD method (see Reference [6]) to discovery PMTU also, Datagram Too Big message can be received on a probe packet (see Reference [6]).

Note 5		SCTP uses PLPMTUD method (see Reference [6]) to discovery stale PMTU.

Note 6		SCTP uses PLPMTUD method (see Reference [6]) also to track PMTU changes.

Note 7		SCTP Data packet doesn't include Maximum Segment Size. So the protocol doesn't store it.

Note 8		Retransmission in SCTP doesn't depend on a received Datagram Too Big message and it is handled according to Reference [7]

Note 9		Retransmission in SCTP doesn't depend on a received Packet Too Big message and it is handled according to Reference [7].

Note 10		SCTP enables IP_DONTFRAG socket option (see Reference [6]) to prohibit IP layer to send packets larger than the IPv6 minimum link MTU.

Note 11		SCTP silently discards PAD parameter in INIT chunks.

Note 12		PMTUD is a combination of PLPMTUD method and handling of ICMP packets. PLPMTUD provides more robust and quick discovery and thus has advantages compared to classical PMTUD. However it is still reasonable to also react on incoming ”fragmentation needed” ICMP (see Reference [7] ) and set DF-bit (see Reference [7] ) as in classical PMTUD.

Note 13		SCTP probe packet contains bundled HEARTBEAT chunk and PAD chunks (see Reference [6]).

Note 14		Initial values of search_low, search_high and eff_pmtu are configured by using configuration parameters Minimum IPv4 PMTU, Maximum IPv4 PMTU and PMTU.

Note 15		SCTP sends the first probe packet with eff_pmtu plus the value of PMTUDAccuracy configuration parameter (see Reference [5]). The size of the following probes is chosen based on the binary search algorithm between search_low and search_high.

Note 16		SCTP tries to detect PMTU change at least afterPMTUD interval (see Reference [5]) after the previous probing has converged.

Note 17		SCTP doesn't support MTU verification due to overwhelming complexity of the solution accompanied with major costs increase. Simple handling of such situations is implicitly presented, because increase of loss rate would result in path failure; when it happens, PMTU will be reset to the minimum value and PMTU Discovery will be restarted.

Note 18		SCTP uses 5*RTO interval (see Reference [6]) after the probe timeout failure until the next probe will be sent.

Note 19		“The table of common MTUs” is not used in SCTP.

Note 20		The PLPMTUD implementation in SCTP doesn't take into IP Security.

Note 21		The combination of local IP address and remote IP address is used as a representation of a path.

Reference List

IETF
[1] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191. November 1990.
[2] J. Mogul, J. McCann, S. Deering, "Path MTU Discovery for IP version 6", RFC 1981. August 1996.
[3] M. Tuexen, R. Steward, P. Lei, "Pudding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820. March 2007.
[4] M. Mathis, J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821. March 2007.
[5] Configuration File Description for SCTP IETF 19073-CAA 901 548 Uen
[6] Functional Specification for SCTP IETF 155 17-CAA 901 548 Uen
[7] R. Stewart, "Stream Control Transmission Protocol", RFC 4960. Standards Track. September 2007.

Copyright	© Ericsson AB 2010-2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer	The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.