Network Working Group Lars-Erik Jonsson, Ericsson (editor) INTERNET-DRAFT Expires: November 2001 Thinh Nguyenphu, Nokia Raymond Hsu, Qualcomm Wayne Bowen, Motorola Rajesh Bhalla, Cisco Mark Lipford, Sprint Tom Hiller, Lucent May 1, 2001 3GPP2 Requirements for 0-byte ROHC IP/UDP/RTP Header Compression 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document contains requirements from 3GPP2 TSG-P on a zero-byte IP/UDP/RTP header compression scheme and should be seen as an input to the work of defining an official document with zero-byte requirements within the ROHC WG. Jonsson (ed.) [Page 1] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 0. Document history March 15, 2001 - 00x Initial and non-official (as an Internet Draft) version of this document as an input from 3GPP2 TSG-P. Distributed over the ROHC WG mailing list prior to 50th IETF in Minneapolis. March 29, 2001 - 00 First official draft. Modified abstract and introduction clearly stating that this is a 3GPP2 input to the work to be done in ROHC. A fifth section of chapter 2 has been added addressing 3GPP2 specific concerns. April 18, 2001 û 01 Updated version with minor corrections and modifications to various parts of the draft. May 1, 2001 - 02 Wording in section 2.3:3 changed to be consistent with [RTR-REQ]. This release is expected to be the final version of this input document from the 3GPP2 community. 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 roundtrip 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 roundtrip times. To provide spectrum efficiency for already deployed speech codecs over existing link technologies, the regular ROHC RTP [ROHC] scheme do not perform well enough and 0-byte header compression is needed. Creation of a 0-byte header compression scheme may seem to be an unsolvable task if the problem is studied from a traditional header compression point of view. However, it has been shown that if certain interaction between the header compression entities and the lower layers is allowed, 0-byte compression is possible to a large extent. Some header compression functionality is in these cases provided by the lower layers, reducing the need for compressed header information and making it possible to completely eliminating the compressed header for most of the packets. Jonsson (ed.) [Page 2] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 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 concerns what kind of headers that must be compressed efficiently. The third and forth groups concern performance requirements and requirements related to link and system issues. Finally, the fifth group includes some 3GPP2 specific concerns and comments. Requirements marked with (*) are identical to the corresponding ROHC RTP requirements in [RTP-REQ]. 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. 2. Ubiquity(*): Must not require modifications to existing IP (v4 or v6) UDP or RTP implementations. Justification: Ease of deployment. Note: The ROHC WG may recommend changes that would increase the compression efficiency for the RTP streams emitted by implementations. However, ROHC cannot rely on such recommendations being followed. 2.2. Supported headers and kinds of RTP streams 1. IPv4 and IPv6(*): Must support both IPv4 and IPv6. 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. Jonsson (ed.) [Page 3] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 2.3. Performance issues 1. Performance/Spectral Efficiency: Must provide low relative overhead under expected operating conditions. Performance should be such that 0-byte header packets are used most of the time to maximize spectral efficiency. Justification: Spectrum efficiency is a primary goal. Studies has shown that for certain speech codecs and link technologies, even a single octet of header may result in a 15-30% decrease in spectrum efficiency compared to existing circuit switched solutions. Note: the relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead. 2. Error propagation(*): 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. Justification: Error propagation reduces spectral efficiency and reduces quality. Note: There are at least two kinds of error propagation; loss propagation, where an error causes subsequent headers to be lost, and damage propagation, where an error causes subsequent headers to be damaged. 3a. Moderate Packet Misordering(*): The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor. Justification: This kind of reordering is common. 3b. Packet Misordering(*): The scheme should be able to compress when there are misordered packets in the RTP stream reaching the compressor. No misordering is expected on the link between compressor and decompressor Justification: Misordering happens regularly in the Internet. However, since the Internet is engineered to run TCP reasonably well, excessive misordering 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. Jonsson (ed.) [Page 4] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 5. Algorithm delay: The scheme should not noticeably add to the end- to-end delay. Justification: RTP packets carrying data for interactive voice or video have a limited end-to-end delay budget. Note: This requirement is intended to prevent schemes that achieve robustness at the expense of delay, for example schemes that require that header i+x, x>0, is received before header i can be decompressed. 6. Multiple links(*): The scheme must perform well when there are two or more cellular links in the end-to-end path. Justification: Such paths will occur. Note: Loss on previous links will cause irregularities in the RTP stream reaching the compressor. Such irregularities should only marginally affect performance. 2.4. Requirements related to link layer and system concerns 1. Configurable frame size fluctuation(*): It should be possible to restrict the number of different frame sizes used by the scheme. Justification: Some radio technologies support only a limited number of frame sizes efficiently. Note: Somewhat degraded performance is to be expected when such restrictions are applied. Note: This implies that a list of "desirable" frame sizes must be made available and that ROHC may pick a suitable header format to utilize available space as well as possible. 2. Header compression coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles Justification: Implementation simplicity is an important issue and therefore should the 0-byte compression scheme has as much as possible in common with the IP/UDP/RTP profile. Jonsson (ed.) [Page 5] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 3. Handover: Using header compression must not introduce any additional degradation at handoff, when compared to existing circuit switched operation. By degradation, it is meant that the header compression process must not introduce erroneous headers or packet loss during the handoff process. This must be true regardless of whether the handoff involves context relocation or not. Loss of compression efficiency shall be minimized during handoff. Justification: Such events can be frequent in cellular systems where the compressor/decompressor on the network side is close to the radio base stations. Soft and Hard handoffs for 0-byte header compression must be supported the same as current SMV and EVRC circuit calls are supported for hard and soft handoff. Definitions of hard and soft handoff can be found in IS2000.2. Note: In order to aid developers of context recreation schemes where context is transferred to the new node, the specification shall outline what parts of the context is to be transferred, as well as conditions for its use. Procedures for context recreation (and discard) without such context transfer will also be provided. 4. Residual errors(*): For a residual bit-error rate of at most 1e-5, the ROHC scheme must not increase the error rate. Justification: Some target links have a residual error rate, i.e., rate of undetected errors, of this magnitude. Note: In the presence of residual bit-errors, ROHC will need error detection mechanisms to prevent damage propagation. These mechanisms will catch some residual errors, but those not caught might cause damage propagation. This requirement states that the reduction of the damage rate due to the error detection mechanisms must not be less than the increase in error rate due to damage propagation. Jonsson (ed.) [Page 6] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 2.5. 3GPP2 specific requirements and notes 1. Speech vocoder support: An implementation of the 0-byte scheme in CDMA2000 must be able to optimally support the EVRC and SMV speech vocoders. Justification: Since these are the two primary forms of vocoders that are supported in cdma2000, the solution must work well with these vocoder technologies. 2. Legacy voice over IP: In 3GPP2, a legacy voice over IP model has been outlined in addition to the true voice over IP model. The purpose of the legacy model is to make simple voice over IP terminals available based on legacy hardware. To support this model, 3GPP2 will standardize transport mechanisms for the speech data reusing parts of the transparent 0-byte compression scheme (almost identical network side implementation). The 0-byte scheme should in no way prevent 3GPP2 from reusing and redefining it for the legacy model. Justification: The legacy model will be supported in 3GPP2 and it would be beneficial from a complexity point of view that the transparent 0-byte scheme, to be implemented anyway on the network side, could be mostly reused also for the legacy model. 3. References [RFC-791] Jon Postel, Internet Protocol, RFC 791, September 1981. [RFC-768] Jon Postel, User Datagram Protocol, RFC 768, August 1980. [RTP-REQ] Mikael Degermark, "Requirements for IP/UDP/RTP Header Compression", RFC 3096, March 2001. [ROHC] C. Bormann, "Robust Header Compression (ROHC)", RFC 3095, March 2001. Jonsson (ed.) [Page 7] INTERNET-DRAFT 3GPP2 Requirements for 0-byte ROHC RTP May 1, 2001 4. Author's addresses Lars-Erik Jonsson (ed.) Tel: +46 (920) 20 21 07 Ericsson Erisoft AB Fax: +46 (920) 20 20 99 Box 920 SE-971 28 Lulea Sweden E-mail: lars-erik.jonsson@ericsson.com Thinh Nguyenphu Tel: +1 (972) 894 5189 Nokia Fax: 6000 Connection Dr. Irving, TX 75039 USA E-mail: thinh.nguyenphu@nokia.com Raymond Hsu Tel: +1 (858) 651 3623 Qualcomm Incorporated 5775 Morehouse Dr. San Diego, CA 92121 USA E-mail: rhsu@qualcomm.com Wayne Bowen Tel: +1 (847) 435 5912 Motorola 1421 Shure Dr. Arlington Heights, IL 60004 USA E-mail: fbowen1@enmail.mot.com Rajesh Bhalla Tel: +1 (408) 853 9265 Cisco Systems Inc. Fax: +1 (408) 853 0406 170 West Tasman Drive San Jose, CA 95134 USA E-mail: rabhalla@cisco.com Mark Lipford Tel: +1 (913) 890 4248 Sprint PCS Fax: +1 (913) 890 4100 15405 College Blvd. Lenexa, KS 66219 E-mail: mlipfo01@sprintspectrum.com Tom Hiller Tel: +1 (630) 979 7673 Lucent Technologies Fax: +1 (630) 979 7673 263 Shuman Dr. Naperville, IL 60566 USA E-mail: tom.hiller@lucent.com This Internet-Draft expires November 1, 2001. Jonsson (ed.) [Page 8]