[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-schmidt-rohc-sctp-requirements) 00 01 02 03

RoHC Working Group                                           Ch. Schmidt
INTERNET DRAFT                                                 M. Tuexen
                                                                 Siemens
Expires August 20, 2002                                February 20, 2002


      Requirements for RoHC IP/SCTP Robust Header Compression (01)
               <draft-ietf-rohc-sctp-requirements-00.txt>



Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026].

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be acessed at
http://www.ietf.org/shadow.html.

Abstract

This document contains requirements for the IP/SCTP header 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.

1.  Document history

September 14, 2001 - draft-schmidt-rohc-sctp-requirements-00.txt.

          Initial version of this document to initiate discussion on
          requirements for SCTP compression in ROHC.

February 20, 2002 - draft-ietf-rohc-sctp-requirements-00.txt.





Schmidt, Tuexen                                                 [Page 1]


Internet Draft           SCTP Header Compression             August 2002


          Enhanced version with modifications, resulting from the
          52.IETF meeting in Salt Lake City

2.  Introduction

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
times. The schemes must perform well for cellular links, using
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
should also be applicable to other future link technologies with high
loss and long round trip times.

The main objective for ROHC has been robust compression of IP/UDP/RTP.
Next step was IP/TCP compression.

SCTP is the new reliable transport protocol from the IETF. It offers a
number of features not available in other reliable transport protocols
such as TCP, including multi-streaming, multi-homing and resistance to
flooding and masquerade attacks.  SCTP is designed to transport PSTN
signaling messages over IP networks but its rich feature set makes it
capable of many broader applications. Main known application today is
the transport of SIP signaling messages.

One of the most important innovations of SCTP is the multi-streaming
function. This feature allows data to be partitioned into multiple
streams where each stream is delivered independently, so in-sequence
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
streams are affected.

>From the header compression point of view the multi-streaming function
raises a number of new issues to solve. Most importantly a SCTP packet
consists of a common header followed by a sequence of chunks. User
payload is transported in DATA chunks which contain stream specific
information. All other chunks do not contain stream specific
information. To obtain maximum compression efficiency it is important to
maintain a separate context for the stream-specific fields from each
stream, but to use a shared context for all general fields.

The remaining requirements will be similar to IP / TCP compression.



3.  Header compression requirements

The following requirements have, more or less arbitrarily, been divided
into five groups. The first group deals with requirements concerning the
impact of a header compression scheme on the rest of the Internet



Schmidt, Tuexen                                                 [Page 2]


Internet Draft           SCTP Header Compression             August 2002


infrastructure. The second group defines what kind of headers that must
be compressed efficiently. The third group defines SCTP specific
requirements,  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

(1) Transparency: When a header is compressed and then decompressed, the
    resulting 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
    headers that might cause problems for any current or future part of
    the Internet infrastructure.

    Note: The ROHC WG has not found a case where "semantically
    identical" is not the same as "bitwise identical".

(2) Ubiquity: Must not require modifications to existing IP (v4 or v6)
    or SCTP implementations.

    Justification: Ease of deployment.



3.2.  Supported headers

(1)  IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all
     possible 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
     foreseeable future.

(2)  Mobile IP: 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
     Option, and the Home Address option.

     Justification: It is very likely that Mobile IP will be used by
     cellular devices.




Schmidt, Tuexen                                                 [Page 3]


Internet Draft           SCTP Header Compression             August 2002


(3)  IPSEC: The scheme should be able to compress headers containing
     IPSEC sub-headers.

     Justification: IPSEC is expected to be used to provide necessary
     end-to-end security.

     Note: It is of course not possible to compress the encrypted part
     of an ESP header, nor the cryptographic data in an AH header.



3.3.  SCTP specific requirements

(1)  Generality: Must support efficient compression of the SCTP
     information in a SCTP packet. This means that the scheme must be
     able to work with 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
     structure of SCTP packets.

(2)  Multi-streaming function of SCTP has to be kept in most of the
     cases.

     Justification: The independent transport of multiple streams is a
     big advantage of SCTP. This feature may be limited by the usage of
     robust header compression. Consider, for example, the following
     sequence of packets (SID - Stream Identifier, SSN - Stream Sequence
     Number):

     Packet 1: COMMON HEADER, DATA(SID=0; SSN=0), DATA(SID=1; SSN=0)
     Packet 2: COMMON HEADER, DATA(SID=0; SSN=1)
     Packet 3: COMMON HEADER, DATA(SID=0; SSN=2), DATA(SID=1; SSN=1)

     Assuming that packet 2 is lost and the decompressor recognizes a
     fault in decompressing packet 3, packet 3 would be discarded. Data
     from both stream 0 and stream 1 are affected. Without header
     compression, the loss of packet 2 would influence only data in
     stream 0.

     Assuming that packet 2 is lost and a decompression fault of packet
     3 can be restricted to the first data chunk of packet 3 (stream 0),
     the decompressor could generate a new SCTP packet containing only
     the second data chunk of packet 3 (stream 1) - this would violate
     the transparency requirement. This should not be done.





Schmidt, Tuexen                                                 [Page 4]


Internet Draft           SCTP Header Compression             August 2002


     The compression scheme must support the multiple streams feature in
     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
     efficiently.

     Justification: SCTP extensions will be a normal part of the
     protocol. To reach good efficiency for SCTP, these extension have
     to be handled in an appropriate way.

(4)  Generic extendibility describes the handling of yet not defined
     chunks, the compression scheme must be able to handle this chunks.

     Justification: The compression scheme must support full SCTP
     functionality.



3.4.  Performance issues

(1)  Performance/Spectral Efficiency: Must provide low relative overhead
     under expected operating conditions.

     Justification: Spectrum efficiency is the primary goal here.

(2)  Error propagation: For SCTP traffic, link layer retransmissions
     should be applied to make use of the bandwidth in the most
     efficient way.  Lost or 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
     introduced by the link, efficiency must be sacrificed. Since loss
     or damage is not expected for SCTP traffic, efficiency should
     instead be prioritized. This does not mean that some robustness
     should not be provided, if efficiency can still be optimized.

     Note: In general, error propagation due to header compression
     should be kept at an absolute minimum. Error propagation is defined
     as the loss or damage of headers subsequent to headers lost or
     damaged by the link, even if those subsequent headers are not lost
     or damaged.

     Note: There are at least two kinds of error propagation; loss
     propagation, where a lost header causes subsequent headers to be
     lost or damaged, and damage propagation, where a damaged header
     causes subsequent headers to be lost or damaged.



Schmidt, Tuexen                                                 [Page 5]


Internet Draft           SCTP Header Compression             August 2002


(3a) Moderate Packet Reordering: The scheme should efficiently handle
     moderate reordering (2-3 packets) in the packet stream reaching the
     compressor.

     Justification: This kind of reordering is common.

(3b) Packet Reordering: 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.
     However, since the Internet is engineered to run SCTP reasonably
     well, excessive reordering will not be common and need not be
     handled with optimum efficiency.

(4)  Processing delay: The scheme must not contribute significantly to
     system delay budget.



3.5.  Capability requirements related to link layer characteristics

(1)  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
     channel or feedback is not desirable for other reasons.

(2)  Link delay: Must operate under all expected link delay conditions.

(3)  Header compression coexistence: The scheme must fit into the ROHC
     framework together with other ROHC profiles



4.  IANA Considerations

A protocol which meets these requirements, e.g., [ROHC], will require
the IANA to assign various numbers. This document by itself, however,
does not require any IANA involvement.



5.  Security Considerations

A protocol specified to meet these requirements, e.g., [ROHC], 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



Schmidt, Tuexen                                                 [Page 6]


Internet Draft           SCTP Header Compression             August 2002


by encrypted protocol header elements. This document by itself, however,
does not add any security risks.



6.  References

[RFC-2960]  R. R. Stewart et al.,"Stream Control Transmission Protocol",
            November 2000.

[ADDIP]     R. R. Stewart et al., "Dynamic Reconfiguration of IP
            Addresses", draft-ietf-tsvwg-addip-sctp-03.txt, November
            2001.

[RFC-1144]  Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
            Serial Links", RFC 1144, February 1990.

[RFC-2507]  Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header
            Compression", RFC 2507, February 1999.

[RFC-3096]  Mikael Degermark, "Requirements for IP/UDP/RTP header
            compression", RFC 3096, July 2001.

[TCPREQ]    Lars-Erik Jonsson, "Requirements for ROHC IP/TCP
            Compression", draft-ietf-rohc-tcp-requirements-02.txt,
            November 2001.



7.  Authors' Addresses


Christian Schmidt             Tel.:   +49 89 722 27822
Siemens AG                    e-mail: Christian.Schmidt@icn.siemens.de
Hofmannstrasse 51
D-81359 Munich
Germany


Michael Tuexen                Tel.:   +49 89 722 47210
Siemens AG                    e-mail: Michael.Tuexen@icn.siemens.de
Hofmannstrasse 51
D-81359 Munich
Germany







Schmidt, Tuexen                                                 [Page 7]


Internet Draft           SCTP Header Compression             August 2002


              This Internet Draft expires August 20, 2002.


















































Schmidt, Tuexen                                                 [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/