draft-ietf-rohc-sctp-requirements-00.txt   draft-ietf-rohc-sctp-requirements-01.txt 
RoHC Working Group Ch. Schmidt Network Working Group Ch. Schmidt
INTERNET DRAFT M. Tuexen Internet-Draft M. Tuexen
Siemens Expires: February 18, 2003 Siemens AG
Expires August 20, 2002 February 20, 2002 August 20, 2002
Requirements for RoHC IP/SCTP Robust Header Compression (01) Requirements for RoHC IP/SCTP Robust Header Compression
<draft-ietf-rohc-sctp-requirements-00.txt> draft-ietf-rohc-sctp-requirements-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of [RFC2026]. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
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 The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be acessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract This Internet-Draft will expire on February 18, 2003.
This document contains requirements for the IP/SCTP header compression Copyright Notice
scheme (profile) to be developed by the ROHC WG. The structure of this
document is inherited from the document defining IP/TCP requirements for
ROHC.
1. Document history Copyright (C) The Internet Society (2002). All Rights Reserved.
September 14, 2001 - draft-schmidt-rohc-sctp-requirements-00.txt. Abstract
Initial version of this document to initiate discussion on This document contains requirements for the IP/SCTP header
requirements for SCTP compression in ROHC. compression scheme (profile) to be developed by the ROHC WG. The
structure of this document is inherited from the document defining
IP/TCP requirements for ROHC.
February 20, 2002 - draft-ietf-rohc-sctp-requirements-00.txt. Table of Contents
Enhanced version with modifications, resulting from the 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
52.IETF meeting in Salt Lake City 2. Header compression requirements . . . . . . . . . . . . . . . 4
2.1 Impact on Internet infrastructure . . . . . . . . . . . . . . 4
2.2 Supported headers . . . . . . . . . . . . . . . . . . . . . . 4
2.3 SCTP specific requirements . . . . . . . . . . . . . . . . . . 5
2.4 Performance issues . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Capability requirements related to link layer
characteristics . . . . . . . . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
2. Introduction 1. Introduction
The goal of the ROHC WG is to develop header compression schemes that The goal of the ROHC WG is to develop header compression schemes that
perform well over links with high error rates and long link round trip perform well over links with high error rates and long link round
times. The schemes must perform well for cellular links, using trip times. The schemes must perform well for cellular links, using
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes technologies such as WCDMA, EDGE, and CDMA-2000. However, the
should also be applicable to other future link technologies with high schemes should also be applicable to other future link technologies
loss and long round trip times. with high loss and long round trip times.
The main objective for ROHC has been robust compression of IP/UDP/RTP. The main objective for ROHC has been robust compression of IP/UDP/
Next step was IP/TCP compression. RTP. Next step was IP/TCP compression.
SCTP is the new reliable transport protocol from the IETF. It offers a SCTP is the new reliable transport protocol from the IETF. It offers
number of features not available in other reliable transport protocols a number of features not available in other reliable transport
such as TCP, including multi-streaming, multi-homing and resistance to protocols such as TCP, including multi-streaming, multi-homing and
flooding and masquerade attacks. SCTP is designed to transport PSTN resistance to flooding and masquerade attacks. SCTP is designed to
signaling messages over IP networks but its rich feature set makes it transport PSTN signaling messages over IP networks but its rich
capable of many broader applications. Main known application today is feature set makes it capable of many broader applications. Main
the transport of SIP signaling messages. known application today is the transport of SIP signaling messages.
One of the most important innovations of SCTP is the multi-streaming One of the most important innovations of SCTP is the multi-streaming
function. This feature allows data to be partitioned into multiple function. This feature allows data to be partitioned into multiple
streams where each stream is delivered independently, so in-sequence streams where each stream is delivered independently, so in-sequence
delivery can be guaranteed for data sent within a single stream. The delivery can be guaranteed for data sent within a single stream. The
advantage of this technique is that when a packet is lost, only certain advantage of this technique is that when a packet is lost, only
streams are affected. certain streams are affected.
>From the header compression point of view the multi-streaming function From the header compression point of view the multi-streaming
raises a number of new issues to solve. Most importantly a SCTP packet function raises a number of new issues to solve. Most importantly a
consists of a common header followed by a sequence of chunks. User SCTP packet consists of a common header followed by a sequence of
payload is transported in DATA chunks which contain stream specific chunks. User payload is transported in DATA chunks which contain
information. All other chunks do not contain stream specific stream specific information. All other chunks do not contain stream
information. To obtain maximum compression efficiency it is important to specific information. To obtain maximum compression efficiency it is
maintain a separate context for the stream-specific fields from each important to maintain a separate context for the stream-specific
stream, but to use a shared context for all general fields. fields from each stream, but to use a shared context for all general
fields.
The remaining requirements will be similar to IP / TCP compression. The remaining requirements will be similar to IP / TCP compression
[5].
3. Header compression requirements 2. Header compression requirements
The following requirements have, more or less arbitrarily, been divided The following requirements have, more or less arbitrarily, been
into five groups. The first group deals with requirements concerning the divided into five groups.
impact of a header compression scheme on the rest of the Internet
infrastructure. The second group defines what kind of headers that must The first group deals with requirements concerning the impact of a
be compressed efficiently. The third group defines SCTP specific header compression scheme on the rest of the Internet infrastructure.
requirements, while the forth and fifth groups concern performance The second group defines what kind of headers that must be compressed
requirements and capability requirements from the properties of the efficiently. The third group defines SCTP specific requirements,
anticipated link technologies. while the forth and fifth groups concern performance requirements and
capability requirements from the properties of the anticipated link
technologies.
3.1. Impact on Internet infrastructure 2.1 Impact on Internet infrastructure
(1) Transparency: When a header is compressed and then decompressed, the Transparency:
resulting header must be semantically identical to the original
header. If this cannot be achieved, the packet containing the When a header is compressed and then decompressed, the resulting
erroneous header must be discarded. header must be semantically identical to the original header. If
this cannot be achieved, the packet containing the erroneous
header must be discarded.
Justification: The header compression process must not produce Justification: The header compression process must not produce
headers that might cause problems for any current or future part of headers that might cause problems for any current or future part
the Internet infrastructure. of the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically Note: The ROHC WG has not found a case where "semantically
identical" is not the same as "bitwise identical". identical" is not the same as "bitwise identical".
(2) Ubiquity: Must not require modifications to existing IP (v4 or v6) Ubiquity:
or SCTP implementations.
Must not require modifications to existing IP (v4 or v6) or SCTP
implementations.
Justification: Ease of deployment. Justification: Ease of deployment.
3.2. Supported headers 2.2 Supported headers
(1) IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all IPv4 and IPv6:
possible changes in the IP header fields must be handled by the
compression scheme and commonly changing fields should be Must support both IPv4 and IPv6. This means that all possible
compressed efficiently. changes in the IP header fields must be handled by the compression
scheme and commonly changing fields should be compressed
efficiently.
Justification: IPv4 and IPv6 will both be around during the Justification: IPv4 and IPv6 will both be around during the
foreseeable future. foreseeable future.
(2) Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be Mobile IP:
supported and should be compressed efficiently. For IPv4 these
include headers of tunneled packets. For IPv6 these include headers The kinds of headers used by Mobile IP{v4,v6} must be supported
and should be compressed efficiently. For IPv4 these include
headers of tunneled packets. For IPv6 these include headers
containing the Routing Header, the Binding Update Destination containing the Routing Header, the Binding Update Destination
Option, and the Home Address option. Option, and the Home Address option.
Justification: It is very likely that Mobile IP will be used by Justification: It is very likely that Mobile IP will be used by
cellular devices. cellular devices.
(3) IPSEC: The scheme should be able to compress headers containing IPSEC:
IPSEC sub-headers.
The scheme should be able to compress headers containing IPSEC
sub-headers.
Justification: IPSEC is expected to be used to provide necessary Justification: IPSEC is expected to be used to provide necessary
end-to-end security. end-to-end security.
Note: It is of course not possible to compress the encrypted part Note: It is of course not possible to compress the encrypted part
of an ESP header, nor the cryptographic data in an AH header. of an ESP header, nor the cryptographic data in an AH header.
3.3. SCTP specific requirements 2.3 SCTP specific requirements
(1) Generality: Must support efficient compression of the SCTP Generality:
information in a SCTP packet. This means that the scheme must be
able to work with the protocol structure of the SCTP protocol (SCTP Must support efficient compression of the SCTP information in a
common header, chunk-1 header, chunk-1 body, chunk-2 header, SCTP packet. This means that the scheme must be able to work with
chunk-2 body...) in a proper way. the protocol structure of the SCTP protocol (SCTP common header,
chunk-1 header, chunk-1 body, chunk-2 header, chunk-2 body...) in
a proper way.
Justification: There must be a generic scheme which reflects the Justification: There must be a generic scheme which reflects the
structure of SCTP packets. structure of SCTP packets.
(2) Multi-streaming function of SCTP has to be kept in most of the Streams:
Multi-streaming function of SCTP has to be kept in most of the
cases. cases.
Justification: The independent transport of multiple streams is a Justification: The independent transport of multiple streams is a
big advantage of SCTP. This feature may be limited by the usage of big advantage of SCTP. In case of a packet loss at the compressed
robust header compression. Consider, for example, the following link, two cases have to be differentiated:
sequence of packets (SID - Stream Identifier, SSN - Stream Sequence
Number):
Packet 1: COMMON HEADER, DATA(SID=0; SSN=0), DATA(SID=1; SSN=0) Case 1: The verification of the decompression via CRC compression
Packet 2: COMMON HEADER, DATA(SID=0; SSN=1) checksum went well. In this case, uncompressed SCTP packets
Packet 3: COMMON HEADER, DATA(SID=0; SSN=2), DATA(SID=1; SSN=1) will be forwarded and the SCTP endpoints will take care about
multi-streaming functionality.
Assuming that packet 2 is lost and the decompressor recognizes a Case 2: The verification of the decompression via CRC compression
fault in decompressing packet 3, packet 3 would be discarded. Data checksum fails. In this case, the release of the related SCTP
from both stream 0 and stream 1 are affected. Without header packet could influence unrelated streams as well. The only way
compression, the loss of packet 2 would influence only data in to avoid this would be the generation of a new SCTP packet by
stream 0. the decompressor (without the data chunks from the involved
stream) - in violation to the transparency transport
requirement.
Assuming that packet 2 is lost and a decompression fault of packet The compression stream must support the multiple streams feature
3 can be restricted to the first data chunk of packet 3 (stream 0), in a way that head of line blocking is introduced by RoHC only in
the decompressor could generate a new SCTP packet containing only very rare cases. Context update should be restricted to a
the second data chunk of packet 3 (stream 1) - this would violate minimum.
the transparency requirement. This should not be done.
The compression scheme must support the multiple streams feature in Extensions:
a way that head of line blocking is introduced by RoHC only in very
rare cases. Context update should be restricted to a minimum.
(3) SCTP extensions as described in [ADDIP] should be compressed SCTP extensions as described in ADDIP [2] and PRSCTP [3] should be
efficiently. compressed efficiently.
Justification: SCTP extensions will be a normal part of the Justification: SCTP extensions will be a normal part of the
protocol. To reach good efficiency for SCTP, these extension have protocol. To reach good efficiency for SCTP, these extension have
to be handled in an appropriate way. to be handled in an appropriate way.
(4) Generic extendibility describes the handling of yet not defined Extendibility:
Generic extendibility describes the handling of yet not defined
chunks, the compression scheme must be able to handle this chunks. chunks, the compression scheme must be able to handle this chunks.
Justification: The compression scheme must support full SCTP Justification: The compression scheme must support full SCTP
functionality. functionality.
3.4. Performance issues 2.4 Performance issues
(1) Performance/Spectral Efficiency: Must provide low relative overhead Performance/Spectral Efficiency:
under expected operating conditions.
Must provide low relative overhead under expected operating
conditions.
Justification: Spectrum efficiency is the primary goal here. Justification: Spectrum efficiency is the primary goal here.
(2) Error propagation: For SCTP traffic, link layer retransmissions Error propagation:
should be applied to make use of the bandwidth in the most
efficient way. Lost or damaged headers should thus not occur and For SCTP traffic, link layer retransmissions should be applied to
therefore it is not a primary goal to have mechanisms for error make use of the bandwidth in the most efficient way. Lost or
propagation avoidance in case of such events. damaged headers should thus not occur and therefore it is not a
primary goal to have mechanisms for error propagation avoidance in
case of such events.
Justification: To provide robustness against loss or damage Justification: To provide robustness against loss or damage
introduced by the link, efficiency must be sacrificed. Since loss introduced by the link, efficiency must be sacrificed. Since loss
or damage is not expected for SCTP traffic, efficiency should or damage is not expected for SCTP traffic, efficiency should
instead be prioritized. This does not mean that some robustness instead be prioritized. This does not mean that some robustness
should not be provided, if efficiency can still be optimized. should not be provided, if efficiency can still be optimized.
Note: In general, error propagation due to header compression Note: In general, error propagation due to header compression
should be kept at an absolute minimum. Error propagation is defined should be kept at an absolute minimum. Error propagation is
as the loss or damage of headers subsequent to headers lost or defined as the loss or damage of headers subsequent to headers
damaged by the link, even if those subsequent headers are not lost lost or damaged by the link, even if those subsequent headers are
or damaged. not lost or damaged.
Note: There are at least two kinds of error propagation; loss Note: There are at least two kinds of error propagation; loss
propagation, where a lost header causes subsequent headers to be propagation, where a lost header causes subsequent headers to be
lost or damaged, and damage propagation, where a damaged header lost or damaged, and damage propagation, where a damaged header
causes subsequent headers to be lost or damaged. causes subsequent headers to be lost or damaged.
(3a) Moderate Packet Reordering: The scheme should efficiently handle Moderate Packet Reordering:
moderate reordering (2-3 packets) in the packet stream reaching the
compressor. The scheme should efficiently handle moderate reordering (2-3
packets) in the packet stream reaching the compressor.
Justification: This kind of reordering is common. Justification: This kind of reordering is common.
(3b) Packet Reordering: The scheme should be able to compress when there Packet Reordering:
are reordered packets in the packet stream reaching the compressor.
The scheme should be able to compress when there are reordered
packets in the packet stream reaching the compressor.
Justification: Reordering happens regularly in the Internet. Justification: Reordering happens regularly in the Internet.
However, since the Internet is engineered to run SCTP reasonably However, since the Internet is engineered to run SCTP reasonably
well, excessive reordering will not be common and need not be well, excessive reordering will not be common and need not be
handled with optimum efficiency. handled with optimum efficiency.
(4) Processing delay: The scheme must not contribute significantly to Processing delay:
system delay budget.
3.5. Capability requirements related to link layer characteristics The scheme must not contribute significantly to system delay
budget.
(1) Unidirectional links: Must be possible to implement (possibly with 2.5 Capability requirements related to link layer characteristics
less efficiency) without explicit feedback messages from
decompressor to compressor. Unidirectional links:
Must be possible to implement (possibly with less efficiency)
without explicit feedback messages from decompressor to
compressor.
Justification: There are links that do not provide a feedback Justification: There are links that do not provide a feedback
channel or feedback is not desirable for other reasons. channel or feedback is not desirable for other reasons.
(2) Link delay: Must operate under all expected link delay conditions. Link delay:
(3) Header compression coexistence: The scheme must fit into the ROHC Must operate under all expected link delay conditions.
framework together with other ROHC profiles
4. IANA Considerations Header compression coexistence:
A protocol which meets these requirements, e.g., [ROHC], will require The scheme must fit into the ROHC framework together with other
the IANA to assign various numbers. This document by itself, however, ROHC profiles.
does not require any IANA involvement.
5. Security Considerations 3. IANA Considerations
A protocol specified to meet these requirements, e.g., [ROHC], must be A protocol which meets these requirements will require the IANA to
able to compress packets containing IPSEC headers according to the IPSEC assign various numbers. This document by itself, however, does not
requirement, 2.2.4. The efficiency of the compression may be influenced require any IANA involvement.
by encrypted protocol header elements. This document by itself, however, 4. Security Considerations
does not add any security risks.
6. References A protocol specified to meet these requirements must be able to
compress packets containing IPSEC headers according to the IPSEC
requirement, 2.2.4. The efficiency of the compression may be
influenced by encrypted protocol header elements. This document by
itself, however, does not add any security risks.
[RFC-2960] R. R. Stewart et al.,"Stream Control Transmission Protocol", References
November 2000.
[ADDIP] R. R. Stewart et al., "Dynamic Reconfiguration of IP [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
Addresses", draft-ietf-tsvwg-addip-sctp-03.txt, November H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
2001. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC-1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed [2] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Serial Links", RFC 1144, February 1990. Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-
05 (work in progress), May 2002.
[RFC-2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header [3] Ramalho, M. and R. Stewart, "SCTP Partial Reliability
Compression", RFC 2507, February 1999. Extension", draft-stewart-tsvwg-prsctp-01 (work in progress),
July 2002.
[RFC-3096] Mikael Degermark, "Requirements for IP/UDP/RTP header [4] Degermark, M., "Requirements for robust IP/UDP/RTP header
compression", RFC 3096, July 2001. compression", RFC 3096, July 2001.
[TCPREQ] Lars-Erik Jonsson, "Requirements for ROHC IP/TCP [5] Jonsson, L., "Requirements for ROHC IP/TCP Header Compression",
Compression", draft-ietf-rohc-tcp-requirements-02.txt, draft-ietf-rohc-tcp-requirements-04 (work in progress), May
November 2001. 2002.
7. Authors' Addresses Authors' Addresses
Christian Schmidt Tel.: +49 89 722 27822 Christian Schmidt
Siemens AG e-mail: Christian.Schmidt@icn.siemens.de Siemens AG
Hofmannstrasse 51 Hofmannstr. 51
D-81359 Munich 81359 Munich
Germany Germany
Michael Tuexen Tel.: +49 89 722 47210 Phone: +49 89 722 27822
Siemens AG e-mail: Michael.Tuexen@icn.siemens.de EMail: Christian.Schmidt@icn.siemens.de
Hofmannstrasse 51
D-81359 Munich Michael Tuexen
Siemens AG
Hofmannstr. 51
81359 Munich
Germany Germany
This Internet Draft expires August 20, 2002.
Phone: +49 89 722 47210
EMail: michael.tuexen@siemens.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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