RoHC
Network Working Group                                        Ch. Schmidt
INTERNET DRAFT
Internet-Draft                                                 M. Tuexen
Expires: February 18, 2003                                    Siemens
Expires AG
                                                         August 20, 2002                                February 20, 2002

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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026]. 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.

   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 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 http://
   www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on February 18, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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

Table of this document to initiate discussion on Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Header compression requirements for  . . . . . . . . . . . . . . .  4
   2.1 Impact on Internet infrastructure  . . . . . . . . . . . . . .  4
   2.2 Supported headers  . . . . . . . . . . . . . . . . . . . . . .  4
   2.3 SCTP compression in ROHC.

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

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

2. 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

1. 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. 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

   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. compression
   [5].

2. 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 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.

2.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.

2.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.

(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.

2.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)

   Streams:

      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  In case of
     robust header compression. Consider, for example, a packet loss at the following
     sequence of packets (SID - Stream Identifier, SSN - Stream Sequence
     Number):

     Packet compressed
      link, two cases have to be differentiated:

      Case 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 verification of the decompressor recognizes a
     fault in decompressing packet 3, packet 3 would decompression via CRC compression
         checksum went well.  In this case, uncompressed SCTP packets
         will be discarded. Data
     from both stream 0 forwarded and stream 1 are affected. Without header
     compression, the loss SCTP endpoints will take care about
         multi-streaming functionality.

      Case 2: The verification of packet 2 would influence only data in
     stream 0.

     Assuming that packet 2 is lost and a the decompression fault via CRC compression
         checksum fails.  In this case, the release of the related SCTP
         packet
     3 can be restricted could influence unrelated streams as well.  The only way
         to avoid this would be the first data chunk generation of packet 3 (stream 0),
     the decompressor could generate a new SCTP packet containing only by
         the decompressor (without the second data chunk of packet 3 (stream 1) chunks from the involved
         stream) - this would violate in violation to the transparency transport
         requirement. This should not be done.

      The compression scheme stream 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)

   Extensions:

      SCTP extensions as described in [ADDIP] ADDIP [2] and PRSCTP [3] 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)

   Extendibility:

      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.

2.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.

(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.

2.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. profiles.

3. IANA Considerations

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

5.

4. Security Considerations

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

6.

References

[RFC-2960]  R. R. Stewart et al.,"Stream

   [1]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
        "Stream Control Transmission Protocol",
            November RFC 2960, October 2000.

[ADDIP]     R.

   [2]  Stewart, R., "Stream Control Transmission Protocol (SCTP)
        Dynamic Address  Reconfiguration", draft-ietf-tsvwg-addip-sctp-
        05 (work in progress), May 2002.

   [3]  Ramalho, M. and 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 Stewart, "SCTP Partial Reliability
        Extension", draft-stewart-tsvwg-prsctp-01 (work in progress),
        July 2002.

   [4]  Degermark, M., "Requirements for robust IP/UDP/RTP header
        compression", RFC 3096, July 2001.

[TCPREQ]    Lars-Erik

   [5]  Jonsson, L., "Requirements for ROHC IP/TCP Header Compression", draft-ietf-rohc-tcp-requirements-02.txt,
            November 2001.

7.
        draft-ietf-rohc-tcp-requirements-04 (work in progress), May
        2002.

Authors' Addresses

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

Michael Tuexen                Tel.:

   Phone: +49 89 722 47210 27822
   EMail: Christian.Schmidt@icn.siemens.de

   Michael Tuexen
   Siemens AG                    e-mail: Michael.Tuexen@icn.siemens.de
Hofmannstrasse
   Hofmannstr. 51
D-81359
   81359 Munich
   Germany

   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 Draft expires August 20, 2002. Society.