Network Working Group Ghyslain Pelletier, Ericsson INTERNET-DRAFT Sweden Expires: November, 2001 May 6, 2001 Link-Layer Assisted ROHC Over CDMA2000 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 defines implementation specifications and guidelines for the Link-Layer Assisted ROHC profile [LLAROHC] over CDMA2000 cellular links. The purpose of this document is to apply this profile for efficient, transparent and robust header compression while using the CDMA2000 link layer characteristics optimally. Its objective is to remain flexible with regards to robustness, complexity and spectral efficiency considerations. In addition to [LLAROHC] it defines logic, parameters and procedures for the use of header-free packets over CDMA2000 links. Pelletier [Page 1] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 Table of contents 1. Introduction....................................................2 2. Terminology..................................................... 3. Overview of the link-layer assisted profile over CDMA2000 links. 3.1. CDMA2000 system overview..................................... 3.1.1. CDMA2000 architecture overview....................... 3.1.2. CDMA2000 link layer characteristics.................. 3.1.3. Typical CDMA2000 voice encoder rates................. 3.2. Functionality provided by the link layer to LLAROHC......... 4. Link-Layer Assisted ROHC over CDMA2000 links..................... 4.1. Operating assumptions....................................... 4.2. Architecture overview....................................... 4.3. Initialization.............................................. 4.3.1. Header Compression Setup.. ........................... 4.3.2. Context IDentifiers (CID) ............................ 4.3.3. Packet sizes.......................................... 4.3.4. Padding............................................... 4.4. LLA MAC logic at the compressor side........................ 4.4.1. Reception of packets from the LLAROHC RTP compressor.. 4.4.2. Sending the NHP packet................................ 4.4.3. Sending the RHP packet................................ 4.4.4. Sending the CCP packet................................ 4.4.5. Assembling the packet for delivery.................... 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED......... 4.4.7. Handling of ROHC segmented packets.................... 4.4.8. False sequence detection for NHP packets.............. 4.4.9. Delayed packet reception.............................. 4.4.10.Congestion handling................................... 4.5. LLA MAC logic at the decompressor side...................... 5. Implementation Guidelines....................................... 5.1. Periodic context validation and speech bursts .............. 6. Security considerations......................................... 7. Acknowledgements................................................ 8. References...................................................... 9. Author's addresses.............................................. Pelletier [Page 2] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 1. Introduction Header compression is a technique to compress and transparently decompress the header information of a packet on a per-hop basis. Several efforts have been made to improve efficiency over bottleneck wired links [VJHC, IPHC] as well as over low bandwidth wireless links with high error rates [ROHC]. Existing air interfaces such as GSM and IS-95 will be used in all-IP networks, adding new implications to the header compression issue. These air interfaces are less flexible with radio bearers optimized for specific payload sizes. This means that not even a single octet of header can be added without using the next higher fixed packet size of the link and this is obviously very costly. For the already deployed speech vocoders, the spectrum efficiency over these links will thus be low compared to the existing circuit switched solutions. For deployment reasons, it is important to also achieve efficiency with these already existing vocoders and air interfaces, such as GSM and IS-95, with minimal effects on spectral efficiency. To this purpose was the Link-Layer Assisted ROHC profile (LLAROHC) proposed. [LLAROHC], extending the ROHC RTP profile, allows the sending of header-free packets when the link layer can provide in-order delivery, packet loss detection and packet type identification. It puts additional requirements on the lower layer to allow the decompressor to infer some of the information needed to maintain robust and transparent header compression. This is possible because of the nature of the synchronized radio bearer. LLAROHC also specifies interfaces between the ROHC component towards the lower layer at both ends of the transmission link. Finally, it describes methods to compress headers so that during most of the normal operation only header-free packets are transmitted over the air interface. These header-free packet account for most of the traffic. The Link-Layer Assisted ROHC profile does not provide link layer specifications. The purpose of this document is to specify how to implement the LLAROHC profile over CDMA2000 links. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. BER Bit Error Rate BSC Base Station Controller CCP Context Check Packet as defined in [LLAROHC] CRC Cyclic Redundancy Check Pelletier [Page 3] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 ECCP Extended CCP as defined in [LLAROHC] HC Header Compressor HD Header Decompressor LCP PPP Link Control Protocol (defined in RFC 1661) LLA MAC LLAROHC adaptation to the CDMA2000 MAC layer LLAROHC Link Layer Assisted ROHC profile MAC Media Access Control MSB Most Significant Bit MN Mobile Node NHP No Header Packet NCP PPP Network Control Protocol (defined in RFC 1661) PDSN Packet Data Serving Node PDU Protocol Data Unit PL Physical Link PPP Point-to-Point Protocol (RFC1661) RHP ROHC Header Packet (either a CCP or a RRP packet) ROHC RObust Header Compression RRP ROHC RTP Packet as defined in [ROHC, profile 1] VoIP End-to-end Voice over IP ROHC RTP ROHC RTP in this document refers to the IP/UDP/RTP profile as defined in [ROHC]. 3. Overview of the Link-Layer Assisted profile over CDMA2000 links The Link-Layer Assisted ROHC profile is a generic scheme applicable to any link providing the necessary functionality for the use of header-free packets in an efficient, transparent and robust way as described in [LLAROHC]. This document specifies how to implement this scheme over CDMA2000 links according to the LLAROHC profile. The following sections introduce the relevant architectural and operational characteristics of the CDMA2000 system before providing an overview of the general ideas behind implementation specifications and guidelines for use of LLAROHC in the system. 3.1. CDMA2000 system overview This section provides a simplified overview of the CDMA2000 system and its characteristics relevant to header compression. 3.1.1 CDMA2000 architecture overview Figure 1 shows the protocol stack view of the IP traffic path in the CDMA2000 system with a LLAROHC header compression implementation. As shown in figure 1, within a CDMA2000 system it cannot be assumed that the ROHC RTP implementation will be physically co-located with Pelletier [Page 4] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 the synchronous radio bearer implementation, i.e. it must be assumed that the base station is remote from the ROHC RTP compressor. This has significant implications on the introduction of a header compression system that makes specific use of the properties of the synchronized bearer. The module implemented close to the synchronous bearer will be referred to as the LLA MAC, i.e. the LLAROHC to CDMA2000 MAC layer adaptation module. MN BSC PDSN +-------------+ +-----+ | RTP | | RTP | +-------------+ +-----+ | UDP | | UDP | +-------------+ +---------------------+ +-----+ | IP | | IP | | IP | +-------------+ +--------------++-----+ +-----+ | ROHC RTP | | ROHC RTP || | | | +-------------+ +--------------+| | | | | LLAROHC | | LLAROHC || | | | +-------------+ +--------------+| | | | | LLACDMA2K | | LLACDMA2K ||LINK | |LINK | +-------------+ +---------------+ +--------------+| | | | | PPP| NO PPP | | RELAY | | PPP| NO PPP ||LAYER| |LAYER| +-------------+ +----------++---+ +--------------+| | | | | LLA MAC | | LLA MAC ||GRE| | GRE || | | | +-------------+ +----------++---+ +--------------+| | | | | MAC | | MAC ||IP | | IP || | | | +-------------+ +----------++---+ +--------------++-----+ +-----+ | AIR LINK |==| AIR LINK ||PL |==|PHYSICAL LINK || PL |==| PL | +-------------+ +----------++---+ +--------------++-----+ +-----+ Fig.1: Stack view of IP traffic path in CDMA2000 system with LLAROHC LLACDMA2K represents the additional functionality required within the LLAROHC RTP implementation, while the LLA MAC contains most of the functionality specific to the LLAROHC implementation for CDMA2000. 3.1.2. CDMA2000 link layer characteristics The channel used in CDMA2000 for circuit-switched voice traffic is characterized by: - No link layer retransmissions - High priority channel - BER (1%) - Fixed frame sizes (16, 40, 80 and 171 bits) - Synchronized channel, 20ms time intervals Pelletier [Page 5] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 The most relevant characteristics to the design of the LLAROHC profile over CDMA2000 are the fixed frame sizes together with the synchronized and non-retransmitting nature of the physical channel. 3.1.3 Typical CDMA2000 voice encoder rates Typical CDMA2000 voice encoders have been designed to transmit small payloads during most of the speech connection. The following table present the typical payload sizes generated: Rate Activity % Payload size (bits) Full 20 171 Half 20 80 Quarter 10 40 Eighth 50 16 Table 1: Frame size distribution for a typical vocoder in CDMA2000 From the table, the most frequent transition introduced by the need to send extra octets will likely happen between the eight rate (from 16 bits payload) and the quarter rate (to 40 bits payload). Noteworthy for the LLAROHC for CDMA2000 implementation is that the rate of the encoders matches the frame rate, or PDU sizes, at the physical level. 3.2. Functionality provided by the link layer to LLAROHC [LLAROHC] states the functionality to be provided by the link layer to the LLAROHC implementation to allow packet type identification, replacement of the sequence number and replacement of the CRC. Packet type identification may be provided through the use of a leading sequence which consist of already existing ROHC padding. Although this approach implies some additional overhead, the need for a leading sequence is constrained to the RRP packet type, which is deemed to be used very seldom in comparison to the NHP traffic during a typical VoIP connection. Furthermore, there is currently no other identified alternate mechanism within the CDMA2000 system to provide this functionality. The sequence number is replaced by packet loss detection at the MAC layer under the ROHC decompressor through the interface specified in [LLAROHC section 4.4]. This is done by using explicit detection of damaged packets over the physical medium from the link layer and through the use of the CCP packet as an indication of packet loss before the compressor. The CRC functionality is replaced by this same packet loss detection coupled with the fact that no errors can damage a header which is not Pelletier [Page 6] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 sent for the case where header-free packets are used. However, to detect also unexpected errors, periodical context checks should also be performed. 4. Link-Layer Assisted ROHC over CDMA2000 links This section describe the implementation specifications to support the LLAROHC profile in the CDMA2000 system. 4.1. Operating assumptions CDMA2000 systems have special characteristics from which we derive the following assumptions, in addition to those described in [ROHC] and [LLAROHC]. Reordering If present, it is assumed that the channel between the ROHC compressor and the LLA MAC may reorder packets (i.e., there is no assumption that the LLA MAC will receive packets in order). Note that out-of-order delivery will have an impact on the compression efficiency of the LLA ROHC profile and should be minimized. Reliability If present, the channel between the ROHC compressor and the LLA MAC is not assumed to be reliable. Packet losses may therefore occur on this channel, but residual bit error rates should be negligible. On-time delivery is not assumed either although expected (i.e., some packets may be delayed so that they are late for transmission over the air I interface). Note that packet losses will have an impact on the compression efficiency of the LLAROHC profile and should obviously be minimized. Duplication If present, it is assumed that a channel between the ROHC compressor and the LLA MAC may duplicate packets (i.e., there is no assumption that the LLA MAC will receive only one copy of the same packet), although duplicates are expected to be handled by the channel itself. The handling of possible duplicates is left to implementations. Link layer channel The channel used to transport header compression traffic is assumed to not introduce any additional overhead, for example for reliability or for any link layer framing additional to the one already present at the physical layer. Pelletier [Page 7] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 4.2. Architecture overview In [LLAROCH section 4.3], a generic interface between the LLAROHC RTP compressor and the lower layer is specified. The CDMA2000 link layer does not currently provide all the functionality needed to fulfill this specification. New functionality, represented by the LLA MAC, is therefore necessary and is here described in [section 4.4]. It uses the available functionality from the CDMA2000 MAC layer and may be implemented together with the LLAROHC compressor as a single entity, although this is not required and not always possible in all CDMA2000 systems. Similarly, [LLAROCH section 4.4] describes a generic interface between the lower layers and the LLAROHC RTP decompressor. The necessary functionality is also here described in [section 4.5]. It should be implemented together with the ROHC decompressor as a single entity to minimize complexity within a mobile terminal. | | + + +---------------------+ +---------------------+ [ROHC RTP] | ROHC RTP HC | | ROHC RTP HC | +---------------------+ +---------------------+ [LLAROCH] | LLAROHC Profile | | LLAROHC Profile | +=====================+ +=====================+ [LLAROCH] | ROHC-LL | | LL-ROHC | [this] | interface | | interface | +=====================+ +=====================+ [this] | LLA MAC | | LLA MAC | | implementation | | implementation | +---------------------+ +---------------------+ | CDMA2000 MAC Layer | | CDMA2000 MAC Layer | +=====================+ +=====================+ | | +------>---- CHANNEL ---->-----+ Fig.2: Overview of the LLAROHC over CDMA2000 implementation Figure 2 shows the various components needed for an implementation of the LLAROHC profile in CDMA2000. It is separated into layers as defined in [ROHC RTP], [LLAROCH] and this document [this]. 4.3. Initialization This section describes profile specific initialization steps for the LLAROHC instances. This section also specifies how parameters are set. 4.3.1 Header Compression Setup [PPP] may be used for the negotiation of ROHC parameters over the Pelletier [Page 8] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 connection setup for header compression. Initialization of ROHC per channel parameters may be done as described in [ROHC section 5.1.1] and [ROHC PPP]. Once the LLAROHC profile has been identified by the compressor and the decompressor, profile specific parameters must be set using ROHC IR packets over the channel which is assumed not to introduce any overhead. The physical establishment and release of the connection used for header compression traffic is outside the scope of this document. 4.3.2. Context Identifiers (CID) The connection for LLAROHC traffic MUST be configured using SMALL CIDS and CID=0 MUST be reserved for LLAROHC traffic. This is necessary to omit the CID field in the ROHC header and still allow identification of the NHP packets. 4.3.3. Packet sizes The PREFERRED PACKET_SIZES parameter MUST be set according to the CDMA2000 link fixed frame sizes, i.e. the list provided MUST be [16,40,80,168,176] and 176 MUST be for NHP packets only. The size of 168 may be produced by the LLAROHC compressor from a typical CDMA2000 codec [EVRC RTP] operating at a speech rate smaller than the full rate (< 171 bits) and the presence of the IP/UDP/RTP compressed header. The size of 176 may be produced for the case of the codec operating at full rate where 5 padding bits are added to obtain octet alignment. This will only be delivered as an NHP packet by the LLAROHC compressor. The LARGE_PACKET_ALLOWED parameter MAY be set to true if large packets with headers are to be treated according to [section 4.4.6]. The resulting effect will be that proper context will be maintained at the decompressor to the expense of dropping the packet. The LARGE_PACKET_ALLOWED parameter MAY be set to false and packets larger than the maximum size specified using the PREFERED PACKET SIZES [LLAROHC, section 5.1.1] parameter will be transmitted as segmented packets according to [section 4.4.7]. These packets will be delivered as segmented ROHC packets. 4.3.4. Padding The ALWAYS_PAD parameter MUST be set in order to request that all RHP packets be padded. A CDMA2000 LLA MAC implementation uses one or more octets as the leading sequence to identify RHP packets. Padding does not introduce new complexity since it is already part of any ROHC RTP implementation [ROHC section 5.2]. Pelletier [Page 9] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 4.4. LLA MAC logic at the compressor side This section describes the logic to be used inside the implementation of the LLA MAC module on the compressor side. This module receives parameters from the ROHC RTP compressor as stated in [LLAROHC section 4.3]. It always receive an RHP with an indication of segmentation, a CCP, an RTP Sequence Number and possibly an NHP. Because the presence or absence of the NHP packet is part of the logic at the LLA MAC, all parameters corresponding to the same packet to be transmitted MUST be ignored at the LLA MAC until they are all received reliably, as described in [section 4.6]. 4.4.1. Reception of packets from LLAROHC RTP header compressor The following steps MUST be performed by the LLA MAC upon reception of a packet delivery from the ROHC header compressor: a. Keep a copy of CCP and RTP SN The LLA MAC MUST always keep a copy of the received CCP with the corresponding RTP Sequence Number. b. Decide which packet needs to be sent If the Context Check Counter is starved, an RHP packet SHOULD be sent according to [section 4.4.3], otherwise refer to section [LLAROHC Section 4.3]. 4.4.2. Sending the NHP packet If it was determined that the NHP packet should be sent, then the following MUST be performed: a. Check for false Leading Sequence according to [section 4.4.8] b. Assemble the packet according to [section 4.4.5] c. Decrement the Context Check Counter Note that if any of these operations determine that an RHP packet must be sent, then the subsequent operation(s) MUST NOT be performed. 4.4.3. Sending the RHP packet If it was determined that the RHP packet will be sent, then the following MUST be performed: a. Verification of RHP segmentation indicator If an indication of segmentation for the RHP packet was received, then the segmented packet is sent as described in [section 4.4.7]. Otherwise, the packet is assembled according to [section 4.4.5]. Pelletier [Page 10] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 b. Reset the Context Check Counter 4.4.4. Sending the CCP packet If it was determined that the CCP packet will be sent, then the following MUST be performed: a. Set the repair (R) bit The R bit is set to R=0 for the CCP. The R bit is set to R=1 when using the extended CCP (ECCP) format. Note that the ECCP contains repair information by carrying fields which will maintain proper context at the decompressor, as described in [LLAROHC]. b. Assemble the packet This is done according to section 4.4.5. As the CCP and its extended format is an RHP packet, a leading sequence will be added during assembly to allow the LLA MAC module at the decompressor side to detect the presence of the header. Because codecs may generate valid 16 bits payload sent as NHP and because of the risk of collision with the leading sequence [section 4.4.8] or the packet type octet, this unfortunately forces a rate transition when sending a CCP packet. It is noted that CDMA2000 defines an empty frame when no speech data is available for sending. This frame is referred to as a filler frame and has a size of 16 bits, all bits set to 1. As LLAROHC requires that no extra packet be artificially inserted by the lower layers in the header compression flow, the LLA MAC implementation will make a CCP packet available to prevent the generation of a filler frame as stated in [section 4.4.9]. c. Reset the Context Check Counter 4.4.5. Assembling the packet for delivery If the packet cannot fit is larger MAX_SIZE_ALLOWED, packets are handled as described in [section 4.4.6]. If the packet delivered is of size 168 bits [section 4.3.3], the packet must be padded to fit the physical frame size of 171 bits. In the case where the packet delivered is of size 176 bits [section 4.3.3], then it must be stripped of the last 5 padding bits to fit the physical frame of 171 bits. Otherwise the packet already matches one of the possible physical frame size and is sent directly. Pelletier [Page 11] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 4.4.6. Handling packets larger than MAX_SIZE_ALLOWED In the case where the calculation of the packet size to be transmitted is larger than the maximum size of a physical frame, the implementation must decide between the two following options: a. Segment the packet using ROHC segmentation This is done according to [section 4.4.7]. b. Discard the packet and send the extended CCP (ECCP) The packet for which the calculation of the size was made is discarded and the ECCP is sent according to [section 4.4.4]. Note that this will readily repair the context at the decompressor according to [LLAROHC] after detection of the packet loss signaled by the reception of the ECCP itself. These two alternatives represent a tradeoff between robustness and spectral efficiency respectively. 4.4.7. Handling of ROHC segmented packets In the case where the RHP packet is to be sent and was delivered as a segmented ROHC packet, an implementation MUST handle the resulting congestion as defined in [section 4.4.10]. 4.4.8. False sequence detection for NHP packets The false sequence problem, defined as the case where the payload to be sent as an NHP coincidentally begins with the same bit pattern as the defined leading sequence, MUST be detected since it will impair efficiency by having the decompressor treat this packet as a packet with a ROHC header. This is to prevent the payload of such a packet to be used as with a corrupted reduced version of the RTP payload. This payload would then be passed to the application. The first bits of the NHP payload MUST be examined prior to transmission. If the pattern matches the ROHC padding and therefore could be interpreted by the receiving end as a false leading sequence than the NHP MUST not be sent and an RHP MUST be sent instead. 4.4.9. Delayed packet reception In the event where no packets are received from the ROHC compressor on time for transmission, this is handled by sending the CCP packet of the previous packet sent which was kept by the LLA MAC instance. The CCP is sent according to [section 4.4.4] and will prevent the artificial insertion of new packets by the link layer. Pelletier [Page 12] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 The CCP, and its extended ECCP format, MUST be interpreted as a packet loss by the LLA MAC at the compressor side. 4.4.10. Congestion handling Packet dropping might be needed to transmit a segmented ROHC packet. The following MAY be performed: a. The first segment is assembled and transmitted according to [section 4.4.5]. b. Remaining segment(s) is transmitted over the same connection in subsequent time interval(s) according to [section 4.4.5], while the packet delivered by the ROHC compressor corresponding to this time slot is be discarded. 4.5. LLA MAC logic at the decompressor side This section describes the logic inside the implementation of the LLA MAC module at the decompressor side. This module receives the packet transmitted over the air interface from the CDMA2000 link layer and delivers the following information to the ROHC HC [LLAROHC section 4.4]: the packet received with an indication of the presence of a header or an indication of packet loss together with explicit sequence number [section 4.7]. Upon reception of a packet, the LLA MAC module MUST perform the following operations: a. Determination of the presence of a header As ROHC padding is used as leading sequence, the first bits of the packet received are examined to determine if a leading sequence is present. If present, the indicator for the presence of a header MUST be set. b. Determination of packet loss The indicator of packet loss MUST be set if the packet received contains a header and the packet type is CCP or ECCP, or upon explicit notification from the physical link layer that the packet was damaged. c. Delivery of the packet and other parameters to the ROHC HD This is done according to the interface specified in [LLAROHC section 4.4] It is considered optional to remove the padding at the LLA MAC. Delivery of the packet with or without the padding will be properly handled by the ROHC decompressor. Pelletier [Page 13] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 Optionally, an implementation SHOULD combine the LLA MAC with the ROHC implementation to reduce complexity whenever possible. 5. Implementation Guidelines 5.1. Periodic context validation and speech bursts Implementations MAY delay a periodic context validation during a speech burst, i.e. during a full-rate NHP train, if it is not possible to transmit the RHP packet over the connection. There SHOULD be a maximum limit of [to be defined later] for which this validation may be delayed and the RHP SHOULD be sent as soon as possible. 6. Security considerations The security considerations of ROHC RTP [ROHC section 7] and of the Link-Layer Assisted ROHC profile [LLAROHC] also apply to this document. 7. Acknowledgements The authors would like to thank Ulises Olvera-Hernandez, Francis Lupien for their input regarding the CDMA2000 standards and Lars-Erik Jonsson, Krister Svanbro for their input regarding header compression issues. 8. References [LLAROHC] L. Jonsson, G. Pelletier, "A Link-Layer Assisted ROHC Profile for IP/UDP/RTP", February 2001, [ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet draft (work in progress), January 2001, [VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro, Pelletier [Page 14] INTERNET-DRAFT Link-Layer Assisted ROHC Over CDMA2000 May 6, 2001 "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, August 2000. [RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header Compression", Internet draft (work in progress), November 2000. [ROCCO] L.-E. Jonsson, M. Degermark, H. Hannu, K. Svanbro, "RObust Checksum-based header COmpression (ROCCO)", Internet draft (work in progress), June 2000. [IP] J. Postel, "Internet Protocol", RFC 791, September 1981. [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [UDP] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [TCP] J. Postel, "Transmission Control Protocol", RFC 793, September 1981. [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [ROHC PPP] C. Bormann, "ROHC over PPP", March 2001, . [EVRC RTP] A. Li, "An RTP Payload Format for EVRC Speech",(work in progress), April 2001 . 9. Author's addresses Ghyslain Pelletier Tel: +46 920 20 24 32 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 SE-971 28 Lulea Sweden EMail: ghyslain.pelletier@epl.ericsson.se This Internet-Draft expires November 4, 2001 Pelletier [Page 15]